yang db
1.0.0
https://www.yangdb.org/
위키
버전 정보
릴리스.노트
리오르 페리
로만 마골리스
모티 코헨
엘라드 비스
시몬 베노시티
Opensearch를 통해 확장 가능한 분산 그래프 DB를 구축하기 위한 새로운 오픈 소스 이니셔티브를 소개하는 게시물 https://www.linkedin.com/pulse/making-db-lior-perry/
Opensearch를 그래프 DB로 활용하는 또 다른 방법 https://medium.com/@imriqwe/elasticsearch-as-a-graph-database-bc0eee7f7622
그래프 데이터베이스의 세계는 지난 몇 년 동안 특히 소셜 네트워크와 일상 활동에 미치는 영향과 관련하여 엄청난 영향을 미쳤습니다.
한때 강력하고 외로운 RDBMS는 이제 데이터 센터에서 점점 더 중요해지고 있는 신흥 파트너인 그래프 데이터베이스를 위한 공간을 마련해야 합니다.
트위터가 이를 사용하고, 페이스북이 이를 사용하고, 심지어 온라인 데이트 사이트도 이를 사용하고 있습니다. 그들은 관계 그래프를 사용하고 있습니다. 결국 소셜은 사회적이며 궁극적으로 관계에 관한 것입니다.
그래프 기술을 구별하는 두 가지 주요 요소는 저장과 처리입니다.
그래프 저장소란 일반적으로 그래프 데이터를 포함하는 데이터베이스의 구조를 의미합니다.
이러한 그래프 저장은 여러 측면에서 그래프에 최적화되어 데이터가 효율적으로 저장되도록 보장하고 실제 물리 계층에서 노드와 관계를 서로 가깝게 유지합니다.
그래프 저장소는 관계형, 열 형식 또는 기타 유형의 데이터베이스와 같은 외부 소스에서 저장소를 가져오는 경우 비기본 저장소로 분류됩니다(대부분의 경우 NoSQL 저장소가 선호됨).
비기본 그래프 데이터베이스는 일반적으로 그래프 데이터 모델 쿼리 시나리오에 맞게 조정된 기존 관계형, 문서 및 키 값 저장소로 구성됩니다.
그래프 처리에는 그래프 액세스, 정점 및 가장자리 탐색, 결과 수집이 포함됩니다.
순회는 일부 규칙에 따라 관계를 따라 시작 노드에서 관련 노드로 이동하여 그래프를 쿼리하는 방법입니다.
"내가 아직 갖고 있지 않은 음악 중 내 친구들은 어떤 음악을 좋아하는가?"와 같은 질문에 대한 답을 찾는 것입니다.
그래프를 표현하는 데 가장 널리 사용되는 모델 중 하나는 속성 모델입니다.
이 모델에는 원하는 수의 속성(키-값 쌍)을 보유할 수 있는 연결된 엔터티(노드)가 포함되어 있습니다.
노드에는 고유 ID가 있으며 속성 목록은 해당 기능과 콘텐츠를 나타냅니다.
노드에는 도메인 내 다양한 역할을 나타내는 라벨이 표시될 수 있습니다. 관계 속성 외에도 레이블은 그래프 요소에 대한 메타데이터를 제공할 수도 있습니다.
노드는 종종 엔터티를 나타내는 데 사용되지만 도메인 관계에 따라 해당 목적으로도 사용될 수도 있습니다.
관계는 연결되는 소스 및 대상 노드로 표시되며 동일한 꼭지점 사이에 여러 연결이 있는 경우 구별할 속성의 추가 레이블(관계 유형)
관계는 노드를 임의의 구조로 구성하여 그래프가 목록, 트리, 맵 또는 복합 엔터티와 유사하도록 허용합니다. 이러한 항목은 모두 더 복잡한 구조로 결합될 수 있습니다.
관계형 DB 모델의 테이블 간 외래 키와 매우 유사하게 그래프 모델의 관계는 정점 간의 관계를 설명합니다.
엄격한 관계형 스키마와 비교하여 이 모델의 주요 차이점 중 하나는 이 스키마 없는 구조를 사용하면 제약 없이 정점 간의 관계를 추가/제거할 수 있다는 것입니다.
추가 그래프 모델은 RDF(Resource Description Framework) 모델입니다.
우리의 사용 사례는 소셜 네트워크 영역에 있습니다. 자주 업데이트되고 두 가지 모두에 사용할 수 있는 매우 큰 소셜 그래프:
단순(주로 텍스트) 검색
그래프 기반 쿼리.
모든 읽기 및 쓰기는 합리적인 응답 시간과 지속적으로 증가하는 처리량을 통해 동시에 수행됩니다.
첫 번째 요구 사항은 매우 많은 양의 데이터를 포함할 수 있는 잘 알려지고 확립된 NoSql 문서 검색 및 저장 엔진인 Opensearch를 사용하여 충족되었습니다.
두 번째 요구 사항에 대해 우리는 최선의 솔루션이 Opensearch를 기본이 아닌 그래프 DB 스토리지 계층으로 사용하는 것이라고 결정했습니다 .
앞서 언급했듯이 그래프-DB 저장소 계층은 NoSql 저장소와 같은 비기본 저장소를 사용하여 구현할 수 있습니다.
향후 토론에서는 그래프 DB에 대한 가장 인기 있는 커뮤니티 대안인 Neo4J가 우리 요구 사항에 맞지 않는 이유에 대해 자세히 설명하겠습니다.
우리 플레이트의 첫 번째 문제는 그래프를 정점과 가장자리의 집합으로 나타내는 데이터 모델을 설계하는 것입니다.
Opensearch를 사용하면 강력한 검색 기능을 활용하여 쿼리 필터에 따라 노드 및 관계 문서를 효율적으로 가져올 수 있습니다.
Opensearch에서 각 인덱스는 특정 스키마에 대한 테이블로 설명될 수 있으며, 인덱스 자체는 공유로 분할되어 클러스터 전체에서 확장 및 중복성(복제본 포함)을 허용합니다.
문서는 다음 공식을 사용하여 인덱스의 특정 샤드로 라우팅됩니다.
shard_num = hash(_routing) % num_primary_shards
각 인덱스에는 문서 구조(Opensearch에서는 매핑이라고 함)를 정의하는 스키마(Opensearch에서는 유형이라고 함)가 있습니다. 각 인덱스는 단일 유형의 매핑만 보유할 수 있습니다(Opensearch 6 이후).
정점 인덱스에는 속성이 있는 정점 문서가 포함되고, 가장자리 인덱스에는 해당 속성이 있는 가장자리 문서가 포함됩니다.
그래프를 탐색하는 방법을 설명하는 방식(데이터 소스)
그래프 지향 쿼리 언어는 거의 없습니다.
Cypher는 Neo4j 그래프 데이터베이스용 쿼리 언어입니다(openCypher 이니셔티브 참조).
Gremlin은 OLTP 및 OLAP 그래프 시스템을 위한 Apache Software Foundation 그래프 순회 언어입니다.
SPARQL은 RDF 그래프용 쿼리 언어입니다.
일부 언어는 패턴 기반이고 선언적이며 일부는 더욱 필수적입니다. 모두 데이터를 탐색하는 논리적인 방법을 설명합니다.
Ascii-art 구문을 사용하여 그래프의 패턴을 시각적으로 설명하기 위한 선언적 SQL 기반 언어인 Cypher를 고려해 보겠습니다.
이를 통해 그래프 데이터에서 선택, 삽입, 업데이트 또는 삭제하려는 항목을 정확하게 수행 방법을 설명하지 않고도 명시할 수 있습니다.
논리적 쿼리가 제공되면 이를 데이터 저장소의 물리적 계층인 Opensearch로 변환해야 합니다.
Opensearch에는 순회가 아닌 검색 및 집계에 초점을 맞춘 쿼리 DSL이 있습니다. 그래프의 도식 구조(및 기본 인덱스)를 고려하는 추가 변환 단계가 필요합니다.
논리적-물리적 쿼리 변환은 몇 가지 단계로 구성된 프로세스입니다.
스키마에 대해 쿼리 유효성 검사
레이블을 실제 스키마 엔터티(색인)로 변환
물리적 Opensearch 쿼리 생성
이는 실제로 높은 수준의 검토 프로세스입니다. 논리적 쿼리를 최적화하는 더 많은 단계가 있습니다. 경우에 따라 여러 물리적 계획(실행 계획)을 생성하고 가져오는 데 필요한 요소 수와 같은 일부 효율성(비용) 전략에 따라 순위를 매기는 것이 가능합니다.
오늘날의 비즈니스 사용 사례에서 그래프 DB의 목적에 대해 논의하는 것부터 시작하여 그래프를 표현하기 위한 다양한 모델을 검토했습니다. 잠재적인 그래프 DB가 구성되어야 하는 기본 논리적 빌딩 블록을 이해하고 스토리지 계층 요구 사항을 충족하기 위해 기존 NoSql 후보를 논의했습니다.
Opensearch를 스토리지 계층으로 선택한 후 LDBC 소셜 네트워크 벤치마크 그래프 모델을 사용하고 이를 단순화하여 특정 스토리지에 최적화했습니다. 중복된 속성을 갖는 실제 스토리지 스키마에 대해 논의하고 SQL과 유사한 그래프 패턴 언어로 스토리지를 쿼리하기 위한 암호 언어를 검토했습니다.
우리는 암호 쿼리가 Opensearch에서 실행되는 물리적 실행 쿼리로 실제로 변환되는 것을 계속해서 확인했습니다.
마지막 섹션에서는 간단한 그래프 쿼리를 사용하여 실행 전략 및 벌킹 메커니즘에 대한 세부 정보를 자세히 살펴보았습니다.
설치 튜토리얼:
스키마 생성 튜토리얼:
데이터 로딩 튜토리얼:
그래프 튜토리얼을 쿼리합니다.
투영 구체화 및 계산 튜토리얼:
