당장 쓰고 싶은대로 NoSQL부터
그림 별로 안이쁘다. 근데 이 것만한 그림이 구글에 안보이더라.
요즘 진행하는 프로젝트에 Cassandra를 포팅해보고 있는데, 먼저 밝히고 가야할 것 먼저.
1.
대용량 데이터? 오우 노. 일단 global 서비스다보니 대용량이 될 가능성은 있지만, 게다가 log성 데이터이기에 또 다시 가능성이 있지만, 굳이 NoSQL을 쓸 필요는 없단게 현재의 판단.
2.
performance 이슈 가능성? 이 역시 희박. 게다가 대기업 답게 눈먼 돈이 많아서 performace 이슈는 인프라 투자로 생각 외로 쉽게 풀 수 있다는.
그럼에도 불구하고 NoSQL을 건드리는 이유는,
1.
현재의 화두이니깐(현재라고 말하는 것도 우스울 정도로 몇 년 지났지만, 여전히 화두임에는 의심의 여지가 없지?).
2.
뭘 알아야 쓰건 안쓰건 선택이라도 할 수 있지.
3.
기술이 요구를 창출하는 건 비일비재하니깐.
4.
요즘 시간 많이 남아 도니깐.
Cassandra.. 그리스신화의 그녀 이름을 딴 요 센스는, Cassandra의 가장 잘 나가는 high level client인 hector의 명명에까지 영향을 미치네. 근데 난 hector를 안쓰고 그의 아들인 Astyanax를 썼다. CQL3를 지원한다는 단 하나의 이유로.
일단 컨텍스트 먼저 말하자면,
SQL table 중 in/output이 많고도 join 등의 (쫌) 복잡 연산이 작은 두 놈을 고르고, 첨 배우는 상황이라 요 두 table scheme 모양새까지 그대로 똑같이 포팅. Cassandra의 column family란 개념은 SQL의 table과 그닥 별반 차이가 안나서리,, 용이하게. 게다가 CQL이란 SQL clone인 언어까지 제공하다보니,, 해피하게 진행. 그러다보니 사실 NoSQL을 쓴다는 설계 상 어떤 주요 특이점이 없어진 상황.
여담
•
실제 고민했던게,, 그럼 내가 왜 고생하면서 NoSQL을 쓰지? 란 근본적 질문까지 자문했다는. 내 초반 설계가 잘못한건 아닌게, 이렇게 시작하는 것이 그닥 틀리지 않았다는 걸 말해주는 요런 포스트가 보인다.
•
CQL을 첨부터 쓴건 아닌데, 이를 본격 쓰게 된 이유는 CQL(version 3 not 2)을 안쓰면 composite key 생성 코드가 아주 지저분하기 때문이다. Cassandra의 composite key는 SQL의 그것과는 다른데, 일단 composite key란 것은 없고, 무조건 단일 key만 수용하는데, composite key 요구에 대해서는 pivoting 비스무리한 개념을 통해 처리한다. 이로 인해 wide row란걸 권장하는 편. 자세한 건 'cassandra composite key'라 구글링하면 우후죽순으로 포스트가 떨어지니 요기선 생략.
근데,, 아니 이게 왠 일인가
복잡하다고 전혀 말할 수 없는 Where 절의 조건 몇 개.. column 4개 정도 참조하는 그 절 처리 속도가 입이 딱 벌어지게 느린거다(사실, client에서는 connection timeout에 걸려 아예 실패를 해버렸다..).
secondary index 생성 속도가 느려서 나중가면 빨라지겠지..라고도 생각했는데, 이는 헛 생각(Cassandra는 key가 아닌 column에 조건을 걸려면 무조건 해당 column에 index를 넣어야 한다)임으로 결과 보기를 포기.
이리저리 뒤져봤지만 딱히 답이 안보여, 걍 내 설계에 문제가 있겠거니 하고 잠시 진행을 중단하고 데이터 모델을 되돌아보는 상황 ㅜㅠ.
이제부터는 그간의 깨달음(?)과 의문
물론 아래 나열할 깨달음은 추후 update될 즉, 잘못된 깨달음일 가능성이 아주 풍부하다(내가 지금 NoSQL을 얼마나 안다고 '깨달음'씩이나 언급할까 ㅡㅡ;;).
1.
denormalization은 내게 duplication과 별로 다른 개념이 아니다(물리적 관점에서). 그나저나 denormalization한 데이터에 대한 update는 어떻게 이루어야 하나? 해당 중복 데이터의 일치성 보장은 어떻게 이루나? => 내 잠정적 결론은 update가 필요없는 데이터에만 denormalization을 적용하는 것임(Cassandra의 초창기에는 insert, delete, retrieve 연산만 있었다나? CRUD 중 Update가 빠졌다는 데에 힌트가).
2.
join은 말할 것도 없고 where 절 사용할 만한 query가 있다면 이는 잘못된 scheme design을 탓해야. 만약 design으로도 해결 못본다면 그건 NoSQL을 사용할 곳이 아니라는 뜻.
3.
query를 먼저 생각하고 scheme design을 하라는 NoSQL design practice가 보이는데(위의 링크도 마찬가지), 이 말은 NoSQL은 용도 확장성에 닫혀 있다는 뜻으로 들린다. 대강 potential과 performance/scalability를 트레이드오프한 것이라 봐도 될까?
4.
NoSQL이 그토록이나 SQL과는 다른 놈이라면, Cassandra는 SQL이나 다름없는 CQL을 도대체 왜 제공할까?(CQL 뿐 아니라 JDBC까지 제공하고 있는 형편이다!) 많은 NoSQL practice에서 SQL 설계 패턴을 잊으라는데, CQL을 제공한건 그 잊으라는 설계 방향과 완전히 반대로 나아가는 진행이다.
뭐 이리저리 질문만 많이 던지며 NoSQL - Cassandra에 대한 의구심을 잔뜩 표한 듯 한데, 이 모든 것은 무지의 소치이겠지... 하는 맘으로 더 디벼볼 예정. 어여 위와 같은 데이터 모델링 문제를 끝내고 sharding 등의 물리 설계 부문으로 나아가고픈 맘과 함께 말이다.
댓글 백업