🥇അനുയോജ്യമായ പാതകൾ കണ്ടെത്തുന്നതിനുള്ള പ്രശ്നം പരിഹരിക്കുന്നതിനായി DBMS JanusGraph ഗ്രാഫിന്റെ പ്രയോഗക്ഷമത പരിശോധിക്കുന്ന ഒരു പരീക്ഷണം

എല്ലാവർക്കും ഹായ്. ഓഫ്‌ലൈൻ ട്രാഫിക് വിശകലനത്തിനായി ഞങ്ങൾ ഒരു ഉൽപ്പന്നം വികസിപ്പിക്കുകയാണ്. പ്രദേശങ്ങളിലുടനീളമുള്ള സന്ദർശക റൂട്ടുകളുടെ സ്ഥിതിവിവര വിശകലനവുമായി ബന്ധപ്പെട്ട ഒരു ടാസ്‌ക് പ്രോജക്റ്റിനുണ്ട്.

ഈ ടാസ്ക്കിന്റെ ഭാഗമായി, ഉപയോക്താക്കൾക്ക് ഇനിപ്പറയുന്ന തരത്തിലുള്ള സിസ്റ്റം ചോദ്യങ്ങൾ ചോദിക്കാൻ കഴിയും:

"എ" ഏരിയയിൽ നിന്ന് "ബി" ഏരിയയിലേക്ക് എത്ര സന്ദർശകർ കടന്നുപോയി;
"എ" ഏരിയയിൽ നിന്ന് "ബി" ഏരിയയിലേക്ക് "സി" ഏരിയയിലൂടെയും തുടർന്ന് "ഡി" ഏരിയയിലൂടെയും എത്ര സന്ദർശകർ കടന്നുപോയി;
ഒരു പ്രത്യേക തരം സന്ദർശകർക്ക് "A" ഏരിയയിൽ നിന്ന് "B" ഏരിയയിലേക്ക് യാത്ര ചെയ്യാൻ എത്ര സമയമെടുത്തു.

സമാനമായ അനലിറ്റിക്കൽ ചോദ്യങ്ങളും.

പ്രദേശങ്ങളിലുടനീളം സന്ദർശകരുടെ ചലനം ഒരു ഡയറക്ട് ഗ്രാഫ് ആണ്. ഇന്റർനെറ്റ് വായിച്ചതിനുശേഷം, ഗ്രാഫ് ഡിബിഎംഎസുകളും വിശകലന റിപ്പോർട്ടുകൾക്കായി ഉപയോഗിക്കുന്നുണ്ടെന്ന് ഞാൻ കണ്ടെത്തി. ഇത്തരം ചോദ്യങ്ങളെ ഗ്രാഫ് ഡിബിഎംഎസുകൾ എങ്ങനെ നേരിടുമെന്ന് കാണാൻ എനിക്ക് ആഗ്രഹമുണ്ടായിരുന്നു (TL; DR; മോശമായി).

ഞാൻ DBMS ഉപയോഗിക്കാൻ തിരഞ്ഞെടുത്തു ജാനസ് ഗ്രാഫ്, ഗ്രാഫ് ഓപ്പൺ സോഴ്‌സ് ഡിബിഎംഎസിന്റെ മികച്ച പ്രതിനിധി എന്ന നിലയിൽ, അത് (എന്റെ അഭിപ്രായത്തിൽ) മാന്യമായ പ്രവർത്തന സവിശേഷതകൾ നൽകേണ്ട, മുതിർന്ന സാങ്കേതികവിദ്യകളുടെ ഒരു കൂട്ടത്തെ ആശ്രയിക്കുന്നു:

ബെർക്ക്‌ലിഡിബി സ്റ്റോറേജ് ബാക്കെൻഡ്, അപ്പാച്ചെ കസാന്ദ്ര, സ്കില്ല;
സങ്കീർണ്ണമായ സൂചികകൾ Lucene, Elasticsearch, Solr എന്നിവയിൽ സൂക്ഷിക്കാം.

OLTP, OLAP എന്നിവയ്‌ക്ക് ഇത് അനുയോജ്യമാണെന്ന് JanusGraph-ന്റെ രചയിതാക്കൾ എഴുതുന്നു.

