ექსპერიმენტი, რომელიც ამოწმებს JanusGraph გრაფიკის DBMS-ის გამოყენებადობას შესაფერისი გზების პოვნის პრობლემის გადასაჭრელად

Სალამი ყველას. ჩვენ ვამუშავებთ პროდუქტს ოფლაინ ტრაფიკის ანალიზისთვის. პროექტს აქვს ამოცანა, რომელიც დაკავშირებულია რეგიონებში ვიზიტორთა მარშრუტების სტატისტიკურ ანალიზთან.

როგორც ამ ამოცანის ნაწილი, მომხმარებლებს შეუძლიათ დაუსვან სისტემის მოთხოვნები შემდეგი ტიპის:

• რამდენი ვიზიტორი გავიდა "A" ზონიდან "B" ზონაში;
• რამდენი ვიზიტორი გავიდა "A" ზონიდან "B" ზონაში "C" და შემდეგ "D" ზონის გავლით;
• რამდენი დრო დასჭირდა გარკვეული ტიპის ვიზიტორს მოგზაურობისთვის "A" ზონიდან "B"-მდე.

და რიგი მსგავსი ანალიტიკური მოთხოვნები.

ვიზიტორის მოძრაობა ზონებში არის მიმართული გრაფიკი. ინტერნეტის წაკითხვის შემდეგ აღმოვაჩინე, რომ გრაფიკული DBMS ასევე გამოიყენება ანალიტიკური ანგარიშებისთვის. მინდოდა მენახა, როგორ გაუმკლავდნენ გრაფიკული DBMS ასეთ შეკითხვებს (TL; DR; ცუდად).

მე ავირჩიე DBMS-ის გამოყენება იანუსგრაფი, როგორც გრაფიკული ღია კოდის DBMS-ის გამორჩეული წარმომადგენელი, რომელიც ეყრდნობა მომწიფებული ტექნოლოგიების დასტას, რომელიც (ჩემი აზრით) უნდა უზრუნველყოს მას ღირსეული ოპერატიული მახასიათებლები:

• BerkeleyDB შენახვის backend, Apache Cassandra, Scylla;
• რთული ინდექსების შენახვა შესაძლებელია Lucene, Elasticsearch, Solr.

JanusGraph-ის ავტორები წერენ, რომ ის შესაფერისია როგორც OLTP-სთვის, ასევე OLAP-ისთვის.

მე ვმუშაობდი BerkeleyDB-თან, Apache Cassandra-სთან, Scylla-სთან და ES-თან და ეს პროდუქტები ხშირად გამოიყენება ჩვენს სისტემებში, ამიტომ ოპტიმისტურად ვიყავი განწყობილი ამ გრაფიკის DBMS-ის გამოცდაზე. მე უცნაურად მივიჩნიე, რომ ავირჩიო BerkeleyDB RocksDB-ზე, მაგრამ ეს ალბათ ტრანზაქციის მოთხოვნების გამოა. ნებისმიერ შემთხვევაში, მასშტაბური, პროდუქტის გამოყენებისთვის, რეკომენდებულია კასანდრაზე ან სკილაზე ბექენდის გამოყენება.

მე არ განვიხილე Neo4j, რადგან კლასტერირება მოითხოვს კომერციულ ვერსიას, ანუ პროდუქტი არ არის ღია წყარო.

გრაფიკული DBMS ამბობს: „თუ ის გრაფიკას ჰგავს, მოექეცით მას როგორც გრაფიკს!“ - სილამაზე!

ჯერ დავხატე გრაფიკი, რომელიც ზუსტად შედგენილია გრაფიკის 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-ს, საიდანაც არის ზღვარი ზონაში. ID=19, დაითვალეთ ასეთი ჯაჭვების რაოდენობა.

