В настоящее время я вижу низкую производительность одновременной записи при добавлении ребер в вершины, которые уже имеют много ребер. Вершины, которые агрегируют другие вершины с большим количеством ребер, называются суперузлами .
Супер узлы вызывают множество проблем:
Ухудшение производительности записи
Добавление новых ребер будет постепеннозамедляться с каждым добавленным ребром.
Причина была указана OrientDB:
К сожалению, невозможно добавить ребра в вершины без загрузки всех связанных структур.
Конфликт при обработке одновременных запросов
При одновременном добавлении новых вершин также необходимо обновить суперузлы. Это можно быстро определить, проверив, какие узлы имеют высокий номер версии.
SELECT @version, @rid, @class from V where @version >40 order by @version DESC
Одновременные обновления для одних и тех же элементов вызовут ожидаемые ошибки, которые потребуют от пользователя повторной попытки транзакции. Это связано с шаблоном MVCC, который OrientDB использует и ожидает.
Для этого потребуется повторить транзакцию. Это приведет к значительному снижению скорости записи.
Параметры
Какие существуют варианты для улучшения производительности в этой ситуации?
Параметры, которые я нашел:
- Удаление суперузлов (не всегда возможно)
- Сегментирование суперузлов путем добавления ребер и вершин к этой вершине, с которой могут соединяться фактически агрегированные вершины.
- Удаление суперузлов и замена их вместо индексированных свойств. дочерние вершины содержат свойство, которое идентифицирует «коллекцию», к которой они принадлежат. Таким образом, индекс можно использовать для быстрого поиска всех вершин в этой коллекции.
Вопросы
Я пока не знаю, как OrientDB может обрабатывать конфликты по индексам, которые могут возникнуть при добавлении индексазаписей. Я предполагаю, что такого рода споры могут быть обработаны более эффективно и могут не вызывать ошибок, которые требуют повторной передачи.
Я знаю, что возможно добавить явные блокировки с OrientDB. Помогут ли эти замки справиться с проблемами раздора? Эти блокировки распространяются на другие узлы кластера?
Есть ли какие-то другие факторы, которые я упустил из виду?
Как базы данных, такие как Neo4j, справляются с конфликтами и суперузлами? Применяются ли подобные ограничения?