Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BulkGet 요청 처리 재검증 #27

Open
jhpark816 opened this issue Jun 30, 2015 · 6 comments
Open

BulkGet 요청 처리 재검증 #27

jhpark816 opened this issue Jun 30, 2015 · 6 comments
Assignees
Labels

Comments

@jhpark816
Copy link
Collaborator

jhpark816 commented Jun 30, 2015

bulk get 수행 방식이 현재 최적인지 확인하고, 개선 부분을 도출한다.
특히, 아래 경우들을 고려한다.

  • inactive node로 mapping되는 key들이 존재할 경우
  • 해당 연산이 하나라도 오류가 발생할 경우
  • 해당 연산이 하나라도 timeout 발생할 경우

추가적으로, local cache 활용도 정상적인지 확인한다.

@jhpark816 jhpark816 assigned minkikim89 and unassigned whchoi83 Jan 15, 2020
@minkikim89 minkikim89 removed their assignment Feb 1, 2021
@jhpark816 jhpark816 changed the title BulkGet 요청 처리 최적화. BulkGet 요청 처리 재검증 Jan 26, 2022
@jhpark816
Copy link
Collaborator Author

@hjyun328 @sUpniverse 모두 확인해 주면 좋겠습니다.

@hjyun328
Copy link
Collaborator

hjyun328 commented Jan 26, 2022

BulkGetFuture - get

  • 하나의 Key라도 Error, Cancel, Timeout이 발생된다면 Exception을 발생시킴.
  • 모든 Key의 Operation이 성공적이어야 Key, Value 데이터들을 Map으로 반환함.

BulkGetFuture - getSome

  • 하나의 Key라도 Error, Cancel이 발생된다면 Exception을 발생시킴.
  • Error, Cancel 없이 Operation이 성공한 Key, Value 데이터들을 Map으로 반환. 반환된 Map에서 Timeout Key는 존재하지 않음.

local caching 동작은 정상인 것으로 보입니다. key list중 일부 key만 local cache에 있다면 서버로 요청되지 않습니다. 또한 local caching을 제외한 응답에 성공한 key들은 local cache에 저장됩니다.

@hjyun328
Copy link
Collaborator

hjyun328 commented Jan 26, 2022

@jhpark816 @sUpniverse

지금은 하나의 operation이라도 실패(operation error, inactive node)가 발생한다면, 일부 성공한 key의 결과를 받을 수 없는 문제가 있습니다.

BulkGetFuture에 새로운 API를 만들어서, 모든 Key에 대한 응답을 Map에 담아 리턴하면 어떨까 싶습니다.
예를 들어 성공한 Key는 Data를, 실패한 Key는 Exception을 반환하는 것으로 개선해볼 수 있을 것 같습니다.

class Result<T> {
  Exception e;    // Error, Cancel, Timeout Exception
  T t;           // data
}

public Map<String, Result<T>> get(long duration, TimeUnit units) {
  ...
}

또는 getSome을 수정해서 성공한 Operation만 Map에 담아 리턴해볼 수도 있을 것 같네요.

@jhpark816 jhpark816 added ongoing and removed ongoing labels Feb 24, 2022
@jhpark816
Copy link
Collaborator Author

@sUpniverse
위의 코멘트 확인하고 의견 주세요.

@sUpniverse
Copy link
Contributor

sUpniverse commented Apr 7, 2022

@jhpark816 @hjyun328
저도 형준 선임 의견 제안에 동의합니다.
현재는 all or nothing 형태로 캐시 조회가 이루어지고 이를 개선한 API가 getSome()으로 Exception 발생 전까지 일부 성공한 key에 대해 조회할 수 있습니다.

성공한 key의 결과만 받는것 보단, 모든 Key의 응답을 담는게 응용에서도 실패한 키에 대해서만
다시 재시도 하거나 DB에 일부 조회하는 패턴에 더 효율적 일것같습니다.

현재 getSome()을 이용한 조회 패턴은 자신이 가지고 있는 키 리스트에서
캐시 조회에 성공한 키를 제외한 실패 목록을 획득해야 하는 하나의 추가 과정이 필요합니다.

그렇기 때문에 전체 조회 결과를 들고오는 API가 더 응용의 관점에서는 편리하다고 생각합니다.

구현 관점에서는 모든 결과를 들고 오는 API를 get()으로 지원하는게 더 적절하다고 생각됩니다.
의미상으로는 현재 get()은 all or nothing으로 전체를 조회하는 get()의 의미와는 조금 다르다고 생각하는데이 부분은 조금 더 논의 하면 좋을것 같습니다.

@jhpark816
Copy link
Collaborator Author

@hjyun328
의견입니다.

  • backward compatibility 지원해야 하므로, get(), getSome() 동작 변경은 어려울 것 같습니다.
  • 어떤 새로운 API 제공할 지의 관점에서 정리하시죠.
    New API 반드시 지원해야 할 지 or 현재 API 정도로 무난할 지 의견도 들었으면 합니다.
    • 모든 결과 (실패 포함)
    • 성공한 결과만
    • 실패한 결과만
  • BulkGetFuture 클래스에 대해 리팩토링 필요한 지 한번 봐 주세요.
  • BulkGetFuture 클래스 질문
    • cancel 시에 WRITING 상태는 cancel 하지 않는 것이 맞는 건지?
    • cancel 시에 이미 읽은 연산을 cancel하는 것이 맞는 건지?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants