ការពិសោធន៍សាកល្បងការអនុវត្តនៃក្រាហ្វ JanusGraph DBMS សម្រាប់ដោះស្រាយបញ្ហានៃការស្វែងរកផ្លូវសមរម្យ

សួស្តី​អ្នក​ទាំងអស់គ្នា។ យើងកំពុងបង្កើតផលិតផលសម្រាប់ការវិភាគចរាចរណ៍ក្រៅបណ្តាញ។ គម្រោងនេះមានភារកិច្ចទាក់ទងនឹងការវិភាគស្ថិតិនៃផ្លូវអ្នកទស្សនានៅទូទាំងតំបន់។

ជាផ្នែកនៃកិច្ចការនេះ អ្នកប្រើប្រាស់អាចសួរសំណួរប្រព័ន្ធនៃប្រភេទខាងក្រោម៖

• តើមានមនុស្សប៉ុន្មាននាក់បានឆ្លងកាត់ពីតំបន់ "A" ទៅតំបន់ "B";
• តើមានមនុស្សប៉ុន្មាននាក់បានឆ្លងកាត់តំបន់ "A" ទៅតំបន់ "B" តាមរយៈតំបន់ "C" ហើយបន្ទាប់មកឆ្លងកាត់តំបន់ "D";
• តើត្រូវចំណាយពេលប៉ុន្មានសម្រាប់ភ្ញៀវទេសចរប្រភេទជាក់លាក់មួយក្នុងការធ្វើដំណើរពីតំបន់ "A" ទៅតំបន់ "B" ។

និងសំណួរវិភាគស្រដៀងគ្នាមួយចំនួន។

ចលនារបស់អ្នកទស្សនានៅទូទាំងតំបន់គឺជាក្រាហ្វដឹកនាំ។ បន្ទាប់ពីអានអ៊ីនធឺណិត ខ្ញុំបានរកឃើញថាក្រាហ្វ DBMS ត្រូវបានប្រើសម្រាប់របាយការណ៍វិភាគផងដែរ។ ខ្ញុំមានបំណងប្រាថ្នាចង់មើលពីរបៀបដែលក្រាហ្វ DBMSs នឹងដោះស្រាយជាមួយនឹងសំណួរបែបនេះ (TL; DR; មិនល្អ) ។

ខ្ញុំបានជ្រើសរើសប្រើ DBMS JanusGraphក្នុងនាមជាអ្នកតំណាងដ៏ឆ្នើមនៃក្រាហ្វិកប្រភពបើកចំហរ DBMS ដែលពឹងផ្អែកលើបណ្តុំនៃបច្ចេកវិទ្យាចាស់ទុំ ដែល (តាមគំនិតរបស់ខ្ញុំ) គួរផ្តល់ឱ្យវានូវលក្ខណៈប្រតិបត្តិការសមរម្យ៖

• ផ្នែកខាងក្រោយផ្ទុក BerkeleyDB, Apache Cassandra, Scylla;
• សន្ទស្សន៍ស្មុគស្មាញអាចត្រូវបានរក្សាទុកនៅក្នុង Lucene, Elasticsearch, Solr ។

អ្នកនិពន្ធនៃ JanusGraph សរសេរថាវាសមរម្យសម្រាប់ទាំង OLTP និង OLAP ។

ខ្ញុំបានធ្វើការជាមួយ BerkeleyDB, Apache Cassandra, Scylla និង ES ហើយផលិតផលទាំងនេះត្រូវបានប្រើប្រាស់ជាញឹកញាប់នៅក្នុងប្រព័ន្ធរបស់យើង ដូច្នេះខ្ញុំមានសុទិដ្ឋិនិយមចំពោះការសាកល្បងក្រាហ្វ DBMS នេះ។ ខ្ញុំបានរកឃើញថាវាជារឿងចម្លែកក្នុងការជ្រើសរើស BerkeleyDB លើ RocksDB ប៉ុន្តែនោះប្រហែលជាដោយសារតែតម្រូវការប្រតិបត្តិការ។ ក្នុងករណីណាក៏ដោយ សម្រាប់ការធ្វើមាត្រដ្ឋាន ការប្រើប្រាស់ផលិតផល វាត្រូវបានស្នើឱ្យប្រើផ្នែកខាងក្រោយនៅលើ Cassandra ឬ Scylla ។

