OrientDB fetchplan - PullRequest
Новая
       12

OrientDB fetchplan

0 голосов
/ 05 июля 2018

У меня проблема с fetchplan в OrientDB 2.2.35

Моя ситуация следующая: у меня есть граф с двумя классами вершин: ridClass и tokenClass, и они связаны через облегченные ребра следующим образом: ridClass->tokenClass->ridClass В моей программе я хочу начать с вершины ridClass и перейти ко всем связанным вершинам tokenClass и из них ко всем связанным вершинам ridClass. Я использую SQL для поиска начальной вершины (ridClass) и GremlinPipeline для пересечения графа.

Я запускаю новый поток для каждого ядра процессора, поэтому в моем случае я запускаю 4 потока. В каждой теме это выглядит так: 

GremlinPipeline pipe = new GremlinPipeline();
OrientDynaElementIterable orientDynaElementIterable = graph.command(new OCommandSQL("select from #18:" + String.valueOf(indexPosition) + " fetchplan ridClass:3")).execute();
pipe.start(orientDynaElementIterable);
pipe.out();
List<Vertex> currentTokenList = pipe.toList();
for (Vertex currentToken : currentTokenList) {
    GremlinPipeline pipe2 = new GremlinPipeline();
    pipe2.start(currentToken);
    pipe2.out();
    List<Vertex> currentRIDList = pipe2.toList();
    for (Vertex currentRidVertex : currentRIDList) {
        //here I do something with the vertices...
    }
}

Из логики я получаю правильные вершины, но проблема в fetchplan. Если я использую fetchplan ridClass:3, как в graph.command в моем коде выше, моя программа не будет быстрее, скорее немного медленнее, чем если бы я не установил fetchplan. Я думал, что с этим fetchplan он возвращает с запросом SQL дополнительные все связанные вершины tokenClass и из этих следующих ridClass вершин в кеш? Это, вероятно, слишком много для кеша или я неправильно понимаю fetchplan? Даже если я уменьшу уровень глубины fetchplan как этот fetchplan ridClass:1, моя программа будет медленнее.

Моя конфигурация OrientDB выглядит следующим образом (мой компьютер имеет 8 ГБ ОЗУ): 

<properties>
    <entry value="1" name="db.pool.min"/>
    <entry value="50" name="db.pool.max"/>
    <entry value="false" name="profiler.enabled"/>
    <entry value="6000" name="storage.diskCache.bufferSize"/>
    <entry value="false" name="storage.useWAL"/>
    <entry value="4000" name="hashTable.slitBucketsBuffer.length"/>
    <entry value="8" name="storage.diskCache.writeCachePart"/>
    <entry value="500" name="storage.record.lockTimeout"/>
    <entry value="notx_sync_repair" name="sql.graphConsistencyMode"/>
</properties>

Может быть, у кого-то есть идея для этой проблемы.

С уважением

Седир Мухаммед

...