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

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

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

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

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

удачи.

две точки:

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

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

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

монета фраза, нет серебряной пули. Его очень недальновидно сказать, что модели графовых баз данных устарели, и использовать один отказывается от 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}