Я много использовал Relational DB и решил выйти на другие доступные типы.
Этот конкретный продукт выглядит хорошо и многообещающе: http://neo4j.org/
Кто-нибудь использовал графические базы данных? Каковы плюсы и минусы в плане удобства использования?
Вы использовали их в производственной среде? Какое требование побудило вас использовать их?
Я использовал базу данных графа в предыдущем задании. Мы не использовали neo4j, это была собственная вещь, построенная поверх DB Berkeley, но она была похожа. Он использовался в производстве (он все еще есть).
Причина, по которой мы использовали базу данных графа, заключалась в том, что данные, хранящиеся системой, и операции, выполняемые системой с данными, были в точности слабым местом реляционных баз данных и были в точности сильным пятном баз данных графов. Системе необходимо хранить коллекции объектов, которые не имеют фиксированной схемы и связаны друг с другом отношениями. Чтобы обосновать данные, системе необходимо было выполнить множество операций, которые были бы двумя обходами в базе данных графа, но это были бы довольно сложные запросы в SQL.
Основными преимуществами модели графа были быстрое время разработки и гибкость. Мы могли бы быстро добавить новые функции, не влияя на существующие развертывания. Если потенциальный клиент хотел импортировать некоторые из своих данных и перенести его поверх нашей модели, его обычно можно было бы сделать на месте представителем отдела продаж. Гибкость также помогла нам при создании новой функции, что избавило нас от попыток сжать новые данные в жесткую модель данных.
Имея странную базу данных, мы создадим много других других странных технологий, предоставляя нам много тайного соуса, чтобы отличить наш продукт от наших конкурентов.
Основным недостатком было то, что мы не использовали стандартную технологию реляционных баз данных, что может быть проблемой, когда ваши клиенты являются предприятиями. Наши клиенты спрашивали, почему мы не можем просто размещать наши данные в своих гигантских кластерах Oracle (у наших клиентов обычно были большие датацентры). Одна из команд фактически переписала слой базы данных для использования Oracle (или PostgreSQL или MySQL), но она была немного медленнее оригинала. По крайней мере одно крупное предприятие даже имело стратегию только для Oracle, но, к счастью, Oracle купила Berkeley DB. Нам также пришлось написать много дополнительных инструментов - мы не могли просто использовать Crystal Reports, например.
Другим недостатком нашей базы данных графов было то, что мы сами ее построили, а это означало, что когда мы сталкивались с проблемой (обычно с масштабируемостью), нам приходилось решать ее самостоятельно. Если бы мы использовали реляционную базу данных, поставщик уже решил проблему десять лет назад.
Если вы создаете продукт для клиентов предприятия и ваши данные вписываются в реляционную модель, используйте реляционную базу данных, если можете. Если ваше приложение не соответствует реляционной модели, но оно соответствует модели графа, используйте базу данных графа. Если это подходит только для чего-то другого, используйте это.
Если вашему приложению не нужно вписываться в текущую архитектуру blub, используйте графическую базу данных, или CouchDB, или BigTable, или все, что подходит вашему приложению, и вы считаете, что это круто. Это может дать вам преимущество, и его удовольствие попробовать новые вещи.
Независимо от того, что вы выбрали, постарайтесь не создавать собственный движок базы данных самостоятельно, если вам не нравится создавать базы данных.
Мы работаем с командой Neo уже более года и очень довольны. Мы моделируем научные артефакты и их отношения, которые находятся на графике db и запускают алгоритмы рекомендаций по сети.
Если вы уже работаете на Java, я думаю, что моделирование с использованием Neo4j очень прямолинейно, и оно имеет самую плотную/самую быструю производительность для R/W любых других решений, которые мы пробовали.
Честно говоря, мне сложно не думать о графике/сети, потому что это намного проще, чем проектирование свернутых структур таблиц для хранения свойств объекта и отношений.
При этом мы сохраняем некоторую информацию в MySQL просто потому, что для бизнес-стороны проще запускать быстрые SQL-запросы. Чтобы выполнять те же функции с Neo, нам нужно будет написать код, который у нас просто не имеет полосы пропускания прямо сейчас. Как только мы это сделаем, я перемещаю все эти данные в Neo!
Удачи.
Две точки:
Во-первых, по данным, которые я работал с прошлыми 5 годами в SQL Server, я недавно ударил стену масштабируемости SQL для типа запросов, которые нам нужно запустить (вложенные отношения... вы знаете...graphs). Я играл с neo4j, и мои поисковые запросы на несколько порядков быстрее, когда мне нужен этот вид поиска.
Во-вторых, до того, что базы данных графов устарели. Эм... нет. Раньше, когда люди пытались эффективно и эффективно хранить данные, они создавали и играли с графическими и сетевыми моделями баз данных. Они были спроектированы таким образом, чтобы физическая модель отражала логическую модель, поэтому их эффективность не была такой замечательной. Такая структура данных была хороша для полуструктурированных данных, но не настолько хороша для структурированных плотных данных. Итак, этот чувак IBM по имени Codd изучал эффективные способы организации и хранения структурированных данных и придумал идею для модели реляционной базы данных. И это было хорошо, и люди были счастливы.
Что у нас есть? Два инструмента для двух разных целей. Графические модели баз данных очень хороши для представления полуструктурированных данных и отношений между объектами (которые могут или не могут существовать). Реляционные базы данных хороши для структурированных данных, которые имеют очень статичную схему и где глубина соединения не очень глубока. Один хорош для одного типа данных, другой хорош для других видов данных.
Чтобы выровнять фразу, нет Серебряной пули. Его очень недальновидный, чтобы сказать, что модели базы данных графов устарели, и использовать их дает 40-летний прогресс. То, что, говоря, используя C, отказывается от всего технологического прогресса, который мы прошли, чтобы получить такие вещи, как Java и С#. Это не правда. C - инструмент, необходимый для выполнения определенных задач. И Java - это инструмент для других задач.
Я много лет использую MySQL для управления инженерными данными, и это сработало хорошо, но одна из проблем, которые мы имели (но не понимали, что мы имели), заключалась в том, что нам всегда приходилось планировать схему вверх. Другая проблема, о которой мы знали, - это сопоставление данных с объектами домена и обратно.
Теперь мы только начали опробовать neo4j, и похоже, что он решает обе проблемы для нас. Возможность добавлять разные свойства к каждому node (и отношениям) позволила нам переосмыслить весь наш подход к данным. Это похоже на динамические и статические языки (Ruby versus Java), но для баз данных. Построение модели данных в базе данных может быть сделано гораздо более гибким и динамичным способом, и это значительно упрощает наш код.
И поскольку объектная модель в коде, как правило, представляет собой структуру графика, сопоставление из базы данных также проще, с меньшим количеством кода и, следовательно, меньшим количеством ошибок.
И в качестве дополнительного бонуса наш начальный код прототипа для загрузки наших данных в neo4j фактически работает быстрее, чем предыдущая версия MySQL. У меня нет твердых чисел на этом (пока), но это была хорошая дополнительная функция.
Но в конце дня выбор, вероятно, должен основываться главным образом на характере вашей модели домена. Является ли это лучше для таблиц или графиков? Решите, выполнив некоторые прототипы, загрузите данные и поиграйте с ними. Используйте neoclipse для просмотра различных представлений данных. После того, как вы это сделали, надеюсь, вы знаете, хорошо ли вы работаете или нет.
Вот хорошая статья, в которой говорится о потребностях, которые заполняются нереляционными базами данных: http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php
Хорошая работа заключается в том, чтобы указывать (кроме имени), что реляционные базы данных не соответствуют действительности или ошибочны, именно в эти дни люди начинают обрабатывать все больше и больше данных в основном программном обеспечении и веб-сайтах, а также реляционные базы данных просто не будет масштабироваться для этих потребностей.
Я создаю интрасеть в своей компании.
Мне интересно понять, как загружать данные, хранящиеся в таблицах (Oracle, MySQL, SQL Server, Excel, Access, различные случайные списки) и загружать их в Neo4J или в какую-либо другую базу данных графов. В частности, что происходит, когда общие данные перекрывают существующие данные уже в системе.
Да, я знаю, что некоторые данные лучше всего моделируются в РСУБД, но мне кажется, что эта идея меня раздражает, когда вам нужно наложить несколько разных таблиц, модель графа лучше, чем структура таблицы.
Например, я работаю в производственной среде. Существует большой проект, над которым мы работаем, и из-за сложности каждый отдел создал отдельную электронную таблицу Excel с спецификацией (Bill Of Materials) в столбце слева, а затем несколько столбцов заметок и чеков, сделанных лицами, которые сделали эти листы.
Таким образом, одна из проблем заключается в объединении всех этих заметок вместе в один "вид", чтобы кто-то мог видеть все проблемы, которые необходимо решить в какой-либо конкретной части.
Вторая проблема заключается в том, что таблица Excel всасывает представление иерархической спецификации, когда общий компонент используется более чем в одном узле. Это означает, что если кто-то пишет записку о реле P34 в сборочном узле, то такой же комментарий должен быть связан с реле P34, используемым в сборочном узле двигателя. Это не произойдет в электронной таблице Excel.
Для интрасети компании я хочу легко найти что угодно. Например, данные, относящиеся к номеру детали, структуре спецификации, номеру телефона, адресу электронной почты, политике компании или процедуре. Я хочу еще расширить это, чтобы управлять ресурсами компьютерного оборудования и установленным программным обеспечением.
Я предполагаю, что как только информационная сеть начнет заполняться, вы можете начать делать крутые обходы, такие как "Я хочу написать электронное письмо всем, кто работает над проектом XYZ". Люди будут связаны с проектом, потому что они будут помечены как создание и изменение данных в проекте XYZ. Таким образом, используя проект XYZ в качестве ключа поиска, будет создан огромный набор со всем, что связано с проектом XYZ. Включая ссылки на людей, которые построили проект XYZ. Ссылки для людей будут подключаться к их адресам электронной почты. Поэтому, участвуя в проекте XYZ, они будут включены в мой адрес электронной почты. Это резко контрастирует с некоторыми секретарями, пытающимися сохранить список людей, работающих над проектом. Мы генерируем много списков. Мы тратим много времени на ведение списков и обеспечение их актуальности. И большая часть этого не добавляет никакой ценности нашим продуктам.
Еще один крутой обход может сообщить обо всех компьютерах, на которых установлена определенная часть программного обеспечения, по версии. Этот отчет может использоваться для создания задач для удаления дополнительных копий старого программного обеспечения и для обновления людей, которым требуется последняя копия. Это также было бы полезно для отслеживания лицензий.
может быть немного поздно, но растет число проектов с использованием Neo4j, более известных из них, перечисленных в Neo4j. Также NeoTechnology, компания за Neo4j, имеет некоторые ссылки на страницу своих клиентов
Примечание: я являюсь частью команды Neo4j