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가 나와야겠지만, 뭐 언제부터 내가 순서 따졌냐.
그림 별로 안이쁘다. 근데 이 것만한 그림이 구글에 안보이더라.
요즘 진행하는 프로젝트에 Cassandra를 포팅해보고 있는데, 먼저 밝히고 가야할 것 먼저.
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> 💡 여담
복잡하다고 전혀 말할 수 없는 Where 절의 조건 몇 개.. column 4개 정도 참조하는 그 절 처리 속도가 입이 딱 벌어지게 느린거다(사실, client에서는 connection timeout에 걸려 아예 실패를 해버렸다..).