NoSQL 도입 시 고려사항

컬럼패밀리 기반 - Cassandra 

- 노드가 추가될 때, Mongo DB보다 더 선형적으로 성능이 좋아진다. ( 참고 - NoSQL 비교(카산드라, HBASE, MongoDB )

- 타임시퀀스한 데이터를 저장할 때 좋다. 

- 데이터를 삭제해도, 내부적으로는 삭제한 데이터도 읽어들여서 데이터가 많아지면 성능이 좋진 않다. 

  그리고 클러스터링 이슈로 지워졌던 데이터가 다시 살아날 수도 있다. ( 참고 - Apache Cassandra 톺아보기 3편 - Delete Data )

- 페이지네이션

  카산드라에서 페이징을 구현하는건 쉬운 일은 아니다. 

  하나의 Row에 속한 컬럼은 이미 정렬되어있어서, 한 Row에 대한 페이징은 가능하다. 그런데 Row Key는 해시키로 관리되기 때문에, Row Key 단위의 페이징을 구현하는건 사실상 불가능하다. 

  이것저것 우회해서 페이징 구현이 가능하긴하다. ( 참고 - Apache Cassandra 톺아보기 3편- Paging )

  고려할점들이 좀 있어서, 페이지네이션이 필요한 데이터이면, 카산드라에 저장하는게 적합하진 않은 것 같다.

문서 기반 - Mongo DB

 

- Shema-free한 데이터구조가 꼭 필요할 때 유용하다

- 샤딩이 꼭 필요한 경우가 아니면 RDBMS의 인덱스, 파티셔닝으로 충분하다. 

   로우수가 1억건 이상이 되지 않으면 RDMBS 으로 충분하다. ( 참고 - MongoDB를 쓰면서 알게 된 것들 )

- 다른 저장소와 데이터 JOIN이 필요한 경우에는 적합하지 않다.

  ROW 데이터에 모든 값을 저장하고, 이걸 그대로 리턴해줄 때 유용하다. 

- 페이지네이션

   skip / limit 함수로 페이지네이션을 구현했으면  데이터양이 많아지면 속도가 느려질 수 있다.

   그러면 튜닝이 필요하다. ( Fast Paging with MongoDB )

 Key-Value 기반 - RocksDB

데이터가 파일 기반으로 영구저장되는 Key-Value 저장소다. 읽고, 쓰는 성능이 좋아서, 낮은 레이턴시가 필요할 때 적합하다고 한다.

rocks db를 기반으로 한 mysql db 엔진 플러그인, mongodb 플러그인도 있다.

참고 - Facebook의 Key-Value DB ‘RocksDB’