ខ្ញុំមិនបានពិចារណា Neo4j ទេ ពីព្រោះការដាក់ចង្កោមតម្រូវឱ្យមានកំណែពាណិជ្ជកម្ម ពោលគឺផលិតផលមិនមែនជាប្រភពបើកចំហទេ។

ក្រាហ្វ DBMSs និយាយថា "ប្រសិនបើវាមើលទៅដូចជាក្រាហ្វ ចូរចាត់ទុកវាដូចជាក្រាហ្វ!" - សម្រស់!

ដំបូង​ខ្ញុំ​គូរ​ក្រាហ្វ​ដែល​ត្រូវ​បាន​ធ្វើ​ឡើង​យ៉ាង​ពិត​ប្រាកដ​ដោយ​យោង​តាម Canons នៃ​ក្រាហ្វ DBMS៖

មានខ្លឹមសារមួយ។ Zoneទទួលខុសត្រូវលើតំបន់។ ប្រសិនបើ ZoneStep ជាកម្មសិទ្ធិរបស់នេះ។ Zoneបន្ទាប់មកគាត់សំដៅទៅលើវា។ នៅលើខ្លឹមសារ Area, ZoneTrack, Person កុំយកចិត្តទុកដាក់ ពួកវាជាកម្មសិទ្ធិរបស់ដែន និងមិនត្រូវបានចាត់ទុកថាជាផ្នែកមួយនៃការធ្វើតេស្តនោះទេ។ សរុបមក សំណួរស្វែងរកខ្សែសង្វាក់សម្រាប់រចនាសម្ព័ន្ធក្រាហ្វបែបនេះនឹងមើលទៅដូច៖

g.V().hasLabel('Zone').has('id',0).in_()
       .repeat(__.out()).until(__.out().hasLabel('Zone').has('id',19)).count().next()

អ្វីដែលជាភាសារុស្សីគឺដូចនេះ៖ ស្វែងរកតំបន់ដែលមានលេខសម្គាល់ = 0 យកចំនុចកំពូលទាំងអស់ដែលគែមមួយទៅវា (ZoneStep) ឈប់ដោយមិនត្រលប់ក្រោយរហូតដល់អ្នករកឃើញ ZoneSteps ទាំងនោះដែលមានគែមទៅតំបន់ជាមួយ ID=19 រាប់ចំនួនច្រវាក់បែបនេះ។

