🥇 उपयुक्त मार्गहरू खोज्ने समस्या समाधान गर्नका लागि JanusGraph ग्राफ DBMS को उपयोगिता परीक्षण गर्ने एउटा प्रयोग

नमस्ते सबै। हामी अफलाइन ट्राफिक विश्लेषणको लागि उत्पादन विकास गर्दैछौं। परियोजनासँग क्षेत्रहरूमा आगन्तुक मार्गहरूको सांख्यिकीय विश्लेषणसँग सम्बन्धित कार्य छ।

यस कार्यको भागको रूपमा, प्रयोगकर्ताहरूले निम्न प्रकारका प्रणाली प्रश्नहरू सोध्न सक्छन्:

क्षेत्र "A" बाट क्षेत्र "B" मा कति आगन्तुकहरू गए;
कति आगन्तुकहरू क्षेत्र "A" बाट क्षेत्र "B" मा क्षेत्र "C" र त्यसपछि क्षेत्र "D" मार्फत गए;
एक निश्चित प्रकारको आगन्तुकलाई क्षेत्र "A" बाट क्षेत्र "B" सम्म यात्रा गर्न कति समय लाग्यो।

र धेरै समान विश्लेषणात्मक प्रश्नहरू।

क्षेत्रहरूमा आगन्तुकको आवागमन एक निर्देशित ग्राफ हो। इन्टरनेट पढेपछि, मैले पत्ता लगाएँ कि ग्राफ डीबीएमएसहरू विश्लेषणात्मक रिपोर्टहरूको लागि पनि प्रयोग गरिन्छ। ग्राफ DBMS ले त्यस्ता प्रश्नहरूको सामना कसरी गर्नेछ भन्ने हेर्न मेरो इच्छा थियो (TL; DR; खराब)।

मैले DBMS प्रयोग गर्न रोजें जानसग्राफ, ग्राफ खुला स्रोत DBMS को एक उत्कृष्ट प्रतिनिधिको रूपमा, जुन परिपक्व प्रविधिहरूको स्ट्याकमा निर्भर गर्दछ, जसले (मेरो विचारमा) यसलाई सभ्य परिचालन विशेषताहरू प्रदान गर्नुपर्छ:

BerkeleyDB भण्डारण ब्याकएन्ड, Apache Cassandra, Scylla;
जटिल अनुक्रमणिकाहरू लुसेन, Elasticsearch, Solr मा भण्डारण गर्न सकिन्छ।

JanusGraph को लेखकहरूले लेख्छन् कि यो OLTP र OLAP दुवैको लागि उपयुक्त छ।

मैले BerkeleyDB, Apache Cassandra, Scylla र ES सँग काम गरेको छु, र यी उत्पादनहरू प्रायः हाम्रो प्रणालीहरूमा प्रयोग गरिन्छ, त्यसैले म यो ग्राफ DBMS परीक्षणको बारेमा आशावादी थिएँ। मलाई RocksDB मा BerkeleyDB छनोट गर्न अनौठो लाग्यो, तर यो सम्भवतः लेनदेन आवश्यकताहरूको कारणले हो। कुनै पनि अवस्थामा, स्केलेबल, उत्पादन प्रयोगको लागि, यो क्यासान्ड्रा वा Scylla मा ब्याकइन्ड प्रयोग गर्न सुझाव दिइएको छ।

मैले Neo4j लाई विचार गरेन किनभने क्लस्टरिङलाई व्यावसायिक संस्करण चाहिन्छ, त्यो हो, उत्पादन खुला स्रोत होइन।

ग्राफ DBMSs भन्छन्: "यदि यो ग्राफ जस्तो देखिन्छ, यसलाई ग्राफ जस्तै व्यवहार गर्नुहोस्!" - सौन्दर्य!

पहिले, मैले ग्राफ कोरें, जुन ग्राफ DBMSs को क्याननहरू अनुसार बनाइएको थियो:

एउटा सार छ 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()

रुसी भाषामा यस्तो कुरा के हो: ID=0 भएको जोन फेला पार्नुहोस्, किनारा (जोनस्टेप) मा जाने सबै ठाडोहरू लिनुहोस्, तपाईंले ती जोनस्टेपहरू फेला नपाएसम्म पछाडि नजाइकन स्टम्प गर्नुहोस् जहाँबाट जोनको किनारा छ। ID=19, त्यस्ता चेनहरूको संख्या गणना गर्नुहोस्।

