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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удачи.

Два момента:

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

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

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

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

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

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

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

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

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

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

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

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

Например, я работаю в производственной среде. Мы работаем над крупным проектом, и из-за его сложности каждый отдел создал отдельную электронную таблицу Excel, в которой есть иерархия BOM (Bill Of Materials) в столбце слева, а затем несколько столбцов заметок и проверок, сделанных отдельными лицами. кто сделал эти листы.

Итак, одна из проблем - объединить все эти заметки в одно «представление», чтобы кто-то мог увидеть все проблемы, которые необходимо решить в любой конкретной части.

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

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

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

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

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

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

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

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