frhyme

always doing another thing

Graph Query Language

3 분 소요

GQL: Graph Query Language

GQL is not GraphQL

  • 우선 GraphQL과는 다릅니다. GraphQL은 페이스북에서 “API간에 통신(데이터 교환)을 원활하게 하기 위해서 정의한 언어”라고 말할 수 있습니다.
  • 쓰다보니, 우선 GraphQL을 복습하고 가야겠는데요(왜냐면 저는 생각의 흐름대로 의문점이나 미심쩍은 부분이 있으면 그것부터 짚고 넘어가야하거든요) 일반 회사에서 혹은 내 개인 서비스에서는 내 컴퓨터에서 데이터베이스로 접근해서 데이터를 가져오죠. 이 때는 보통 SQL을 씁니다.
  • 그런데, 우리가 다양한 서비스를 만드는 과정에서는 서비스와 서비스를 혼합하여 새로운 서비스를 만들 일들이 있습니다. 페이스북/구글 계정을 연동하여 가입하는 경우도 그렇고, 뭐 아무튼 많지요. 즉 이 때는 인터페이스와 인터페이스간에서 데이터 교환이 발생하게 됩니다. 그런데 보통 각 인터페이스에서 원하는 데이터 스펙(이걸 쿼리, 라고 불러도 문제가 없죠)이 서로 다른 형태로 존재한다면 매우 귀찮고 복잡해집니다. 보통 json을 가지고 사용하기는 하는데 아무튼 뭐 그렇죠.
  • 따라서, 이걸 어떤 문법, 아무튼 규격화형태로 표준을 만들려고 하는 것이 GraphQL입니다. 그런데, 이 이름에 왜 Graph가 들어가는지 잘 모르겠어요. 찾아봐도 잘 안 나옵니다만, 아마도 여러 api들이 연결되어 서비스로서 제공되는 것이 현재의 서비스들인데, 이것이 마치 네트워크처럼 복잡하게 얽혀있죠. 아마 그걸 표현하려고 한게 아닐가 시프요.

Back to GQL: Graph Query Language

  • 아무튼, 이제 다시 원래대로 돌아옵니다.
  • GQL은 말 그대로 Graph Query Language의 약자이며, SQL이 Structural Query Language의 약자인것과 비슷하죠.
  • SQL의 경우 사실 지배적인 DB 패러다임인 관계형DB를 효과적으로 읽고쓰고고치고맛보기 위한 언어죠, 이것만 존나 잘해도 일을 존나 잘하는 것이기는 한데요.
  • 그러나, SQL의 경우 그래프 데이터를 표현하는 것에는 좀 번거로움들이 있습니다. 네트워크로 형태로 표현되어 있는 데이터를 테이블로 변경해서 저장해야 하고, 사람이 이 데이터를 읽기 위해서 SQL을 사용하려면, 뭐랄까, 메타메타메타처럼 sub-sub-sub 쿼리가 연속으로 들어가야해서 매우 더럽고 복잡해지죠.
  • 어쨌든 현실에서느 네트워크 데이터 관리에 대한 필요성이 증가하기 시작하고(네트워크와 그래프는 사실 좀 같은 의미로 쓰입니다, 저도 이걸 번갈아가면서 막 쓰고요 호호호), GraphDB들도 증가하기 시작하니까, Graph로 표현된 데이터들을 효과적으로 관리하기 위한 언어들이 조금씩 생겨나기 시작했죠.

GQL manifesto

  • 자세한 내용은 여기에서 보실 수 있습니다만, 이를 제가 적당히 번역/요약하면 다음과 같습니다.

  • GraphDB가 아주아주 많이 등장하고 있다(아마존 넵튠, 오라클, SAP등 모두 graphDB를 가지고 있음)
  • 그리고 점점더 많은 사람들이 Graph관점으로 데이터를 관리하는 것을 원한다!
  • 이미 SQL이 데이터베이스의 표준이고 혁신적인 변화를 가져왔지만, 이 아이만으로는 충분하지 못하다!
  • 특히, 지금 표준이 없이 프로덕트별로 쿼리방법이 다른데 이러면 안된다, 이를 해결하기 위해서는 GQL이 필요하다.
  • GQL은 당연히 SQL과도 함께 작동해야겠지만, SQL의 영역에 제한되어서 만들어지지는 않을 것이다.
  • 기존에 있는 3가지 방식의 Graph query 방식을 혼합하여 GQL을 선언한다.

  • 조금 더 자세하게 다른 언어들과의 관계를 보면 다음과 같죠.

Neo4j: how to use it.

  • 어떻게 쓸 수 있나요? 는 아직 잘 모릅니다. 왜냐면 아직 결과물이 분명하게 나오지 않았기 때문이죠.
  • 그래도, 대략 어떤 형태일지는 다른 GraphDB query를 참고하면 어느정도 예상할 수 있지 않을까 싶어요.

cypher: GQL for neo4j

  • cypher는 neo4j 에서 데이터를 쿼리하기 위해서 사용하는 그래프디비쿼리 언어입니다.
  • 여기에 들어가시면, 어떻게 쓰는지 대략 알 수 있습니다만, 대충 보고 몇 가지를 정리해보겠습니다.
  • Person이라는 개체를 가지는 모든 노드를 리턴
    • p는 제가 임의로 배정한 변수명입니다 마치 sql에서 as s1으로 변수명을 지정해주는것과 같죠. 이 변수가 이후에 다른 조건문들에서 쓰일 수 있으므로 만들어주는 것 같아요. 만약 하나밖에 없다면 굳이 만들 필요는 없겠죠.
MATCH (p:Person)
RETURN p
  • Person이라는 개체들 중에서 name attribute가 “Jennifer”인 개체를 찾고, 리턴.
MATCH (jenn:Person {name: 'Jennifer'})
RETURN jenn
  • 개체와 개체간의 관계는 -[:relation]->으로 표현됩니다.
    • 끝에 리턴할 때 company만 리턴한다는 것은 결국 회사만 보여지도록 한다는 것이겠쬬.
MATCH (:Person {name: 'Jennifer'})-[:WORKS_FOR]->(company:Company)
RETURN company
  • 기타로, 당연하지만, where를 사용해서 필터링하는 것도 있고, create등도 있고 다 있습니다. 언뜻 보기에는 SQL이 익숙하면 꽤 금방 익숙해질 수 있을 것 같아요.

wrap-up

  • 뭐, 사실 GQL이 ISO 표준으로 체택되었다고 해서 오랜만에 정리해본 것입니다. 저는 이미 SQL에 꽤 익숙해져 있는 상황이라서, GQL의 예시인 cypher가 그렇게 낯설게 느껴지지 않았습니다. 특히, 쿼리 자체는 node - relation - node의 관계로 되어 있지만, 그 결과는 RETURN을 통해 테이블의 형태로 가져오는 것이죠(물론 이걸 시각화해서 보여줄 수도 있지만). 그렇다면 이 값에 대해서 다시 SQL을 통해서 쓸 수도 있을 것이고요.
  • GQL의 필요성에 대해서는 저도 동의를 하고, 조금 익숙해지면 그래프적으로 접근하게 되서 편해질 것이라고는 생각하지만, 음. 글쎄요. 아직은 잘 모르겠습니다. 그런데, 제가 아직 잘 모르는 것은 아직 현업의 데이터를 다루지 않아서 그럴 수도 있어요.

reference

댓글남기기