Simple P2P structure based data storing design

Intro

issue #161 을 진행하면서 block chain의 구조를 만들고 block 끼리 chaining 을 형성하여 validation 을 하고 transaction list 를 block 에 담는 구조를 가질 필요가 있을까에 대한 고민을 함

Problem

기존의 blockchain 은 거래의 기록을 담기 위한 데이터 구조
기존의 모든 blockchain 구조는 청렴한 거래내역을 보장하기 위한 장부 의 특성에 맞음. 이전의 거래가 현재 값에 영향이 있음.
transaction, address, recipient, amount 등의 구조는 decentralized time series database 형태인 pdb에 필요하지 않는 것 같음
기존 blockchain의 consensus 또 한 기존의 연결된 장부 내역을 모두가 검증하고, 변조를 할 수 없게 하기 위함에 있음
한 global chain을 유지하고 fork 된 chain 간에 main chain 을 유지해야하므로 valid chain 으로 replace 할 수 있는 validation 과정이 주요하므로 consensus가 여기에 초점이 맞춰져있음
transaction 들을 모아서 block주기 마다 block 을 commit 하고 chain 에 포함하기 위한 연산/시간 비용을 사용하게됨

Approach

paust-db 는 기존의 분산 데이터 베이스 context 의 consensus(consistency, integrity 등을 보장), + 탈중앙화 특성만 가져가면 되지 않나?
blockchain 의 linked list 구조, vote, precommit, commit 등의 life cycle을 버리고 간단하게 가자
기존의 복잡한 consensus algorithm 제외
block 에 transaction list 가 아닌 한 트랜잭션만 저장하는 구조처럼, block 에 데이터를 바로 저장
각 노드는 자신의 데이터를 rocksdb 를 이용하여 시간순으로 저장하고있음
모두가 physical 하게 동일한 데이터 상태를 유지하는 것이 아닌(non-fullcopy) logical 한 time-series 를 형성하는 분산 저장 구조
노드로 참여할 때 저장구조, data term, sync time 등의 부분은 다 정책을 이용해서 네트워크를 구성할 수 있도록 해야함. 개발자가 정해놓은 static 한 로직에 의해서 돌아가는 네트워크보다 각 노드가 각자 다른 정책을 이룬형태로 네트워크가 형성됨. 동적부분 분산이 가능한 p2p network(dennis 표현)

Base structure

(비잔틴, 보안 측면을 제외한 분산 데이터 저장관점(PUT) 에서만 생각해본 구조)

각 노드는 k개의 여러 노드에게 연결되는 p2p 네트워크
한 노드에 PUT 요청이 들어오면 로컬에 데이터를 저장하고(rocksdb) 그 노드와 연결된 k개의 노드에게 데이터를 저장하게끔 전파(propagation)함. 전파받은 노드는 더 전파 안하고 자신만 저장해놓음 (default depth=1)
한 노드에게 QUERY 요청이 들어오면 해당 range 의 데이터가 있는지 체크해서 있으면 넘겨주고 없으면 QUERY 를 propagation 하여 필요한 데이터 수집 후 return 함
QUERY 시에 없는 데이터는 로컬에 갱신 (QUERY 가 많이 들어올수록 full copy 에 가까워짐)
QUERY를 받지 못한 노드들은 최신 데이터를 유지하지 못하게 되므로 Node 마다 Update time 값을 설정하여 매 Update time interval 마다 n range 만큼의 data 를 다른 노드에게 query 하여 로컬에 갱신하도록 함 (이빨빠진 time-series) - 짧을수록 full copy 에 가까워지고 길 수록 비어있는 부분이 많아짐
그러면 노드는 참여할 때 fullcopy 가 아닌 상태로도 사용가능한 상태가됨. 물론 시작할 때 total timerange 에 대해서 propagation query 를 하면 처음부터 full copy 로 시작할 수 있을듯

Next Experiment point