ខ្ញុំ​មិន​ធ្វើ​ពុត​ជា​ដឹង​ពី​ភាព​ស្មុគស្មាញ​ទាំង​អស់​នៃ​ការ​ស្វែង​រក​នៅ​លើ​ក្រាហ្វ​នោះ​ទេ ប៉ុន្តែ​សំណួរ​នេះ​ត្រូវ​បាន​បង្កើត​ឡើង​ដោយ​ផ្អែក​លើ​សៀវភៅ​នេះ (https://kelvinlawrence.net/book/Gremlin-Graph-Guide.html).

ខ្ញុំបានផ្ទុក 50 ពាន់បទដែលមានប្រវែងពី 3 ទៅ 20 ពិន្ទុទៅក្នុងមូលដ្ឋានទិន្នន័យក្រាហ្វ JanusGraph ដោយប្រើផ្នែកខាងក្រោយរបស់ BerkeleyDB បានបង្កើតលិបិក្រមយោងទៅតាម ភាពជាអ្នកដឹកនាំ.

ស្គ្រីបទាញយក Python៖

from random import random
from time import time

from init import g, graph

if __name__ == '__main__':

    points = []
    max_zones = 19
    zcache = dict()
    for i in range(0, max_zones + 1):
        zcache[i] = g.addV('Zone').property('id', i).next()

    startZ = zcache[0]
    endZ = zcache[max_zones]

    for i in range(0, 10000):

        if not i % 100:
            print(i)

        start = g.addV('ZoneStep').property('time', int(time())).next()
        g.V(start).addE('belongs').to(startZ).iterate()

        while True:
            pt = g.addV('ZoneStep').property('time', int(time())).next()
            end_chain = random()
            if end_chain < 0.3:
                g.V(pt).addE('belongs').to(endZ).iterate()
                g.V(start).addE('goes').to(pt).iterate()
                break
            else:
                zone_id = int(random() * max_zones)
                g.V(pt).addE('belongs').to(zcache[zone_id]).iterate()
                g.V(start).addE('goes').to(pt).iterate()

            start = pt

    count = g.V().count().next()
    print(count)

យើងបានប្រើ VM ដែលមាន 4 cores និង 16 GB RAM នៅលើ SSD ។ JanusGraph ត្រូវបានដាក់ពង្រាយដោយប្រើពាក្យបញ្ជានេះ៖

docker run --name janusgraph -p8182:8182 janusgraph/janusgraph:latest

ក្នុងករណីនេះ ទិន្នន័យ និងលិបិក្រមដែលត្រូវបានប្រើសម្រាប់ការស្វែងរកការផ្គូផ្គងពិតប្រាកដត្រូវបានរក្សាទុកនៅក្នុង BerkeleyDB ។ ដោយ​បាន​អនុវត្ត​សំណើ​ដែល​បាន​ផ្តល់​ឱ្យ​មុន​នេះ ខ្ញុំ​បាន​ទទួល​ពេល​វេលា​ស្មើ​នឹង​រាប់​សិប​វិនាទី។

ដោយដំណើរការស្គ្រីបទាំង 4 ខាងលើស្របគ្នា ខ្ញុំបានគ្រប់គ្រងដើម្បីប្រែក្លាយ DBMS ទៅជាល្ពៅជាមួយនឹងស្ទ្រីម Java stacktraces ដ៏រីករាយ (ហើយយើងទាំងអស់គ្នាចូលចិត្តអាន Java stacktraces) នៅក្នុងកំណត់ហេតុ Docker ។

បន្ទាប់​ពី​បាន​គិត​មួយ​ចំនួន ខ្ញុំ​បាន​សម្រេច​ចិត្ត​សម្រួល​ដ្យាក្រាម​ក្រាហ្វ​ទៅ​ដូច​ខាង​ក្រោម៖

ការសម្រេចថាការស្វែងរកតាមគុណលក្ខណៈអង្គភាពនឹងលឿនជាងការស្វែងរកតាមគែម។ ជាលទ្ធផល សំណើរបស់ខ្ញុំបានប្រែទៅជាដូចខាងក្រោម៖

g.V().hasLabel('ZoneStep').has('id',0).repeat(__.out().simplePath()).until(__.hasLabel('ZoneStep').has('id',19)).count().next()

អ្វីដែលជាភាសារុស្សីមានអ្វីមួយដូចនេះ៖ ស្វែងរក ZoneStep ជាមួយ ID=0, stomp ដោយមិនត្រលប់ក្រោយរហូតដល់អ្នករកឃើញ ZoneStep ជាមួយ ID=19, រាប់ចំនួនច្រវ៉ាក់បែបនេះ។

ខ្ញុំក៏បានសម្រួលការផ្ទុកស្គ្រីបដែលបានផ្តល់ឱ្យខាងលើ ដើម្បីកុំឱ្យបង្កើតការតភ្ជាប់ដែលមិនចាំបាច់ ដោយដាក់កម្រិតខ្លួនខ្ញុំចំពោះគុណលក្ខណៈ។

សំណើនៅតែចំណាយពេលប៉ុន្មានវិនាទីដើម្បីបញ្ចប់ ដែលជាការមិនអាចទទួលយកបានទាំងស្រុងសម្រាប់កិច្ចការរបស់យើង ព្រោះវាមិនសមស្របនឹងគោលបំណងនៃសំណើរបស់ AdHoc គ្រប់ប្រភេទ។

ខ្ញុំបានព្យាយាមដាក់ពង្រាយ JanusGraph ដោយប្រើ Scylla ជាការអនុវត្ត Cassandra លឿនបំផុត ប៉ុន្តែនេះក៏មិននាំឱ្យមានការផ្លាស់ប្តូរដំណើរការសំខាន់ៗណាមួយដែរ។

ដូច្នេះបើទោះបីជាការពិតដែលថា "វាមើលទៅដូចជាក្រាហ្វ" ខ្ញុំមិនអាចយកក្រាហ្វ DBMS ដើម្បីដំណើរការវាបានលឿនទេ។ ខ្ញុំសន្មត់យ៉ាងពេញលេញថាមានអ្វីមួយដែលខ្ញុំមិនដឹង ហើយថា JanusGraph អាចត្រូវបានធ្វើឡើងដើម្បីធ្វើការស្វែងរកនេះក្នុងរយៈពេលមួយវិនាទី ប៉ុន្តែខ្ញុំមិនអាចធ្វើវាបានទេ។

ដោយសារបញ្ហានៅតែត្រូវដោះស្រាយ ខ្ញុំចាប់ផ្តើមគិតអំពី JOINs និង Pivots of tables ដែលមិនបានជំរុញឱ្យមានសុទិដ្ឋិនិយមទាក់ទងនឹងភាពឆើតឆាយ ប៉ុន្តែអាចជាជម្រើសដែលអាចដំណើរការបានទាំងស្រុងក្នុងការអនុវត្ត។

គម្រោងរបស់យើងប្រើ Apache ClickHouse រួចហើយ ដូច្នេះខ្ញុំបានសម្រេចចិត្តសាកល្បងការស្រាវជ្រាវរបស់ខ្ញុំលើ DBMS វិភាគនេះ។

បានដាក់ពង្រាយ ClickHouse ដោយប្រើរូបមន្តសាមញ្ញមួយ៖

sudo docker run -d --name clickhouse_1 
     --ulimit nofile=262144:262144 
     -v /opt/clickhouse/log:/var/log/clickhouse-server 
     -v /opt/clickhouse/data:/var/lib/clickhouse 
     yandex/clickhouse-server

ខ្ញុំបានបង្កើត Database និងតារាងមួយនៅក្នុងវាដូចនេះ៖

CREATE TABLE 
db.steps (`area` Int64, `when` DateTime64(1, 'Europe/Moscow') DEFAULT now64(), `zone` Int64, `person` Int64) 
ENGINE = MergeTree() ORDER BY (area, zone, person) SETTINGS index_granularity = 8192

ខ្ញុំបានបំពេញវាដោយទិន្នន័យដោយប្រើស្គ្រីបខាងក្រោម៖

from time import time

from clickhouse_driver import Client
from random import random

client = Client('vm-12c2c34c-df68-4a98-b1e5-a4d1cef1acff.domain',
                database='db',
                password='secret')

max = 20

for r in range(0, 100000):

    if r % 1000 == 0:
        print("CNT: {}, TS: {}".format(r, time()))

    data = [{
            'area': 0,
            'zone': 0,
            'person': r
        }]

    while True:
        if random() < 0.3:
            break

        data.append({
                'area': 0,
                'zone': int(random() * (max - 2)) + 1,
                'person': r
            })

    data.append({
            'area': 0,
            'zone': max - 1,
            'person': r
        })

    client.execute(
        'INSERT INTO steps (area, zone, person) VALUES',
        data
    )

ចាប់តាំងពីការបញ្ចូលមកជាបាច់ ការបំពេញគឺលឿនជាង JanusGraph ។

បង្កើតសំណួរពីរដោយប្រើ JOIN ។ ដើម្បីផ្លាស់ទីពីចំណុច A ទៅចំណុច B៖

SELECT s1.person AS person,
       s1.zone,
       s1.when,
       s2.zone,
       s2.when
FROM
  (SELECT *
   FROM steps
   WHERE (area = 0)
     AND (zone = 0)) AS s1 ANY INNER JOIN
  (SELECT *
   FROM steps AS s2
   WHERE (area = 0)
     AND (zone = 19)) AS s2 USING person
WHERE s1.when <= s2.when

ដើម្បីឆ្លងកាត់ ៣ ពិន្ទុ៖

SELECT s3.person,
       s1z,
       s1w,
       s2z,
       s2w,
       s3.zone,
       s3.when
FROM
  (SELECT s1.person AS person,
          s1.zone AS s1z,
          s1.when AS s1w,
          s2.zone AS s2z,
          s2.when AS s2w
   FROM
     (SELECT *
      FROM steps
      WHERE (area = 0)
        AND (zone = 0)) AS s1 ANY INNER JOIN
     (SELECT *
      FROM steps AS s2
      WHERE (area = 0)
        AND (zone = 3)) AS s2 USING person
   WHERE s1.when <= s2.when) p ANY INNER JOIN
  (SELECT *
   FROM steps
   WHERE (area = 0)
     AND (zone = 19)) AS s3 USING person
WHERE p.s2w <= s3.when

ជាការពិតណាស់សំណើមើលទៅគួរឱ្យខ្លាចណាស់; សម្រាប់ការប្រើប្រាស់ជាក់ស្តែង អ្នកត្រូវបង្កើតឧបករណ៍បង្កើតកម្មវិធី។ ទោះយ៉ាងណាក៏ដោយពួកគេធ្វើការហើយពួកគេធ្វើការយ៉ាងឆាប់រហ័ស។ ទាំងសំណើទីមួយ និងទីពីរត្រូវបានបញ្ចប់ក្នុងរយៈពេលតិចជាង 0.1 វិនាទី។ នេះគឺជាឧទាហរណ៍នៃពេលវេលាប្រតិបត្តិសំណួរសម្រាប់ការរាប់ (*) ឆ្លងកាត់ 3 ពិន្ទុ៖

SELECT count(*)
FROM 
(
    SELECT 
        s1.person AS person, 
        s1.zone AS s1z, 
        s1.when AS s1w, 
        s2.zone AS s2z, 
        s2.when AS s2w
    FROM 
    (
        SELECT *
        FROM steps
        WHERE (area = 0) AND (zone = 0)
    ) AS s1
    ANY INNER JOIN 
    (
        SELECT *
        FROM steps AS s2
        WHERE (area = 0) AND (zone = 3)
    ) AS s2 USING (person)
    WHERE s1.when <= s2.when
) AS p
ANY INNER JOIN 
(
    SELECT *
    FROM steps
    WHERE (area = 0) AND (zone = 19)
) AS s3 USING (person)
WHERE p.s2w <= s3.when

┌─count()─┐
│   11592 │
└─────────┘

1 rows in set. Elapsed: 0.068 sec. Processed 250.03 thousand rows, 8.00 MB (3.69 million rows/s., 117.98 MB/s.)

កំណត់ចំណាំអំពី IOPS. នៅពេលផ្ទុកទិន្នន័យ JanusGraph បានបង្កើតចំនួន IOPS ខ្ពស់គួរសម (1000-1300 សម្រាប់ចំនួនទិន្នន័យចំនួនបួន) ហើយ IOWAIT គឺខ្ពស់ណាស់។ ក្នុងពេលជាមួយគ្នានោះ ClickHouse បានបង្កើតបន្ទុកតិចតួចបំផុតនៅលើប្រព័ន្ធរងរបស់ថាស។

សេចក្តីសន្និដ្ឋាន

យើងបានសម្រេចចិត្តប្រើ ClickHouse ដើម្បីផ្តល់សេវាសំណើប្រភេទនេះ។ យើងតែងតែអាចបង្កើនប្រសិទ្ធភាពសំណួរដោយប្រើទិដ្ឋភាពជាក់ស្តែង និងការប្រៀបធៀបដោយដំណើរការស្ទ្រីមព្រឹត្តិការណ៍ជាមុនដោយប្រើ Apache Flink មុនពេលផ្ទុកពួកវាទៅក្នុង ClickHouse ។

ការសម្តែងគឺល្អខ្លាំងណាស់ ដែលយើងប្រហែលជាមិនចាំបាច់គិតអំពីតារាង pivoting តាមកម្មវិធីនោះទេ។ ពីមុន យើងត្រូវធ្វើ pivots នៃទិន្នន័យដែលទាញយកពី Vertica តាមរយៈការបង្ហោះទៅកាន់ Apache Parquet។

ជាអកុសល ការប៉ុនប៉ងមួយផ្សេងទៀតដើម្បីប្រើក្រាហ្វ DBMS មិនជោគជ័យទេ។ ខ្ញុំមិនបានរកឃើញថា JanusGraph មានប្រព័ន្ធអេកូឡូស៊ីដែលងាយស្រួលប្រើក្នុងការបង្កើនល្បឿនជាមួយនឹងផលិតផលនោះទេ។ ក្នុងពេលជាមួយគ្នានេះ ដើម្បីកំណត់រចនាសម្ព័ន្ធម៉ាស៊ីនមេ វិធីសាស្ត្រ Java បុរាណត្រូវបានប្រើ ដែលនឹងធ្វើឱ្យមនុស្សដែលមិនស្គាល់ Java ស្រក់ទឹកភ្នែក៖

host: 0.0.0.0
port: 8182
threadPoolWorker: 1
gremlinPool: 8
scriptEvaluationTimeout: 30000
channelizer: org.janusgraph.channelizers.JanusGraphWsAndHttpChannelizer

graphManager: org.janusgraph.graphdb.management.JanusGraphManager
graphs: {
  ConfigurationManagementGraph: conf/janusgraph-cql-configurationgraph.properties,
  airlines: conf/airlines.properties
}

scriptEngines: {
  gremlin-groovy: {
    plugins: { org.janusgraph.graphdb.tinkerpop.plugin.JanusGraphGremlinPlugin: {},
               org.apache.tinkerpop.gremlin.server.jsr223.GremlinServerGremlinPlugin: {},
               org.apache.tinkerpop.gremlin.tinkergraph.jsr223.TinkerGraphGremlinPlugin: {},
               org.apache.tinkerpop.gremlin.jsr223.ImportGremlinPlugin: {classImports: [java.lang.Math], methodImports: [java.lang.Math#*]},
               org.apache.tinkerpop.gremlin.jsr223.ScriptFileGremlinPlugin: {files: [scripts/airline-sample.groovy]}}}}

serializers:
# GraphBinary is here to replace Gryo and Graphson
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphBinaryMessageSerializerV1, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphBinaryMessageSerializerV1, config: { serializeResultToString: true }}
  # Gryo and Graphson, latest versions
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV3d0, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV3d0, config: { serializeResultToString: true }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV3d0, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
  # Older serialization versions for backwards compatibility:
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV1d0, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV1d0, config: { serializeResultToString: true }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoLiteMessageSerializerV1d0, config: {ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV2d0, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV1d0, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistryV1d0] }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV1d0, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistryV1d0] }}

