123

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

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

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

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

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

  • Error: User Rate Limit Exceeded

    от
  • Error: User Rate Limit Exceededneo4j.org/community/list

    от
  • Error: User Rate Limit Exceeded

    от
  • Error: User Rate Limit Exceeded

    от
  • Error: User Rate Limit Exceeded

    от
  • Error: User Rate Limit Exceeded

    от
  • Error: User Rate Limit Exceeded

    от
  • На данный момент у меня нет никаких бизнес-требований для использования графической базы данных. Это может быть потому, что я не думаю ни о чем другом, кроме СУБД. Вполне возможно, что большую часть времени я пробую Квадратный колышек в круглом отверстии. Db на основе графов - это совершенно новая для меня перспектива. Я использовал основанную на Scenegraph постоянную среду (Java3D, Xith3D), но она предназначалась для хранения графических приложений. Весь этот разговор дает мне новую перспективу. Любое приложение, которое использует графическую базу данных, чтобы я мог видеть вещи в действии!

    от Khangharoth
  • Neo4j сегодня используется по-разному в международных компаниях. Neo Technology предлагает несколько технических документов, анализирующих каждое из этих применений: 1. Обнаружение мошенничества 2. Рекомендации в реальном времени и социальные сети 3. Управление центром обработки данных Подробнее:bbvaopen4u.com/en/actualidad/…

    от Chirag Maliwal
7 ответов
  • 2

    может быть немного поздно

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

    Note: I am part of the Neo4j team

  • 14

    Я годами использовал MySQL для управления инженерными данными

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

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

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

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

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

  • 179

    Я использовал базу данных графа в предыдущей работе. Мы не использовал

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

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

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

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

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

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

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

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

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

  • 22

    Два момента:

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

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

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

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

  • 31

    Мы работаем с командой Neo уже более года и были очень счастливы. Мы м

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

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

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

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

    Удачи.

  • 3

    Вот хорошая статья

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

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

  • 3

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

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

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

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

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

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

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

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

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