FEATURE: add set offset command

[jeesup0103]

🔗 Related Issue

• https://github.com/jam2in/arcus-works/issues/571

⌨️ What I did

• Set get 연산시 offset을 기준으로 get을 할 수 있도록 변경했습니다.

sop get <key> [<offset>] <count> [delete | drop]\r\n

구현방법

Offset 탐색 방식

• Offset 탐색은 subtree count 방식을 사용하여 진행했습니다.
• tot_elem_cnt 를 자식 노드까지 포함한 subtree의 element 개수로 변경했습니다.
  • 기존에는 현재 노드의 element 개수만 저장했습니다.

Offset으로 탐색 시:

1. 노드 → 버킷(체인) → element 순서로 확인합니다.

tot_elem_cnt를 노드별로 유지하기 위해:

1. 삽입 시:
   • 부모 node pointer를 저장하여 삽입이 정상적으로 작동하면 갱신합니다.
2. 삭제 시:
   • DFS로 부모 노드로 올라가며 tot_elem_cnt를 갱신합니다.
3. 현재 노드의 element 개수가 필요할 때:
   • (tot_elem_cnt) - (자식 노드들의 tot_elem_cnt 합)으로 계산하여 사용합니다.

예외처리

• offset 값이 ccnt 보다 크거나 같으면 NOT_FOUND_ELEMENT 처리합니다.

사용 예시

sop get skey 0
VALUE 0 7
1 b
1 c
1 a
1 f
1 g
1 d
1 e
END

sop get skey 1 1
VALUE 0 1
1 c
END

sop get skey 1 0
VALUE 0 6
1 c
1 a
1 f
1 g
1 d
1 e
END

sop get skey 3 5
VALUE 0 4
1 f
1 g
1 d
1 e
END

sop get skey 12 0
NOT_FOUND_ELEMENT

[namsic]

코드 포맷 위주로 1차 리뷰합니다.

commit message 분류(FEATURE:)는 대문자로 작성하면 좋겠습니다.

[namsic]

수정하는 김에 코드 스타일도 함께 정리해두면 좋겠습니다.

Suggested change

	if (strcmp(tokens[read_ntokens+rest_ntokens-1].value, "delete")==0 ||
	strcmp(tokens[read_ntokens+rest_ntokens-1].value, "drop")==0) {
	if (strcmp(tokens[read_ntokens+rest_ntokens-1].value, "delete") == 0 ||
	strcmp(tokens[read_ntokens+rest_ntokens-1].value, "drop") == 0) {

[namsic]

100은 무엇을 기준으로 한 크기인가요?

[jeesup0103]

코드에서 해시 트리의 최대 깊이에 대한 정보가 없어서 적당히 넉넉한 값으로 100을 설정했습니다.
Collection 하나의 최대 크기가 1,000,000으로 설정할 수 있는데 고르게 분포 된다는 가정하에 한 노드에 1024개의 element 가 저장됩니다. 이때, 한 노드에는 16개의 bucket이 있기 때문에 트리의 깊이가 10이라고 할 때 1024*(16^10) 정도 저장됩니다. 이는 1,000,000보다 훨씬 크기도 하고 worst case를 고려해서 적당히 큰 수인 depth 를 100으로 설정했습니다.
다른 코드에서 해시 트리의 깊이에 대한 정보가 있으면 조정 할 수 있을 것 같습니다.

[namsic]

아래에서 *skip_cnt += 1; 하고 있는데, 여기서도 괄호 없어도 되죠?

[jeesup0103]

네. 없어도 되는데 가독성과 통일성을 위해서 추가하는 것이 좋을 것 같습니다.

[namsic]

offset과 count는 같은 line에 위치하도록 하면 좋겠습니다.
btree 참고 바랍니다.

static uint32_t do_btree_elem_get(btree_meta_info *info,
                                  const int bkrtype, const bkey_range *bkrange,
                                  const eflag_filter *efilter,
                                  const uint32_t offset, const uint32_t count, const bool delete,
                                  btree_elem_item **elem_array,
                                  uint32_t *opcost, bool *potentialbkeytrim)

[namsic]

tot_elem_cnt를 자식 노드까지 포함한 subtree의 element 개수로 변경했습니다.
기존에는 현재 노드의 element 개수만 저장했습니다.

tot_elem_cnt는 map collection에서도 동일한 이름/목적으로 사용하는 필드인데,
set collection에서만 그 의미가 달라지면 혼동이 생길 수 있어 보입니다.

map collection에도 동일한 변경을 적용하거나, tot_elem_cnt 변경하지 않는 구현 방안이면 좋겠습니다.

[namsic]

tot_elem_cnt의 의미가 변경되면서 이전에 없던 loop가 추가되었습니다.

offset 인자를 지정하는 경우보다 default 값(0)으로 사용하는 경우가 더 많을 것이므로,
offset 기능을 최적화하기 위해 다른 구현에서 추가 비용을 지불하는 형태는 피했으면 좋겠습니다.

현재 PR과 같은 구현이 아니면 offset 기능이 크게 비효율적으로 동작하게 되나요?

[jeesup0103]

현재 구현은 노드(서브트리) 단위에서도 스킵할 수 있도록 tot_elem_cnt의 의미를 “서브트리 element 전체 개수”로 변경했습니다.
그러다보니 위와 같이 현재 노드의 element 개수를 알아야 하는 코드가 추가되었습니다.

이 때문에 추가 루프 비용이 생기는데, 이를 해결하기 위한 두 가지 방법이 있습니다.

1. tot_elem_cnt를 원래대로 두고, 새 변수 tree_elem_cnt를 만들어 서브트리 element 개수를 관리
   • 장점: 노드(서브트리) 단위 스킵 가능
   • 단점: 새로운 변수 관리
2. 노드 단위 스킵을 하지 않고 해시 버킷(체인) 단위에서만 스킵 (tot_elem_cnt를 그대로 유지)
   • 장점: 추가 변수 없음
   • 단점: offset 탐색이 느려짐

[namsic]

제 생각에는 2번과 같이 구현하는 것으로 충분해 보입니다.

물론 부모 hash_node 수준에서 건너뛰는 것보다는 느리겠지만,
최소한 기존에 모든 노드를 탐색하는 것보다는 효율적으로 동작할 것이고,
아마 2번 방식에서는 기존 로직을 거의 수정하지 않고 최소한의 수정으로 offset 기능 구현이 가능할 것입니다.