title: "**NoSQL - Cassandra 디비는 중 한마디**"
description: "**NoSQL - Cassandra 디비는 중 한마디**"
cleanUrl: /sw-engineer/nosql-cassandra
ogImage: "<https://anyflower.notion.site/image/https%3A%2F%2Fprod-files-secure.s3.us-west-2.amazonaws.com%2F7570d2fc-66b1-4e23-bb3c-ff7b56842b0d%2Fff0146b9-d2ae-489c-9abf-cbd79c92481b%2FUntitled.png?table=block&id=e74a420b-4437-4622-8cd9-e4e243e84ea3&spaceId=7570d2fc-66b1-4e23-bb3c-ff7b56842b0d&width=1160&userId=&cache=v2>"
floatFirstTOC: right

순서대로라면 요즘 쓰고 있는거 리포팅, 소감 #1 - JIRA, Github 의 #2가 나와야겠지만, 뭐 언제부터 내가 순서 따졌냐.

당장 쓰고 싶은대로 NoSQL부터

그림 별로 안이쁘다. 근데 이 것만한 그림이 구글에 안보이더라.

요즘 진행하는 프로젝트에 Cassandra를 포팅해보고 있는데, 먼저 밝히고 가야할 것 먼저.

1. 대용량 데이터? 오우 노. 일단 global 서비스다보니 대용량이 될 가능성은 있지만, 게다가 log성 데이터이기에 또 다시 가능성이 있지만, 굳이 NoSQL을 쓸 필요는 없단게 현재의 판단.
2. performance 이슈 가능성? 이 역시 희박. 게다가 대기업 답게 눈먼 돈이 많아서 performace 이슈는 인프라 투자로 생각 외로 쉽게 풀 수 있다는.

그럼에도 불구하고 NoSQL을 건드리는 이유는,

1. 현재의 화두이니깐(현재라고 말하는 것도 우스울 정도로 몇 년 지났지만, 여전히 화두임에는 의심의 여지가 없지?).
2. 뭘 알아야 쓰건 안쓰건 선택이라도 할 수 있지.
3. 기술이 요구를 창출하는 건 비일비재하니깐.
4. 요즘 시간 많이 남아 도니깐.

NoSQL 솔루션 중 가장 잘나가는 듯한 형국을 보이는 Cassandra 낙점. 그 많은 솔루션 중 Cassandra를 선택한 여러 이유 중 가장 큰 건 아마도 Twitter가 Cassandra를 앞으로도 더 많이 적용할 예정이란 소리를 들어서겠지(by Ryan King of Twitter. 이외에 NoSQL 비교를 잘(?)한 요런 포스트도 있는데,, 비교를 너무 평면적으로 했다는 생각이..)

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을 쓴다는 설계 상 어떤 주요 특이점이 없어진 상황.

<aside> 💡 여담

• 실제 고민했던게,, 그럼 내가 왜 고생하면서 NoSQL을 쓰지? 란 근본적 질문까지 자문했다는. 내 초반 설계가 잘못한건 아닌게, 이렇게 시작하는 것이 그닥 틀리지 않았다는 걸 말해주는 요런 포스트가 보인다.
• CQL을 첨부터 쓴건 아닌데, 이를 본격 쓰게 된 이유는 CQL(version 3 not 2)을 안쓰면 composite key 생성 코드가 아주 지저분하기 때문이다. Cassandra의 composite key는 SQL의 그것과는 다른데, 일단 composite key란 것은 없고, 무조건 단일 key만 수용하는데, composite key 요구에 대해서는 pivoting 비스무리한 개념을 통해 처리한다. 이로 인해 wide row란걸 권장하는 편. 자세한 건 'cassandra composite key'라 구글링하면 우후죽순으로 포스트가 떨어지니 요기선 생략. </aside>

근데,, 아니 이게 왠 일인가

복잡하다고 전혀 말할 수 없는 Where 절의 조건 몇 개.. column 4개 정도 참조하는 그 절 처리 속도가 입이 딱 벌어지게 느린거다(사실, client에서는 connection timeout에 걸려 아예 실패를 해버렸다..).