Каковы варианты использования Основанных на графике Баз данных (http://neo4j.org/)? [закрытый]
Для начальной загрузки 4 документы говорят, что вы можете сделать это:
Удалено .btn-group-justified. В качестве замены вы можете использовать <div class="btn-group d-flex" role="group"></div> в качестве обертки вокруг элементов с .w-100.
7 ответов
Я использовал базу данных графов в предыдущей работе . Мы не использовали neo4j, это была собственная разработка на базе Berkeley DB, но она была похожа. Он использовался в производстве (и до сих пор используется).
Причина, по которой мы использовали графовую базу данных, заключалась в том, что данные, хранящиеся в системе, и операции, которые система выполняла с данными, были именно слабым местом реляционных баз данных и были именно сильная сторона графовых баз данных. Система должна была хранить коллекции объектов, не имеющих фиксированной схемы и связанных между собой отношениями. Чтобы рассуждать о данных, системе необходимо было выполнить множество операций, которые были бы парой обходов в базе данных графа, но это были бы довольно сложные запросы в SQL.
Основными преимуществами графовой модели были быстрое время разработки и гибкость. Мы могли быстро добавить новые функции, не влияя на существующие развертывания. Если потенциальный клиент хотел импортировать некоторые из своих данных и перенести их на нашу модель, обычно это мог сделать торговый представитель на месте. Гибкость также помогла, когда мы разрабатывали новую функцию, избавляя нас от попыток втиснуть новые данные в жесткую модель данных.
Наличие странной базы данных позволило нам создать множество других наших странных технологий, дав нам много секретов. чтобы отличать наш продукт от продуктов наших конкурентов.
Основным недостатком было то, что мы не использовали стандартную технологию реляционных баз данных, что может быть проблемой, когда ваши клиенты являются корпоративными. Наши клиенты спрашивали, почему мы не можем? просто размещать наши данные на своих гигантских кластерах Oracle (у наших клиентов обычно были большие центры обработки данных). Один из членов команды фактически переписал уровень базы данных, чтобы использовать Oracle (или PostgreSQL, или MySQL), но это было немного медленнее, чем оригинал. По крайней мере одно крупное предприятие даже придерживалось политики Oracle, но, к счастью, Oracle купила Berkeley DB. Нам также пришлось написать много дополнительных инструментов - например, мы не могли просто использовать Crystal Reports.
Другим недостатком нашей графической базы данных было то, что мы создавали ее сами, а это означало, что когда мы сталкивались с проблемой (обычно с масштабируемостью) ) нам пришлось решать это самим. Если бы мы использовали реляционную базу данных, поставщик уже решил бы проблему десять лет назад.
Если вы создаете продукт для корпоративных клиентов и ваши данные вписываются в реляционную модель, по возможности используйте реляционную базу данных. Если ваше приложение не соответствует реляционной модели, но соответствует модели графа, используйте базу данных графов. Если он подходит только для чего-то другого, используйте это.
Если вашему приложению не нужно вписываться в текущую архитектуру blub, используйте базу данных графов, или CouchDB, или BigTable, или что-то еще, что подходит вашему приложению, и вы думаете, что это круто. Это может дать вам преимущество, и вам будет весело пробовать что-то новое.
Что бы вы ни выбрали, старайтесь не создавать ядро базы данных самостоятельно, если вы действительно не любите создавать механизмы баз данных.
или что-то, что подходит вашему приложению, и вы считаете его крутым. Это может дать вам преимущество, и вам будет весело пробовать что-то новое.Что бы вы ни выбрали, старайтесь не создавать ядро базы данных самостоятельно, если вы действительно не любите создавать механизмы баз данных.
или что-то, что подходит вашему приложению, и вы считаете его крутым. Это может дать вам преимущество, и вам будет весело пробовать что-то новое.Что бы вы ни выбрали, старайтесь не создавать ядро базы данных самостоятельно, если вы действительно не любите создавать механизмы баз данных.
We've been working with the Neo team for over a year now and have been very happy. We model scholarly artifacts and their relationships, which is spot on for a graph db, and run recommendation algorithms over the network.
If you are already working in Java, I think that modeling using Neo4j is very straight forward and it has the flattest / fastest performance for R/W of any other solutions we tried.
To be honest, I have a hard time not thinking in terms of a Graph/Network because it's so much easier than designing convoluted table structures to hold object properties and relationships.
That being said, we do store some information in MySQL simply because it's easier for the Business side to run quick SQL queries against. To perform the same functions with Neo we would need to write code that we simply don't have the bandwidth for right now. As soon as we do though, I'm moving all that data to Neo!
Good luck.
I've been using MySQL for years to manage engineering data, and it worked well, but one of the problems we had (but didn't realise we had) was that we always had to plan the schema up-front. Another problem we knew we had was mapping the data up to domain objects and back.
Now we've just started trying out neo4j and it looks like it is solving both problems for us. The ability to add different properties to each node (and relation) has allowed us to re-think our entire approach to data. It is like dynamic versus static languages (Ruby versus Java), but for databases. Building the data model in the database can be done in a much more agile and dynamic way, and that is dramatically simplifying our code.
And since the object model in code is generally a graph structure, mapping from the database is also simpler, with less code and consequently fewer bugs.
And as a additional bonus, our initial prototype code for loading our data into neo4j is actually performing faster than the previous MySQL version. I have no solid numbers on this (yet), but that was a nice additional feature.
But at the end of the day, the choice probably should be based mostly on the nature of your domain model. Does it map better to tables or graphs? Decide by doing some prototypes, load the data and play with it. Use neoclipse to look at different views of the data. Once you've done that, hopefully you know if you're on to a good thing or not.
Two points:
First, on the data I've been working with the past 5 years in SQL Server, I've recently hit the scalability wall with SQL for the type of queries we need to run (nested relationhsips...you know...graphs). I've been playing around with neo4j, and my lookup times are several orders of magnitude faster when I need this kind of lookup.
Second, to the point that graph databases are outdated. Um...no. Early on, as people were trying to figure out how to store and lookup data efficiently, they created and played with graph and network style database models. These were designed so the physical model reflected the logical model, so their efficiency wasnt that great. This type of data structure was good for semi-structured data, but not as good for structured dense data. So, this IBM dude named Codd was researching efficient ways to arrange and store structured data and came up with the idea for the relational database model. And it was good, and people were happy.
What do we have here? Two tools for two different purposes. Graph database models are very good for representing semi-structured data and the relationships between entities (that may or may not exist). Relational databases are good for structured data that has a very static schema, and where join depths do not go very deep. One is good for one kind of data, the other is good for other kinds of data.
To coin the phrase, there is no Silver Bullet. Its very short sighted to say that graph database models are out of date and to use one gives up 40 years of progress. That's like saying using C is giving up all the technological progress we've gone through to get things like Java and C#. That's not true though. C is a tool that is needed for certain tasks. And Java is a tool for other tasks.
Вот хорошая статья, в которой рассказывается о потребностях, которые удовлетворяют нереляционные базы данных: http://www.readwriteweb.com/enterprise/2009/02/is-the-relational -database-doomed.php
Он хорошо справляется с указанием (помимо названия), что реляционные базы данных не являются ошибочными или ошибочными, просто в наши дни люди начинают обрабатывать все больше и больше данных в основном программном обеспечении и в Интернете. сайтов, и что реляционные базы данных просто не подходят для этих нужд.
может быть немного запоздалым, но растет число проектов, использующих Neo4j, наиболее известные из которых перечислены на Neo4j . Также NeoTechnology, компания, стоящая за Neo4j, имеет некоторые ссылки на странице своих клиентов
Примечание: я являюсь частью команды Neo4j
Я создаю интранет в своей компании.
Меня интересует, как загрузить данные, которые хранились в таблицах (Oracle, MySQL, SQL Server, Excel, Access, различные случайные списки) и загрузить их в Neo4J, или другую базу данных графиков. В частности, что происходит, когда обычные данные перекрывают существующие данные, уже находящиеся в системе.
Да, я знаю, что некоторые данные лучше всего моделировать в СУБД, но у меня есть идея, которая меня зудит, что когда нужно наложить несколько отдельных таблиц, то графическая модель лучше структуры таблиц.
Например, я работаю в производственной среде. Есть один крупный проект, над которым мы работаем, и из-за сложности каждый отдел создал отдельную таблицу Excel, которая имеет иерархию BOM (Bill Of Materials) в колонке слева, а затем несколько столбцов заметок и проверок, сделанных теми, кто сделал эти листы.
Таким образом, одна из проблем заключается в объединении всех этих записей в одно "представление", чтобы кто-то мог видеть все вопросы, которые необходимо решить в какой-либо конкретной части.
Вторая проблема заключается в том, что электронная таблица Excel отстойно представляет иерархическую спецификацию, когда общий компонент используется более чем в одной подсистеме. Это означает, что если кто-то пишет заметку о реле P34 в блоке зажигания, то этот же комментарий должен быть связан с реле P34, используемыми в блоке моторного привода. Этого не произойдет в электронной таблице excel.
Для корпоративной интранет-системы я хочу иметь возможность легко искать что угодно. Например, данные, связанные с номером детали, структурой спецификации, номером телефона, адресом электронной почты, политикой компании или процедурой. Я даже хочу расширить эту возможность, чтобы управлять аппаратными средствами компьютера и установленным программным обеспечением.
Я предполагаю, что как только информационная сеть начнет заполняться, вы можете начать делать крутые обходы, такие как "Я хочу написать электронное письмо всем, кто работает над проектом XYZ". Люди будут ассоциироваться с проектом, потому что они будут помечены как создающие и изменяющие данные в проекте XYZ. Таким образом, используя проект XYZ в качестве ключа поиска, будет создан огромный набор со всем, что связано с проектом XYZ. Включая ссылки на людей, которые создали проект XYZ. Ссылки на людей будут соединяться с их электронными адресами. Таким образом, их участие в проекте XYZ будет включено в мою электронную почту. Это резко контрастирует с тем, что какой-то секретарь пытается вести список людей, которые работают над проектом. Мы генерируем много списков. Мы тратим много времени на поддержку списков и следим за тем, чтобы они были в актуальном состоянии. И большинство из них не добавляют никакой ценности нашим продуктам.
Другой крутой обход мог бы сообщить обо всех компьютерах, на которых установлено определённое программное обеспечение, по версиям. Этот отчет можно было бы использовать для создания задач по удалению дополнительных копий старых программ и обновлению людей, которым нужна последняя копия. Он был бы также полезен для отслеживания лицензий.