대규모 데이타 관리 자료구조...

용도에 따라 다르게 자료 구조를 만들어서 관리하는게 좋을 듯 합니다.

단순히 타임 아웃만 관리 한다면 시간 순으로 정렬해서 타임 아웃이 예상 되는 시간 위치에 저장해 놓고,
그 시간이 되어서 검사해야 하는 노드만 검사 하면 좀더 적은 갯수를 검사해도 됩니다.

동일한 노드를 다른 조건에 의해서 검색해야 한다면 그에 맞는 자료 구조를 사용해서 노드를 정렬하는게 좋구요.
결국 이렇게 되면 동일한 노드가 여러개의 자료 구조에 매달릴수 있는데,
이는 구조만 잘 잡으면 별 문제 없을듯 하네요.

제가 타임 아웃과 복잡한 키의 조합에 의한 검색을 이와 같이 분리해서 구현 했습니다.
최대 수는 250만 노드.... 물론 250만개가 1초 이내에 생성 되면 이론의 베이스가 망가지긴 합니다. ㅋ
타임아웃을 위해서 250만 노드를 모두 뒤지거나 삽입시 정렬하는 것은 정말 많은 부하가 예상 되죠....

이 아이디어는 리눅스 커널의 타이머 이벤트 처리 부분에서 힌트를 얻었습니다.

10만~50만의 노드라는게 데이터의 갯수가 아니라 클러스터 노드인가요?;; 10만~50만이면 대규모 데이터라고 하기엔 좀 작아서요.

10만~50만의 데이터를 키로 탐색도 해야 하고 시간순 정렬도 필요하다면 저도 B+tree추천이요.

10~50 만에 key base 면 범용 db 도 충분할 것 같고 (메모리만 되면 어차피 몽땅 다 메모리에 올라가겠죠.)

conch db나 mongo db 도 괜찮을 듯합니다.
트리 구현해서 쓰면 차후 관리하기가 귀찮아지죠.

메모리에 상주해서 돌리면 뭐 memche 나 redis 면 날아갈듯 합니다.