ການ​ທົດ​ລອງ​ການ​ທົດ​ສອບ​ການ​ນໍາ​ໃຊ້​ຂອງ JanusGraph graph DBMS ສໍາ​ລັບ​ການ​ແກ້​ໄຂ​ບັນ​ຫາ​ຂອງ​ການ​ຊອກ​ຫາ​ເສັ້ນ​ທາງ​ທີ່​ເຫມາະ​ສົມ

ສະບາຍດີທຸກຄົນ. ພວກເຮົາກໍາລັງພັດທະນາຜະລິດຕະພັນສໍາລັບການວິເຄາະການຈະລາຈອນອອບໄລນ໌. ໂຄງການດັ່ງກ່າວມີວຽກງານທີ່ກ່ຽວຂ້ອງກັບການວິເຄາະສະຖິຕິຂອງເສັ້ນທາງນັກທ່ອງທ່ຽວໃນທົ່ວພາກພື້ນ.

ເປັນສ່ວນຫນຶ່ງຂອງວຽກງານນີ້, ຜູ້ໃຊ້ສາມາດຖາມຄໍາຖາມລະບົບຂອງປະເພດດັ່ງຕໍ່ໄປນີ້:

• ນັກທ່ອງທ່ຽວຈາກເຂດ "A" ໄປເຂດ "B" ມີຈໍານວນເທົ່າໃດ;
• ນັກທ່ອງທ່ຽວຜ່ານເຂດ "A" ໄປຫາເຂດ "B" ຜ່ານເຂດ "C" ແລະຫຼັງຈາກນັ້ນຜ່ານເຂດ "D";
• ມັນໃຊ້ເວລາດົນປານໃດສໍາລັບນັກທ່ອງທ່ຽວປະເພດໃດນຶ່ງໃນການເດີນທາງຈາກເຂດ “A” ໄປເຂດ “B”.

ແລະການສອບຖາມການວິເຄາະທີ່ຄ້າຍຄືກັນຈໍານວນຫນຶ່ງ.

ການ​ເຄື່ອນ​ໄຫວ​ຂອງ​ຜູ້​ມາ​ຢ້ຽມ​ຢາມ​ໃນ​ທົ່ວ​ພື້ນ​ທີ່​ແມ່ນ​ເສັ້ນ​ສະ​ແດງ​ກໍາ​ນົດ​. ຫຼັງຈາກອ່ານອິນເຕີເນັດ, ຂ້າພະເຈົ້າໄດ້ຄົ້ນພົບວ່າ DBMSs graph ຍັງຖືກນໍາໃຊ້ສໍາລັບບົດລາຍງານການວິເຄາະ. ຂ້າພະເຈົ້າມີຄວາມຕ້ອງການທີ່ຈະເບິ່ງວ່າ DBMSs ຈະຮັບມືກັບການສອບຖາມດັ່ງກ່າວແນວໃດ (TL; DR; ບໍ່ດີ).

ຂ້ອຍເລືອກໃຊ້ DBMS JanusGraph, ເປັນຕົວແທນທີ່ໂດດເດັ່ນຂອງກາຟແຫຼ່ງເປີດ DBMS, ເຊິ່ງອີງໃສ່ເຕັກໂນໂລຢີທີ່ໃຫຍ່ຫຼວງຫຼາຍ, ເຊິ່ງ (ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ) ຄວນໃຫ້ມັນມີລັກສະນະປະຕິບັດງານທີ່ເຫມາະສົມ:

• Backend ການເກັບຮັກສາ BerkeleyDB, Apache Cassandra, Scylla;
• ດັດສະນີຊັບຊ້ອນສາມາດຖືກເກັບໄວ້ໃນ Lucene, Elasticsearch, Solr.

ຜູ້ຂຽນຂອງ JanusGraph ຂຽນວ່າມັນເຫມາະສົມສໍາລັບທັງ OLTP ແລະ OLAP.

ຂ້ອຍໄດ້ເຮັດວຽກກັບ BerkeleyDB, Apache Cassandra, Scylla ແລະ ES, ແລະຜະລິດຕະພັນເຫຼົ່ານີ້ມັກຈະຖືກໃຊ້ໃນລະບົບຂອງພວກເຮົາ, ດັ່ງນັ້ນຂ້ອຍມີຄວາມຫວັງໃນການທົດສອບ DBMS graph ນີ້. ຂ້ອຍພົບວ່າມັນແປກທີ່ຈະເລືອກ BerkeleyDB ຫຼາຍກວ່າ RocksDB, ແຕ່ນັ້ນອາດຈະເປັນຍ້ອນຄວາມຕ້ອງການການເຮັດທຸລະກໍາ. ໃນກໍລະນີໃດກໍ່ຕາມ, ສໍາລັບການຂະຫຍາຍ, ການນໍາໃຊ້ຜະລິດຕະພັນ, ແນະນໍາໃຫ້ໃຊ້ backend ກ່ຽວກັບ Cassandra ຫຼື Scylla.

ຂ້າພະເຈົ້າບໍ່ໄດ້ພິຈາລະນາ Neo4j ເພາະວ່າການຈັດກຸ່ມຮຽກຮ້ອງໃຫ້ມີສະບັບການຄ້າ, ນັ້ນແມ່ນ, ຜະລິດຕະພັນບໍ່ແມ່ນແຫຼ່ງເປີດ.

Graph DBMSs ເວົ້າວ່າ: "ຖ້າມັນຄ້າຍຄືກາຟ, ປະຕິບັດມັນຄືກັບກາຟ!" - ຄວາມງາມ!

