Чи правильне це порівняння Neo4j з часом виконання RDBMS?

Передумови: Далі йде з книги " Графічні бази даних" , яка охоплює тест на ефективність, згаданий у книзі Neo4j в дії :

Взаємовідносини в графі природно утворюють контури. Запит або перегляд графіка включає наступні шляхи. Через принципово орієнтований на дорогу характер моделімоделі, більшість операцій з базою даних графіків на основі контурів сильно узгоджуються із способом викладення даних, що робить їх надзвичайно ефективними. У своїй книзі Neo4j у дії, партнер та 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 працює в дві третини часу реляційного, кінцевий користувач ледь помітить різницю в мілісекундах між ними. До того моменту, коли ми досягнемо три глибини (friend-of-friend-of-friend), однак, зрозуміло, що реляційна база даних вже не може обробляти запит у розумні часові рамки: тридцять секунд, необхідних для виконання, були б абсолютно неприйнятними. для онлайн-системи. На відміну від цього, час відповіді Neo4j залишається відносно рівним: лише частина секунди для виконання запиту - безумовно, досить швидка для онлайн-системи.

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

Питання:

• Це розумний тест, щоб наслідувати те, що можна окрім як знайти у соціальній мережі? (Це означає, що у справжніх соціальних мереж зазвичай є вузли з приблизно 50 друзями, наприклад; схоже, що модель " збагатитися збагачується " була б більш природною для соціальних мереж, хоча це може бути неправильно.)
• Незалежно від природності емуляції, чи є підстави вважати, що результати вимкнено чи невідтворювані?

Дивлячись на цей документ під назвою " Анатомія Facebook", зауважу, що медіана становить 100. Дивлячись на сукупний графік функцій, я можу зробити ставку, що середнє значення вище, близько 200. Тож 50, здається, не найкраще число тут. Однак я думаю, що це не головне питання.

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

Здається розумним, що зберігання даних, розроблене спеціально для структур графіків, буде більш ефективним, ніж традиційні RDBM. Однак, навіть якщо RDBM не входять в останні тенденції як вибір зберігання даних, ці системи постійно розвиваються в гонці з розмірами набору даних. Існують різні типи можливих конструкцій, різні способи індексації даних, удосконалення, пов’язані з одночасністю тощо.

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

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

• Деякі використовують розумні індексації та Stored Procs, торгують завантаженням процесора та налаштовують тимчасові таблиці на дисках оперативної пам’яті для більш швидкої швидкості пошуку графіків.

• Деякі використовують попередньо обчислені контури графіків (це може бути менш здійсненно в сценарії соціальної мережі, але в дереві, де більшість вузлів є вузликами листя, це досить хороший проміжок часу на час

• Деякі просто обчислюють цикл, використовуючи невідрегульовану таблицю тимчасових темпів. З #, кинутого в статті, це пахне тим, що вони зробили (30 секунд - продуктивність на досить невеликих наборах даних)

  Наприклад, у мене є власне обчислення дерев.

  • Він інкапсульований у високоналагодженому зберіганні

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

  • У мене не було доступу до основного інструменту прискорення, темп-таблиці на диску оперативної пам’яті.

  • Представницький набір даних, який я отримував, і, здається, дещо відповідає їхньому, отримував піддірець 150 000 вузлів з повного набору даних лісу в 2,5 М вузла (необмежена глибина дерева, яка коливається між 5 і 15, але менша середня аритність даного вузла, ніж 50 друзів, перелічених в експерименті)

  • Я налаштував його на те, що цей запит ~ 30-45 секунд. Це, звичайно, НЕ демонструє експоненціальне уповільнення, яке фігури у питанні, схоже, вказують на їх продуктивність RDBMS, що є надзвичайно подвійним дивним, враховуючи, що експоненціальне зростання набору результатів (яке, як мені здається, викликає невідрегульований індекс на таблиця темп із особистого досвіду).

Таким чином, це порівняння, швидше за все, є невірним і засноване на поганій конструкції сторони RDBMS, хоча, як зазначалося в попередній відповіді, неможливо встановити без них відкриті джерела пошуку 100% визначень коду та таблиці.