processors:
  - { className: org.apache.tinkerpop.gremlin.server.op.session.SessionOpProcessor, config: { sessionTimeout: 28800000 }}
  - { className: org.apache.tinkerpop.gremlin.server.op.traversal.TraversalOpProcessor, config: { cacheExpirationTime: 600000, cacheMaxSize: 1000 }}

metrics: {
  consoleReporter: {enabled: false, interval: 180000},
  csvReporter: {enabled: false, interval: 180000, fileName: /tmp/gremlin-server-metrics.csv},
  jmxReporter: {enabled: false},
  slf4jReporter: {enabled: true, interval: 180000},
  gangliaReporter: {enabled: false, interval: 180000, addressingMode: MULTICAST},
  graphiteReporter: {enabled: false, interval: 180000}}
threadPoolBoss: 1
maxInitialLineLength: 4096
maxHeaderSize: 8192
maxChunkSize: 8192
maxContentLength: 65536
maxAccumulationBufferComponents: 1024
resultIterationBatchSize: 64
writeBufferHighWaterMark: 32768
writeBufferHighWaterMark: 65536
ssl: {
  enabled: false}

ខ្ញុំបានគ្រប់គ្រងដោយចៃដន្យ "ដាក់" កំណែ BerkeleyDB នៃ JanusGraph ។