ກ່ອນອື່ນ ໝົດ, ຂ້ອຍໄດ້ແຕ້ມກາຟ, ເຊິ່ງຖືກເຮັດຕາມ canons ຂອງກາຟ 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, ເອົາຈຸດຕັ້ງທັງຫມົດທີ່ແຂບໄປຫາມັນ (ZoneStep), ຢຸດໂດຍບໍ່ໄດ້ກັບຄືນຈົນກວ່າທ່ານຈະຊອກຫາ ZoneSteps ທີ່ມີຂອບໄປຫາເຂດທີ່ມີ. ID=19, ນັບຈຳນວນຕ່ອງໂສ້ດັ່ງກ່າວ.

ຂ້າ​ພະ​ເຈົ້າ​ບໍ່​ໄດ້​ທໍາ​ທ່າ​ທີ່​ຈະ​ຮູ້​ຈັກ intricacies ທັງ​ຫມົດ​ຂອງ​ການ​ຊອກ​ຫາ​ໃນ​ກາ​ຟ​, ແຕ່​ການ​ສອບ​ຖາມ​ນີ້​ໄດ້​ຖືກ​ສ້າງ​ຂຶ້ນ​ໂດຍ​ອີງ​ໃສ່​ປຶ້ມ​ນີ້ (https://kelvinlawrence.net/book/Gremlin-Graph-Guide.html).

ຂ້າພະເຈົ້າໄດ້ໂຫລດ 50 ພັນເພງຕັ້ງແຕ່ 3 ຫາ 20 ຈຸດໃນຄວາມຍາວເຂົ້າໄປໃນຖານຂໍ້ມູນ JanusGraph ໂດຍໃຊ້ backend BerkeleyDB, ສ້າງດັດສະນີອີງຕາມການ ຄວາມເປັນຜູ້ນໍາ.

script ດາວໂຫຼດ 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 ແລະ RAM 16 GB ໃນ SSD. JanusGraph ຖືກນຳໃຊ້ໂດຍໃຊ້ຄຳສັ່ງນີ້:

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

ໃນກໍລະນີນີ້, ຂໍ້ມູນແລະດັດສະນີທີ່ຖືກນໍາໃຊ້ສໍາລັບການຄົ້ນຫາກົງກັນທີ່ແນ່ນອນຈະຖືກເກັບໄວ້ໃນ BerkeleyDB. ໂດຍໄດ້ປະຕິບັດຄໍາຮ້ອງຂໍທີ່ໃຫ້ກ່ອນຫນ້ານີ້, ຂ້າພະເຈົ້າໄດ້ຮັບເວລາເທົ່າກັບຫຼາຍສິບວິນາທີ.

ໂດຍການແລ່ນ 4 scripts ຂ້າງເທິງໃນຂະຫນານ, ຂ້າພະເຈົ້າໄດ້ຈັດການປ່ຽນ 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 ຂອງຕາຕະລາງ, ເຊິ່ງບໍ່ໄດ້ດົນໃຈໃນແງ່ດີໃນແງ່ຂອງຄວາມສະຫງ່າງາມ, ແຕ່ອາດຈະເປັນທາງເລືອກທີ່ເຮັດວຽກໄດ້ຢ່າງສົມບູນໃນການປະຕິບັດ.

ໂຄງການຂອງພວກເຮົາໃຊ້ 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

ຂ້າພະເຈົ້າໄດ້ຕື່ມຂໍ້ມູນໃສ່ມັນໂດຍໃຊ້ script ຕໍ່ໄປນີ້:

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
    )

ນັບຕັ້ງແຕ່ inserts ເຂົ້າມາໃນ batches, ການຕື່ມຂໍ້ມູນແມ່ນໄວກວ່າ 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 ໄດ້ສ້າງການໂຫຼດຫນ້ອຍສຸດໃນລະບົບຍ່ອຍຂອງແຜ່ນ.

ສະຫລຸບ

ພວກເຮົາໄດ້ຕັດສິນໃຈໃຊ້ 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. ຕົວຢ່າງ, ການສ້າງດັດສະນີຕ້ອງເຮັດໂດຍການຂຽນລະຫັດໃນ console 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()

ຂ້ອຍບໍ່ສາມາດໄດ້ຮັບການຕອບສະຫນອງທີ່ມີປະສິດຕິພາບໂດຍໃຊ້ເວລາປະມວນຜົນຫນ້ອຍກວ່າຫນຶ່ງວິນາທີ.

ສົມບັດສິນທໍາຂອງເລື່ອງແມ່ນວ່າຄວາມຄິດທີ່ສວຍງາມແລະການສ້າງແບບຈໍາລອງແບບ paradigmatic ບໍ່ໄດ້ນໍາໄປສູ່ຜົນໄດ້ຮັບທີ່ຕ້ອງການ, ເຊິ່ງສະແດງໃຫ້ເຫັນເຖິງປະສິດທິພາບສູງກວ່າຫຼາຍໂດຍໃຊ້ຕົວຢ່າງຂອງ ClickHouse. ກໍລະນີການນໍາໃຊ້ທີ່ນໍາສະເຫນີໃນບົດຄວາມນີ້ແມ່ນເປັນຮູບແບບການຕໍ່ຕ້ານທີ່ຊັດເຈນສໍາລັບກາຟ DBMSs, ເຖິງແມ່ນວ່າມັນເບິ່ງຄືວ່າເຫມາະສົມສໍາລັບການສ້າງແບບຈໍາລອງໃນຄໍາຂວັນຂອງພວກເຂົາ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com