ഞാൻ BerkeleyDB, Apache Cassandra, Scylla, ES എന്നിവയ്‌ക്കൊപ്പം പ്രവർത്തിച്ചിട്ടുണ്ട്, ഈ ഉൽപ്പന്നങ്ങൾ ഞങ്ങളുടെ സിസ്റ്റങ്ങളിൽ പലപ്പോഴും ഉപയോഗിക്കാറുണ്ട്, അതിനാൽ ഈ ഗ്രാഫ് DBMS പരീക്ഷിക്കുന്നതിൽ എനിക്ക് ശുഭാപ്തി വിശ്വാസമുണ്ടായിരുന്നു. RocksDB-യെക്കാൾ BerkeleyDB തിരഞ്ഞെടുക്കുന്നത് വിചിത്രമാണെന്ന് ഞാൻ കണ്ടെത്തി, പക്ഷേ അത് ഇടപാട് ആവശ്യകതകൾ കാരണമായിരിക്കാം. ഏത് സാഹചര്യത്തിലും, സ്കെയിലബിൾ, ഉൽപ്പന്ന ഉപയോഗത്തിന്, കസാന്ദ്രയിലോ സ്കില്ലയിലോ ഒരു ബാക്കെൻഡ് ഉപയോഗിക്കാൻ നിർദ്ദേശിക്കുന്നു.

ഞാൻ Neo4j പരിഗണിച്ചില്ല, കാരണം ക്ലസ്റ്ററിങ്ങിന് ഒരു വാണിജ്യ പതിപ്പ് ആവശ്യമാണ്, അതായത് ഉൽപ്പന്നം ഓപ്പൺ സോഴ്‌സ് അല്ല.

ഗ്രാഫ് 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()

റഷ്യൻ ഭാഷയിൽ ഇതുപോലെയാണ്: ID=0 ഉള്ള ഒരു സോൺ കണ്ടെത്തുക, അതിലേക്ക് ഒരു എഡ്ജ് പോകുന്ന എല്ലാ ശീർഷകങ്ങളും എടുക്കുക (ZoneStep), സോണിലേക്ക് ഒരു എഡ്ജ് ഉള്ള ആ സോൺസ്റ്റെപ്പുകൾ കണ്ടെത്തുന്നത് വരെ പിന്നോട്ട് പോകാതെ സ്റ്റോമ്പ് ചെയ്യുക ഐഡി=19, അത്തരം ചെയിനുകളുടെ എണ്ണം എണ്ണുക.