ឯកសារគឺមានភាពច្របូកច្របល់ក្នុងលក្ខខណ្ឌនៃលិបិក្រម ចាប់តាំងពីការគ្រប់គ្រងលិបិក្រមតម្រូវឱ្យអ្នកអនុវត្ត shamanism ចម្លែកមួយចំនួននៅក្នុង Groovy ។ ឧទាហរណ៍ ការបង្កើតលិបិក្រមត្រូវតែធ្វើឡើងដោយការសរសេរកូដនៅក្នុងកុងសូល Gremlin (ដែលតាមវិធីនេះ វាមិនដំណើរការចេញពីប្រអប់ទេ)។ ពីឯកសារ JanusGraph ផ្លូវការ៖

graph.tx().rollback() //Never create new indexes while a transaction is active
mgmt = graph.openManagement()
name = mgmt.getPropertyKey('name')
age = mgmt.getPropertyKey('age')
mgmt.buildIndex('byNameComposite', Vertex.class).addKey(name).buildCompositeIndex()
mgmt.buildIndex('byNameAndAgeComposite', Vertex.class).addKey(name).addKey(age).buildCompositeIndex()
mgmt.commit()

//Wait for the index to become available
ManagementSystem.awaitGraphIndexStatus(graph, 'byNameComposite').call()
ManagementSystem.awaitGraphIndexStatus(graph, 'byNameAndAgeComposite').call()
//Reindex the existing data
mgmt = graph.openManagement()
mgmt.updateIndex(mgmt.getGraphIndex("byNameComposite"), SchemaAction.REINDEX).get()
mgmt.updateIndex(mgmt.getGraphIndex("byNameAndAgeComposite"), SchemaAction.REINDEX).get()
mgmt.commit()

