புரோஹோஸ்டர் > Блог > நிர்வாகம் > பொருத்தமான பாதைகளைக் கண்டறிவதில் உள்ள சிக்கலைத் தீர்ப்பதற்கு JanusGraph வரைபடம் DBMS இன் பொருந்தக்கூடிய தன்மையை சோதிக்கும் ஒரு சோதனை

பொருத்தமான பாதைகளைக் கண்டறிவதில் உள்ள சிக்கலைத் தீர்ப்பதற்கு JanusGraph வரைபடம் DBMS இன் பொருந்தக்கூடிய தன்மையை சோதிக்கும் ஒரு சோதனை

பொருத்தமான பாதைகளைக் கண்டறிவதில் உள்ள சிக்கலைத் தீர்ப்பதற்கு JanusGraph வரைபடம் DBMS இன் பொருந்தக்கூடிய தன்மையை சோதிக்கும் ஒரு சோதனை

அனைவருக்கும் வணக்கம். ஆஃப்லைன் ட்ராஃபிக் பகுப்பாய்விற்கான தயாரிப்பை நாங்கள் உருவாக்குகிறோம். இந்தத் திட்டமானது பிராந்தியங்கள் முழுவதும் பார்வையாளர் வழித்தடங்களின் புள்ளிவிவர பகுப்பாய்வு தொடர்பான பணியைக் கொண்டுள்ளது.

இந்தப் பணியின் ஒரு பகுதியாக, பயனர்கள் பின்வரும் வகையின் கணினி வினவல்களைக் கேட்கலாம்:

  • "A" பகுதியிலிருந்து "B" பகுதிக்கு எத்தனை பார்வையாளர்கள் சென்றுள்ளனர்;
  • "A" பகுதியிலிருந்து "B" பகுதிக்கு "C" பகுதி வழியாகவும் பின்னர் "D" பகுதி வழியாகவும் எத்தனை பார்வையாளர்கள் சென்றனர்;
  • ஒரு குறிப்பிட்ட வகை பார்வையாளர்கள் "A" பகுதியிலிருந்து "B" பகுதிக்கு பயணிக்க எவ்வளவு நேரம் ஆனது.

மற்றும் பல ஒத்த பகுப்பாய்வு வினவல்கள்.

பகுதிகள் முழுவதும் பார்வையாளர்களின் இயக்கம் ஒரு இயக்கப்பட்ட வரைபடமாகும். இணையத்தைப் படித்த பிறகு, பகுப்பாய்வு அறிக்கைகளுக்கும் வரைபட DBMSகள் பயன்படுத்தப்படுகின்றன என்பதைக் கண்டுபிடித்தேன். கிராஃப் டிபிஎம்எஸ்கள் அத்தகைய வினவல்களை எவ்வாறு சமாளிக்கும் என்பதைப் பார்க்க எனக்கு ஆசை இருந்தது (டிஎல்; டி.ஆர்; மோசமாக).

நான் DBMS ஐப் பயன்படுத்தத் தேர்ந்தெடுத்தேன் ஜானஸ் கிராஃப், கிராஃப் ஓப்பன் சோர்ஸ் DBMS இன் சிறந்த பிரதிநிதியாக, இது முதிர்ந்த தொழில்நுட்பங்களின் அடுக்கை நம்பியுள்ளது, இது (என் கருத்துப்படி) ஒழுக்கமான செயல்பாட்டு பண்புகளை வழங்க வேண்டும்:

  • பெர்க்லிடிபி சேமிப்பக பின்தளம், அப்பாச்சி கசாண்ட்ரா, ஸ்கைல்லா;
  • சிக்கலான குறியீடுகளை Lucene, Elasticsearch, Solr இல் சேமிக்கலாம்.

JanusGraph இன் ஆசிரியர்கள் OLTP மற்றும் OLAP இரண்டிற்கும் ஏற்றது என்று எழுதுகிறார்கள்.

நான் BerkeleyDB, Apache Cassandra, Scylla மற்றும் ES உடன் பணிபுரிந்துள்ளேன், மேலும் இந்த தயாரிப்புகள் பெரும்பாலும் எங்கள் கணினிகளில் பயன்படுத்தப்படுகின்றன, எனவே இந்த வரைபட DBMS ஐச் சோதிப்பதில் நான் நம்பிக்கையுடன் இருந்தேன். RocksDB ஐ விட பெர்க்லிடிபியைத் தேர்ந்தெடுப்பது எனக்கு வித்தியாசமாக இருந்தது, ஆனால் அது பரிவர்த்தனை தேவைகள் காரணமாக இருக்கலாம். எவ்வாறாயினும், அளவிடக்கூடிய, தயாரிப்பு பயன்பாட்டிற்கு, கசாண்ட்ரா அல்லது ஸ்கைல்லாவில் பின்தளத்தைப் பயன்படுத்த பரிந்துரைக்கப்படுகிறது.

