이것저것

NoSQL 데이터베이스 비교

tobee 2023. 3. 14. 19:43
728x90

NoSQL 데이터베이스를 비교한 글인 것으로...

 

SQL 데이터베이스들은 정말 유용한 툴임에 틀림없지만, 이제 그 독과점에 끝을 고할 마지막 10년이 왔습니다. 그리고 이제 때가 된 것이지요: 지금까지 정말 셀 수도 없이 이것이 올바른 선택인가 고민도 하기 전에 오로지 수많은 관계 형 데이터베이스를 사용하도록 강제해 왔습니다.

(말하자면, 관계형 데이터베이스는 그 ‘관계’를 짓기 위한 항상 최고의 솔루션이었다는 것이죠. )

 

그렇지만, NoSQL 데이터베이스들과의 차이를 비교하는 것은 이전, 한 SQL 데이터베이스와 그와 비슷한 다른 데이터베이스들과의 차이를 비교 하는 일보다 훨씬 더 방대한 작업이 되었습니다. 다시 말해 프로젝트 시작 초기에 적절한 데이터베이스를 선택하기 위한 소프트웨어 아키텍트들의 몫은 더욱 더 커져 있다는 것입니다.

 

이 생각을 가지고 여기에

Cassandra,

Mongodb,

CouchDB,

Redis,

Riak,

RethinkDB,

Couchbase(ex-Membase),

Hypertable, ElasticSearch,

Accumulo,

VoltDB,

Kyoto Tycoon,

Scalaris,

OrientDB,

Aerospike,

Neo4j 그리고

HBase

에 대해서 비교한 결과를 내놓았습니다.

 

가장 유명한 것들

 