내가 가지고 있는 데이터가 최신본이라는 것을 확신할 수 있는 algorithm. 해당 노드가 어떤 time range 를 가지고 있는지 등? 에 대한 정보들을 유지하도록 하는 구조가 필요할듯. ex) 1분 1초 10ms 데이터는 node1 에, 1분 1초 20ms 데이터는 node2 에 PUT 이 들어왔을 때, node 1 에 1분1초-2초 QUERY 가 들어온다면? node1은 1분1초~2초 데이터가 있지만 내가 그 사이 전부를 가지고 있는가를 보장할 수 있나? - commit 개념이 필요할것인가?
노드가 참여제외 됬을때를 대비하기 위한 정책. 최소한의 몇개의 노드가 살아있어야지 네트워크가 보장될 수 있는지, 최소한 몇개의 노드가 몇개의 다른 노드와 연결되있어야하는지 등에 대한 가용성 보장 조건 실험. ex)full copy 와 가까운 majority 노드를 최소 몇개 유지해야한다 던가, majority 가 죽었을때 다른 특정 노드를 majority 노드로 유지하기 위한 정책, 방안 등에 대한 실험
Update time 을 threshold 값으로 주는 것 보단 해당 노드의 상태(QUERY range의 시간이 길다던가, space complexity 가 높거나) 에 따라 값을 정할 수 있는 함수 형태로 나올 수 있도록 하는 수식이 필요 - factor 들을 어떤 걸 사용할지도 고민 필요함
short-term 정책에 따른 depth 값 조절하여 최대한 많은 노드에게 바로 업데이트되도록 할 수 있을듯. PUT 시에 전파해서 타고갈 depth 를 깊게 할 수 록 많은 노드들이 최신데이터를 유지할 수 있음 (jayden idea)
해당 노드의 저장공간이 가득찼을때 가지고 있는 데이터를 다른 노드들에게 분산해서 저장하도록 하는 구조 (도중에도 node 의 availability 는 보장해야함)
노드의 상태나, 메타 데이터의 종류에 따른 (데이터의 특성에따른?) 분류로 데이터를 쌓이게 할 수도 있지 않을까? 완전 랜덤하게 저장되는 PUT 보단 어떤 clustering analysis 형태를 띄며 저장되는 구조라면?

한 노드의 입장에서 연결할 k개의 여러 노드를 정하는 로직이 필요해보입니다
query는 flush된 데이터에 대해서만 가져올 수 있나요? 아니라면 memory안에서의 데이터를 sorting하여 저장하는 구조도 필요할 것 같습니다
query 후 로컬에 갱신하여 많이 들어올수록 full copy에 가까워지게하는 이유가 query속도 향상을 위함인가요? 이러한 가정이라면 한번 query를 한 data는 query가 자주 일어날 것이라는 가정이 필요한데 오히려 최신 데이터는 query 횟수가 부족할 것이므로 해당 가정은 위험하지 않을까요? 오래된 데이터가 용량을 차지할 것 같아요
update time마다 query를 하는 대상은 k개의 node인가요?

한 노드가 propagation 을 대기 했다가 결과를 모아서 return 을 하는것이 아닌 전파되는 도중에 데이터가 다 모이면 바로 리턴해줄 수 있는 구조에 대한 실험
기존에는 time 을 main key 로 저장했다면 이 구조에선 source 를 기반으로 저장하고 분리하는 로직이 필요해보임. user 의 요구조건상 특정 시간대의 전체 시간을 조회하기보단 특정 source 의 특정 시간대를 조회할 것이므로, 전체 데에티어 대한 특정 시간대 query는 느릴수 밖에 없다고 가정하면 될지?

한 노드가 propagation 을 대기 했다가 결과를 모아서 return 을 하는것이 아닌 전파되는 도중에 데이터가 다 모이면 바로 리턴해줄 수 있는 구조에 대한 실험

원하는 데이터를 다 모았는지 확인하기 위해서는 어떤 노드가 어떤 데이터를 가지고 있는지 DHT와 같은 방식으로 가지고 있으면 필요한 노드에만 query를 propagate 할 수 있어서 효율적일 것 같습니다.

