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

Question

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

Этот конкретный продукт выглядит хорошо и многообещающе: http://neo4j.org/

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

Использовали ли вы их в производственной среде? Какое требование побудило вас использовать их?

Answer 1

Я использовал графическую базу данных в предыдущей работе. Мы не использовали neo4j, это была собственная система, построенная на базе Berkeley DB, но она была похожа. Он был использован в производстве (он все еще есть).

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

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

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

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

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

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

Если ваше приложение не должно вписываться в текущую архитектуру blub, используйте базу данных графиков, или CouchDB, или BigTable, или что угодно, что подходит вашему приложению, и вы думаете, что это круто. Это может дать вам преимущество, и вам интересно пробовать новые вещи.

Что бы вы ни выбрали, старайтесь не создавать движок базы данных самостоятельно, если вам не нравится создавать движки баз данных.

Answer 2

Мы работаем с командой Neo уже более года и были очень счастливы. Мы моделируем научные артефакты и их взаимосвязи, которые характерны для графа db, и запускаем алгоритмы рекомендаций по сети.

Если вы уже работаете в Java, я думаю, что моделирование с использованием Neo4j очень прямолинейно и обеспечивает самую плоскую и быструю производительность для R / W среди любых других решений, которые мы пробовали.

Честно говоря, мне трудно не думать в терминах «График / Сеть», потому что это намного проще, чем проектировать извилистые структуры таблиц для хранения свойств и отношений объекта.

При этом мы храним некоторую информацию в MySQL просто потому, что для бизнеса проще запускать быстрые SQL-запросы. Чтобы выполнить те же функции с Neo, нам нужно было бы написать код, для которого у нас сейчас просто нет пропускной способности. Как только мы это сделаем, я перенесу все эти данные в Neo!

Удачи.

Answer 3

Две точки:

Во-первых, в отношении данных, с которыми я работал в течение последних 5 лет на SQL Server, я недавно столкнулся со стеной масштабируемости с помощью SQL для типа запросов, которые нам нужно выполнить (вложенные отношенияhsips ... вы знаете. ..graphs). Я играл с neo4j, и время моего поиска на несколько порядков быстрее, когда мне нужен этот вид поиска.

Во-вторых, до такой степени, что графовые базы данных устарели. Эм ... нет. Вначале, когда люди пытались выяснить, как эффективно хранить и искать данные, они создавали и использовали модели баз данных в виде графиков и сетевых стилей. Они были спроектированы таким образом, чтобы физическая модель отражала логическую модель, поэтому их эффективность была не такой большой. Этот тип структуры данных был хорош для полуструктурированных данных, но не так хорош для структурированных плотных данных. Итак, этот чувак из IBM по имени Кодд занимался поиском эффективных способов упорядочения и хранения структурированных данных и предложил идею модели реляционной базы данных. И это было хорошо, и люди были счастливы.

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

Для обозначения фразы не существует Серебряной пули. Очень недальновидно сказать, что модели графовых баз данных устарели, а их использование - 40 лет прогресса. Это все равно, что сказать, что использование C - это отказ от всего технического прогресса, через который мы прошли, чтобы получить такие вещи, как Java и C #. Это не правда, хотя. C является инструментом, который необходим для определенных задач. А Java - это инструмент для других задач.

Answer 4

Я много лет использовал MySQL для управления инженерными данными, и это работало хорошо, но одна из проблем, которые у нас были (но мы не осознавали), заключалась в том, что нам всегда приходилось планировать схему заранее. Еще одной проблемой, которую мы знали, было сопоставление данных с объектами домена и обратно.

Теперь мы только начали пробовать neo4j, и похоже, что он решает обе проблемы за нас. Возможность добавлять различные свойства для каждого узла (и отношения) позволила нам переосмыслить весь наш подход к данным. Это похоже на динамические и статические языки (Ruby и Java), но для баз данных. Построение модели данных в базе данных может быть выполнено гораздо более динамично и динамично, и это значительно упрощает наш код.

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

И в качестве дополнительного бонуса, наш исходный код прототипа для загрузки наших данных в neo4j фактически работает быстрее, чем предыдущая версия MySQL. У меня нет точных цифр (пока), но это была хорошая дополнительная функция.

Но, в конце концов, выбор, вероятно, должен основываться главным образом на характере модели вашего домена. Это лучше сопоставить с таблицами или графиками? Решите, сделав несколько прототипов, загрузите данные и поиграйте с ними. Используйте neoclipse, чтобы посмотреть на различные представления данных. Как только вы это сделаете, надеюсь, вы узнаете, хорошо ли вы это делаете или нет.

Answer 5

Я создаю интранет в моей компании.

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

Да, я знаю, что некоторые данные лучше всего моделировать в RDBMS, но у меня возникает эта мысль, что когда вам нужно наложить несколько отдельных таблиц, модель графа лучше, чем структура таблицы.

Например, я работаю в производственной среде. Есть крупный проект, над которым мы работаем, и из-за сложности каждый отдел создал отдельную электронную таблицу Excel, которая имеет Иерархия спецификаций (ведомости материалов) в столбце слева, а затем несколько столбцов примечаний и проверок, выполненных лицами, которые составили эти листы

Поэтому одной из проблем является объединение всех этих заметок в один " вид " так что кто-то может увидеть все проблемы, которые необходимо решить в любой конкретной части.

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

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

Я предполагаю, что, как только информационная сеть начнет заполняться, вы можете начать делать крутые обходы, такие как "Я хочу написать электронное письмо всем, кто работает над проектом XYZ". Люди будут связаны с проектом, потому что они будут помечены как создающие и изменяющие данные в проекте XYZ. Таким образом, используя проект XYZ в качестве ключа поиска, будет создан огромный набор со всем, что связано с проектом XYZ. Включая ссылки на людей, которые создали проект XYZ. Ссылки людей будут соединяться с их адресами электронной почты. Таким образом, благодаря участию в проекте XYZ, они будут включены в мою электронную почту. Это резко контрастирует с тем, что какой-то секретарь пытается вести список людей, работающих над проектом. Мы генерируем много списков. Мы проводим много времени за ведением списков и проверкой их актуальности. И большая часть этого не добавляет никакой ценности нашим продуктам.

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

Answer 6

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

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

Answer 7

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

_{Примечание. Я являюсь частью команды Neo4j}