Redis (V3.0RC)

  • 작성언어: C
  • ​​주요 판단근거: 빛의 속도로 빠름
  • 라이선스: BSD
  • 프로토콜: Telnet-like, binary safe
  • 디스크 기반 in-memory 데이터베이스
  • 컴퓨터 램의 크기로 데이터셑 크기가 한정됨(하지만 클러스터링으로 여러 머신의 램을 사용 하도록 확장 가능)
  • 마스터-슬레이브 복제, 자동 failover
  • 키들에 의한 데이터 구조 혹은 간단한 값(Simple values, data structures)
  • 하지만, ZREVRANGEBYSCORE 같은 복잡한 오퍼레이션들임(http://redis.io/commands)
  • INCR & co (비율 한정 혹은 통계에 좋음 - good for rate limiting or statistics)
  • 비트 오퍼레이션(예: bloom filter들의 구현)
  • Has sets (also union/diff/inter)
  • 해시 셑 종류(또한 union/diff/inter)
  • 해시 리스트 종류(또한 큐; 블록킹 pop)
  • 해시 테이블(다중 필드들의 오브젝트들)
  • Sorted sets (high score table, 범위 쿼리에 좋음- good for range queries)
  • 루아 스크립팅 가능(!)
  • 해시 트랜잭션(!)
  • 값들의 expire 설정 가능(캐시 상이므로)
  • 메시징을 구현하도록 해주는 Pub/Sub

최적사용법:

예측 가능한 데이터베이스 크기로 데이터가 빠르게 변경되는 경우(거의 메모리 상에서 맞춤)

 

예:

실시간 주식시세 저장. 실시간 분석. Leaderboards.

​실시간 커뮤니케이션 그리고 전에 memcached 사용했던 모든 곳.

 

MongoDB (2.6.7)

  • 작성언어: C++
  • 주요판단근거: 몇 친근한 SQL의 기능(쿼리, 인덱스)을 놓고 싶지 않을 때.
  • 라이선스: AGPL (Drivers: Apache)
  • Protocol: Custom, binary (BSON)
  • 마스터-슬레이브 복제 (replica sets 을 통한 자동 failover)
  • 빌트인 Sharding(Sharding 이란 다중 머신들 사이에 데이터를 저장하는 방법이다.)
  • 자바스크립트 표현 식을 사용한 쿼리들
  • 서버 측 임의의 자바스크립트 함수들 구동
  • CouchDB 보다 나은 update-in-place 방식(내부적으로 나머지 다른 코드를 건드리지 않고 해당 데이터만 읽고/쓰고/프로세싱 할 수 있는 것)
  • 데이터 저장소에 memory mapped 파일 사용
  • Performance over features
  • 저널링 기능 on(--journal 옵션)
  • 32 비트 시스템에서, ~2.5Gb 로 제한
  • 텍스트 검색 통합
  • Big data + metadata 를 저장하는 GridFS (정확히 FS는 아님)
  • 공간 인덱싱 기능
  • Data center aware

최적사용법:

동적 쿼리들이 필요 할 때. map/reduce 기능들 말고 인덱스를 정의하는 것을 선호 할 때. 빅 데이터베이스 상에서 최적화된 성능이 필요할 때. CouchDB를 사용해야 하지만 디스크를 채우는 데이터의 변동이 너무 잦을 때.

 

사용예:

대부분의 경우 MySQL 이나 PostgreSQL을 사용할 것이지만, 미리 정의된 컬럼이 당신의 발목을 잡을 때.

 

Cassandra (2.0)

  • 작성언어: Java
  • Main point: "거의" SQL 같은 곳에 거대한 데이터 셑을 저장하고 싶을 때.
  • 라이선스: Apache
  • 프로토콜: CQL3 & Thrift
  • CQL3는 SQL과 매우 비슷하지만, 확장성에서 오는 약간의 제약들이 있다.(제일 많이 지목되는 것: JOIN들이 없고, aggregate 함수들이 없음)
  • CQL3는 이제 공식 인터페이스가 되었다. 레거시 애플리케이션으로 작업하지 않는 한, Thrift를 쳐다보지 않아도 된다. 이렇게, ColumnFamilies, SuperColumns, 등등의 이해 없이도 잘 살 수 있다.
  • 키 값, 혹은 키 범위 쿼리 (secondary 인덱스들을 사용 가능함)
  • 분산과 복제를 위한 튜닝 가능한 trade-off들(N,R,W)
  • expiration 을 가진 데이터 생성(INSERT 에서 설정)
  • 읽기 보다 더 빠른 쓰기(읽기가 disk-bound 일때)
  • 아파치 하둡을 통한 Map/reduce 가능
  • Hadoop/HBase와 반대로 모든 노드들이 비슷함
  • 안정적이고 상당히 좋은 cross-datacenter 복제
  • 분산 카운터 데이터 타입
  • 자바로 트리거들을 만들 수 있음.

최적사용법:

정말 큰 데이터를 저장 할 필요가 있을 때, 서버에 저장하는 것이 올바른 방법이 아니지만, 여전히 저장하기 위한 친근한 인터페이스가 필요하다.

 

사용예:

시간당, 브라우저 당, IP 당 등등의 웹 분석. 트랜잭션 로깅. 거대한 센서 배열들로부터 데이터 수집.

 

ElasticSearch (0.20.1)

  • 작성언어: Java
  • Main point: Advanced Search
  • 라이선스: Apache
  • 프로토콜: JSON over HTTP (Plugins: Thrift, memcached)
  • JSON 문서로 저장.
  • 버전 관리.
  • 부모 자식 도큐먼트.
  • 도큐먼트들은 타임아웃 가능.
  • 매우 다양하고 복잡한 쿼리에 사용하며 스크립팅 가능.
  • Write consistency: one, quorum or all
  • 스코어 별 소팅(!)
  • Geo distance 소팅
  • 인공지능 검색들(근접 날짜, 등등 - approximate date) (!)
  • 비동기식 복제
  • Atomic, scripted updates (good for counters, etc)
  • 자동 "stats groups" 가능(디버깅에 좋음)
  • 여전히 한명의 개발자에게 매우 의존적임(kimchy).

최적사용법:

(유동적인)필드들을 가진 오브젝트를 가지고 있으며, "advanced search" 기능이 필요할 때.

 

사용예:

나이 차이, 지리적인 위치, 음식취향 그리고 싫어하는 것들 등을 핸들링 해야 하는 데이트 서비스. 혹은 여러가지 변수에 종속적인 leaderboard system.

 

 

클래식 도큐먼트와 빅테이블 저장소들

CouchDB (V1.2)

  • 작성언어: Erlang
  • Main point: 사용하기 쉽고, DB consistency를 원할 때.
  • 라이선스: Apache
  • 프로토콜: HTTP/REST
  • 양방향(!) 복제, 충돌 감지 연속적이거나 ad-hoc 인 마스터 마스터 복제(!)
  • MVCC – 쓰기 동작들은 읽기 동작을 블록킹 하지 않음.
  • Previous versions of documents are available
  • 도큐먼트들의 이전 버전 찾기 가능.
  • Crash-only (reliable) design
  • 때때로 컴팩트 작업이 필요.
  • Views: 임베디드 map/reduce
  • Formatting views: lists & shows
  • 정형화된 views: lists & shows
  • 서버 측 도규먼트 검증 가능
  • 인증 적용 가능
  • '_changes' 를 통한 실시간 업데이트(!)
  • Attachment handling
  • thus, CouchApps (standalone js apps)

최적사용법:

미리정의된(pre-defined) 쿼리를 실행하는 저장되거나 때때로 변하는 데이터.

버전닝이 중요한 곳

 

사용예:

Versioning 이 중요 한 곳, 데이터를 쌓거나 때때로 변경하기 위해

미리 정의 된 쿼리가 구동하는 곳.

 

Accumulo (1.4)

  • 작성언어: Java and C++
  • Main point: 셀 단위 보안이 적용 되는 BigTable 한 종류.
  • 라이선스: Apache
  • 프로토콜: Thrift
  • 다른 빅테이블 클론, 하둡 상에서 또한 구동 가능.
  • NSA로부터 시작.
  • 셀 단위 보안.
  • 메모리보다 더 큰 row 허용.
  • 자바 바깥에서 C++ STL로 메모리 맵 유지.
  • 하둡 기능(툴)을 이용한 Map/reduce(ZooKeeper & co)
  • 몇몇 서버 측 프로그래밍

최적사용법:

셀 단위로 접근 제한이 필요 할 때.

 

사용예:

HBase 같이, 기본적으로 다음의 대체 데이터베이스이다: 검색 엔진들. 로그 데이터 분석.

거대하고, 2차원이며 join이 없는 테이블들을 스캔 하는 것이 요구 사항이 어떤 곳.

 

HBase (V0.92.0)

  • 작성언어: Java
  • Main point: 수백만개의 컬럼을 가진 수십억 개의 row들을 가지고 싶을 때.
  • 라이선스: Apache
  • 프로토콜: HTTP/REST (also Thrift)
  • Google's BigTable 후 모델됨
  • 하둡의 HDFS를 저장소로 사용
  • 하둡을 이용한 map/reduce
  • 서버측 스캔을 통한 push down을 기본이며 필터들을 가짐.
  • 실시간 쿼리들의 최적화.
  • 고성능 Thrift 게이트웨이
  • XML, Protobuf, 와 binary를 지원하는 HTTP
  • Jruby-based (JIRB) shell
  • 마이너 업그레이드들이나 환경설정이 바꼈을 때, 재 시작(Rolling restart)
  • MySQL과 같은 Random access performance
  • 클러스터는 여러 다른 타입의 노드들로 구성된다.

최적사용법:

하둡은 아마 여전히 거대한 데이터 셑들 위에서 Map/Reduce job들을 구동하는 최고의 방법이다. 만약 Hadoop/HDFS스택을 사용하고 있다면 완전 최고다.

 

사용 예: 

검색 엔진들, 로그 데이터 분석. 거대하고, 2차원이며 join이 없는 테이블들을 스캔 하는 것이 요구 사항이 어떤 곳.

 

Hypertable (0.9.6.5)

  • 작성 언어: C++
  • 주요판단근거: HBase 보다 더 빠르고, 더 작은 데이터베이스.
  • 라이선스: GPL 2.0
  • 프로토콜: Thrift, C++ library, or HQL shell
  • 구글의 BigTable 디자인을 구현.
  • 하둡의 HDFS 상에서 구동.
  • 자신만의 "SQL-비슷한" 언어인, HQL 사용.
  • 키로 검색 셀로 검색, 혹은 컬럼 패밀리 내의 값으로 검색 가능.
  • 키/컬럼 범위로 한정하여 검색 가능.
  • Baidu 스폰서
  • 마지막 N 이력 값들을 유지.
  • 테이블들은 네임스페이스 상에 존재.
  • Map/reduce with Hadoop
  • 하둡을 이용한 map/reduce

최적사용법:

좀 더 향상 된 HBase를 사용하고 싶다면.

 

사용예:

HBase 같이, 기본적으로 다음의 대체 데이터베이스이다: 검색 엔진들. 로그 데이터 분석.

거대하고, 2차원이며 join이 없는 테이블들을 스캔 하는 것이 요구 사항이 어떤 곳.

 

 

Graph 데이터베이스

OrientDB (2.0)
  • 작성언어: Java
  • 주요판단근거: 도큐먼트 기반의 그래프 데이터베이스
  • 라이선스: Apache 2.0
  • 프로토콜: binary, HTTP REST/JSON, or Java API for embedding
  • 트랜잭션들과 완벽 ACID 적용.
  • 도큐먼트로서 그래프 데이터베이스로서 양쪽 다 사용 가능(프로퍼티를 가진 vertex들)
  • 노드들과 relationship 들을 둘다 메타데이터로 가질 수 있음.
  • 다중 마스터 아키텍처.
  • persistent pointers (LINK, LINKSET, LINKMAP, LINKLIST field types)를 통한 도큐먼트들간의 relationship들을 지원.
  • SQL류의 쿼리 언어(주의: JOIN이 없고 포인터들이 존재함)
  • 웹 기반의 GUI ( UI가 괜찮음, 독립적)
  • 클래스들 사이의 상속. 노드들과 relationship들의 인덱스화
  • SQL 혹은 자바스크립트 내에서 사용자 함수를 사용.
  • Sharding
  • 다중 알고리즘을 사용 한 Advanced path-finding과 Gremlin traversal language
  • 온라인 백업과 Advanced monitoring은 상용 라이선스 사용.

최적사용법:

그래프 형식에 풍부하고 복잡하며 서로 연결된 데이터를 사용 할 때.

 

사용예:

사회적인 관계, 공공 교통 정보 연계, 거리 지도, 혹은 네트워크 토폴로지를 구성 할 때 사용.

 

Neo4j (V1.5M02)

  • 작성언어: Java
  • 주요판단근거: Graph database - connected data
  • 라이선스: GPL, some features AGPL/commercial
  • 프로토콜: HTTP/REST (or embedding in Java)
  • 자바 애플리케이션내에 임베디드 혹은 단독으로 존재.
  • Full ACID conformity (including durable data)
  • 노드들과 관계들 둘 다를 메타데이터화 할 수 있음
  • 통합 패턴 매칭 기반 쿼리 언어("Cypher")
  • 또한 "Gremlin" graph traversal language를 사용 가능.
  • 노드들과 관계들을 인덱스화
  • 멋진 독립 된 웹 관리 화면을 가짐
  • 다중 알고리즘을 통한 발전된 path-finding.
  • 키들과 관계들을 인덱스화
  • 읽기들의 최적화
  • 트랜잭션을 가짐(자바 API)
  • 그루비를 사용해서 스크립팅.
  • 클러스터링, 복제, 캐싱, 온라인 백업, 특수 모니터링과 HA는 상용 라이선스 적용.

최적사용법:

그래프 형식에 풍부하고 복잡하며 서로 연결된 데이터를 사용 할 때.

 

사용 예: 

사회적인 관계, 공공 교통 정보 연계, 거리 지도, 혹은 네트워크 토폴로지를 구성 할 때 사용.

"long tail"

(널리 알려지진 않았지만, 정말 유용한 것들)

Couchbase (ex-Membase)(2.0)

  • 작성언어: Erlang & C
  • 주요판단근거: 영속성(persistence)과 클러스터링이 가능하면서 Memcache와 호환성을 가지고 싶을 때.
  • 라이선스: Apache
  • 프로토콜: memcached + extensions
  • 키에 의한 데이터 접근이 매우 빠름(200k+/sec)
  • 디스크 persistence.
  • 모든 노드들이 동일함(마스터-마스터 복제)
  • Memcached 형식의 in-memory caching buckets 역시 제공.
  • IO를 줄이기 위한 de-duplication 쓰기
  • 친근한 클러스터-매니지먼트 웹 GUI
  • 연결 풀링과 멀티플랙싱(Moxi)을 위한 커넥션 프록시
  • Incremental map/reduce
  • Cross-datacenter replication

최적사용법:

low-latency 데이터 접근, 고성능 concurrency 지원과 고 가용성이 요구 되는 애플리케이션.

 

사용 예: 

온라인 게이밍 같은(젠가) 고 동시성 웹 앱들 혹은 광고 목적 같은 Low-latency use-cases

 

Scalaris (0.5)

  • 작성언어: Erlang
  • 주요판단근거: 분산 P2P 키-값 저장소
  • 라이선스: Apache
  • 프로토콜: Proprietary & JSON-RPC
  • In-memory ( 백엔드로 Tokyo Cabinet 을 디스크로 사용)
  • YAWS 웹서버로 사용.
  • 트랜잭션들(adapted Paxos commit)
  • 일관된 분산 쓰기 조작.
  • 가용성 기반의 CAP, values Consistency(네트워크 파티셔닝, 좀 더 큰 파티셔닝 작업에 한함)

최적사용법:

Erlang이 기호에 맞고, Mnesia 혹은 DETS 혹은 ETS를 사용하기 원한 다면..

 

사용 예: 

당신이 파이썬, 루비 혹은 자바 프로그래머에게 데이터베이스에 접근권한을 주고 싶을 때를 위한 Erlang 기반 시스템.

 

Aerospike (3.4.1)

  • 작성언어: C
  • 주요판단근거: 속도, SSD-최적화 저장소.
  • 라이선스: License: AGPL (Client: Apache)
  • 프로토콜: Proprietary
  • Cross-datacenter replication 은 상용 라이선스
  • 키 값으로 데이터 접근이 매우 빠름
  • 데이터 저장을 위해서 블록 디바이스로 SSD 디바이스들을 사용(RAM + persistence 가능)
  • 클러스터에서 데이터의 노드 화 추가 삭제 시 자동 failover와 자동 rebalancing
  • LUA를 통한 사용자 정의 함수들 사용 가능
  • 웹 GUI로 클러스터 조작 가능
  • 기본 타입(integer, string, blob) 이외의 복잡한 데이터 타입(리스트와 맵 들) 사용 가능
  • Secondary 인덱스
  • Aggregation query model
  • TTL(time-to-live)를 데이터에 붙여서 expire 가능
  • 거대 데이터 타입 기능 지원

최적사용법:

low-latency 데이터 접근, 고 기능 동시성 지원 및 고 가용성이 주요 요구기능이 되는 애플리케이션

 

사용예:

온라인 광고나 유통을 위한 웹사이트들의 거대한 프로파일 데이터를 저장 할 때.

 

RethinkDB (2.1)

  • 작성언어: C++
  • 주요판단근거: 스트림 데이터 업데이트를 위한 JSON 저장소
  • 라이선스: License: AGPL (Client: Apache)
  • 프로토콜: Proprietary
  • JSON 도큐먼트 저장소
  • "ReQL" 이라는 자바스크립트 기반의 쿼리 언어 사용.
  • Underscore.js 를 사용해 봤다면 친근하게 생각 될 "ReQL"은 실용적인 언어 임
  • Sharded clustering, replication built-in
  • 레퍼런스들을 이용하여 데이터는 JOIN 가능함
  • BLOB의 조작 가능.
  • 공간 자료 지원
  • Multi-datacenter support

최적사용법:

계속적인 실시간 업데이트가 필요한 애플리케이션

 

사용예:

온라인 혹은 여러 디스플레이들에 스포츠 스코어를 표출 할 때. 모니터링 시스템들. 빠른 워크플로우 애플리케이션.

 

Riak (V1.2)

  • 작성언어: Erlang & C, some JavaScript
  • 주요판단근거: Fault tolerance
  • 라이선스: Apache
  • 프로토콜: HTTP/REST or custom binary
  • Blob 저장 기능
  • 분산과 복제를 위한 튜닝 가능한 trade-off들
  • 검증과 보안을 위해서 JavaScript 혹은 Erlang 통해 Pre-와 post-commit을 잡아 낼 수 있다.
  • JavaScript 혹은 Erlang을 이용한 map/reduce
  • 그래프데이터베이스로서 사용: Links & link walking
  • Secondary indices: but only one at once
  • 세컨더리 인덱스 사용 가능: 하지만 오직 한번에 하나씩.
  • 큰 오브젝트 지원(Luwak)
  • “오픈소스”와 “엔터프라이즈” 에디션 두개가 존재.
  • Riak Search를 사용한 Full-text 검색, 인덱싱, 쿼리.
  • 저장 백엔드 시스템인 "Bitcask" 부터 Google의 "LevelDB" 까지 마이그레션 가능.
  • 마스터 필요 없는 multi-site 복제와 SNMP 모니터링은 상용 라이선스 적용.

최적사용법:

Dynamo 같은 데이터 저장소를 원하지만, bloat과 복잡도 등을 취급 할 방법이 없는 경우. 인 사이트 확장성, 가용성 및 fault-tolerance를 원하지만, multi-site 복제를 위해서 돈을 낼 준비가 되어 있을 때.

 

사용예:

Point-of-sales data collection. Factory control systems. 일초도 down time이 생기면 안 되는 곳. well-update-able 웹 서버로 사용 가능.

​★ Software bloat: 프로그램 새 버전이 나올 때마다 사용자에게 필요 없는 기능이 추가되거나 점점 더 많은 시스템 자원을 사용하는 경향을 이르는 용어.

 

VoltDB (2.8.4.1)

  • 작성언어: Java
  • 주요판단근거: 빠른 트랜잭션과 신속한 데이터 변경.
  • 라이선스: AGPL v3 and proprietary
  • 프로토콜: Proprietary
  • In-memory 관계형 데이터베이스.
  • 하둡으로 데이터를 export 가능.
  • ANSI SQL 지원.
  • Stored procedures in Java
  • 자바 Stored procedure 작성 가능.
  • Cross-datacenter 복제.

 

최적사용법:

입력되는 데이터의 거대한 양을 빠르게 처리해야 할 때.

 

사용예:

Point-of-sales 데이터 분석. 공장 컨트롤 시스템.

 

POS[포스]란 판매와 관련된 데이터를 물품이 판매되는 그 시간과 장소에서 즉시 취득하는 것이다.

 

Kyoto Tycoon (0.9.56)

  • 작성언어: C++
  • 주요판단근거: 경량 네트웍 DBM
  • 라이선스: GPL
  • 프로토콜: HTTP (TSV-RPC or REST)
  • Kyoto Cabinet 기반, Kyoto Cabinet의 嫡子(본처아들).
  • 스토리지 백엔드 군: 해시, 트리, Dir, 등등(Kyoto Cabinet에서 상속됨)
  • Kyoto Cabinet은 초당 1M+의 insert/select 조작들이 가능함(그러나 Tycoon은 오버헤드로 인해 기능이 좀 떨어짐)
  • 서버 측에서 루아를 사용할 수 있음.
  • C, Java, Python, Ruby, Perl, Lua, 등의 언어로 바인딩 가능.
  • "visitor" 패턴 사용.
  • 핫 백업, 비동기 복제.
  • in-memory 데이터베이스의 백그라운드 스냅샷
  • 자동 expiration(캐시 서버로 사용가능)

최적사용법:

가장 정확하게 백엔트 저장 알고리즘 엔진을 선택하고 싶을 때. 속도가 기본이 되어야 할 때.

 

사용 예: 

캐시 서버. 증권. 분석. 실시간 데이터 수집. 실시간 커뮤니케이션.

 

Memcached를 전에 사용 했던 곳.

물론. 이 모든 시스템들은 여기서 기록된 내용보다 더 많은 기능을 가지고 있습니다. 나는 그냥 그 위에 나의 결정을 입혀서 중요한 기능을 기록하기를 원했던 것 뿐입니다. 그리고 이들 시스템들은 빠른 개발 단계에 있기 때문에, 항상 자주 바뀔수 있다는 것을 알아야 할 것입니다.

 

Hacker News의 토론 내용2

 

다음 사이트를 3참고 하였슴.​

 

이상.

 

 

728x90