Является ли это сравнение Neo4j со временем выполнения СУБД правильным?

Справочная информация: Ниже приводится книга « Базы данных графиков» , в которой описывается тест производительности, упомянутый в книге « Neo4j в действии» :

Отношения в графе естественно образуют пути. Запрос или обход графика включает в себя следующие пути. Из-за принципиально ориентированной на путь природы модели данных большинство операций с базой данных на основе путей графа тесно связаны с тем, как располагаются данные, что делает их чрезвычайно эффективными. В своей книге Neo4j в действии Partner и Vukotic проводят эксперимент с использованием реляционного магазина и Neo4j.

Сравнение показывает, что графическая база данных значительно быстрее для связанных данных, чем реляционный магазин. Эксперимент Партнера и Вукотика направлен на поиск друзей в социальной сети, максимально на пять глубин. Имеются ли произвольно выбранные два человека, существует ли какой-то путь, который связывает их не более чем в пять отношений? Для социальной сети, содержащей 1 000 000 человек, каждый из которых имеет приблизительно 50 друзей, результаты убедительно показывают, что графические базы данных являются лучшим выбором для связанных данных, как мы видим в Таблице 2-1.

Таблица 2-1. Поиск расширенных друзей в реляционной базе данных по сравнению с эффективным поиском в Neo4j

Depth   RDBMS Execution time (s)    Neo4j Execution time (s)     Records returned
2       0.016                       0.01                         ~2500    
3       30.267                      0.168                        ~110,000 
4       1543.505                    1.359                        ~600,000 
5       Unfinished                  2.132                        ~800,000

На втором уровне (друзья друзей) и реляционная база данных, и база данных графов работают достаточно хорошо, чтобы мы могли рассмотреть их использование в онлайн-системе. Хотя запрос Neo4j выполняется в две трети времени от реляционного запроса, конечный пользователь едва заметит разницу в миллисекундах между ними. Однако к моменту, когда мы достигнем третьей глубины («друг друга друга»), становится ясно, что реляционная база данных больше не может обрабатывать запрос в разумные сроки: тридцать секунд, которые требуются для выполнения, будут совершенно неприемлемы для онлайн-системы. Напротив, время отклика Neo4j остается относительно плоским: всего лишь доли секунды для выполнения запроса - определенно достаточно быстро для онлайн-системы.

На четвертой глубине реляционная база данных демонстрирует сокрушительную задержку, что делает ее практически бесполезной для онлайн-системы. Время Neo4j тоже немного ухудшилось, но задержка здесь на периферии приемлемости для отзывчивой онлайн-системы. Наконец, на пятой глубине реляционная база данных просто занимает слишком много времени для выполнения запроса. Neo4j, напротив, возвращает результат примерно через две секунды. На пятой глубине выясняется, что почти вся сеть - наш друг: для многих реальных случаев использования мы, вероятно, сократили бы результаты и сроки.

Вопросы:

• Это разумный тест для подражания тому, что можно найти, кроме как найти в социальной сети? (Имеется в виду, например, что в реальных социальных сетях обычно есть узлы с примерно 50 друзьями; кажется, что модель " богатые становятся богаче " была бы более естественной для социальных сетей, хотя и может быть ошибочной.)
• Независимо от естественности эмуляции, есть ли основания полагать, что результаты отрицательны или не воспроизводимы?

Глядя на этот документ под названием « Анатомия Facebook», я отмечаю, что медиана равна 100. Глядя на график совокупной функции, я могу поспорить, что среднее значение выше, около 200. Таким образом, 50, похоже, не является лучшим числом здесь. Однако я думаю, что это не главная проблема здесь.

Основной проблемой является отсутствие информации о том, как использовалась база данных.

Представляется разумным, что хранилище данных, разработанное специально для графовых структур, должно быть более эффективным, чем традиционные RDBM. Однако даже если RDBM не соответствуют последним тенденциям в качестве хранилища данных, эти системы постоянно развивались в гонке с размерами набора данных. Существуют различные типы возможных конструкций, различные способы индексации данных, улучшения, связанные с параллелизмом и так далее.

В заключение, я думаю, что в отношении воспроизводимости, в исследовании отсутствует правильное описание того, как была разработана схема базы данных. Я не ожидаю, что база данных будет доминировать на таком короле допросов, однако я ожидаю, что при хорошо настроенном дизайне различия не будут такими большими.

Есть хорошие / быстрые способы моделирования графиков в RDBMS, и тупые / медленные способы.

• Некоторые используют умную индексацию и Stored Procs, торгуют загрузкой процессора и настроенными временными таблицами на RAM-дисках для более быстрой скорости получения графиков.

• Некоторые используют пути предварительно вычисленных графов (это может быть менее осуществимо в сценарии социальной сети, но в дереве с большинством узлов, являющихся конечными узлами, это довольно хороший компромисс для времени

• Некоторые просто вычисляют в цикле, используя ненастроенную индексированную временную таблицу. От #s, добавленных в статью, пахнет как то, что они сделали (30 секунд - производительность на довольно маленьком наборе данных)

  Например, у меня есть свои собственные вычисления дерева.

  • Он инкапсулирован в хорошо настроенный хранимый процесс

  • Хотя он работает на аппаратном сервере данных Sybase ASE15 корпоративного размера, этот сервер используется совместно с парой терабайт данных из всех других корпоративных приложений, некоторые из которых гораздо более голодны, чем мои; и не посвящен исключительно выполнению моих запросов.

  • У меня не было доступа к основному инструменту ускорения, временной таблице на диске RAM.

  • Репрезентативный набор данных, который я собирал и который, по-видимому, несколько соответствовал их данным, получал 150000 поддерево узла из набора данных полного леса узла 2.5M (неограниченная глубина дерева, которая варьируется между 5 и 15, но меньшая средняя арность данного узла, чем 50 друзей, перечисленных в эксперименте)

  • Я настроил его до такой степени, что этот запрос ~ 30-45 секунд. Это, безусловно, не демонстрирует экспоненциальное замедление, которое цифры в вопросе, кажется, указывают на их производительность RDBMS, что является вдвойне странным, учитывая, что в наборе результатов нет экспоненциального роста (что мне кажется, не настроенный индекс на временная таблица из личного опыта).

Таким образом, это сравнение, скорее всего, неверно и основано на плохом дизайне стороны СУБД, хотя, как отмечалось в предыдущем ответе, невозможно установить без них открытый исходный код 100% их кодов и определений таблиц.