நான் Neo4j ஐக் கருத்தில் கொள்ளவில்லை, ஏனெனில் கிளஸ்டரிங்கிற்கு வணிகப் பதிப்பு தேவைப்படுகிறது, அதாவது தயாரிப்பு திறந்த மூலமாக இல்லை.

வரைபட DBMSகள் கூறுகின்றன: "இது ஒரு வரைபடமாக இருந்தால், அதை ஒரு வரைபடமாக கருதுங்கள்!" - அழகு!

முதலில், நான் ஒரு வரைபடத்தை வரைந்தேன், இது வரைபட DBMS களின் நியதிகளின்படி சரியாக உருவாக்கப்பட்டது:

பொருத்தமான பாதைகளைக் கண்டறிவதில் உள்ள சிக்கலைத் தீர்ப்பதற்கு JanusGraph வரைபடம் 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), எந்த மண்டலத்திற்கு ஒரு விளிம்பு உள்ளதோ அந்த ZoneSteps ஐக் கண்டுபிடிக்கும் வரை பின்வாங்காமல் தடவவும். ஐடி=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 ஜிபி ரேம் கொண்ட VMஐப் பயன்படுத்தினோம். இந்த கட்டளையைப் பயன்படுத்தி JanusGraph பயன்படுத்தப்பட்டது:

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

இந்த வழக்கில், சரியான பொருத்தத் தேடல்களுக்குப் பயன்படுத்தப்படும் தரவு மற்றும் குறியீடுகள் BerkeleyDB இல் சேமிக்கப்படும். முன்பு கொடுக்கப்பட்ட கோரிக்கையை நிறைவேற்றியதால், பல பத்து வினாடிகளுக்கு சமமான நேரத்தைப் பெற்றேன்.

மேலே உள்ள 4 ஸ்கிரிப்ட்களை இணையாக இயக்குவதன் மூலம், டோக்கர் பதிவுகளில் ஜாவா ஸ்டேக்ட்ரேஸ்களின் (நாம் அனைவரும் ஜாவா ஸ்டேக்ட்ரேஸ்களைப் படிக்க விரும்புகிறோம்) மகிழ்ச்சியான ஸ்ட்ரீம் மூலம் DBMS ஐ பூசணிக்காயாக மாற்ற முடிந்தது.

சிறிது யோசனைக்குப் பிறகு, வரைபட வரைபடத்தை பின்வருவனவற்றிற்கு எளிதாக்க முடிவு செய்தேன்:

பொருத்தமான பாதைகளைக் கண்டறிவதில் உள்ள சிக்கலைத் தீர்ப்பதற்கு JanusGraph வரைபடம் 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 ஐப் பயன்படுத்த முயற்சித்தேன், ஆனால் இதுவும் குறிப்பிடத்தக்க செயல்திறன் மாற்றங்களுக்கு வழிவகுக்கவில்லை.

"இது ஒரு வரைபடமாகத் தெரிகிறது" என்ற போதிலும், அதை விரைவாகச் செயலாக்க வரைபட DBMS ஐப் பெற முடியவில்லை. எனக்குத் தெரியாத ஏதோ ஒன்று இருப்பதாகவும், ஒரு நொடியில் இந்தத் தேடலை JanusGraph ஆல் செய்ய முடியும் என்றும் நான் முழுமையாகக் கருதுகிறேன், இருப்பினும் என்னால் அதைச் செய்ய முடியவில்லை.

பிரச்சனை இன்னும் தீர்க்கப்பட வேண்டியிருப்பதால், நான் JOINs மற்றும் Pivots of tables பற்றி சிந்திக்க ஆரம்பித்தேன், இது நேர்த்தியின் அடிப்படையில் நம்பிக்கையைத் தூண்டவில்லை, ஆனால் நடைமுறையில் முற்றிலும் செயல்படக்கூடிய விருப்பமாக இருக்கலாம்.

எங்கள் திட்டம் ஏற்கனவே 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 வினாடிகளுக்குள் முடிக்கப்படும். 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 ஐப் பயன்படுத்தி நிகழ்வு ஸ்ட்ரீமை முன்-செயலாக்குவதன் மூலம், மெட்டீரியல் செய்யப்பட்ட பார்வைகள் மற்றும் இணையானதாக்குதல் ஆகியவற்றைப் பயன்படுத்தி வினவல்களை எப்போதும் மேம்படுத்தலாம்.

செயல்திறன் மிகவும் நன்றாக உள்ளது, எனவே அட்டவணைகளை நிரல் ரீதியாக மாற்றுவது பற்றி நாம் சிந்திக்க வேண்டியதில்லை. முன்னதாக, வெர்டிகாவிலிருந்து Apache Parquet க்கு பதிவேற்றம் செய்வதன் மூலம் மீட்டெடுக்கப்பட்ட தரவுகளின் பிவோட்களை நாங்கள் செய்ய வேண்டியிருந்தது.

துரதிர்ஷ்டவசமாக, 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

கருத்தைச் சேர்