5/8 Research Note

node discovery, routing 을 적절히 하는 방법을 고안하기 위해서 기존의 p2p 시스템을 조사하고 있음

Chord
Pastry
CAN
Fasttrack
kelips
Kademlia

Old P2P structure design

이러한 기존의 p2p 알고리즘들은 단순히 파일을 랜덤하게 분산시켜서 저장하고 관리하는데 초점을 두고 있음.
기존의 p2p 서비스들은 decentralized file sharing 시스템을 목적으로 두었음.
이러한 시스템은 node 가 네트워크 상에서 붙었다가 떨어지고 하는 session time 이 길지 않은 read only (RO) node 가 많기 때문에 churn rate 가 높은걸 가정해서 시스템을 고안함.

Paust-db P2P structure design

paust-db 시스템은 파일 하나를 분산해서 저장하는 것이 아닌 계속 증가하는 하나의 time-series 를 분산해서 저장하는 것임. 어떻게 보면 단일 파일인데 계속 증가하는 파일로 볼 수 있음.
paust-db 는 node 가 Read Only, ReadWrite 노드 의 성격이 나뉘게됨. RO 노드는 p2p 네트워크에 참여하지 않고 RW 노드는 애초에 computing node, storage node 로 참여하겠다는 성격이 있기때문에 churn rate 는 낮을 것으로 예상. -> churn 으로 인한 routing table 조정, 데이터 재분배 등에 대한 time complexity 는 크게 중요하지 않음
full-copy로 가지않고 각 time-series data 를 분산해서 저장하게 되면 time 기준으로 분산하기엔 힘들 것 같다는 생각.
stream 처리에 적합한 분산 저장, 쿼리를 고려 할 필요가 있음. (Source 개념으로 접근해서 분할해서 저장할 수 있을까? 어떤 특정 동일한 source로 분류되는 데이터들은 어디에 저장되는지 빠르고 쉽게 찾을수 있는 구조 등..)
Node 간의 연결을 end-point 에 직접 연결하는 것 보단,
1. propagation 을 통해서 이 연결과 유지할 노드를 찾는다. - 랜덤한 확률로 연결할지 말지 판단? - 낮은확률로 아무와도 연결안될 가능성 있음. 랜덤배치로 연관없는 연결성 유지
2. source 기준, traffic 기준, locality 기준 등 을 통하여 최대한 연관성이 있는 노드와의 연결 - DHT routing table 을 유지할때 hashing을 통해서 나온 node id의 근사치로 가까움을 판단하는 것이 아닌 time series 처리에 맞는 routing table 형성할 필요성 있음 (어떤 기준을 통해서 노드를 묶고 분류할 수 있는가?)
3. 노드가 연결될때 전역적인 routing table metadata 를 통해서 연결할 노드를 선택? - 트래픽이 집중될 수 있음 -> 다른노드에 가상서버로 라우팅할수도 있긴할듯

등등 고려할 부분이 많음. p2p 연결을 형성하고 routing table 을 어떻게 만들고 관리할지에 집중하고있음

5/10 Research Note

위 커멘트에 대한 아이디어 제안

2. source 기준, traffic 기준, locality 기준 등 을 통하여 최대한 연관성이 있는 노드와의 연결 - DHT routing table 을 유지할때 hashing을 통해서 나온 node id의 근사치로 가까움을 판단하는 것이 아닌 time series 처리에 맞는 routing table 형성할 필요성 있음 (어떤 기준을 통해서 노드를 묶고 분류할 수 있는가?)

CLOCK: Circler Timeseries p2p network

Time 은 계속 증가만 하므로 blockchain 처럼 앞으로만 뻗어가는 linked list 형태가 적합해보이지만, 시계(CLOCK)는 환(Circle) 형태임

