dragon0170 commented 5 years ago

Reference

19 #20

timestamp, attributes(user key, data type) 기준으로 키를 설계하여 read/write가 가능한 PAUST virtual storage prototype 구현

client write 방식

아래와 같은 struct를 json으로 serialize하여 tx로 전송

type Data struct {
Timestamp int64 `json:"timestamp"`
UserKey []byte `json:"userKey"`
Type string `json:"type"`
Data []byte `json:"data"`
}

timestamp는 nano unix timestamp이다.
user key는 ed25519 public key로 32byte이다.
type은 data의 type으로 최대 8byte이다.

RocksDB 관련 설계

row key 는 timestamp(8byte) + user key(32byte) + type(8byte) + time offset(4byte)로 구성
type의 크기가 8byte보다 작을 경우 zero padding으로 8byte로 맞추어 저장
"meta" CF를 이용하여 각 특성들의 이름과 값을 json 형태로 만든 다음 serialize해서 저장
"data" CF를 이용하여 실 데이터 값을 저장

추후 comment로 추가할 내용

client에서 여러 데이터를 하나의 tx으로 write 설계
meta query를 통한 특정 데이터의 attribute read 설계
between query를 통한 데이터 값 read 설계

code-to-gold commented 5 years ago

위에서 말씀하시는 데이터의 type의 의미가 뭔가요? 저희 얘기했던 어떤 종류의 데이터냐에요? 아니면 Integer, Float와 같은건가요?
Andrew와 Kevin이 위 태스크를 서로 어떻게 나눈건가요?

dragon0170 commented 5 years ago

https://github.com/paust-team/paust-db/issues/22#issuecomment-446821956

데이터의 type은 어떤 종류의 데이터인가 입니다. 예를 들어 car speed, car gas gauge 등이 있겠네요.
저번과 비슷하게 저는 client쪽과 interface 설계 위주, Andrew는 rocksdb server쪽을 담당합니다. client와 interface 설계가 빨리 끝날 것으로 예상되므로 추후 제가 Andrew와 함께 server쪽 작업을 나누어 진행할 예정입니다.

code-to-gold commented 5 years ago

https://github.com/paust-team/paust-db/issues/22#issuecomment-446825944

그럼 8byte로 너무 적지 않나요?
cli 지금 command, option 설계를 어떻게 했는지 어디서 볼 수 있나요?

@kwjooo @dragon0170 통으로 이슈를 만들기보다 각각 작업하는거에 대해 이슈생성 해주시고 개발하시다 논의 이슈나 설계에 대해 올려주시는게... 좋을 것 같아요

kwjooo commented 5 years ago

21 이 진행된 후 attribute가 정의되면 크기를 정하려고 하고 있습니다. 우선 8byte로 설정하여 코딩하려 합니다.
cli command와 option 설계는 source파일을 통해서만 볼 수 있습니다.. cmd 관련 설계는 client와 server 각각 issue를 만들어 진행사항을 댓글로 발전시키는 형태로 작업하면 어떨까요?

이번 issue를 reference로 하여 client와 server각각의 이슈를 생성하는 게 좋겠네요.

dragon0170 commented 5 years ago

Client 인터페이스 설계

복수 데이터 tx 설계

https://github.com/paust-team/paust-db/issues/22#issue-390104136 에 정의된 json object의 배열을 tx으로 전송

tx 예시

[
{"timestamp":1544772882435375000,"userKey":"Krc92XkJ+LhkDMO+Qe1utVg1KNGbXdhri3Ol9u5dIAY97w88jgyruQkiMMmN9+hOXqzkR7MZBLIhy7ljYpgNoQ==","type":"cpu","data":"YWJj"},
{"timestamp":1544772960049177000,"userKey":"Krc92XkJ+LhkDMO+Qe1utVg1KNGbXdhri3Ol9u5dIAY97w88jgyruQkiMMmN9+hOXqzkR7MZBLIhy7ljYpgNoQ==","type":"mem","data":"ZGVm"},
{"timestamp":1544772967331458000,"userKey":"Krc92XkJ+LhkDMO+Qe1utVg1KNGbXdhri3Ol9u5dIAY97w88jgyruQkiMMmN9+hOXqzkR7MZBLIhy7ljYpgNoQ==","type":"speed","data":"Z2hp"}
]