म ग्राफहरूमा खोजीका सबै जटिलताहरू थाहा पाएको बहाना गर्दिन, तर यो प्रश्न यस पुस्तकको आधारमा उत्पन्न गरिएको थियो (https://kelvinlawrence.net/book/Gremlin-Graph-Guide.html).

मैले BerkeleyDB ब्याकइन्ड प्रयोग गरेर JanusGraph ग्राफ डाटाबेसमा 50 देखि 3 बिन्दु लम्बाइका 20 हजार ट्र्याकहरू लोड गरें, अनुसार अनुक्रमणिकाहरू सिर्जना गरियो। नेतृत्व.

पाइथन डाउनलोड स्क्रिप्ट:


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)

हामीले SSD मा 4 कोर र 16 GB RAM भएको VM प्रयोग गर्यौं। JanusGraph यो आदेश प्रयोग गरेर तैनात गरिएको थियो:

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

यस अवस्थामा, डेटा र अनुक्रमणिकाहरू जुन सटीक मिलान खोजहरूको लागि प्रयोग गरिन्छ BerkeleyDB मा भण्डारण गरिन्छ। पहिले दिइएको अनुरोध कार्यान्वयन गरिसकेपछि, मैले धेरै दसौं सेकेन्ड बराबरको समय प्राप्त गरें।

माथिका ४ वटा स्क्रिप्टहरू समानान्तरमा चलाएर, मैले DBMS लाई जाभा स्ट्याकट्रेसहरू (र हामी सबैलाई जाभा स्ट्याकट्रेसहरू पढ्न मनपर्छ) डकर लगहरूमा रमाइलो स्ट्रिमको साथ कद्दूमा परिणत गर्न सफल भयो।

केहि सोच पछि, मैले ग्राफ रेखाचित्रलाई निम्नमा सरल बनाउने निर्णय गरें:

निकाय विशेषताहरूद्वारा खोजी गर्नु किनाराहरूद्वारा खोजी गर्नुभन्दा छिटो हुनेछ भन्ने निर्णय गर्दै। नतिजाको रूपमा, मेरो अनुरोध निम्नमा परिणत भयो:

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

रूसी भाषामा के यस्तो छ: ID=0 को साथ ZoneStep फेला पार्नुहोस्, तपाईंले ID=19 सँग ZoneStep फेला नपाएसम्म पछाडि नजाइकन स्टम्प गर्नुहोस्, त्यस्ता चेनहरूको संख्या गणना गर्नुहोस्।

मैले अनावश्यक जडानहरू सिर्जना नगर्नका लागि माथि दिइएको लोडिङ स्क्रिप्टलाई पनि सरल बनाएको छु, आफूलाई विशेषताहरूमा सीमित राख्दै।

अनुरोध पूरा हुन अझै धेरै सेकेन्ड लाग्यो, जुन हाम्रो कार्यको लागि पूर्ण रूपमा अस्वीकार्य थियो, किनकि यो कुनै पनि प्रकारको AdHoc अनुरोधहरूको उद्देश्यका लागि उपयुक्त थिएन।

मैले JanusGraph लाई Scylla को सबैभन्दा छिटो Cassandra कार्यान्वयनको रूपमा प्रयोग गर्ने प्रयास गरे, तर यसले कुनै पनि महत्त्वपूर्ण कार्यसम्पादन परिवर्तनहरू निम्त्याउन सकेन।

त्यसैले "यो ग्राफ जस्तो देखिन्छ" भन्ने तथ्यको बावजुद, मैले यसलाई छिटो प्रशोधन गर्न ग्राफ DBMS प्राप्त गर्न सकिन। म पूर्णतया मान्छु कि त्यहाँ केहि छ जुन मलाई थाहा छैन र JanusGraph लाई सेकेन्डको एक अंशमा यो खोज गर्न सकिन्छ, तथापि, मैले यो गर्न सकेन।

समस्या अझै समाधान गर्न आवश्यक भएकोले, मैले तालिकाको JOIN र Pivots बारे सोच्न थालें, जसले सुन्दरताको सन्दर्भमा आशावादलाई प्रेरित गर्दैन, तर व्यवहारमा पूर्ण रूपमा कार्ययोग्य विकल्प हुन सक्छ।

