Search

Graph Database 입문자가 1년동안 배운 것들



추가 QnA에 대한 글 공유드립니다!

Q1 : gremlin 이란 이름이 지어진 유래가 궁금하네요.


A1 : 저도 맞는 답을 모르지만 https://www.datastax.com/blog/tales-tinkerpop에서Graphophysics 분야에서 big traversal을 뜻하는 “Grem Line”라는 단어에서 파생이 되었다고 주장하고 있습니다.

Q2 : vertex의 adjacent edge가 굉장히 많은 경우에도 이 edge들을 조회하는 데에, RDB에 비해 성능 상의 이점이 있나요? (한 manager에게 direct report하는 사람이 수만명인 경우)


A2 : Performance issue가 있을지 없을지는, 말씀하신 graph structure보다는 query가 얼마나 많은 것들을 touch하냐에 따라 정해집니다. 예를 들어서 쿼리가 100 hops를 하되 각각 레이어 마다 하나의 node 계속 traversal할때는 괜찮겠지만, 2 hops but with 100K nodes in each layer 는 아무래도 좀더 오래 걸리는것 처럼요. 나의 쿼리가 얼마나 많은 부분을 traversal하는지 체크하기 위해서는 쿼리의 explain/profile을 사용하시면 됩니다.

Q3 : Neptune이 neo4j보다 좋은점이 무엇인가요?


A3 : 경쟁사와 비교하기 보다는 넵튠의 강점에 포커스를 두고 말씀드리겠습니다.

  1. Flexibility: 두 가지 모델 RDF와 Labeled property graph를 서포트합니다. 그리고 SPARQL & Gremlin을 쓰실수 있고요. 각각 강점이 다르기에 옵션이 많습니다

  2. “Fully managed” & Cloud: AWS 전체 서비스들 처럼 pay as you use, highly available and scalable합니다

Q4 : 그래프 DB 솔루션을 보유 및 제공하고 있는 한국 기업 아시는 곳이 있으실까요?


A4 : 제가 아는 graph platform providers에서 한국 기업은 잘 모르겠습니다. 대부분이 미국에서 시작했고 그나마 제가 떠올릴수있는, 근접한것은 중국 Alibaba graph database정도 입니다.

Q5 : relationDB와 비교하여 graphDB가 가지는 한계점이 궁금합니다.


A5 : 이 질문은 어떤 쿼리를 하나 먼저 알아야합니다. 만약에 간단한 질문 (예. 회사 구조에서 “Erin의 매니저는 누구인가”, “Erin의 teammate는 누구인가”) 일때는 두가지의 데이타베이스 쓸때 차이가 없어서 굳이 그래프를 쓸 필요는 없습니다. 하지만 connection에 집중된 질문이라면 (예. 소셜 네트워크에서 “Erin과 Bob은 어떻게 연결되어있나?”와 같은 여러 N hops를 아니면 아예 connected 되어 있지 않을때의 질문들) 그래프 데이타베이스를 쓰시는것이 유리합니다.

Q6 : Amazon Neptune은 특정 오픈소스를 customize해서 발전시킨 것인가요? 아니면 아마존에서 새로 만든 것인가요?


A6 : 규정상 답변 드리긴 어려울것 같습니다

Q7 : 실제로 AWS에는 report level이 몇까지 있는지 궁금하네요.


A7 : 너무나도 큰 그래프라서 저도 잘 모르겠습니다

Q8 : Relationship 에는 별도로 속성을 지정할 수 있나요?


A8 : Yes, labeled property graph모델에서 node와 edge에 property을 저장할수 있습니다. (슬라이드 12)

Q9 : Graph DB 가 갖는 flexibility 로 인해서 Node, Edge의 속성이 계속 확장될 수 있다는 것이 오히려 DB 사용자의 확장성의 한계가 되는 경우가 있을까요? (예를 들어 만든 사람이 아니면 Graph에 대해서 한 눈에 이해하기가 어려워 보일 수 있지 않을까라는 생각도 듭니다.)