Meta query 설계

path: /meta

request Data 예시

{
"timestamp":1544772882435375000,
"userKey":"Krc92XkJ+LhkDMO+Qe1utVg1KNGbXdhri3Ol9u5dIAY97w88jgyruQkiMMmN9+hOXqzkR7MZBLIhy7ljYpgNoQ=="
}

response Value 예시

{
"userKey":"Krc92XkJ+LhkDMO+Qe1utVg1KNGbXdhri3Ol9u5dIAY97w88jgyruQkiMMmN9+hOXqzkR7MZBLIhy7ljYpgNoQ==",
"type":"cpu"
}

kwjooo commented 5 years ago

https://github.com/paust-team/paust-db/issues/22#issuecomment-447249605 Meta query설계의 response 부분에 timestamp를 추가하는 것이 좋을 것 같습니다. meta CF에 대한 between query의 경우에는 response에 timestamp가 있어야 하므로 통일성을 맞추는 게 좋지 않을까요?

1dennispark commented 5 years ago

@kwjooo timestamp를 굳이 통일성을 맞춘다고 추가할 필요는 없습니다. 오히려 traffic은 줄이면 줄일 수록 좋으니까요 ㅎㅎ

dragon0170 commented 5 years ago

Between query 설계

path: /between

1. user key, type 명시

request Data 예시

{
"start":1544772882435375000,
"end":1544772967331462000,
"userKey":"Krc92XkJ+LhkDMO+Qe1utVg1KNGbXdhri3Ol9u5dIAY97w88jgyruQkiMMmN9+hOXqzkR7MZBLIhy7ljYpgNoQ==",
"type":"cpu"
}

response Value 예시

[
{"timestamp":1544772882435375000,"userKey":"Krc92XkJ+LhkDMO+Qe1utVg1KNGbXdhri3Ol9u5dIAY97w88jgyruQkiMMmN9+hOXqzkR7MZBLIhy7ljYpgNoQ==","type":"cpu","data":"YWJj"},
{"timestamp":1544772960049177000,"userKey":"Krc92XkJ+LhkDMO+Qe1utVg1KNGbXdhri3Ol9u5dIAY97w88jgyruQkiMMmN9+hOXqzkR7MZBLIhy7ljYpgNoQ==","type":"cpu","data":"ZGVm"},
{"timestamp":1544772967331458000,"userKey":"Krc92XkJ+LhkDMO+Qe1utVg1KNGbXdhri3Ol9u5dIAY97w88jgyruQkiMMmN9+hOXqzkR7MZBLIhy7ljYpgNoQ==","type":"cpu","data":"Z2hp"}
]

2. user key 명시

request Data 예시

{
"start":1544772882435375000,
"end":1544772967331462000,
"userKey":"Krc92XkJ+LhkDMO+Qe1utVg1KNGbXdhri3Ol9u5dIAY97w88jgyruQkiMMmN9+hOXqzkR7MZBLIhy7ljYpgNoQ=="
}

response Value 예시

[
{"timestamp":1544772882435375000,"userKey":"Krc92XkJ+LhkDMO+Qe1utVg1KNGbXdhri3Ol9u5dIAY97w88jgyruQkiMMmN9+hOXqzkR7MZBLIhy7ljYpgNoQ==","type":"cpu","data":"YWJj"},
{"timestamp":1544772960049177000,"userKey":"Krc92XkJ+LhkDMO+Qe1utVg1KNGbXdhri3Ol9u5dIAY97w88jgyruQkiMMmN9+hOXqzkR7MZBLIhy7ljYpgNoQ==","type":"mem","data":"ZGVm"},
{"timestamp":1544772967331458000,"userKey":"Krc92XkJ+LhkDMO+Qe1utVg1KNGbXdhri3Ol9u5dIAY97w88jgyruQkiMMmN9+hOXqzkR7MZBLIhy7ljYpgNoQ==","type":"speed","data":"Z2hp"}
]

