DB count query 추가

[kimhanbeom]

database의 특정 column family에 들어가 있는 raw data의 총 갯수를 반환해주는 query를 구현합니다.
query의 입력값은 column family의 이름( Option<Vec<String>>) 입니다. 이름을 지정하지 않는 경우에는 모든 column family에 대한 count 결과를 반환하도록 합니다.

[msk]

이건 어떤 목적에 쓰일 건가요?

@sehkone, @syncpark: 이런 류의 query가 꼭 필요한가요? 아무 제한 조건 없이 전체 개수를 세는 작업은 다음과 같은 문제가 있습니다.

1. giganto가 정기적으로 오래된 데이터를 삭제하기 때문에 전체 개수는 별 의미가 없습니다. 개수가 필요하다면 기간을 명시하고 해당 기간의 데이터만 세도록 해야 의미있는 값이 됩니다.
2. RocksDB나 대부분의 고성능 key-value 스토리지의 경우 전체 개수를 따로 관리하지 않습니다. 결국 정확한 개수를 파악하려면 전체 key-value 쌍을 모두 읽어서 하나씩 세는 수밖에 없습니다. 이 작업은 giganto처럼 많은 데이터를 저장하고 있는 경우 시간도 오래 걸리고 캐시를 무효화시켜서 상당한 성능 저하를 가져옵니다. 1번처럼 기간을 명시하더라도 어느 한도까지만 세고(예: 10,000) 그보다 많으면 "> 10,000"으로 돌려주는 것이 바람직합니다.

[syncpark]

@msk

1. Count 기능은 일반적으로 사용하기 위한 기능이 아닙니다. 비정상인 상황 혹은 해당 DB에 처음으로 접근하는 엔지니어가 DB의 상태를 확인하고자 할 때 사용하는 용도입니다. UI와 연동하지 않을 API이며, 비상상황이나 정기점검할 때 CLI 등을 통해서 상태확인을 할 수 있는 용도입니다.
2. Export 기능이 들어가기 전까지는 Giganto DB에 뭐가 들어있는지 블랙박스처럼 알 수 있는 방법이 없었습니다. Count 기능이 없다면 매번 Export를 해서 건수를 계산해야하는데 이게 더 비효율적일 것 같습니다.
3. DB에 어떤 데이터가 얼마나 들어있는지 알려면 GraphQL API를 이용한 검색으로는 어렵습니다. 클러스터링하려면 보통 50만~100건씩 지정하는데, 건수를 알 수 없으니 직접 클러스터링을 동작시켜서 몇 라운드까지 가는지 눈으로 확인하는 방법 뿐입니다.

[msk]

UI와 연동하지 않을 API이며, 비상상황이나 정기점검할 때 CLI 등을 통해서 상태확인을 할 수 있는 용도입니다.

그럼 GraphQL 쿼리가 아닌 거네요. 처음 이슈 올라왔을 때 "... query를 구현합니다"로 되어 있어서 웹 클라이언트에서 접근 가능한 GraphQL 쿼리를 구현한다고 생각했습니다.

여전히 count가 필요한가에 대해서는 아직 납득이 안 되는데요, "비정상인 상황 혹은 해당 DB에 처음으로 접근하는 엔지니어가 DB의 상태를 확인하고자 할 때" column family별로 몇 개씩 들어가있는지를 알면 어떤 대응을 할 수 있나요? 데이터 개수가 아니라 column family별로 사용하는 디스크 스페이스로는 안되나요?

그리고 이 기능이 UI와 연동하지 않는 기능이면 3번의 경우는 클러스터링을 하기 전에 "CLI 등을 통해서 상태확인"을 한 다음 개수를 파악해서 하는 건가요?

[syncpark]

column family 별로 사용하는 디스크 용량을 알 수 있는 방법이 있나요? 그렇다면 사용중인 크기와 이벤트의 평균 크기를 비교해서 대략적인 이벤트 건수를 확인하는 방법으로 이벤트 건수를 계산하는 방법이겠네요?

대부분 시스템소프트웨어들은 비상 상황 (혹은 장애 상황)이 발생했을 때를 대비해서 UI가 아닌 다른 방법으로 시스템의 자세한 상황 파악이 가능한 도구들을 제공합니다. 그래서 여러 통계 기능과 Count 기능들을 그런 용도로 사용하고자 합니다.

또한 지금 당장 시험할 때도 DB에 어느정도의 데이터가 들어있는지 알 수 있는 방법이 없습니다. REconverge를 실행해서 몇 라운드 동안 어느정도의 데이터를 분석했으니 몇 건 정도의 데이터가 들어있을 거다...이렇게 판단하기에는 너무 시간이 많이 걸립니다. 그리고 전체 건수를 알아야 period와 batch size등을 적당하게 설정할 수 있지 않을까요?

[sehkone]

현재 두 가지 다른 목적이 있습니다.

1. Giganto가 구동되는 시스템의 상황 파악을 위한 통계 기능
2. REconverge의 성능 범위 이내로 Giganto가 데이터를 보내고 있는 것인지 확인할 수 있는 정보 취득

우선 2번과 관련해서는 Giganto가 보내는 데이터를 REconverge가 다 처리하고 있는지를 파악하는 것으로 해결해야 맞는 것 같습니다. 즉, Giganto에서 해야할 일이 아니라 REconvege가 해야할 일로 생각됩니다.

1번과 관련해서도 시스템의 상황 파악이므로 시스템이 파악해야지 Giganto가 파악하면 안 될 것 같습니다.

다만, 1과 2의 목적이 아니라 Giganto에 저장된 데이터의 양 등 상세 정보를 파악하는 별도의 목적이 있을 수는 있겠습니다. 이러한 목적이 앞의 1과 2와 구별되는 별도의 목적인지를 명확히 하고, 그런 경우에 한해서 Giganto에 필요 기능을 넣어야 할 것 같습니다.

@syncpark @msk 의견 부탁드려요.