Node 는 endpoint 에 바로 연결되는 것이 아닌 Chord, pastry 처럼 virtual ring 형태로 네트워크가 연결되는 구조
Finger table, Routing table 을 구성하는 것이 핵심
Ring 은 특정한 time cycle(C)로 이루어 짐. 예를 들어 cycle(C)이 60sec 이면 0~59 의 range 를 가질 수 있음 (60개의 노드만 배치될 수 있다는 것은 아니고 coverage 임
Node 의 참여하는 Timestamp, data 가 put 되는 Timestamp 를 C로 mod 연산을 통하여 해당 ring 에 배치할 수 있음
네트워크를 이루기위해 초기 B개의 bootstrap 노드로 ring 을 형성할수 있음. 예를들어 B=5 , C=60 이면 각각의 부트스트랩노드는 0 ~ 11sec, 12 ~ 23, 24 ~ 35, 36 ~ 47, 48 ~ 59 의 range 를 cover 하는 node 가 될 것임
특정 노드가 참여될때 다음과 같은 형식의 node id 를 부여받음 [bootstrap_index][ts mod C][node metadata hash prefix m bit] ex) 1 3 AB84
C가 커질 수록 각 node 가 연속된 time range 를 많이 포함하고 있을 것임 -> 노드의 정책이나 스팩에 따라 노드가 저장하고 포함하는 coverage 를 조정하여 배치가 될 수 있을까?
각 Bootstap 노드는 각 해당 range 에 대하서는 full copy 노드임. 즉 bootstrap 노드가 1 개면 완전 풀복제 네트워크며 Bootstrap 노드가 많아질수록 분산률이 높아짐
모든 요청들이 bootstrap 노드를 통해 중재되는 것이 아닌 기존의 p2p 알고리즘에서 차용하는 라우팅 방식과 비슷하게 가도록 함. bootstrap 은 보조, failure 대비를 위한 안정적인 시스템을 형성하려고 있는 강화노드 같은 느낌

Summary

해당 방식으로 지금 시점의 데이터를 저장하고 과거의 데이터 조회를 위한 decentralized time series database 의 역할의 base 를 구성할 수 있을 것 같음.
기존의 p2p 에서 사용하는 consistent hashing 으로 연속된 시간을 완전 random 분산하여 저장하고 조회하는 것 보단 PUT 할 때 이 데이터는 어떤 곳에 저장되야 한다는 규칙을 만들어서 Query 할 시 해당 영역의 데이터는 저쪽에서 시작해서 쭉 있겠구나 해서 network routing hop 을 더 줄여서 Query 가 가능하지 않을까 생각함.
kelips p2p system 과 유사하다 볼 수 있는데 고정된 affinity group을 사용하는 kelips 가 될듯(affinity group 이 고정되면 그룹안에 저장되는 노드는 계속 증가될 것이므로 서로가 어떤 데이터를 저장하고있는지 알아야하는 정보들이 많아져 메모리사용량이 높아 질 것임. )
stream 처리를 위한 아이디어는 아직 고안 안된 버전임

5/15 Research Note

본래 제안한 구조는 storage 관점에서만 생각한 구조였음. 이런식으로 데이터를 분산 저장하고 long term 에 대한 데이터를 query 하는 '데이터베이스' 형태로만은 의미가 없음 (dennis, edan 과 회의)
PDSN의 형태는 LG, Google, Amazon 등의 기존의 데이터를 그런식으로 저장하고 있던 네트워크 간의 연결을 맺어 네트워크간의 연결 + 실시간 time series 데이터 처리하는 네트워크
실제 각자 네트워크의 저장되는 데이터를 무작정 PDSN에 올리는 것이 아닌 내가 어떤 소스형태의 데이터를 생산하는지의 정보를 가지고 PDSN에 attach하고 해당 source 데이터가 필요한 수요자의 query 로 부터 첫 전송이 발생하게됨.
수요자 노드가 네트워크에 계속 붙어서 subscribe 하고 있는 상태에선 source 노드는 계속 데이터를 생산하여 publish 하게됨
시간이 지나다 보면 한 소스에 대한 여러 수요자가 생길 수 있고 여러 소스 또한 발생하게 될 수 있기때문에 특정 소스를 수요자에 가까운 노드들에게 replication 하는 과정, 새로 연결한 수요자가 데이터 접근이 용이하도록 rebalancing 이 필요함