3. type 명시

request Data 예시

{
"start":1544772882435375000,
"end":1544772967331462000,
"type":"cpu"
}

response Value 예시

[
{"timestamp":1544772882435375000,"userKey":"Krc92XkJ+LhkDMO+Qe1utVg1KNGbXdhri3Ol9u5dIAY97w88jgyruQkiMMmN9+hOXqzkR7MZBLIhy7ljYpgNoQ==","type":"cpu","data":"YWJj"},
{"timestamp":1544772960049177000,"userKey":"RMMfqsKyYVV4i89jCgGgF5VXaODpf2HCpX4tShmnXWh8XO4wZwEdcZJ27D18GazZe5/h+P6rir5G1v3yzjx7Sw==","type":"cpu","data":"ZGVm"},
{"timestamp":1544772967331458000,"userKey":"Ky6L4XxaFX9ZAutbzGNPHyZDEKFaDYqiq/MfjKI6fTZajmtSy6lO030VPPGAvtzbpAqxW6H1tPREPu9a+qJasQ==","type":"cpu","data":"Z2hp"}
]

4. 시간만 명시

request Data 예시

{
"start":1544772882435375000,
"end":1544772967331462000
}

response Value 예시

[
{"timestamp":1544772882435375000,"userKey":"Krc92XkJ+LhkDMO+Qe1utVg1KNGbXdhri3Ol9u5dIAY97w88jgyruQkiMMmN9+hOXqzkR7MZBLIhy7ljYpgNoQ==","type":"cpu","data":"YWJj"},
{"timestamp":1544772960049177000,"userKey":"RMMfqsKyYVV4i89jCgGgF5VXaODpf2HCpX4tShmnXWh8XO4wZwEdcZJ27D18GazZe5/h+P6rir5G1v3yzjx7Sw==","type":"mem","data":"ZGVm"},
{"timestamp":1544772967331458000,"userKey":"Ky6L4XxaFX9ZAutbzGNPHyZDEKFaDYqiq/MfjKI6fTZajmtSy6lO030VPPGAvtzbpAqxW6H1tPREPu9a+qJasQ==","type":"cpu","speed":"Z2hp"}
]

dragon0170 commented 5 years ago

https://github.com/paust-team/paust-db/issues/22#issuecomment-447249605 Meta query의 경우 동일한 timestamp와 user key를 가지지만 type이 다른 경우가 있을 수 있습니다. 이와 같은 경우 하나의 request에 대한 response data가 하나의 object가 아니라 array가 되어야할 수도 있다는 것을 염두에 두면 될 것 같습니다.

kwjooo commented 5 years ago

https://github.com/paust-team/paust-db/issues/22#issuecomment-448550101 Meta query에서 request를 보낼 때 start time과 end time 사이의 데이터를 지원해야 할 수도 있을 것 같습니다.

code-to-gold commented 5 years ago

아까 논의한대로, meta에 대한 between query도 있어.. 헷갈리므로, meta data query, real data query로 구분해서 사용합시다. between query는 meta 와 real 모두에 적용될 수 있습니다.

dragon0170 commented 5 years ago

@code-to-gold @kwjooo 그럼 각각의 query들 path는 아래와 같이 변경하여 진행할까요? 적절한 이름 있으면 추천해주세요.

기존 설계

meta data query: /meta
between query: /between

변경안

meta data query: /meta
real data query: /real

dragon0170 commented 5 years ago

확정안

meta data query: /metadata
real data query: /realdata

dragon0170 commented 5 years ago

Metadata query 설계 변경

기존의 meta query에서 between에 대한 request를 적용하면 https://github.com/paust-team/paust-db/issues/29#issuecomment-448892814 와 똑같은 형태의 request data 형태를 가질 것으로 보인다. 따라서 client는 아래의 DataQuery struct를 사용해 query path만 다르게 하여 metadata query와 realdata query를 보내면 된다.

