효율적인 SQL 구문은 아니지만, 가벼운 SQL 쿼리문에서는 WHERE절에 `IN`을 이용한 Multiple Value에 대한 매칭을 하는 경우가 종종 있습니다. 안타깝게도 Presto 쿼리 신텍스에는 동일한 구문이 존재하지는 않습니다. 다만, 비슷한 방식으로 사용하는 구문이 존재합니다.
-- Presto Query
SELECT id, name, department
FROM data_source.default
WHERE department = ANY (VALUES 'ORG1', 'ORG2')
Presto의 WHERE 구문에서는 ANY라는 키워드를 이용할 수 있습니다. 이후 VALUES 키워드에 이어서 해당 컬럼에서 찾고자 하는 여러 값을 콤마로 구분해서 넣어주면 됩니다. 보다 자세한 구문 설명은 아래 링크에서 참고하세요.
influxDB 는 시계열 DB (TSDB) 입니다. 일반적인 SQL 문장을 사용할 수 있다보니 종종 TSDB 가 아닌 RDB 로 착각할때가 많습니다. 때문에 일어나는 해프닝이 참 많은데요, <SELECT INTO> 를 이용하여 Measurement 간에 데이터를 옮길 때도 종종 문제가 생기곤 합니다.
사실 저 역시 infludDB 를 많이 사용해 보지는 못했습니다. 어쩌다 보니 다른 분이 운영하던 Graphite 에 저장하고 있던 데이터가 더 이상 적재되지 않고 있어 어디서부터 손을 대볼까하다 "새롭게 해보자!" 는 마음으로 influxDB 를 구성해서 쓰는 정도이기 때문입니다. 아시겠지만 무언가를 할 때마다 매번 새로운 기분이라...
우선, influxDB 에서 <SELECT INTO> 구문을 사용하기 전에 공식 문서를 한 번 읽어보는 것을 추천드립니다. influxDB 의 공식문서가 마음에 드는 점 중 하나는 설명만 나열하는 것이 아니라 샘플 쿼리와 같은 예시가 중간중간에 소개된다는 점입니다. 설명을 읽는 것도 중요하지만 샘플을 가지고 이해하는 것이 더 좋을떄도 많기 때문이지요!
여전히 많은 사람들이 RDB 사고 방식으로 TSDB 를 보고 있나 봅니다. 공식 문서에서도 <Common Issues> 항목으로 <Missing data> 가 있어서 빠르게 해결할 수는 있었습니다. TSDB 에 대한 인식, InfluxDB 의 Tag 에 대한 이해 없이 막 사용하다 보니 발생한 해프닝이겠죠? 사실 이렇게 글을 적고는 있지만 현업에서의 이슈 해결이 급하다 보니 Tag 에 대해 이해할 수 있는 문서들을 더 열람해 보지는 않았습니다. 공부하는대로 다음 포스팅으로 적을 것을 약속합니다 :-)
제 경우의 이슈는 Issue 1 에 설명된 부분이었습니다. RDB 에서 의례 했던 것처럼 아래의 구문으로 특정 값을 가진 데이터를 다른 Measurement 로 옮기려는 것이 제 의도였습니다. 하지만, where 절의 값을 바꾸면서 3회 정도 쿼리를 수행했지만, 목적지의 레코드 갯수는 턱없이 적었습니다.
SELECT * INTO "new_table" FROM "old_table" WHERE "type"='audio'
SELECT * INTO "new_table" FROM "old_table" WHERE "type"='video'
SELECT * INTO "new_table" FROM "old_table" WHERE "type"='etc'
공식 문서의 Issue 1 에 나온 것처럼 <현재 Measurement 의 태그(tags)를 새로운 Measurement 의 필드(Fields)로 컨버트한다> 는 동작 때문이었습니다. 인지하지 못한 사이에 현재 Measurement 의 "type" 은 태그였던 것입니다. 왜냐구요? 아직 공부하지 못했습니다 ㅜㅜ 여튼 그런연유로 데이터가 계속 겹쳐 써지면서 제대로 이관이 되지 않았던 상황이었습니다.
역시나 문서에 나온것처럼 원래의 태그를 유지하기 위해서는 "GROUP BY *" 구문을 추가하여 사용하여 문제를 해결했습니다. 새로운 데이터베이스에 대한 이해가 부족한 상태에서 필요한 결과물을 빨리 얻으려다보니 생긴 해프닝입니다. 여러분들도 혹시 유사한 문제를 만난다면 구문을 살펴보고 GROUP BY 를 추가해 주면 이슈를 벗어날 수 있을겁니다!
SELECT * INTO "new_table" FROM "old_table" WHERE "type"='audio' GROUP BY *
SELECT * INTO "new_table" FROM "old_table" WHERE "type"='video' GROUP BY *
SELECT * INTO "new_table" FROM "old_table" WHERE "type"='etc' GROUP BY *
XE는 사용자가 꽤 많은 CMS (Content Management System) 임에도 불구하고 열악한 기술지원과 매뉴얼 때문에 커스터마이징을 필요로 하는 사람들에게 참 많은 숙제를 안겨주고 있다. 제로보드 시절만 해도 그렇지 않았는데 네이버가 인수한 이후에는 뭔가 부드럽지 않은 분위기다.
오늘 올리는 내용은 사실 포스팅으로 남겨 두기도 참 뻘쭘한 내용이다. XE 개발자 매뉴얼에 제대로 기술이 되어 있지 않아 삽질한 내용이기 때문이다. MySql 에서 쿼리 크기를 제한할 때는 쿼리 뒷부분에 limit [숫자] 형태로 쿼리 갯수를 제한할 수 있다. MS-SQL 에서 select 문 바로 뒤에 top [숫자] 를 적어주는 것과 동일한 효과다.
select *
from xe_documents
where module_srl=3038
and voted_count > 5
limit 5
특정한 게시판 모듈에서 추천수가 5 이상인 게시물을 가져오되 5개를 넘지 않도록 만든 아주 간단한 쿼리다. 이 쿼리를 XE 가 사용하는 XML 형태로 변경하면 어떻게 될까? 구현하는 사람에 따라 차이가 있겠지만 아래와 같은 XML 로 만들어질 것 같다.
삽질을 했던 이유는 바로 마지막의 <list_count> 부분이다. 개발자 매뉴얼 그 어디에도 <list_count> 엘레멘트가 <navigation> 엘레멘트의 하위 엘레멘트라는 표기가 없다. 물론 <navigation> 엘레멘트 설명에는 "정렬 순서나 페이징을 지원" 이라고 되어 있지만 그 설명을 "따라서 <list_count> 는 <navigation> 의 자식입니다"로 해석할 수 있는 사람은 몇 안될것 같다. 누군가 동일한 삽질을 할까봐 포스팅으로 남겨둔다.