მე არ ვიტყვი, რომ ვიცი გრაფიკებზე ძიების ყველა სირთულე, მაგრამ ეს შეკითხვა შეიქმნა ამ წიგნის საფუძველზე (https://kelvinlawrence.net/book/Gremlin-Graph-Guide.html).

მე ჩავტვირთე 50 ათასი ტრეკი, სიგრძით 3-დან 20 ქულამდე JanusGraph გრაფიკის მონაცემთა ბაზაში BerkeleyDB backend-ის გამოყენებით, შევქმენი ინდექსები მიხედვით ხელმძღვანელობა.

პითონის ჩამოტვირთვის სკრიპტი:

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-ზე გამოვიყენეთ VM 4 ბირთვით და 16 GB ოპერატიული მეხსიერებით. 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-ით, დაარტყით უკან დაბრუნების გარეშე, სანამ არ იპოვით ZoneStep ID=19-ით, დათვალეთ ასეთი ჯაჭვების რაოდენობა.

მე ასევე გავამარტივე ზემოთ მოცემული ჩატვირთვის სკრიპტი, რათა არ შემექმნა ზედმეტი კავშირები, შემოვიფარგლო ატრიბუტებით.

მოთხოვნას ჯერ კიდევ რამდენიმე წამი დასჭირდა, რაც სრულიად მიუღებელი იყო ჩვენი ამოცანისთვის, რადგან ის საერთოდ არ იყო შესაფერისი რაიმე სახის AdHoc მოთხოვნების მიზნებისთვის.

მე ვცადე JanusGraph-ის დანერგვა Scylla-ს გამოყენებით, როგორც ყველაზე სწრაფი Cassandra განხორციელების, მაგრამ ამან ასევე არ გამოიწვია რაიმე მნიშვნელოვანი შესრულების ცვლილებები.

ასე რომ, მიუხედავად იმისა, რომ "ის ჰგავს გრაფიკს", მე ვერ მივიღე გრაფიკის DBMS მისი სწრაფად დასამუშავებლად. მე სრულად ვვარაუდობ, რომ არის რაღაც, რაც არ ვიცი და რომ JanusGraph-ს შეუძლია შეასრულოს ეს ძებნა წამის ნაწილში, თუმცა მე ეს ვერ შევძელი.

იმის გამო, რომ პრობლემა ჯერ კიდევ მოსაგვარებელი იყო, დავიწყე ფიქრი ცხრილების JOIN-სა და Pivots-ზე, რომლებიც არ შთააგონებდნენ ელეგანტურობის კუთხით ოპტიმიზმს, მაგრამ პრაქტიკაში შეიძლება იყოს სრულიად გამოსადეგი ვარიანტი.

ჩვენი პროექტი უკვე იყენებს 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

მე შევქმენი მონაცემთა ბაზა და ცხრილი მასში ასე:

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 წამზე ნაკლებ დროში. აქ არის მოთხოვნის შესრულების დროის მაგალითი count(*)-ისთვის, რომელიც გადის 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-ში ჩატვირთავთ.

შესრულება იმდენად კარგია, რომ ცხრილების პროგრამულად გადახვევაზე ფიქრიც არ მოგვიწევს. ადრე ჩვენ უნდა გაგვეკეთებინა ვერტიკიდან ამოღებული მონაცემების კრებული Apache Parket-ზე ატვირთვის გზით.

სამწუხაროდ, გრაფიკის 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 ვერსიის „დადება“.

დოკუმენტაცია ინდექსების თვალსაზრისით საკმაოდ მრუდეა, რადგან ინდექსების მართვა მოითხოვს თქვენგან შეასრულოთ საკმაოდ უცნაური შამანიზმი 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-ის მაგალითით. ამ სტატიაში წარმოდგენილი გამოყენების შემთხვევა აშკარა ანტი-ნიმუშია გრაფიკული DBMS-ებისთვის, თუმცა, როგორც ჩანს, შესაფერისია მათი პარადიგმის მოდელირებისთვის.

წყარო: www.habr.com