type DataQuery struct {
    Start   int64  `json:"start"`
    End     int64  `json:"end"`
    UserKey []byte `json:"userKey"`
    Type    string `json:"type"`
}

1. user key, type 명시

request Data 예시

{
"start":1544772882435375000,
"end":1544772967331462000,
"userKey":"Krc92XkJ+LhkDMO+Qe1utVg1KNGbXdhri3Ol9u5dIAY97w88jgyruQkiMMmN9+hOXqzkR7MZBLIhy7ljYpgNoQ==",
"type":"cpu"
}

2. user key 명시

request Data 예시

{
"start":1544772882435375000,
"end":1544772967331462000,
"userKey":"Krc92XkJ+LhkDMO+Qe1utVg1KNGbXdhri3Ol9u5dIAY97w88jgyruQkiMMmN9+hOXqzkR7MZBLIhy7ljYpgNoQ==",
"type":""
}

3. type 명시

request Data 예시

{
"start":1544772882435375000,
"end":1544772967331462000,
"userKey":null
"type":"cpu"
}

4. 시간만 명시

request Data 예시

{
"start":1544772882435375000,
"end":1544772967331462000,
"userKey":null,
"type":""
}

5. 공통 response Value 예시

[
    {"timestamp":1544772882435375000,"userKey":"Krc92XkJ+LhkDMO+Qe1utVg1KNGbXdhri3Ol9u5dIAY97w88jgyruQkiMMmN9+hOXqzkR7MZBLIhy7ljYpgNoQ==","type":"cpu"},
    {"timestamp":1544772960049177000,"userKey":"RMMfqsKyYVV4i89jCgGgF5VXaODpf2HCpX4tShmnXWh8XO4wZwEdcZJ27D18GazZe5/h+P6rir5G1v3yzjx7Sw==","type":"mem"},
    {"timestamp":1544772967331458000,"userKey":"Ky6L4XxaFX9ZAutbzGNPHyZDEKFaDYqiq/MfjKI6fTZajmtSy6lO030VPPGAvtzbpAqxW6H1tPREPu9a+qJasQ==","type":"speed"}
]

kwjooo commented 5 years ago

현재 데이터를 저장할 때 초 단위의 timewindow로 조회할 때의 성능이 극대화있는 상황으로, rowkey의 timestamp가 second 단위이며(기존 nano단위 timestamp에서 10의 9승을 나눈 몫) offset(나눈 나머지)은 nanosecond단위입니다. 이로 인해, Client에서 query의 인터페이스를 초단위 간격으로 제한할 필요가 있어 보입니다.

kwjooo commented 5 years ago

또한 단일 timestamp조회에 대한 구현도 필요합니다.

kwjooo commented 5 years ago

후에 데이터의 성격에 따라 조회할 time interval을 설정할 수 있도록 지원해야 할 것 같습니다

code-to-gold commented 5 years ago

@kwjooo nano second 단위로 query를 요청해도 그에 맞는 timewindow를 찾아주면 되는 것 아닌가요?

code-to-gold commented 5 years ago

@kwjooo https://github.com/paust-team/paust-db/issues/22#issuecomment-449967136 의 의미를 구체적으로 알려주세요

kwjooo commented 5 years ago

https://github.com/paust-team/paust-db/issues/22#issuecomment-450052335 second단위로 조회가 들어오면, rowkey를 deserialization하여 offset을 비교하는 연산이 필요없어 지기 때문입니다.

kwjooo commented 5 years ago

https://github.com/paust-team/paust-db/issues/22#issuecomment-450052414 interval을 설정한다는 의미는 기준이 되는 단위(second 혹은 milli second 혹은 nano second)를 정하고 이에 따라 저장하고 query한다는 것을 의미합니다

code-to-gold commented 5 years ago

@kwjooo 그건 개발자 입장에서만 편할것같네요... 쓰는 사람 입장에서는 아닐것 같아요

