데이터베이스 - 4부 : No SQL

By Gi Pyeong Lee
NoSQL mongoDB memcached redis

훑어보기

앞에서 언급한 RDBMS 의 ACID 모델과는 반대로 NoSQL의 consistency 모델은 BASE 라고 표현한다.

트랜잭션에서의 ACID

  • Atomic
    • 작업은 수행되다가 중단되지 않는다. 중단된다면 이전으로 돌아가야한다.
  • Consistency
    • 트랜잭션 성공시 언제나 모든 데이터는 일관성을 유지해야한다. 무결성제약이 걸렸있다고 했을때, 그 무결성제약을 위배하는 트랜잭션들은 취소된다.
  • Isolation
    • 트랜잭션 중간에 다른 트랜잭션이 개입할 수 없다.
  • Durability
    • 성공한 트랜잭션은 영원히 반영되한다. 시스템 문제가 나더라도.

BASE

  • BA ( Basic Availability )
    • 데이터베이스는 대부분 작동한다.
  • Soft-state
    • 저장소가 쓰기 일관적일 필요는 없으며 서로 다른 복제본이 항상 상호 일관적일 필요도 없다.
  • Eventual consistency
    • 저장소는 결국 나중에는 일관성을 갖는다.

위에서 말한 특성을 기억하며 아래의 NoSQL 데이터베이스에 대해서 얘기해보자.

NoSQL 데이터 베이스

Redis ( Remote Dictionary Server )

  • Open source
  • In-memory data structure store
  • NoSQL/Cache Solution ( 데이터베이스로도 쓰임 )
  • Support snapshotting ( RDB ) / AOF (Append on file) backup
    • RDB : Snapshot whole redis data. ( SAVE, BGSAVE )
      • Good : 빠르다. 스냅샷을 바로 로드하는 형태라 리스타트가 빠르다.
      • Bad : 유실. 스냅샷 시점 이후로의 데이터가 유실 될 수 있다.
    • AOF : log all of write/update operations
      • Good : Lossless. 장비가 내려가기 직전까지의 opertation 들을 기록하여 데이터 유실이 없다.
      • Bad : Slow. write/update 의 모든 operation 을 기록하기에 공간이 RDB 타입보다 많이 필요하며, 리스타트시 기록된 operation 을 모두 진행시켜야하므로 느리다.
    • Hybrid (Recommend) 두개를 섞어서 쓰는 것을 추천한다.
      • RDB + AOF : ~ 스냅샷 (+ 스냅샷 이후 부터는 AOF )
  • Pub/Sub model
    • 1:1 큐, 1:N 메시징 형태를 모두 지원한다
    • 하나의 토픽에 대해 여러개의 메시지를 받을 수 있다.
      • ex) music.jazz, music.classic > music 토픽 -> jazz,classic

memcached ( not NoSQL )

  • Open source
  • Distributed memory caching system
  • (주의) 만일 메모리에 저장공간이 없다면, 멤캐시는 LPU Algorithm 을 이용해서 기존 데이터를 삭제하고, 메모리를 재사용한다.

cassandra

Apache Cassandra는 대규모로 확장 가능한 분산 NoSQL DB로 Facebook 내부에서 시작하여 오픈소스로 출시됐다. 특징으로는 P2P 프로토콜(Gossip)을 이용 1초마다 클러스터내의 최대 3개 노드와 상태메시지를 교환한다. 그리고 이를 이용하여 모든 노드는 클러스터내의 다른 노드들을 빠르게 학습한다. 주의해야할 점은 여러 데이터 센터 클러스터를 사용할 경우 내결함성을 위해 데이터 센터 당 두 개 이상의 시드 노드를 지정하는 것이 좋다.

  • 분산화 : 물리적으로 떨여져 있는 데이터 센터간에도 단일 카산드라 클러스터를 운영할 수 있다.
  • 비집중화 : 모든 노드가 완벽하게 같다.
  • 확장성 : 클러스터 중단 없이 확대 및 축소 가능하다.
  • 고성능 : 멀티프로세서 / 멀티코어 머신을 최대한 활용하고 다중 데이터 센터에 설치된 수백 대의 머신 사이에서 실행되도록 설계되었다.
  • Row 지향
    • 카산드라는 관계형 구조가 아니며 희소 다차원 해시 테이블로 구조를 표현한다.
    • 희소는 로우가 하나 이상의 컬럼을 가질 수 있지만, 각 로우가 다른 로우와 똑같은 컬럼을 모두 가질 필요는 없다는 뜻이다.
  • 사용하는 기업
    • twitter : 분석 용도로 사용
    • Facebook : 받은 편지함 검색에 사용
    • Redit : 영속적인 캐시로 사용
    • Ooyala : 거의 실시간에 가까운 비디오 분석 데이터 서비스와 저장에 사용
  • 단점
    • Join이나 Transaction을 지원하지 않음
    • RDBMS와 같은 Paging을 구현하는 것이 힘들고 Keyspace나 Table 등을 과도하게 생성할 경우 Memory Overflow가 발생할 수 있음

추가적으로 카산드라 클러스터 설정 및 구성이 HBase 클러스터 구성보다 훨씬 쉽다. 카산드라가 일반적으로 write시 5배 이상의 더 나은 성능, read시 4배 이상의 성능을 보인다.

생각해보기

NoSQL의 대부분은 대용량 처리를 염두해두고 있다. 그래서인지 RDBMS 에서 보장해주는 Consistancy 를 대게는 완벽하게 지원해주지 않는다. 이를 위해서는 trade off 되는 설정을 하는 것으로 보여진다.

Appendix