Які випадки використання баз даних на основі графіків (http://neo4j.org/)? [зачинено]

Я багато використовував реляційні БД і вирішив зайнятися іншими доступними типами.

Цей товар виглядає добре і перспективно: http://neo4j.org/

Хтось використовував бази даних на основі графіків? Які плюси і мінуси в перспективі зручності використання?

Ви використовували їх у виробничих умовах? Яка вимога спонукала вас використовувати їх?

Я використовував базу даних графіків у попередньому завданні. Ми не використовували neo4j, це була внутрішня річ, побудована на базі Берклі DB, але це було схоже. Він використовувався у виробництві (він досі є).

Причиною, по якій ми використовували базу даних графіків, було те, що дані, що зберігаються системою, і операції, які система робила з даними, були саме слабким місцем реляційних баз даних і були саме сильним місцем баз даних графіків. Системі, необхідній для зберігання колекцій об'єктів, яким не вистачає фіксованої схеми і пов'язані між собою відносинами. Для того, щоб міркувати про дані, системі потрібно було зробити багато операцій, які б були парами обходу в базі даних графіків, але це були б досить складні запити в SQL.

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

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

Основним недоліком було те, що ми не використовували стандартну реляційну базу даних, що може бути проблемою, коли ваші клієнти є підприємливими. Наші клієнти запитують, чому ми не могли просто розмістити наші дані на своїх гігантських кластерах Oracle (зазвичай наші клієнти мали великі центри обробки даних). Одна з команди фактично переписала шар бази даних для використання Oracle (або PostgreSQL, або MySQL), але це було трохи повільніше, ніж оригінал. Принаймні одне велике підприємство навіть проводило політику, що стосується лише Oracle, але, на щастя, Oracle купив Berkeley DB. Нам також довелося написати багато додаткових інструментів - ми не могли просто використати Crystal Reports, наприклад.

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

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

Якщо вашій програмі не потрібно вписуватися в поточну архітектуру blub, використовуйте графічну базу даних, або CouchDB, або BigTable, або все, що відповідає вашому додатку, і ви вважаєте, що це здорово. Це може дати вам перевагу та весело пробувати нові речі.

Що б ви не вибрали, намагайтеся не створювати двигун бази даних самостійно, якщо вам не подобається створення двигунів бази даних.

Ми працюємо з командою Neo вже більше року і були дуже раді. Ми моделюємо артефакти наукових досліджень та їх взаємозв'язки, що вказується на графіку db, та запускаємо рекомендаційні алгоритми по мережі.

Якщо ви вже працюєте в Java, я думаю, що моделювання з використанням Neo4j дуже прямо, і воно має найвищу / найшвидшу продуктивність для R / W будь-яких інших рішень, які ми намагалися.

Якщо чесно, мені важко не думати з точки зору графіка / мережі, тому що це набагато простіше, ніж проектувати складні структури таблиць, щоб утримувати властивості об'єкта та відносини.

Зважаючи на це, ми зберігаємо деяку інформацію в MySQL просто тому, що для Business сторони легше запускати швидкі запити SQL. Для виконання тих же функцій з Neo нам потрібно було б написати код, у якого просто зараз немає смуги пропускання. Як тільки ми це зробимо, я переміщу всі ці дані до Neo!

Удачі.

Два бали:

По-перше, на даних, якими я працював протягом останніх 5 років у SQL Server, нещодавно я потрапив у стіну масштабування за допомогою SQL за типом запитів, які нам потрібно виконувати (вкладені відношенняhsips ... ви знаєте ... графіки ). Я граю з neo4j, і час мого пошуку на кілька порядків швидше, коли мені потрібен такий вид пошуку.

По-друге, до того, що графічні бази даних застаріли. Гм ... ні. На початку, коли люди намагалися зрозуміти, як ефективно зберігати та шукати дані, вони створювали та грали з моделями баз даних графіків та мереж. Вони були розроблені так, щоб фізична модель відображала логічну модель, тому їх ефективність була не такою великою. Цей тип структури даних був хорошим для напівструктурованих даних, але не такий гарний для структурованих щільних даних. Отже, цей хлопець IBM на ім'я Кодд досліджував ефективні способи впорядкування та зберігання структурованих даних і придумав ідею для реляційної моделі баз даних. І це було добре, і люди були щасливі.

Що ми маємо тут? Два інструменти для двох різних цілей. Моделі баз даних графіків дуже хороші для представлення напівструктурованих даних та взаємозв'язків між сутностями (які можуть бути або не існувати). Реляційні бази даних хороші для структурованих даних, що мають дуже статичну схему, і де глибина з'єднання не надто глибока. Один хороший для одного виду даних, інший - для інших видів даних.

Щоб вивести фразу, немає срібної кулі. Дуже короткозорість говорить про те, що моделі баз даних графіків застаріли, а їх використання дає 40 років прогресу. Це як би сказати, що використання C - це відмова від усього технологічного прогресу, який ми пережили, щоб отримати такі речі, як Java та C #. Це неправда, хоча. C - це інструмент, необхідний для виконання певних завдань. А Java - це інструмент для інших завдань.

Я використовував MySQL протягом багатьох років для управління інженерними даними, і він працював добре, але однією з проблем, які ми мали (але не усвідомлювали, що були), було те, що нам завжди доводилося планувати схему наперед. Ще одна проблема, яку ми знали, - це зіставлення даних до об’єктів домену та назад.

Зараз ми лише почали випробовувати neo4j, і схоже, що це вирішує обидві проблеми для нас. Можливість додавати різні властивості до кожного вузла (і відношення) дозволила нам переосмислити весь наш підхід до даних. Це як динамічні порівняно зі статичними мовами (Ruby vs Java), але для баз даних. Побудова моделі даних в базі даних може бути здійснена набагато більш гнучким та динамічним способом, що суттєво спрощує наш код.

А оскільки об'єктна модель в коді є, як правило, структурою графіків, відображення з бази даних також простіше, з меншим кодом і, отже, меншою кількістю помилок.

І як додатковий бонус, наш початковий код прототипу для завантаження наших даних у neo4j насправді працює швидше, ніж попередня версія MySQL. У мене поки що немає солідних цифр, але це була приємна додаткова функція.

Але наприкінці дня вибір, ймовірно, повинен ґрунтуватися переважно на характері вашої доменної моделі. Чи краще воно відображається у таблицях чи графіках? Вирішіть, зробивши кілька прототипів, завантажте дані та пограйте з ними. Використовуйте неоклипс для перегляду різних поглядів даних. Коли ви це зробите, сподіваємось, ви дізнаєтесь, чи хочете ви добру справу чи ні.

Я будую інтранет у своїй компанії.

Мені цікаво зрозуміти, як завантажувати дані, які зберігалися в таблицях (Oracle, MySQL, SQL Server, Excel, Access, різні випадкові списки) та завантажувати їх у Neo4J або якусь іншу базу даних графіків. Зокрема, що відбувається, коли загальні дані перекривають існуючі дані вже в системі.

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

Наприклад, я працюю у виробничому середовищі. Є великий проект, над яким ми працюємо, і через складність, кожен відділ створив окрему електронну таблицю Excel, яка має ієрархію BOM (Bill Of Materials) у колонці зліва, а потім кілька стовпчиків приміток та чеків, зроблених особами. хто робив ці аркуші.

Отже, одна з проблем - це об'єднання всіх цих записок разом в один «погляд», щоб хтось міг бачити всі проблеми, які потребують вирішення в будь-якій конкретній частині.

Друга проблема полягає в тому, що таблиця Excel висмоктує представлення ієрархічної BOM, коли загальний компонент використовується в більш ніж одній підскладах. Це означає, що якщо хтось пише примітку про реле P34 в підсистемі запалювання, той самий коментар повинен бути пов'язаний з релеми P34, що використовуються в складі двигуна драйвера двигуна. Це не відбудеться в таблиці Excel.

Для інтранет мережі компанії я хочу мати можливість що-небудь легко шукати. Такі, як дані, що стосуються номера деталі, структури BOM, номера телефону, електронної адреси, політики компанії або процедури. Я хочу навіть розширити це на управління активами комп'ютерного обладнання та встановленим програмним забезпеченням.

Я припускаю, що після того, як інформаційна мережа почне заповнюватися, ви можете почати робити цікаві траверси, такі як "Я хочу написати електронний лист усім, хто працює над проектом XYZ". Люди будуть пов'язані з проектом, оскільки вони будуть позначені як створення та зміна даних у рамках проекту XYZ. Таким чином, використовуючи проект XYZ як ключ пошуку, буде створено величезний набір із усім, що стосується проекту XYZ. У тому числі посилання на людей, які побудували проект XYZ. Посилання людей підключаться до їх електронних адрес. Тож завдяки їхній участі у проекті XYZ вони будуть включені до мого електронного листа. Це суперечить різкому секретарю, який намагається підтримувати список людей, які працюють над проектом. Ми створюємо безліч списків. Ми витрачаємо багато часу, підтримуючи списки та переконуючись, що вони актуальні.

Ще одна крута траверса могла повідомити про всі комп'ютери, на яких встановлено певний програмний продукт, за версією. Цей звіт може використовуватися для створення завдань для видалення зайвих копій старого програмного забезпечення та для оновлення людей, яким потрібно мати останню копію. Це також було б корисно для відстеження ліцензій.

Ось гарна стаття, яка розповідає про потреби, які заповнюють нереляційні бази даних: http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php

Це добре допомагає вказувати (окрім назви), що реляційні бази даних не є помилковими чи неправильними, це лише те, що в ці дні люди починають обробляти все більше і більше даних у програмному забезпеченні та веб-сайтах, і що реляційні бази даних просто не мають масштабу для цих потреб.

можливо, трохи пізно, але зростає кількість проектів, які використовують Neo4j, більш відомі, перелічені в Neo4j . Також NeoTechnology, компанія, що стоїть за Neo4j, має кілька посилань на своїй сторінці клієнтів

_{Примітка: Я є частиною команди Neo4j}