Design row key with column-family on RocksDB

[code-to-gold]

Reference #17 #19

---

기존에는 timestamp, user key 기준으로 key를 설계 하였다면, data의 각 속성 기준 효율적인 쿼리가 가능하도록 설계. RocksDB의 특성을 활용하여 row key를 디자인 해야 함.

CF = column family

RocksDB 특성

• hbase와는 다르게, column qualifier가 존재하지 않음. key value 구조를 유지하기 위해 CF만 존재.
• CF는 논리적으로 파티셔닝 하기 위해 사용.
• 각 key, value pair는 하나의 CF와 연관되어 있음. write시 CF를 설정하지 않으면 "default" CF로 저장됨.
• SSTable 구조. 문자열 기준으로 정렬이 되어있음.

User Scenario

• Time Stamp 기준 between query를 하는 경우가 많음.
• 데이터의 실제 값 뿐만 아니라, 해당 데이터의 특성에 대해 알고 싶어 함. 추후 paust db를 통해 데이터의 거래가 일어날 시 필수 조건.

설계 과정

• Row key는 timestamp 기준으로 sorting되어있는게 between query를 통한 조회시 가장 유리.

• Timestamp 기준 between과 함께 각각 특성에 대해 조회하는 경우가 있을 것이고, timestamp만을 row key로 사용할시 중복 이슈가 있으므로, timestamp + a 로 row key를 디자인

• 특성에 대한 조회의 복잡도를 낮추기 위해(value를 가져와 iteration을 하는 것을 피하기 위함) row key에 특성 정보가 들어가는 것이 좋음. 단, row key가 너무 길면 효울이 좋지 않으므로 정보의 길이를 줄여야함. 또한, n번째 bit 가 특정 특성을 나타내거나 (길이 고정), row key를 어느정도 읽으면 해당 특성의 위치 정보를 알 수 있어야 함. 전자가 유리할 것으로 판단됨.

• One-way function인 hash를 사용해도 되고, 단순 serialize를 사용해도 되고, UID Mapping Table 을 이용해도 됨. UID Mappping Table이 가장 효율적일 것으로 판단됨.

• User Scenario의 두번째 가정을 충족시키기 위해, CF를 이용해 Attribute 정보만을 담는것을 구성하는 것이 좋을 것으로 보임.

• User는 데이터의 각 특성에 대해 하나하나 조회하기 보다, 전체 특성을 조회하는 경우가 많음. 각 특성별로 CF를 구성하기 보다, "Meta"라는 CF를 구성하여 value에 serialized json object 를 담아 모든 특성 정보를 저장하는 것이 유리할 것으로 판단됨.

  결론

• row key 는 time stamp + UID(attr1 name + attr1 value + attr2 name + ...)로 구성

• "Meta" CF를 이용하여 각 특성들의 이름과 값을 json 형태로 만든 다음 serialize해서 저장

• "Data" CF를 이용하여 실 데이터 값을 저장

[code-to-gold]

초기는 UID Table을 이용하기 보다, 단순 serialize해서 저장하는 것으로 prototype을 생성하는게 좋을듯

[code-to-gold]

@co1god 확인 부탁드려요 컨펌 후에 @kwjooo @dragon0170 이 작업 시작하면 될듯

[1dennispark]

저도 @code-to-gold 와 마찬가지의 생각입니다. 초기에는 UID 테이블보다 그냥 META CF를 통해 단순 serialize해서 저장하는 것을 추천합니다.

나중에 이 META CF의 조회가 병목이 될 것이라 예상하고 있어서요. 이 부분을 in-memory로 로드 후에 최적화 알고리즘을 통해 조회하는 것을 목적으로 하고 있습니다.

그래서 그 다음에 저 최적화 알고리즘에 따라 UID 테이블과 유사한 형태로 새로 디자인할 가능성이 있기 때문에 지금은 시도하지 않는 것을 추천드리는 바입니다.