ഗ്രാഫുകളിൽ തിരയുന്നതിന്റെ എല്ലാ സങ്കീർണതകളും ഞാൻ അറിയുന്നതായി നടിക്കുന്നില്ല, പക്ഷേ ഈ പുസ്തകത്തെ അടിസ്ഥാനമാക്കിയാണ് ഈ ചോദ്യം സൃഷ്ടിച്ചത് (https://kelvinlawrence.net/book/Gremlin-Graph-Guide.html).

ബെർക്ക്‌ലിഡിബി ബാക്കെൻഡ് ഉപയോഗിച്ച് 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 റാമും ഉള്ള VM ഉപയോഗിച്ചു. ഈ കമാൻഡ് ഉപയോഗിച്ചാണ് JanusGraph വിന്യസിച്ചത്:

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

ഈ സാഹചര്യത്തിൽ, കൃത്യമായ പൊരുത്ത തിരയലുകൾക്കായി ഉപയോഗിക്കുന്ന ഡാറ്റയും സൂചികകളും BerkeleyDB-യിൽ സംഭരിച്ചിരിക്കുന്നു. നേരത്തെ നൽകിയ അഭ്യർത്ഥന നടപ്പിലാക്കിയതിനാൽ, എനിക്ക് നിരവധി പതിനായിരക്കണക്കിന് സെക്കൻഡുകൾക്ക് തുല്യമായ സമയം ലഭിച്ചു.

മുകളിലെ 4 സ്ക്രിപ്റ്റുകൾ സമാന്തരമായി പ്രവർത്തിപ്പിക്കുന്നതിലൂടെ, ഡോക്കർ ലോഗുകളിലെ ജാവ സ്റ്റാക്ക്ട്രെസുകളുടെ (ഞങ്ങൾ എല്ലാവരും ജാവ സ്റ്റാക്ക്ട്രേസുകൾ വായിക്കാൻ ഇഷ്ടപ്പെടുന്നു) സന്തോഷകരമായ ഒരു സ്ട്രീം ഉപയോഗിച്ച് 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 അഭ്യർത്ഥനകളുടെ ആവശ്യങ്ങൾക്ക് ഒട്ടും അനുയോജ്യമല്ല.

ഞാൻ സ്കില്ല ഉപയോഗിച്ച് ജാനസ്ഗ്രാഫ് വിന്യസിക്കാൻ ശ്രമിച്ചു, എന്നാൽ ഇതും കാര്യമായ പ്രകടന മാറ്റങ്ങളൊന്നും വരുത്തിയില്ല.

"ഇത് ഒരു ഗ്രാഫ് പോലെ തോന്നുന്നു" എന്ന വസ്തുത ഉണ്ടായിരുന്നിട്ടും, അത് വേഗത്തിൽ പ്രോസസ്സ് ചെയ്യാൻ എനിക്ക് ഗ്രാഫ് DBMS ലഭിക്കില്ല. എനിക്ക് എന്തെങ്കിലും അറിയില്ലെന്നും ഒരു നിമിഷത്തിനുള്ളിൽ ഈ തിരയൽ നടത്താൻ JanusGraph-നെ പ്രേരിപ്പിക്കാൻ കഴിയുമെന്നും ഞാൻ പൂർണ്ണമായും അനുമാനിക്കുന്നു, എന്നിരുന്നാലും, എനിക്ക് അത് ചെയ്യാൻ കഴിഞ്ഞില്ല.

പ്രശ്നം ഇപ്പോഴും പരിഹരിക്കേണ്ടതിനാൽ, ഞാൻ ജോയിനുകളെക്കുറിച്ചും പട്ടികകളുടെ പിവറ്റുകളെക്കുറിച്ചും ചിന്തിക്കാൻ തുടങ്ങി, അത് ചാരുതയുടെ കാര്യത്തിൽ ശുഭാപ്തിവിശ്വാസത്തെ പ്രചോദിപ്പിക്കുന്നില്ല, പക്ഷേ പ്രായോഗികമായി പൂർണ്ണമായും പ്രവർത്തനക്ഷമമായ ഓപ്ഷനായിരിക്കാം.

ഞങ്ങളുടെ പ്രോജക്റ്റ് ഇതിനകം തന്നെ അപ്പാച്ചെ ക്ലിക്ക്ഹൗസ് ഉപയോഗിക്കുന്നു, അതിനാൽ ഈ അനലിറ്റിക്കൽ ഡിബിഎംഎസിൽ എന്റെ ഗവേഷണം പരീക്ഷിക്കാൻ ഞാൻ തീരുമാനിച്ചു.

ഒരു ലളിതമായ പാചകക്കുറിപ്പ് ഉപയോഗിച്ച് 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

ഞാൻ ഇതുപോലെ ഒരു ഡാറ്റാബേസും അതിൽ ഒരു പട്ടികയും സൃഷ്ടിച്ചു:

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
    )

ഉൾപ്പെടുത്തലുകൾ ബാച്ചുകളായി വരുന്നതിനാൽ, പൂരിപ്പിക്കൽ ജാനസ് ഗ്രാഫിനേക്കാൾ വളരെ വേഗത്തിലായിരുന്നു.

JOIN ഉപയോഗിച്ച് രണ്ട് അന്വേഷണങ്ങൾ നിർമ്മിച്ചു. പോയിന്റ് എയിൽ നിന്ന് ബി പോയിന്റിലേക്ക് നീങ്ങാൻ:

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 സെക്കൻഡിനുള്ളിൽ പൂർത്തിയായി. എണ്ണം (*) 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-ലേക്ക് ലോഡുചെയ്യുന്നതിന് മുമ്പ്, Apache Flink ഉപയോഗിച്ച് ഇവന്റ് സ്ട്രീം പ്രീ-പ്രോസസ്സ് ചെയ്യുന്നതിലൂടെ, മെറ്റീരിയലൈസ്ഡ് കാഴ്‌ചകളും സമാന്തരവൽക്കരണവും ഉപയോഗിച്ച് ചോദ്യങ്ങൾ കൂടുതൽ ഒപ്റ്റിമൈസ് ചെയ്യാനാകും.