Summary

PDSN 은 과거의 데이터들을 저장하고 조회하는 database 라기 보단 여러 네트워크간의 데이터를 연결해주는 data network 성격. streaming 데이터를 실시간으로 받고 그 데이터에 대한 처리(operation) 까지 가능케 하는 데이터 네트워크
PDSN 상에서도 operation 개념으로 동작하도록 Flink 의 동작방식에 대한 이해가 필요함.
한 소스에 대한 데이터는 최대한 한 노드에서만 저장하는게 좋음. 그래야 query 성능이 좋을듯.(물론 replication 필요한데 distribution 은 효율 떨어짐) 그 노드의 저장공간이 차면 다른노드에 저장할 수 있도록 만들어야함. 본래 내용은 ring 형태로 모든 데이터를 time mod 로 나눠서 put 으로 들어오는 데이터를 full 분산하는 구조를 생각했었는데 이 구조를 가져갈 필요가 없지 않을까 싶음
replication, rebalancing 을 효율적으로 할 수 있도록 하는 factor를 찾는 실험 필요

네트워크간의 연결과 수요자와 생산자를 연결해주기 위한 분산저장구조, 라우팅 구조 만 고려할 것이 아닌 네트워크안에서 구성된 노드들을 통해서 operation 을 처리하는 역할도 겸해야함. storage + computation

5/20 Research Note

PDSN에 참여하는 노드는 저장, 연산, 프로바이더, 컨슈머 등 다양한 역할을 할 수 있는 노드가 될 수 있음.
클라이언트 노드가 참여할때 노드의 특성을 골라서 참여하거나, node 의 스펙, 상태등을 판단하여 타입을 시스템상에서 유동적으로 바꿔줄 수도 있을 것임
Consumer, Provider 를 제외한 클라이언트노드가 직접 참여할 방식을 골라서 네트워크에 포함되어 role 을 알고있는 것 보단 참여만 하고 내 노드가 뭘 하는지는 모르게 하는 투명성을 제공하는 방식으로 가는게 좋을듯 (악의적인 행위를 방지하기 위함)
Network 상에 Provider(Source node)들이 공급하는 source 데이터가 일관적으로 관리가 되어야하며 consumer 들은 PDSN 상에 공급되는 source 들에 대한 정보를 볼 수 있는 Source Browser 가 필요할듯.

Source Structure

Source Meta

path (source 에 대한 bundle identifier path ex. com.google.iot.cleaner)
key (unique key - source 를 공급하는 주체가 자신이 보내는 source meta 임을 검증하기 위핸 개인키 같은것)
dataType (해당 소스가 생산하는 데이터 타입 ex. int64, string)
description (해당 소스가 어떤 데이터를 생산하는지? 등에 대한 description)
hash (Sorce Meta 에 대한 hash 로 고유값으로 사용하기위함)
providerHost (소스 제공자 endpoint)

Source Data

Timestamp (event timestamp)
Timezone
SensorID (source 를 생산하는 device ID. 여러 디바이스에서 한 소스를 생산할 수 있음)
OwnerID
Qualifier
Data
MetaHash (Source Meta hash)

Node Definition

Super Node

Role

