Design the efficient structure for storing data

[elon0823]

Problem

현재 Tendermint 구조는 Transaction들을 모아서 블록을 만들고 그 블록을 part 로 쪼개서 leveldb(우리는 rocksdb 로바꿈) 에 저장을 하게됩니다. 즉 abci lifecycle 을 타면서 tx 를 검증해서 block 에 tx 를 추가하고 block 생성시간(1sec) 동안 모은 tx[] 를 bytearray 로 만들어서 blockstore 를 통해 db 에 저장하는 구조입니다. 이 때, paust-db의 PUT 요청에서도 tx 를 받았을때 transaction 데이터에 담긴 real/meta 데이터를 rocksdb 에 또 저장하고있습니다. 여기서 데이터 중복이 생기게 되는데 이를 해결할 수 있는 방안이 있을지 고민해보고있습니다.

Tendermint Block 구조

tendermint 의 Block 구조는 header, data, lastCommit 으로 구성되어있습니다. 주의깊게 봐야할건 header 와 data 인데

Block

A Block is composed of:

• Header: basic information about the chain and last state
• Data: transactions and other data
• LastCommit: +2/3 precommit signatures for the previous block

Header

The block Header is composed of:

• ChainId (string): name of the blockchain, e.g. "tendermint"
• Height (int): sequential block number starting with 1
• Time (time): local time of the proposer who proposed this block
• LastBlockHash ([]byte): block hash of the previous block at height Height-1
• LastBlockParts (PartSetHeader): partset header of the previous block
• StateHash ([]byte): state hash of the state after processing this block

Data

The block Data is composed of:

• Txs ([]Tx): a list of transactions

To-do

1. 먼저 paust-db 가 따로 rocksdb 에 PUT 데이터를 저장안하고 tendermint 상에서 저장된 block 들을 통해서 Query / Fetch 를 하는 시나리오를 생각해봅시다. tendermint 블록이 여러 블록파트로 나뉘게 되면서 블록의 모든 transaction byte array 또한 나눠지게됩니다. 이로부터 데이터를 찾으려면 Query/fetch 시 매번 partblocks -> block -> transactions 으로 재구성하는 과정을 거쳐야할탠데 이에 대한 throughput 이 잘 나올지 실험을 해봐야 할것같습니다.

2. Tendermint block store의 구조를 변경해서 tx[] 엔 transaction 의 hash 들만 저장하게끔하고 transaction 의 데이터를 지금처럼 따로 저장하게끔 하는 구조도 생각해볼 수 있지 않을까합니다. 그럼 블록의 data 에 저장되는 tx[] byte 는 transaction 에 대한 meta 테이블 같은 형태가 되겠죠.

3. 텐더민트를 걷어낸다

또 좋은 방법이 있을지 고찰이 필요할것같습니다.

[dragon0170]

tendermint block, rocksdb 데이터 중복 저장과 관련된 것들 중 rocksdb 동일 데이터 overwrite 이슈도 있습니다.

• 현재 tendermint를 종료 후 재시작하는 경우 모든 지금까지 쌓였던 모든 block이 다시 paust-db abci cycle에 따라 실행되면서 tx 내에 포함된 put을 반복하게 됩니다. 따라서 같은 put이 반복되므로 동일한 데이터가 overwrite 되게 됩니다. 이 과정은 time과 processing 모두 낭비가 됩니다.
• 1차 prototype의 테스트에서는 블록 수와 데이터 수가 적어서 큰 문제가 없어서 추후 의논 및 개선하기로 결정하고 진행하였습니다.(@elon0823)

• 현재 구조에서 가장 간단하게 이를 해결할 방법은 rocksdb 내에 last excuted block height를 기록해서 tendermint 재시작시 paust-db master에서 해당 height 이전의 블록들의 실행을 막는 것이 있습니다.

  2. Tendermint block store의 구조를 변경해서 tx[] 엔 transaction 의 hash 들만 저장하게끔하고 transaction 의 데이터를 지금처럼 따로 저장하게끔 하는 구조도 생각해볼 수 있지 않을까합니다. 그럼 블록의 data 에 저장되는 tx[] byte 는 transaction 에 대한 meta 테이블 같은 형태가 되겠죠.

위와 같은 형태로 tendermint block store를 변경하게 된다면 새로운 tendermint node가 추가될 때 데이터 sync 과정에서 기존 block 동기화 과정에 paust-db를 위해 최적화된 rocksdb 데이터 동기화 과정이 추가로 필요할 것 같습니다.

• 이렇게 텐더민트를 변경하게 될 경우 tendermint를 fork떠서 paust-db에 적절하게 튜닝하는 것이 좋아보이네요.
  • 이 경우에는 위의 rocksdb 데이터 overwrite 문제를 paust-db master application에서 해결하는 것이 아니라 아예 기존에 쌓인 블록들은 paust-db abci cycle을 타지 않도록 수정할 수도 있겠네요.
  • 튜닝하게 되면 request, response protocol도 paust-db에 필요한 것만 남기거나 변경하는 건 어떨까 싶네요.
  • 최종적으로는 tendermint, paust-db 바이너리를 따로 두는 것이 아니라 하나의 바이너리로 합치는 것도 괜찮을 것 같습니다.

[elon0823]

Block 은 timestamp 로 쌓인다하여도 해당 transaction 들에 대한 timestamp 는 순차적이지 않을 수 있는 문제가 있습니다. PUT 할 때 데이터의 timestamp 를 정해서 넣을수 있으니까요