Afterword

ក្នុងន័យមួយ ការពិសោធន៍ខាងលើគឺជាការប្រៀបធៀបរវាងក្តៅ និងទន់។ ប្រសិនបើអ្នកគិតអំពីវា ក្រាហ្វ DBMS ធ្វើប្រតិបត្តិការផ្សេងទៀតដើម្បីទទួលបានលទ្ធផលដូចគ្នា។ ទោះយ៉ាងណាក៏ដោយ ជាផ្នែកនៃការធ្វើតេស្ត ខ្ញុំក៏បានធ្វើការពិសោធន៍ជាមួយនឹងសំណើដូចជា៖

g.V().hasLabel('ZoneStep').has('id',0)
    .repeat(__.out().simplePath()).until(__.hasLabel('ZoneStep').has('id',1)).count().next()

ដែលឆ្លុះបញ្ចាំងពីចម្ងាយដើរ។ ទោះយ៉ាងណាក៏ដោយ សូម្បីតែនៅលើទិន្នន័យបែបនេះ ក្រាហ្វ DBMS បានបង្ហាញលទ្ធផលដែលលើសពីពីរបីវិនាទី... នេះជាការពិតណាស់ ដោយសារតែមានផ្លូវដូចជា 0 -> X -> Y ... -> 1ដែលម៉ាស៊ីនក្រាហ្វក៏បានពិនិត្យផងដែរ។

សូម្បីតែសម្រាប់សំណួរដូចជា៖

g.V().hasLabel('ZoneStep').has('id',0).out().has('id',1)).count().next()

ខ្ញុំមិនអាចទទួលបានការឆ្លើយតបប្រកបដោយផលិតភាពជាមួយនឹងពេលវេលាដំណើរការតិចជាងមួយវិនាទី។

សីលធម៌នៃរឿងគឺថាគំនិតដ៏ស្រស់ស្អាតនិងគំរូគំរូមិននាំទៅរកលទ្ធផលដែលចង់បានដែលត្រូវបានបង្ហាញដោយប្រសិទ្ធភាពខ្ពស់ដោយប្រើឧទាហរណ៍ ClickHouse ។ ករណីប្រើប្រាស់ដែលបង្ហាញក្នុងអត្ថបទនេះគឺជាការប្រឆាំងនឹងគំរូច្បាស់លាស់សម្រាប់ក្រាហ្វ DBMSs ទោះបីជាវាហាក់ដូចជាសមរម្យសម្រាប់គំរូនៅក្នុងគំរូរបស់ពួកគេក៏ដោយ។

ប្រភព: www.habr.com