그래프 기반 데이터베이스 (http://neo4j.org/)의 사용 사례는 무엇입니까?

그래프 기반 데이터베이스 (http://neo4j.org/)의 사용 사례는 무엇입니까? [닫은]

---

Relational DB를 많이 사용했으며 사용 가능한 다른 유형을 찾기로 결정했습니다.

이 특정 제품은 훌륭하고 유망 해 보입니다 : http://neo4j.org/

누구든지 그래프 기반 데이터베이스를 사용 했습니까? 사용성 관점에서 장단점은 무엇입니까?

프로덕션 환경에서 이것을 사용 했습니까? 그것들을 사용하라는 요구 사항은 무엇입니까?

---

이전 작업에서 그래프 데이터베이스를 사용했습니다. 우리는 neo4j를 사용하지 않았으며, 버클리 DB 위에 구축 된 사내 작업이지만 비슷했습니다. 그것은 생산에 사용되었습니다 (여전히 있습니다).

그래프 데이터베이스를 사용한 이유는 시스템이 저장하는 데이터와 시스템이 데이터를 사용하여 수행 한 작업이 관계형 데이터베이스의 약점이고 정확히 그래프 데이터베이스의 강점 이었기 때문입니다. 시스템은 고정 된 스키마가없고 관계에 의해 서로 연결된 개체 컬렉션을 저장해야했습니다. 데이터를 추론하기 위해 시스템은 그래프 데이터베이스에서 몇 번의 순회가 될 많은 작업을 수행해야했지만 SQL에서는 상당히 복잡한 쿼리입니다.

그래프 모델의 주요 장점은 빠른 개발 시간과 유연성이었습니다. 기존 배포에 영향을주지 않고 새로운 기능을 빠르게 추가 할 수있었습니다. 잠재 고객이 자체 데이터 중 일부를 가져 와서 모델 위에 이식하려는 경우 일반적으로 영업 담당자가 현장에서 수행 할 수 있습니다. 유연성은 또한 새로운 기능을 설계 할 때 도움이되었으며, 새로운 데이터를 엄격한 데이터 모델로 압축하지 않아도됩니다.

이상한 데이터베이스가 있으면 다른 이상한 기술을 많이 만들어서 경쟁사 제품과 차별화 할 수있는 비밀 소스를 많이 얻을 수 있습니다.

가장 큰 단점은 표준 관계형 데이터베이스 기술을 사용하지 않았기 때문에 고객이 기업 일 때 문제가 될 수 있다는 것입니다. 우리 고객들은 왜 거대한 오라클 클러스터에서 데이터를 호스팅 할 수 없는지 묻습니다 (고객은 일반적으로 큰 데이터 센터를 가짐). 팀 중 하나가 실제로 Oracle (또는 PostgreSQL 또는 MySQL)을 사용하도록 데이터베이스 계층을 다시 작성했지만 원래보다 약간 느 렸습니다. 적어도 하나의 대기업이 Oracle 전용 정책을 가지고 있었지만 다행히도 Oracle은 Berkeley DB를 구입했습니다. 또한 많은 추가 도구를 작성해야했습니다. 예를 들어 Crystal Reports 만 사용할 수 없었습니다.

그래프 데이터베이스의 또 다른 단점은 직접 구축했기 때문에 문제가 발생했을 때 (보통 확장 성 문제) 해결해야한다는 것을 의미했습니다. 관계형 데이터베이스를 사용했다면 벤더는 이미 10 년 전에 문제를 해결했을 것입니다.

기업 고객을위한 제품을 구축 할 때 데이터가 관계형 모델에 적합한 경우 가능하면 관계형 데이터베이스를 사용하십시오. 응용 프로그램이 관계형 모델에는 적합하지 않지만 그래프 모델에는 적합하면 그래프 데이터베이스를 사용하십시오. 다른 것에 적합하다면 사용하십시오.

응용 프로그램이 현재 blub 아키텍처에 맞지 않아도되는 경우 그래프 데이터베이스, CouchDB 또는 BigTable 또는 앱에 맞는 항목을 사용하고 멋지다고 생각하십시오. 그것은 당신에게 이점을 줄 수 있고 새로운 일을 시도하는 재미입니다.

무엇을 선택하든 데이터베이스 엔진 작성이 마음에 들지 않으면 데이터베이스 엔진을 직접 구축하지 마십시오.

---

우리는 1 년 넘게 Neo 팀과 함께 일해 왔으며 매우 기뻤습니다. 우리는 학계 인공물과 그 관계를 모델링하여 그래프 DB에서 찾아 볼 수 있으며 네트워크를 통해 추천 알고리즘을 실행합니다.

이미 Java로 작업하고 있다면 Neo4j를 사용한 모델링이 매우 간단하고 우리가 시도한 다른 솔루션의 R / W에서 가장 평평하고 빠른 성능을 가지고 있다고 생각합니다.

솔직히 말해서, 그래프 / 네트워크와 관련하여 생각 하지 않는 것은 힘든 일 입니다. 그래서 객체 속성과 관계를 유지하기 위해 복잡한 테이블 구조를 디자인하는 것보다 훨씬 쉽기 때문입니다.

즉, 비즈니스 측에서 빠른 SQL 쿼리를보다 쉽게 ​​실행할 수 있기 때문에 일부 정보를 MySQL에 저장합니다. Neo와 동일한 기능을 수행하려면 현재 대역폭이없는 코드를 작성해야합니다. 그래도 우리는 모든 데이터를 Neo로 옮길 것입니다!

행운을 빕니다.

---

두 가지 점 :

먼저, 지난 5 년 동안 SQL Server에서 작업 한 데이터에서 최근 실행해야하는 쿼리 유형 (중립 관계식 ... 알다시피 ... 그래프)에 대해 SQL을 사용하여 확장 성 문제를 해결했습니다. ). 나는 neo4j로 놀고 있었고, 이런 종류의 조회가 필요할 때 조회 시간이 몇 배 빠릅니다.

둘째, 그래프 데이터베이스가 오래되었다는 점입니다. 음 .. 아니야. 초기에 사람들은 데이터를 효율적으로 저장하고 조회하는 방법을 알아 내려고하면서 그래프 및 네트워크 스타일 데이터베이스 모델을 만들고 사용했습니다. 이것은 물리적 모델이 논리적 모델을 반영하도록 설계되었으므로 효율성은 그다지 크지 않았습니다. 이 유형의 데이터 구조는 반 구조화 된 데이터에는 적합하지만 구조화 된 고밀도 데이터에는 적합하지 않습니다. 따라서 Codd라는 IBM 친구는 구조화 된 데이터를 정렬하고 저장하는 효율적인 방법을 연구하고 관계형 데이터베이스 모델에 대한 아이디어를 생각해 냈습니다. 그리고 좋았고 사람들은 행복했습니다.

우리는 여기에 무엇을 가지고 있습니까? 두 가지 다른 목적을위한 두 가지 도구. 그래프 데이터베이스 모델은 반 구조화 된 데이터와 엔티티 간의 관계 (존재하거나 존재하지 않을 수 있음)를 나타내는 데 매우 적합합니다. 관계형 데이터베이스는 매우 정적 인 스키마를 가지고 있고 조인 깊이가 그리 깊이 가지 않는 구조화 된 데이터에 적합합니다. 하나는 한 종류의 데이터에 적합하고 다른 하나는 다른 종류의 데이터에 적합합니다.

문구를 코인하기 위해 Silver Bullet은 없습니다. 그래프 데이터베이스 모델이 오래되었다고 말하면 40 년의 발전을 포기한다는 것은 매우 짧은 일입니다. C를 사용하는 것이 Java 및 C #과 같은 것들을 얻기 위해 우리가 겪은 모든 기술적 진보를 포기한다고 말하는 것과 같습니다. 하지만 사실이 아닙니다. C는 특정 작업에 필요한 도구입니다. Java는 다른 작업을위한 도구입니다.

---

엔지니어링 데이터를 관리하기 위해 수년 동안 MySQL을 사용해 왔지만 제대로 작동했지만, 우리가 가진 문제 중 하나는 항상 스키마를 미리 계획해야한다는 것이 었습니다. 우리가 알고있는 또 다른 문제는 데이터를 도메인 개체에 매핑하는 것입니다.

이제 우리는 방금 neo4j를 시험해보기 시작했으며 우리에게 두 가지 문제를 모두 해결하는 것처럼 보입니다. 각 노드 (및 관계)에 다른 속성을 추가하는 기능을 통해 데이터에 대한 전체 접근 방식을 다시 생각할 수있었습니다. 동적 언어와 정적 언어 (Ruby와 Java)와 비슷하지만 데이터베이스의 경우와 같습니다. 데이터베이스에서 데이터 모델을 구축하는 것은 훨씬 민첩하고 역동적 인 방식으로 수행 될 수 있으며 이는 코드를 크게 단순화시킵니다.

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.

---

I am building an intranet at my company.

I am interested in understanding how to load data that was stored in tables (Oracle, MySQL, SQL Server, Excel, Access, various random lists) and loading it into Neo4J, or some other graph database. Specifcally, what happens when common data overlaps existing data already in the system.

Yes, I know some data is best modeled in RDBMS, but I have this idea itching me, that when you need to superimpose several distinct tables, the graph model is better than the table structure.

For instance, I work in a manufacturing environment. There is a major project we are working on and because of the complexity, each department has created a seperate Excel spreadsheet that has a BOM (Bill Of Materials) hierarchy in a column on the left and then several columns of notes and checks made by individuals who made these sheets.

So one of the problems is merging all these notes together into one "view" so that someone can see all the issues that need to be addressed in any particular part.

The second problem is that an Excel spreadsheet sucks at representing a hierarchial BOM when a common component is used in more than one subassembly. Meaning that, if someone writes a note about the P34 relay in the ignition subassembly, the same comment should be associated with the P34 relays used in the motor driver subassembly. This won't occur in the excel spreadsheet.

For the company intranet, I want to be able to search for anything easily. Such as data related to a part number, a BOM structure, a phone number, an email address, a company policy, or procedure. I want to even extend this to manage computer hardware assets, and installed software.

I envision that once the information network starts to get populated you can start doing cool traversals such as "I want to write an email to everyone working on the XYZ project". People will have been associated with the project because they will be tagged as creating and modifying the data within the XYZ project. So by using the XYZ project as a search key, a huge set with everything related to the XYZ project will be created. Including links to people who built the XYZ project. The people links will connect to their email addresses. So by their involvement in the XYZ project, they will be included in my email. This is in stark contrast to some secretary trying to maintain a list of people work on the project. We generate a lot of lists. We spend a lot of time maintaining lists and making sure they are up to date. And most of it doesn't add any value to our products.

Another cool traversal could report all the computers that have a certain piece of software installed, by version. That report could be used to generate tasks to remove extra copies of old software and to update people who need to have the latest copy. It would also be useful for license tracking.

---

Here is a good article that talks about the needs that non relational databases fill: http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php

It does a good job at pointing out (aside from the name) that relational databases arent flawed or wrong, its just that these days people are starting to process more and more data in mainstream software and web sites, and that relational databases just wont scale for these needs.

---

might be a bit late, but there is a growing number of projects using Neo4j, the better known ones listed at Neo4j . Also NeoTechnology, the company behind Neo4j, has some references at their customers page

_{Note: I am part of the Neo4j team}

참고URL : https://stackoverflow.com/questions/1000162/what-are-the-use-cases-of-graph-based-databases-http-neo4j-org