예를 들어서 RDB의 경우 ERD를 통해 관계를 요약해서 보는 것처럼, GraphDB의 여러 관계 Layer 들을 쉽게 볼 수 있는 View가 있을까요?


A9 : Schema visualization tool에 대해서 여쭤보시는 것 같은데요. 현재 넵튠으로는 그런 질문을 자기가 스스로 query로 답해야합니다. 알려진 불편한 점이라서 개선할 예정입니다.

Q10 : 그래프DB를 적용한 기업사례는 어떤식으로 서치해볼 수 있을까요?


A10 : https://aws.amazon.com/blogs/database/category/database/amazon-neptune/https://neo4j.com/use-cases/을 시작점으로 쓰시면 될것 같습니다.

Q11 : 현업에서 neptune을 OLTP용도로 주로 사용하나요? OLAP로 사용되나요?


A11 : OLTP입니다

Q12 : neo4j 보다 쉽게 접근할 방법이 있는지? / neo4j 와 비교해서 model change effort 를 비교한다면?


A12 : labeled property graph로 옮길때 모델이 같으니 차이가 없을 것 같습니다.

Q13 : 모든 것을 Graph Database로 처리하기에는 한계가 있을 것 같은데, (기존 DB에서 migration 작업 등) multiple DB를 통합적으로 사용할 수 있는 방법은 없을까요?


A13 : 네, 수많은 purpose-built databases들 하나인 graph database를 항상 모든 문제에 쓸수는 없습니다. 각각 유즈케이스마다 다른 NoSQL (key value, doc, etc)를 쓰거나 relational database를 쓸수 있습니다. 방법에 대한 질문은 고객 각각 마다의 유즈케이스에 따라 답이 다르기에 AWS 어카운트의 account manager나 Neptune Discussion Forums으로 연락주시면 됩니다.

Q14 : label propagation 하는 방법이 궁금합니다.자동으로 라벨링을 어떻게 되는지 여부입니다.


Q14 : 현재 넵튠은 주로 OLTP입니다. 반대로 label propagation은 OLAP이고요. AWS Neptune과 EMR을 같이써서 이런 analytical questions를 풀고 있다고 들었습니다. 혹 더 많은 정보가 필요하시면 AWS 어카운트의 account manager나 Neptune Discussion Forums으로 연락주시면 됩니다.

Q15 : Neptune -> sagemaker로 트레이닝시 데이터 전처리 없이 바로 되는건가요?


A15 : Graph data를 DGL에 쓸수 있도록 feature preprocessing(ie. Feature normalization, encoding text features using word2vec)을 합니다. 밑에 보이시는 것(블로그 포스팅에 나오는 샘플 노트북)처럼 sagemaker에서 Neptune API & command를 써서 바로 할수 있습니다.


Q16 : 타 그래프 데이터베이스에서 순환 관계라던가(recursive) a-b, c-a 관계 데이터가 분산되어 병렬(parallel)로 저장될 경우 a 노드에 대해서 동시에 락을 요청해 병목(bottleneck)이 되는 경우가 있었는데 혹시 관계 데이터를(relational data) 병렬로 밀어 넣는 좋은 패턴 같은게 있을까요?


A16 : 제가 질문을 잘 이해했다면 그래프 데이타베이스보다는 Relational database안에서의 질문인것 같은데요. 저도 잘 모르겠습니다.

발표 슬라이드도 함께 공유드리겠습니다😊 https://docs.google.com/presentation/d/1eRKHetKZ3_aSssuz6drQ5vE04kNnZkwKXDLBKCvPSbg/edit?usp=sharing

Copyright © 2021 Upstage all rights reserved.

  • 블랙 페이스 북 아이콘
  • 블랙 인스 타 그램 아이콘
  • 블랙 유튜브 아이콘
  • 블랙 트위터 아이콘