전체 네트워크 상에 Provider(Source) node 의 source meta 정보를 관리하는 노드
슈퍼 노드간에는 네트워크 전체의 source meta 에 대해서 일관적으로 유지하기 위해 blockchain 형식으로 연결되어 합의과정을 거쳐 소스메타정보를 최신상태로 유지함 (source meta 정보만 합의 과정을 거쳐 blockchain 형태로 관리하고 실제 real data 는 chain 에 담지 않음
소스 노드들이 super node 에게 자신이 provide 하는 source 메타정보를 주면 소스메타 테이블에 등록시키고 나중에 필요한 consumer 생겨서 요청할때 소스 노드에게 연결하여 처음 데이터 전송을 요청하도록 함
모든 consumer 노드가 없어질때, 해당 source 대한 수요가 없어질때 source node 와 연결을 해제하고 source meta 및 데이터 flush
bootstrap 노드에게 super node 인 자신의 정보를 업데이트 하도록 해야함
to Discuss
Super node 로 설정하는 방법. super node 로 선출되기 위한 factor(computing power, latency, 인접 노드 수 등)들도 필요하고 언제부터 언제까지 super node 로 설정되는건지 등에 대한 lifecycle 에 대한 guide 필요
소스노드가 어디다가 데이터를 저장할지 (replica 를 어디에 뜰지, consumer가 여러곳에서 들어옴에 따라 어떻게 할지 등)에 대한 방법 필요
소스노드와 consumer node 간의 path 들을 관리하여 중복되는 path 를 최대한 활용하여 source node 가 직접 여러곳에 replica 를 뜨는 것이 아닌 기존의 path 를 활용하거나 path 상의 다른 노드들이 replica 를 떠주는 방식으로 부하를 p2p 분산하도록 하는 방법 필요

Bootstrap Node

Role

PDSN을 구성할때 포함되는 bootstrap node로 super node들에 대한 정보를 가지고 있음
PDSN 에 연결되는 모든 노드들은 bootstrap 노드에게 누구에게 연결될지 요청
Super node 에 대한 정보를 주는 역할외의 별도의 로직이 들어가지 않도록 설계 필요 (부하가 걸리지 않도록 최소한의 작업만 하도록함)
to Discuss
초기 bootstrap 의 개수, 부하를 얼마나 받을지, 노드가 증가할때마다 bootstrap 에 걸리는 값을 보는 실험을 해야할듯
Super node 테이블을 관리하는 방안 (heart beat 등)

Provider Node (Source Node)

Role

Source 를 생성하는 주체
개인이 관리하는 스트리밍 데이터를 생성하는 노드 및 디바이스, 기업의 네트워크(Google IoT, Lg smart home, amazon aws), end device(IoT sensor) 등이 PDSN에 연결되는 노드 PDSN 에서 제공하는 interface, module 을 통하여 PDSN 에 attach 하고 source meta 정보를 형식에 맞게 작성하여 register 를 함
이미 등록된 source path 일 때 자신의 key 와 같으면 source meta 정보가 최신으로 update 되고 key 가 다르면 등록이 안되며 다른 source path 를 사용하여야함 (source path 는 domain을 사는게 우선순위 인 것 처럼 처음 등록한 노드의 소유가 되는 것임)
attach 후에 consumer 의 수요가 생겨서 super node 로 부터 재연결이 되어 데이터 put 요청을 받으면 그 때 부터 첫 소스 데이터를 전송하는 스트림을 열어서 전송 -해당 소스에 대한 수요가 없어지면 notify 를 받아서 connection 을 종료시키고 스트림을 더이상 보내지않음

to Discuss

PDSN 에 연결되기 위한 interface 및 모듈에 대한 설계 (gRPC 기반, lifecycle 설계 등)
Source 의 전송하는 timeout 고려 필요한가? (각 기기 마다 생산하는 interval 이 다를 것임)

Consumer Node

Role

데이터를 소비하는 client node
source meta browser 를 통하여 source path 를 알고 source path 를 super node 에 요청하여 소스를 받아갈 경로 를 획득함
경로의 나와 가까운 노드에게 데이터를 가져갈 수있는 channel 을 열어 query 하고 iterate, fetch 할 수 있음

to Discuss

단순히 데이터를 가져가는 것만 고려된 것으로 stream processing 에 대한 동작에 대한 설계 필요
Operation 에 대한 정의 (어떤 operation 을 제공할 것인가 - map, filter, sum 등)
Operation 에 따른 network path 를 계산하는 방식 (Operation 을 배정하고(node 상에) path 정보를 관리하고 세팅하는 방식은 super node 에서 해줘야하지 않을까)
Edan 이 제안한 중간의 path 노드들 간의 연산 chain 을 만들어서 구성하는 방법에 대한 논의 필요
Client Interface 재정의

Computing Node (Storage Node, Computation Node)

Role

PDSN 의 computing power 로 참여하는 노드( 자신은 storage, computation 역할을 하는지 모르고 node 의 상태 및 factor 에 따라서 storage, computation 혹은 둘다 할 수 있는 노드로 셋업 되어야함)
Rocksdb 를 사용해서 data stream 을 event time 순서로 order 된 상태로 테이블을 유지하도록 함
단순히 data 를 transfer, replica 하는 storage 노드 뿐만 아니라 consumer node 가 셋업한 Operation에 대한 processing 을 할 수 있도록 해야함 - operation 이 어떻게 동작할 것인지 부터 정의가 필요함
consumer node 와 채널을 열어서 가지고 있는 data 에 대해서 query, fetch 를 위한 인터페이스 제공되어야함. (rpc 로 가능?)
to Discuss
Time windowing, water mark 등 flink 에서 exactly once, loss 를 보장하기 위한 처리를 해야 하는가?
transfer 역할은 나의 다음 path 에 있는 노드에게 데이터를 매번 전송해주는 형태가 될지, source node 가 직접 다 복사
Spec 의 최소 사양에 대한 정의 (ex. Storage 가 가능하려면 하드가 100TB 이상 등 )
failover 에 대한 처리 - source 의 데이터를 replica 해서 저장하는 노드인데 죽으면 consumer 와의 channel 이 끊기므로 super node 상에서 조정해줘야하고 해당 노드에 대해서 패널티를 줘서 패널티를 많이 먹은 노드는 PDSN 에서 퇴출?
Recover 에 대한 처리 - 죽었다가 다시 살아났을때 다시 원래 사용되던 자원으로 배정되어 복귀될 것인가 (과거데이터가 중요하지 않고 새로운 데이터 스트림으로 부터만 처리될거라면 다시 연결되지 않고 다른곳에서 배정될때 까지 대기상태면 될듯)

Super node 의 필요성에 대해서는 생각해볼 필요가 있음 모든 노드(cell) 이 유기적으로 flexible 하게 역할을 바꿔갈 수 있는 구조가 필요함 source node, consumer node (sink node) 또한 pdsn 내의 한 노드로써 동작해야함 위에서 써놓은 consumer node 는 client 의미로 써져있고 provider node 는 source provider client 를 의미함 source node pdsn 내에 source node 들이 존재해서 provider 들이 source 를 복사할 point 가 되는 노드가 되어야함. 물론 이 source node 들이 client 의 요청에 따라서 유기적으로 가까운 노드가 source 노드가 되어서 처리될 포인트들을 client 근처로 땡겨오던가, sink 노드가 클라이언트 근처로 되어서 땡겨오는게 좋은가 등은 생각해봐야하는 관점

현재 pdsn 내에서 수행되어야 하는 transfer 의 기능과 operation 의 기능 2가지의 실험을 진행하기 위한 base 를 만들고 있음. 토폴로지를 어떻게 구성할 것인가에 대하 많은 고민을 해봤는데 기존에 네트워크가 어떻게 연결되있고 누구랑 연결되고 몇개랑 연결되며 p2p 네트워크를 형성하는 것을 정하기 힘듬. client 의 요청에 따라서 효율적인 path 가 다시 만들어 져야 하기 때문에 미리 연결을 유지해놓는 것이 아닌 torrent 의 tracker server 기능처럼 노드들에 대한 정보를 기록하도록(super node 나 bootstrap node 가) 하여 client 요청에 따라 path 를 정해서 연결이 되도록 하는 구조가 되는 base 를 만들고 있음. 차주 내에 완료하여 transfer 역할을 위한 관점,factor 들을 조사하고 살펴볼 예정(kafka partioning, time windowing, ordering, bath 등등)

paust-team / paust-db