Design server and client structure for multiple query

[kwjooo]

Reference

124

[]QueryObj를 처리하기 위한 server와 client의 architecture에 관한 이슈

[]QueryObj는 client에서 fetch를 하기 전까지 쌓이는 QueryObj들의 list. server와 client가 통신 함에 있어 두 가지 방식이 가능할 것으로 예상.

1. fetch 전까지 client가 []QueryObj를 가지고 있다가 fetch 후 []QueryObj를 server에 전달
2. client는 QueryObj 혹은 []QueryObj를 계속해서 보내고, server가 client 별로 저장한 후 client가 fetch할 경우에 해당 client에 해당하는 QueryObj 혹은 []QueryObj를 삭제.

1번의 경우 []QueryObj의 크기가 거대해 질 경우 이를 나누어 server에 전달해야하는 단점이 존재하며 2번의 경우 client의 수에 따라 server의 부담이 가중된다.

[kwjooo]

또한 multi-query obj를 하나의 queryobj로 만드는 과정에 있어서 이에 대해 and인지 or인지 둘다를 지원해야하는 지에 대한 확립이 필요.

[elon0823]

Mutiple Query가 어떻게 사용이 될 것인가에 대한 시나리오의 예가 있으면 좋겠어요 @co1god 단순히 range 를 다르게 하고 싶어서 쿼리를 여러번 때리는 것인지, query1(0-5), query2(4-6), query3(5-10) 이런 range 쿼리들을 조합해서 (0~10) 쿼리만 실행해서 간소화 하기 위함인가 아니면 query는 계속 서버에 전송되어서 실시간으로 실행되지만, fetch 할 데이터를 매 query마다 조회를해서 single fetch를 최적화 하기 위함인가 등등 에 대한 고민을 해봤습니다.

[1dennispark]

철저하게 사용자 입장에서만 본다면 시간 순서에따라 데이터를 탐색한다고 보시면 쉽습니다.

사용자는 시간을 정확하게 기억하지 못한상태에서 query를 던지게 되고 그의 일부결과를 보고 자기의 query를 수정해나가는 것입니다.

그래서 뭐 완벽하게 100% 맞진않지만 @elon0823 의 의견중 후자에 가깝다고 볼수있습니다.

[elon0823]

철저하게 사용자 입장에서만 본다면 시간 순서에따라 데이터를 탐색한다고 보시면 쉽습니다.

사용자는 시간을 정확하게 기억하지 못한상태에서 query를 던지게 되고 그의 일부결과를 보고 자기의 query를 수정해나가는 것입니다.

그래서 뭐 완벽하게 100% 맞진않지만 @elon0823 의 의견중 후자에 가깝다고 볼수있습니다.

그럼 사용자가 query 해서 날라온 meta-data 만으로 결과를 판단해서 '아 좀 더 전에 데이터를 조회해봐야겠다' 라는 시나리오가 나와야 할 것 같은데 meta 를 구성하는 형태도 중요하겠네요

[elon0823]

네 연속적인 query요청에 대한 거였습니다

[1dennispark]

@elon0823 meta만 보지않고 fetch까지 해볼겁니다. 아 질문이 query만 하는 상황이었나요??

사실 query 만 요청하는 거에 대해서는 range query가 겹치는 경우는 거의 없을 겁니다. 아마 프레임웍이나 기타 다른 이유로 겹치기만 할겁니다.

[elon0823]

그럼 결국 지금과 같은 single query-> single fetch개념으로 보이는데 multi query -> single fetch 에 대해서 필요성을 잘 못느끼고있어요.. 수요일날 같이 얘기해봐요

[dragon0170]

multi query, fetch에 대한 문맥은 @co1god 이 예시로 설명한 google maps에서의 검색과 비슷한 시나리오로 흘러간다고 보면됩니다. 이를 위해서는 아래와 같은 client의 query interface feature들이 필요합니다.

• interface design - NoSQL인 timeseries database에 적절한 query interface를 설계할 필요가 있습니다. 살펴볼만한 query interface는 graph database인 Apache TinkerPop(http://tinkerpop.apache.org/)이 있습니다.
• client session design - query를 한 후 초반 몇 개의 data만 fetch를 해서 사용자가 필요한 데이터가 아니라고 판단되면 수정된 query를 사용자가 새로 보내게 될텐데 이전 query의 정보를 기억하기 위해 client query session이 유지될 필요가 있습니다. Apache TinkerPop과 HBase의 client console을 살펴볼 예정입니다.
• fetch design - query한 모든 결과를 fetch하는 것이 아니라 iterator를 하나씩 돌면서 fetch를 해보는 방식이 필요합니다. 이는 HBase의 scan을 참고하면 좋다고 합니다.

위의 feature들에 대해 새로운 이슈를 생성하여 survey와 실험을 진행하겠습니다.