FEATURE: Add CompletableFuture BTree insert/get API

[oliviarla]

🔗 Related Issue

• bopCreate/bopInsert/bopInsertAndGetTrimmed/bopGet/bopMultiGet/bopSortMergeGet API 구현에 대한 커밋을 추가해두었습니다.

⌨️ What I did

• GenericTranscoder 대신 CFB로부터 Transcoder<Object> 타입을 가져와 Transcoder<T> 타입으로 형변환합니다.
• Collection 타입의 경우 Decode하는 로직을 별도 스레드에 위임하지 않습니다.
• 새로 추가된 VO 클래스들과 각 메서드의 서버 응답 별 반환 값은 링크에 정리되어 있습니다.

[uhm0311]

우선 질문입니다.

[jhpark816]

@uhm0311 @brido4125 리뷰가 진행되어야 합니다.

[uhm0311]

@jhpark816

#1026 (comment)
제 리뷰가 아직 반영되지 않은 상태인 것 같습니다.

[uhm0311]

한 번 더 질문입니다.

[uhm0311]

기존 SMGetResult 클래스에서 merge하는 로직과 달라졌습니다.
단순화하기로 결정된 건가요?

[oliviarla]

정렬된 여러 리스트를 하나의 정렬된 리스트로 병합할 때 적합한 K-way merge 방식으로 구현해보았으나, Collections.sort 방식이 벤치마크했을 때 더 빠르기 때문에 이와 같이 수정하였습니다.

벤치마크 시 사용한 k-way merge 구현 코드와 테스트 코드는 링크 참고 부탁드립니다.

벤치마크 테스트 결과

======================================================================
SMGetResult Merge Algorithm Benchmark
Comparing k-way merge vs Collections.sort
======================================================================

=== Small Dataset ===
Nodes: 5
Elements per node: 100
Total elements: 500
Iterations: 1000

Results:
K-way merge: 39 ms (0.04 ms/iteration)
Collections.sort: 12 ms (0.01 ms/iteration)
Speedup: 0.31x
✗ Old implementation is faster

=== Medium Dataset ===
Nodes: 10
Elements per node: 500
Total elements: 5000
Iterations: 100

Results:
K-way merge: 39 ms (0.39 ms/iteration)
Collections.sort: 7 ms (0.07 ms/iteration)
Speedup: 0.18x
✗ Old implementation is faster

=== Large Dataset ===
Nodes: 20
Elements per node: 1000
Total elements: 20000
Iterations: 50

Results:
K-way merge: 94 ms (1.88 ms/iteration)
Collections.sort: 13 ms (0.26 ms/iteration)
Speedup: 0.14x
✗ Old implementation is faster

=== Very Large Dataset ===
Nodes: 50
Elements per node: 2000
Total elements: 100000
Iterations: 10

Results:
K-way merge: 123 ms (12.30 ms/iteration)
Collections.sort: 13 ms (1.30 ms/iteration)
Speedup: 0.11x
✗ Old implementation is faster

=== Many Nodes ===
Nodes: 500
Elements per node: 100
Total elements: 50000
Iterations: 50

Results:
K-way merge: 497 ms (9.94 ms/iteration)
Collections.sort: 41 ms (0.82 ms/iteration)
Speedup: 0.08x
✗ Old implementation is faster

=== Few Nodes Large Elements ===
Nodes: 3
Elements per node: 5000
Total elements: 15000
Iterations: 50

Results:
K-way merge: 24 ms (0.48 ms/iteration)
Collections.sort: 5 ms (0.10 ms/iteration)
Speedup: 0.21x
✗ Old implementation is faster

======================================================================
Benchmark Complete
======================================================================

[uhm0311]

기존 로직은 unique 여부, reverse 여부, count 값에 따라 결과가 달라지는 로직이었습니다.
중복된 bkey는 제거하고, reverse이면 역순으로 정렬하고, count보다 많은 원소는 반환되지 않았습니다.
현재 PR은 기존 로직과 달리 그냥 모든 결과를 다 포함하고 있는데, 위와 같은 로직들을 단순화하기로 결정한 것인지 궁금합니다.

[oliviarla]

앗 이부분은 제가 놓쳤습니다.
count의 경우는 bopMultiGet에서도 SMGet과 동일하게 bkey 정렬 순서대로 잘라서 반환해야 할 것 같은데 어떻게 생각하시나요? (일관된 의미를 가져야 한다는 생각입니다.)

[uhm0311]

bopMultiGet의 경우 서버 단에서 이미 count에 맞춰서 반환했으니 문제 없습니다.
smget 연산에서 문제가 되는 부분은, 각 캐시 서버 단에서는 count에 맞춰서 반환을 했지만 이를 Client에서 병합하는 과정에서 count 개수를 초과할 가능성이 있는 부분입니다.
예를 들어 count 값이 50인데 캐시 서버 2대에서 둘 다 50개의 원소를 반환했다면, Client 입장에서는 100개의 원소를 받은 것입니다.
그래서 기존 smget에서는 count보다 많은 원소를 버리는 동작이 있었던 것입니다.

[brido4125]

btree api PR에 전체적으로 아래와 같은 설명 덧붙여 주세요

• as-is 상태에서의 반환값 / to-be 상태에서의 반환값
• as-is 상태에서의 예외 시 반환 값 / to-be 상태에서의 예외 시 반환값

위 부분이 나중에 해당 기능 릴리즈 할 때, 어차피 사용자에게도 가이드 되어야 할 내용입니다.
번거롭더라도 지금 미리 작성한다고 생각하고 해주시면 감사하겠습니다

[oliviarla]

@brido4125
API 메서드마다 javadoc에 반환 타입에 대한 내용을 자세히 추가해두었습니다.
as-is가 ArcusClient#asyncBop... 말씀하시는게 맞다면, 저는 이 둘을 비교하면 오히려 더 헷갈릴 것이라고 생각합니다.
따라서 현재 형태에서 반환 값이 적절한지 리뷰해주시면 감사하겠습니다. (exception이 발생하는 상황은 노션에 정리되어 있습니다.)