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

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

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

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

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

удачи.

две точки:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

вторая проблема заключается в том, что электронная таблица 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}