Survey query interface design of other NoSQL database

[dragon0170]

ref: https://github.com/paust-team/paust-db/issues/145#issuecomment-475202619, #160

paust-db의 query interface를 timeseries database에 적절하게 설계하기위해 다른 NoSQL database의 query interface design을 우선 찾아보려고 합니다.

• TinkerPop (Graph Query)
• HBase (Column based Query)

[dragon0170]

Graph traversal을 위한 machine인 Apache TinkerPop의 Getting Started(http://tinkerpop.apache.org/docs/current/tutorials/getting-started/) 와 Gremlin Console(http://tinkerpop.apache.org/docs/current/tutorials/the-gremlin-console/) Document를 조사하면서 찾은 내용 중 paust-db에서 참고할만한 것들입니다.

• Gremlin console은 java, JVM을 기반으로 만들어졌으면 REPL 구조임. 따라서 동일한 query에 대해 console에서 입력하는 명령어와 java application에서 사용하는 함수의 형태가 같음. -> CLI 환경상에서 interactive하고 session 유지를 위해서 paust-db의 CLI도 이런 REPL 구조를 가지면 좋을 것 같습니다. 그리고 paust-db도 CLI에서 사용하는 query 명령어가 paust-db client library를 import하여 사용하는 함수와 연결되는 구조를 가지면 좋을 것 같습니다.
• JVM기반이라 java와 거의 동일하게 다른 java library import도 가능하고 함수 실행도 가능함. 다른 module(ex. hadoop, cassandra 등)과 연동도 간단하게 할 수 있는 이점이 있음. -> 상당히 편한 기능인 것 같습니다. paust-db CLI가 사용하게 될 언어의 기본 library를 활용할 수 있으면 좋아보입니다.
• graph 구조가 fst 구조와 비슷한데 비슷한 방식으로 traverse 전략을 세울 수 있지 않을까? -> 어차피 path를 찾는 건 fst의 연산으로 찾으므로 traverse가 의미가 없을 거 같습니다. 중복인 것 같네요.
• Gremlin에서 graph를 traverse하기 위해서는 TraversalSource를 생성해야하며 이는 traversal strategy와 traversal engine에 대한 정보를 갖고 있음 -> paust-db도 사용자마다 필요한 데이터 query 전략이 다를 것이므로 long/short term policy, node 등에 대한 정보를 갖고 있는 객체가 추후에 필요할 것 같습니다.

  gremlin> graph = TinkerFactory.createModern()
  ==>tinkergraph[vertices:6 edges:6]
  gremlin> g = graph.traversal()
  ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
  gremlin> g.V()
  ==>v[1]
  ==>v[2]
  ==>v[3]
  ==>v[4]
  ==>v[5]
  ==>v[6]
  gremlin> g.V().has('person','name',within('vadas','marko')).values('age')
  ==>29
  ==>27

• 위의 g.V(), g.V().has().values()와 같은 query는 사실 traversal을 위한 iterator를 생성하는 것이지 query에 대한 결과값을 가지고 있는 것이 아님. 실제 query 결과값을 얻기 위해서는 해당 iterator를 iterate하여야 함. 하지만 Gremlin console에서는 iterator가 return되는 경우 자동으로 iterate하면서 결과값을 fetch해서 보여주기 때문에 마치 결과값을 바로 출력해주는 것처럼 보임. Gremlin을 console이 아니라 java에서 직접적으로 사용한다면 명시적으로 모두 iterate를 하여야 결과값을 볼 수 있음. -> 이 구조는 paust-db에서 가져야할 query의 결과와 비슷합니다. paust-db의 query 명령을 통해서는 실제 값을 가져오는 것이 아니라 가져올 주소를 가진 iterator가 생기는 것이고 해당 iterator를 next operation이 들어올 때 실제 값을 fetch해서 사용자에게 보여주게 됩니다. 이런 query-fetch 구조를 paust-db CLI에서 비슷하게 가져가면 좋을 것 같습니다. 다만 console 상에서 자동으로 iterator를 iterate하는 것이 default로 있으면 안될 것 같습니다. 사용자가 하나씩 next명령어를 통해 iterate하고 원하는 데이터라면 나머지 모든 데이터를 iterate 하는 명령어를 입력하는 방식이 좋아보입니다. -> 이런 구조는 또한 multi query-fetch에 어울릴 것 같습니다. query한 iterator를 하나씩 돌다가 원하는 데이터가 아니면 새롭게 수정된 query를 보내는 구조가 됩니다. 이전 query문에 대한 정보를 재활용할 수 있으면 좋을 것 같네요.
• g.V().has('person','name',within('vadas','marko')).values('age') query에는 has()로 데이터의 property에 대해 제한하고 within()으로 'vadas' or 'marko'와 같은 로직도 사용할 수 있음. -> has()와 같은 query interface는 paust-db의 qualifier에 대한 containing query로 사용하면 좋아보입니다. 그리고 within()과 같은 OR interface도 paust-db query에 필요해 보입니다.
• data analysis를 위해 fetch하는 데이터를 filter, 가공하여 다른 형태로 출력하는 함수들(where(), as(), group() 등)이 있음. -> 이런 기능은 paust-db client에 당장은 필요없을 것 같습니다. 우선 가공하는 건 client에서 직접하도록 하고 나중에 추가하면 편한 기능일 것 같습니다.

[elon0823]

저도 node 환경에서 REPL 을 통해서 실험한번해봤습니다. REPL 은 쉽게 implementation 가능한것같아요. 중요한건 인터페이스를 설계하는건데 모델 기반으로 설계를 해야할 것 같습니다. 지금은 httpclient상에서 각 인터페이스 구현부가있고 직접 호출하는 형태인데 이게 아닌 Query, Fetch, 등을 모델로 구현해서 내부의 interface를 통하여 iterator operation 을 구현하면 좋을듯하네요. 아직 어떤 인터페이스 들어갈지 정해진않아서 iterator operation 은 없지만 제 repo에 pdb-tester 에서도 진행하고있으니 같이 설계를 함 해봅시다.

[dragon0170]

Column 기반 NoSQL database인 HBase의 HBase Shell(https://hbase.apache.org/book.html#shell) Document를 조사하면서 나온 것들 중 paust-db에서 참고할만한 것들입니다. HBase의 console은 Gremlin과는 달리 실제 query보다는 admin이 테스트나 관리를 위해 사용하는 관점을 위주로 만들어진 것 같습니다. 실제로 java application에서 import해서 사용하는 HBase의 코드 구현부를 살펴보면 paust-db Query Interface 구현에 도움이 될 것 같습니다.

• HBase console은 JRuby의 IRB(interactive ruby shell)임. Gremlin과 마찬가지로 REPL 방식임.
• JRuby는 JVM상의 ruby language 환경이라고 보면 됨.
• HBase console은 ruby 환경이므로 ruby script 입력해서 사용 가능.
  • console실행 시 ruby script file 실행 가능
• java library도 import해서 사용 가능

  
  hbase(main):021:0> import java.text.SimpleDateFormat
  hbase(main):022:0> import java.text.ParsePosition
  hbase(main):023:0> SimpleDateFormat.new("yy/MM/dd HH:mm:ss").parse("08/08/16 20:56:29", ParsePosition.new(0)).getTime() => 1218920189000

================================

hbase(main):021:0> import java.util.Date hbase(main):022:0> Date.new(1218920189000).toString() => "Sat Aug 16 20:56:29 UTC 2008"

* HBase console scan interface는 아래와 같습니다.
> Scan a table; pass table name and optionally a dictionary of scanner
specifications. Scanner specifications may include one or more of:
TIMERANGE, FILTER, LIMIT, STARTROW, STOPROW, TIMESTAMP, MAXLENGTH,
or COLUMNS, CACHEIf no columns are specified, all columns will be scanned.
```shell
hbase> scan ‘.META.’, {COLUMNS => ‘info:regioninfo’}
hbase> scan ‘t1’, {COLUMNS => [‘c1’, ‘c2’], LIMIT => 10, STARTROW => ‘xyz’}
hbase> scan ‘t1’, {COLUMNS => ‘c1’, TIMERANGE => [1303668804, 1303668904]}
hbase> scan ‘t1’, {FILTER => “(PrefixFilter (‘row2’) AND
(QualifierFilter (>=, ‘binary:xyz’))) AND (TimestampsFilter ( 123, 456))”}
hbase> scan ‘t1’, {FILTER =>
org.apache.hadoop.hbase.filter.ColumnPaginationFilter.new(1, 0)}

• Gremlin과 비슷하게 jruby-style object-oriented references for tables 제공

  
  hbase(main):007 > t = create 't', 'f'
  0 row(s) in 1.0970 seconds

=> Hbase::Table - t hbase(main):008 > t.put 'r', 'f', 'v' 0 row(s) in 0.0640 seconds hbase(main):009 > t.scan ROW COLUMN+CELL r column=f:, timestamp=1331865816290, value=v 1 row(s) in 0.0110 seconds hbase(main):010:0> t.describe DESCRIPTION ENABLED 't', {NAME => 'f', DATA_BLOCKENCODING => 'NONE', BLOOMFILTER => 'ROW', REPLICATION true SCOPE => '0', VERSIONS => '1', COMPRESSION => 'NONE', MIN_VERSIONS => '0', TTL => '2 147483647', KEEP_DELETED_CELLS => 'false', BLOCKSIZE => '65536', IN_MEMORY => 'false ', BLOCKCACHE => 'true'} 1 row(s) in 0.0210 seconds hbase(main):038:0> t.disable 0 row(s) in 6.2350 seconds hbase(main):039:0> t.drop 0 row(s) in 0.2340 seconds

==============================

hbase(main):011 > create 't','f' 0 row(s) in 1.2500 seconds

=> Hbase::Table - t hbase(main):012:0> tab = get_table 't' 0 row(s) in 0.0010 seconds

=> Hbase::Table - t hbase(main):013:0> tab.put 'r1' ,'f', 'v' 0 row(s) in 0.0100 seconds hbase(main):014:0> tab.scan ROW COLUMN+CELL r1 column=f:, timestamp=1378473876949, value=v 1 row(s) in 0.0240 seconds hbase(main):015:0>

[dragon0170]

query 관련 내부 구조

HBase

https://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/package-summary.html#package.description 에 있는 Example API Usage 참고

1. Scan object를 생성하고 탐색할 column family/qualifier, start key, end key, min/max timestamp, filter 등을 설정함.
2. table.getScanner(Scan object) method로 ResultScanner object 생성. 얘가 Iterator 역할을 함.
3. ResultScanner object에서 next() method를 통해 iterate하면서 Result object를 생성.
4. Result Object에 실제 value 데이터가 있으며 value(), getValue(family, qualifier) 등의 method를 통해 사용 가능.

   TinkerPop Gremlin

   https://www.datastax.com/wp-content/uploads/2016/10/bytecode-to-execution.png 참고

5. GraphTraversalSource object에서 V(), E()와 같은 method들로 GraphTraversal<S,E> object 생성.
   • GraphTraversal<S,E>는 Iterator를 상속받은 interface임. 따라서 iterate는 next()로 가능함.
6. has(), values(), out()과 같은 method를 통해 존 GraphTraversal로부터 새로운 GraphTraversal 객체가 만들어짐.
   • 새로운 GraphTraversal 객체는 내부에서 addStep이라는 GraphTraversal method로 구성함. GraphTraversal 객체에 method의 이름과 똑같이 step을 하나하나씩 더해나가는 형태임.
   • step의 종류도 링크 사진의 machine code 부분에서 보듯이 여러가지임.
7. has(), values(), out()과 같은 method들이 적용되면서 GraphTraversal의 E가 바뀜. 즉, iterator가 바뀜.