हाम्रो परियोजना पहिले नै Apache ClickHouse प्रयोग गर्दछ, त्यसैले मैले यो विश्लेषणात्मक DBMS मा मेरो अनुसन्धान परीक्षण गर्ने निर्णय गरें।

एक साधारण नुस्खा प्रयोग गरेर क्लिकहाउस तैनात:

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

मैले यसमा एउटा डाटाबेस र एउटा तालिका यसरी बनाएको छु:

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

3 बिन्दुहरू मार्फत जान:

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 बिन्दुहरू मार्फत गुजरने गणना (*) को लागि क्वेरी कार्यान्वयन समयको उदाहरण हो:

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 धेरै उच्च थियो। एकै समयमा, क्लिकहाउसले डिस्क सबसिस्टममा न्यूनतम लोड उत्पन्न गर्यो।

निष्कर्षमा

हामीले यस प्रकारको अनुरोध सेवा गर्न क्लिकहाउस प्रयोग गर्ने निर्णय गर्यौं। हामी जहिले पनि वस्तुगत दृश्यहरू र समानान्तरीकरण प्रयोग गरेर क्वेरीहरूलाई क्लिकहाउसमा लोड गर्नु अघि अपाचे फ्लिंक प्रयोग गरेर घटना स्ट्रिमलाई पूर्व-प्रशोधन गरेर थप अनुकूलन गर्न सक्छौं।

प्रदर्शन यति राम्रो छ कि हामीले सम्भवतः पिभोटिङ् तालिकाहरू प्रोग्रामेटिक रूपमा सोच्नुपर्दैन। पहिले, हामीले Apache Parquet मा अपलोड मार्फत Vertica बाट प्राप्त डाटाको पिभोटहरू गर्नुपर्थ्यो।

दुर्भाग्यवश, ग्राफ DBMS प्रयोग गर्ने अर्को प्रयास असफल भयो। मैले JanusGraph लाई उत्पादनसँग गति लिन सजिलो बनाउने अनुकूल इकोसिस्टम पाउन सकिन। एकै समयमा, सर्भर कन्फिगर गर्न, परम्परागत जाभा तरीका प्रयोग गरिन्छ, जसले जाभासँग परिचित नभएका मानिसहरूलाई रगतको आँसु रुन्छ:

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}

मैले संयोगवश JanusGraph को BerkeleyDB संस्करण "राख्नु" व्यवस्थित गरें।

कागजातहरू अनुक्रमणिकाहरूको सन्दर्भमा एकदमै बाङ्गो छ, किनकि अनुक्रमणिकाहरू प्रबन्ध गर्न तपाईंले ग्रोभीमा केही अनौठो शमनवाद प्रदर्शन गर्न आवश्यक छ। उदाहरणका लागि, अनुक्रमणिका सिर्जना गर्न ग्रेमलिन कन्सोलमा कोड लेखेर गर्नुपर्छ (जसले, बाकस बाहिर काम गर्दैन)। आधिकारिक 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()

पछिशब्द

एक अर्थमा, माथिको प्रयोग न्यानो र नरम बीचको तुलना हो। यदि तपाइँ यसको बारेमा सोच्नुहुन्छ भने, ग्राफ 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()

म एक सेकेन्ड भन्दा कमको प्रशोधन समय संग एक उत्पादक प्रतिक्रिया प्राप्त गर्न असमर्थ थिए।

कथाको नैतिकता यो हो कि एक सुन्दर विचार र प्रतिमानात्मक मोडेलिङले वांछित परिणामको नेतृत्व गर्दैन, जुन क्लिकहाउसको उदाहरण प्रयोग गरेर धेरै उच्च दक्षताको साथ प्रदर्शन गरिएको छ। यस लेखमा प्रस्तुत गरिएको प्रयोग केस ग्राफ DBMS को लागि स्पष्ट विरोधी ढाँचा हो, यद्यपि यो तिनीहरूको प्रतिमानमा मोडेलिङको लागि उपयुक्त देखिन्छ।

स्रोत: www.habr.com

उपयुक्त मार्गहरू खोज्ने समस्या समाधान गर्नका लागि JanusGraph ग्राफ DBMS को प्रयोगशीलता परीक्षण गर्ने एक प्रयोग

निष्कर्षमा

पछिशब्द

एक टिप्पणी थप्न Отменить ответ