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

Question

Я использовал Relational DB и решил выйти на другие доступные типы.

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

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

Удачи.

Answer 4

Две точки:

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

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

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

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

Answer 5

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

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

Answer 6

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

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

Answer 7

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

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

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

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

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

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

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

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

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