code-to-gold commented 5 years ago

@kwjooo time unit을 말씀하시는것 같네요. 근데 "데이터의 특성에 따라" 라는게 잘 와닿지 않아서요

kwjooo commented 5 years ago

@code-to-gold time unit이 의미가 더 적합하네요. 저장되는 데이터가 초단위가 중요한지, nano초단위 까지도 중요한지에 따라 time unit이 달라지게 설정하여 사용할 수 있게 하자는 의미입니다

kwjooo commented 5 years ago

@code-to-gold 편한 것보다는 필요없는 연산을 줄여서 쿼리 속도를 높이는 것이 의도였습니다

code-to-gold commented 5 years ago

@kwjooo 필요한 연산이라고 생각됩니다. andrew는 어떻게 생각하세요?

kwjooo commented 5 years ago

@code-to-gold master server를 실행시킬 때 command line flag로 자주 사용되는 query의 time unit 설정을 하고 time unit범위에서만 조회하려해도 괜찮지 않을까 생각했었는데.... 생각해보니 자주 사용 단위(초단위)가 아닌 더 낮은단위(나노단위)도 지원 하는게 완전하겠네요

code-to-gold commented 5 years ago

@kwjooo 나중에는 long-term, short term 기준으로 최근의 데이터의 경우 real-time을 지원하도록 time unit이 작아지고, 일정 기간 이상의 오래된 데이터는 time unit을 크게 하는 형식으로 변경될 것 같습니다.

kwjooo commented 5 years ago

@dragon0170 @code-to-gold server에서 between query에 대한 response를 줄 때 start 이상 end 이하 start 이상 end 미만 start 초과 end 미만 어느 경우가 맞는 것일까요?

kwjooo commented 5 years ago

언어의 정의에 따르면 start초과 end 미만이 맞는 것 같기도 하고... slice[0:8]처럼 개발에 친숙하면 start이상 end 미만이 맞는 것 같기도 하고... 혼란스럽네요 어떻게 생각하시나요

dragon0170 commented 5 years ago

코드 상에서 익숙한건 이상, 미만인데.. 하나의 timestamp에 대해서 데이터를 조회하기 편한 건 이상, 이하일 거 같네요.

kwjooo commented 5 years ago

데이터를 write할 때 timestamp를 timeunit과 offset으로 나누어 저장하였는데, 이는 timeunit단위의 query를 고려한 것이었습니다. 그리하여 현재 코드 상에서 timeunit은 second단위, offset은 nanosecond단위로 되어 있습니다. 하지만 nanosecond단위의 query도 지원해야합니다. 그러므로 offset이 존재할 필요가 없어질 것으로 보입니다. 결론적으로 rowkey의 구조가 timestamp(8byte) + user key+ type + time offset(4byte) 에서 timestamp + userkey + type으로 수정하려하는데 어떻게 생각하시나요?

kwjooo commented 5 years ago

https://github.com/paust-team/paust-db/issues/22#issuecomment-450066738 다른 tsdb는 어떻게 하는 지 조사하였는데, opentsdb는 이상 미만이고 influxDB는 SQL문에 이상인지 초과인지 이하인지 미만인지를 명시하여 사용합니다.

dragon0170 commented 5 years ago

https://github.com/paust-team/paust-db/issues/22#issuecomment-450081049 저도 현재 프로토타입의 구조에서는 offset이 필요성이 없을 것 같아 동일하게 생각합니다.

code-to-gold commented 5 years ago

이상 미만으로 가면 되고, key에서 offset은 빼도 좋을 것 같습니다.

paust-team / paust-db

Implement meta data storing and read query of PAUST virtual storage prototype #22

19 #20

21 이 진행된 후 attribute가 정의되면 크기를 정하려고 하고 있습니다. 우선 8byte로 설정하여 코딩하려 합니다.

Client 인터페이스 설계

Between query 설계

기존 설계

변경안

확정안

Metadata query 설계 변경