പ്രകടനം വളരെ മികച്ചതാണ്, ടേബിളുകൾ പ്രോഗ്രാമാറ്റിക് ആയി പിവറ്റ് ചെയ്യുന്നതിനെക്കുറിച്ച് നമുക്ക് ചിന്തിക്കേണ്ടി വരില്ല. മുമ്പ്, അപ്പാച്ചെ പാർക്ക്വെറ്റിലേക്ക് അപ്‌ലോഡ് ചെയ്യുന്നതിലൂടെ വെർട്ടിക്കയിൽ നിന്ന് വീണ്ടെടുത്ത ഡാറ്റയുടെ പിവറ്റുകൾ ഞങ്ങൾക്ക് ചെയ്യണമായിരുന്നു.

നിർഭാഗ്യവശാൽ, ഒരു ഗ്രാഫ് 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()

Afterword

ഒരർത്ഥത്തിൽ, മുകളിൽ പറഞ്ഞ പരീക്ഷണം ഊഷ്മളവും മൃദുവും തമ്മിലുള്ള താരതമ്യമാണ്. നിങ്ങൾ അതിനെക്കുറിച്ച് ചിന്തിക്കുകയാണെങ്കിൽ, അതേ ഫലങ്ങൾ ലഭിക്കുന്നതിന് ഒരു ഗ്രാഫ് DBMS മറ്റ് പ്രവർത്തനങ്ങൾ ചെയ്യുന്നു. എന്നിരുന്നാലും, പരിശോധനകളുടെ ഭാഗമായി, ഇതുപോലുള്ള ഒരു അഭ്യർത്ഥനയുമായി ഞാൻ ഒരു പരീക്ഷണവും നടത്തി:

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

ഇത് നടക്കാനുള്ള ദൂരം പ്രതിഫലിപ്പിക്കുന്നു. എന്നിരുന്നാലും, അത്തരം ഡാറ്റയിൽ പോലും, ഗ്രാഫ് ഡിബിഎംഎസ് കുറച്ച് നിമിഷങ്ങൾക്കപ്പുറമുള്ള ഫലങ്ങൾ കാണിച്ചു ... ഇത് തീർച്ചയായും, ഇതുപോലുള്ള പാതകൾ ഉണ്ടായിരുന്നതുകൊണ്ടാണ് 0 -> X -> Y ... -> 1, ഗ്രാഫ് എഞ്ചിനും പരിശോധിച്ചു.

ഇതുപോലുള്ള ഒരു ചോദ്യത്തിന് പോലും:

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

ഒരു സെക്കൻഡിൽ താഴെയുള്ള പ്രോസസ്സിംഗ് സമയം കൊണ്ട് എനിക്ക് ഉൽപ്പാദനക്ഷമമായ പ്രതികരണം നേടാനായില്ല.

കഥയുടെ ധാർമ്മികത, മനോഹരമായ ഒരു ആശയവും മാതൃകാപരമായ മോഡലിംഗും ആവശ്യമുള്ള ഫലത്തിലേക്ക് നയിക്കില്ല എന്നതാണ്, ഇത് ക്ലിക്ക്ഹൗസിന്റെ ഉദാഹരണം ഉപയോഗിച്ച് വളരെ ഉയർന്ന കാര്യക്ഷമതയോടെ പ്രകടമാക്കുന്നു. ഈ ലേഖനത്തിൽ അവതരിപ്പിച്ചിരിക്കുന്ന ഉപയോഗ കേസ് ഗ്രാഫ് ഡിബിഎംഎസുകളുടെ വ്യക്തമായ വിരുദ്ധ പാറ്റേണാണ്, എന്നിരുന്നാലും അവയുടെ മാതൃകയിൽ മോഡലിംഗിന് അനുയോജ്യമാണെന്ന് തോന്നുന്നു.

അവലംബം: www.habr.com

തീരുമാനം

Afterword

ഒരു അഭിപ്രായം ചേർക്കുക മറുപടി റദ്ദാക്കാൻ

ഒരു അഭിപ്രായം ചേർക്കുക