Relational DB를 많이 사용했으며 사용 가능한 다른 유형을 찾기로 결정했습니다.
이 특정 제품은 훌륭하고 유망 해 보입니다 : http://neo4j.org/
누구든지 그래프 기반 데이터베이스를 사용 했습니까? 사용성 관점에서 장단점은 무엇입니까?
프로덕션 환경에서 이것을 사용 했습니까? 그것들을 사용하라는 요구 사항은 무엇입니까?
답변:
이전 작업에서 그래프 데이터베이스를 사용했습니다. 우리는 neo4j를 사용하지 않았으며 Berkeley 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)와 비슷하지만 데이터베이스의 경우와 같습니다. 데이터베이스에서 데이터 모델을 구축하는 것은 훨씬 민첩하고 역동적 인 방식으로 수행 될 수 있으며 이는 코드를 크게 단순화시킵니다.
또한 코드의 객체 모델은 일반적으로 그래프 구조이기 때문에 코드가 적고 결과적으로 버그가 적어 데이터베이스에서 매핑하는 것이 더 간단합니다.
또한 추가 보너스로, 데이터를 neo4j에로드하기위한 초기 프로토 타입 코드는 실제로 이전 MySQL 버전보다 더 빠르게 수행됩니다. 나는 이것에 확실한 숫자가 없지만 (아직도) 멋진 추가 기능이었다.
그러나 하루가 끝나면 선택은 주로 도메인 모델의 특성을 기반으로해야합니다. 테이블이나 그래프에 더 잘 매핑됩니까? 일부 프로토 타입을 수행하여 데이터를로드하고 재생하십시오. 네오 클립 스를 사용하여 데이터의 다른 뷰를 봅니다. 당신이 그 일을 한 후에, 당신이 좋은 일인지 아닌지를 알고 있기를 바랍니다.
회사에서 인트라넷을 만들고 있습니다.
테이블 (Oracle, MySQL, SQL Server, Excel, Access, 다양한 임의의 목록)에 저장된 데이터를로드하고 Neo4J 또는 다른 그래프 데이터베이스에로드하는 방법을 이해하고 싶습니다. 구체적으로, 공통 데이터가 시스템에 이미 존재하는 기존 데이터와 겹칠 때 발생하는 상황.
예, 일부 데이터가 RDBMS에서 가장 잘 모델링된다는 것을 알고 있지만 여러 가지 고유 한 테이블을 겹쳐 야 할 때 그래프 모델이 테이블 구조보다 낫다는 아이디어가 있습니다.
예를 들어, 나는 제조 환경에서 일합니다. 현재 진행중인 주요 프로젝트가 있으며 복잡성으로 인해 각 부서는 BOM (Bill Of Materials) 이있는 별도의 Excel 스프레드 시트를 작성했습니다. 왼쪽 열에 계층 구조를 가진 다음 개인이 작성한 여러 메모 및 확인 열 이 시트를 만든 사람.
따라서 문제 중 하나는 이러한 모든 메모를 하나의 "보기"로 병합하여 누군가가 특정 부분에서 해결해야하는 모든 문제를 볼 수 있도록합니다.
두 번째 문제는 공통 구성 요소가 둘 이상의 횡단 구성 요소에 사용될 때 Excel 스프레드 시트가 계층 BOM을 나타내는 데 어려움을 겪습니다. 즉, 누군가 점화 서브 어셈블리에서 P34 릴레이에 대한 메모를 작성하는 경우 모터 드라이버 서브 어셈블리에 사용 된 P34 릴레이와 동일한 주석이 연결되어야합니다. 이것은 엑셀 스프레드 시트에서 발생하지 않습니다.
회사 인트라넷의 경우 쉽게 검색 할 수 있기를 원합니다. 부품 번호, BOM 구조, 전화 번호, 이메일 주소, 회사 정책 또는 절차와 관련된 데이터 컴퓨터 하드웨어 자산 및 설치된 소프트웨어를 관리하기 위해 이것을 확장하고 싶습니다.
정보 네트워크가 채워지기 시작하면 "XYZ 프로젝트를 진행하는 모든 사람에게 이메일을 쓰고 싶습니다"와 같은 멋진 탐색을 시작할 수 있습니다. XYZ 프로젝트 내에서 데이터를 작성하고 수정하는 것으로 태그가 지정되므로 사람들이 프로젝트와 연관되었을 것입니다. 따라서 XYZ 프로젝트를 검색 키로 사용하면 XYZ 프로젝트와 관련된 모든 것을 갖춘 거대한 세트가 작성됩니다. XYZ 프로젝트를 만든 사람들과의 링크를 포함합니다. 사용자 링크는 이메일 주소에 연결됩니다. XYZ 프로젝트에 참여함으로써 내 이메일에 포함됩니다. 이것은 프로젝트에 종사하는 사람들의 명단을 유지하려는 일부 비서와는 완전히 대조적이다. 우리는 많은 목록을 생성합니다. 우리는 많은 시간을 목록을 유지하고 최신 상태로 유지합니다.
또 다른 멋진 순회는 특정 소프트웨어가 설치된 모든 컴퓨터를 버전별로보고 할 수 있습니다. 이 보고서는 이전 소프트웨어의 추가 사본을 제거하고 최신 사본이 필요한 사람들을 업데이트하는 작업을 생성하는 데 사용될 수 있습니다. 라이센스 추적에도 유용합니다.
다음은 비 관계형 데이터베이스의 요구 사항에 대한 좋은 기사입니다. http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php
관계형 데이터베이스에 결함이 있거나 잘못되지 않았으며 요즘 사람들이 주류 소프트웨어 및 웹 사이트에서 점점 더 많은 데이터를 처리하기 시작하고 관계형 데이터베이스가 확장되지 않는다는 점을 지적하는 데 잘 작동합니다. 이러한 요구에.