기본 콘텐츠로 건너뛰기

Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Membase vs Neo4j comparison

번역 작업

 원문

NoSQL DB 비교 분석 자료

MongoDB

  • 구현 : C++
  • 특징 : 몇가지 SQL과 비슷한 속성을 가짐(Query, index 등)
  • 라이센스 : AGPL
  • 프로토콜 : Custom, binary(BSON)
  • 특징
    • Master/slave replication(auto failover with replica sets)
    • Sharding built-in
    • Queries are javascript expressions
    • Run arbitrary javascript functions server-side
    • Better update-in-place than CouchDB
    • Uses memory mapped files for data storage
    • Performance over features
    • Journaling (with --journal) is best turned on
    • On 32bit system, limited to 2.5Gb
    • An empty database takes up 192Mb
    • GridFS to store big data + metadata (not actually an FS)
    • Has geospatial indexing
  • 주요 사용처
    • 만약 다양한 쿼리가 필요하다면
    • map/reduce 함수가 아니라 인텍스를 선호한다면
    • big DB에서 좋은 성능을 바란다면
    •  CouchDB를 사용하길 원하지만, filling up disks에 너무 많은 데이터 변화가 있다면
  • 사용예
    • For most things that you would do with MySQL or PostgreSQL, but having predefined columns really holds you back.

CouchDB

  • 구현 :  Erlang
  • 주요특징 : DB consistency, 쉬운 사용
  • 라이센스 : Apache
  • 프로토콜 : HTTP/REST
  • 상세특징
    • Bi-directional replication
    • continuous or ad-hoc
    • with conflict detection
    • thus, master-master replication
    • MVCC - write operations do not block reads
    • Previous version of documents are available
    • Crash-only(relabel) design
    • Needs compacting from time to time
    • Views: embedded map/reduce
    • Formatting views : lists&shows
    • Server-side document validation possible
    • Authentication possible
    • Real-time updates via_changes
    • Attachement handling
    • thus CouchAps(standalone js apps)
    • jQuery library included
  • 주요 사용처
    • 누적, 일시적 데이터 변화, 미리 정의된 쿼리가 사용될 때, versioning이 중요한 곳
    • For accumulating, occasionally changing data, on which pre-defined queries are to be run. Places where versioning is important.
  • 사용예
    • CRM, CMS systems. Master-master replication is an especially interesting feature, allowing easy multi-site deployments.

HBase

  • 구현 : 자바
  • 주요특징 : 수십억 row  x  수백만 column
  • 라이센스 :  Apache
  • 프로토콜 : HTTP/REST(also Thrift)
  • 상세특징
    • Modeled after Google's BigTable
    • Uses Hadoop's HDFS as storage
    • Map/reduse with hadoop
    • Query predicate push down via server side scan and get filters
    • Optimizations for real time queries
    • A high performance Thrift gateway
    • HTTP supports XML, Protobuf, and binary
    • Cascading, hive, and pig source and sink modules
    • Jruby-based (JIRB) shell
    • Rolling restart for configuration changes and minor upgrades
    • Random access performance is like MySQL
    • A cluster consists of several different types of nodes
  • 주요사용처
    • Hadoop is probably still the best way to run Map/Reduce jobs on huge datasets. Best if you use the Hadoop/HDFS stack already.
  • 사용예
    •  Analysing log data

Cassandra

  • 구현 : 자바
  • 주요특징 : Best of BigTable and Dynamo
  • 라이센스 : Apache
  • 프로토콜 : Custom, binary(Thrift)
  • 상세특징
    • Tunable trade-offs for distribution and replication (N, R, W)
    • Querying by column, range of keys
    • BigTable-like features: columns, column families
    • Has secondary indices
    • Writes are much faster than reads
    • Map/reduce possible with Apache Hadoop
    • All nodes are similar, as opposed to Hadoop/HBase
  • 주요사용처
    • When you write more than you read (logging). If every component of the system must be in Java. ("No one gets fired for choosing Apache's stuff.")
  • 사용예
    • Banking, financial industry (though not necessarily for financial transactions, but these industries are much bigger than that.) 
    • Writes are faster than reads, so one natural niche is real time data analysis

라벨:

댓글

댓글 쓰기

이 블로그의 인기 게시물

AWS ELB 504 Error

AWS EC2  운영 중 가끔씩 볼 수 있는 에러가 있습니다. 대표적으로 다음의 세가지 502, 503, 504 입니다. 이 중에서 이번에 알아볼 문제는 HTTP 504 에러입니다 .  타임 아웃이 되어   Request 를 처리하지 못하는 상황이 됩니다 .   해결 방법부터 이야기 하자면 다음과 같이 웹서버의 Time-out 시간을 60 초 이상으로 늘리는 것입니다 . Web Server & Application Time-out >= 60 sec 그 이유는 다음과 같은 ELB의 특성 때문입니다. ELB는 클라이언트와 EC2 서버 양쪽으로 커넥션을 유지하고 있습니다. ELB는 클라이언트와  EC2 서버간의 커넥션을 관리하는 역할을 맡고 있습니다. 그래서 유효한 커넥션만을 남겨놓습니다. 이를 위해서 Time-out 시간을 가지고 이 시간동안 데이터가 송수신되지 않으면 연결을 끊습니다.  기본적으로 Elastic Load Balancing는 두 연결 모두에 대해 Time-out(유휴 시간) 시간을 60초로 되어 있습니다. 그렇기 때문에 HTTP 또는 HTTPS를 사용할 경우 "KeppAlive" 옵션을 사용하여 커넥션을 재활용해야 합니다. 이 때  ELB 커넥션도 재사용되기 때문에 CPU 사용률을 줄일 수 있습니다. Browser Time-out Opera 11.11 120 sec IE 9 60 sec Chrome 13 300 sec FireFox 4 115 sec 서버 로직 중에서 60초 이상 실행될 수 있는 부분이 있는 경우 504 에러를 자주 볼 수 있을 것입니다. 문제 해결을 위해서는 Web Server는 물론  Tomcat 설정 또한 60초 이상으로 변경해주어야 합니다. ...
댓글 쓰기
자세한 내용 보기

Spring Data Projection 기능 활용

Projection Spring Data REST에서는 Projection 기능을 제공하고 있습니다. Spring Data란?   Data Access Layer에 대한 추상화 기능을 제공하는 프레임워크입니다. 간단히 설명하자면 기존에는 Database에 데이터를 저장하고 읽어오기 위해서는 Database의 종류, 스키마를 고려하여 SQL Query를 사용해서 데이터를 저장하고 읽어왔습니다. 그러나 Spring Data를 이용하게 되면 이 과정을 ORM을 사용하여 함수를 사용하여 쉽게 처리할 수 있습니다. ORM(Object Relational Mapping)란?   데이터베이스가 테이블, 필드간 상관 관계를 통해 도메인 데이터를 표현하였다고 한다면,  ORM은 Object, 클래스 간의 상관 관계를 통해 도메인 데이터를 표현하는 것을 말합니다. 다음의 링크는 Spring Data REST Documentation 중에서 Projection 부분입니다.               8. Projections and Excerpts 그러나 실제 "Projection" 기능을 사용하는데는 한가지 문제점이 있습니다. 레거시 웹서비스를 쓰고 있다거나, Spring Data  REST를 이용하지 않는다면 "Projection" 기능을 활용하는 것이 힘들다는 것입니다. Spring Data REST의 경우 데이터  Response Type이 json-hal 타입만을 지원하기 때문입니다. JSON-HAL 타입으로 경우 웹서비스 제공 입장에서 최선의 선택일 수 있습니다. 그러나 실제 프로젝트에서는 이를 쓰려는 클라이언트가 없을 경우 사용할 수 없게 될 것입니다. 그렇다면 Projection 기능만을 사용할 수 있는 방법이 없을까요? 있습니다. ProjectionFactory 를 직접 사용하는 것입니다. 다음과 같이 Spr...
댓글 쓰기
자세한 내용 보기

BicData maturity model(성숙모델)

성숙모델은 2011년 마르쿠스 스프렌저가 정의한 모델로 3년간 2천개 조직을 대상으로 인터뷰와 업무를 통해 도출됐다. ■1단계 사용할 만한 데이터가 없는 단계 1단계는 성숙모델의 이론적 토대이자 출발점이다. 이 상황의 기업은 어떤 사용가능한 데이터도 갖고 있지 않다. 이 단계에서 조직은 통계를 운영할 수 없다. 그리고 확실히 이해도 않으며, 정보화 거버넌스와 이디스커버리 수요에 대해 넘겨 짚을 뿐이다. 사업을 개선해줄 정보에 기반한 인사이트도 없다. 조직은 밖에 조언을 구하고, 서비스프로바이더가 정보화 요구를 충족하기 위해 많은 돈을 사용하게 한다며 경멸한다. ■2단계 빅데이터 조직은 이 단계에서 빅데이터를 수용하기 위한 첫발을 뗀다. 그들은 꾸준히 내부와 외부의 소스로부터 데이터를 모은다. 그러나 이 데이터를 가치있는 정보로 바꿀 도구는 갖고 있지 않다. 단순히 데이터만 모아둘 뿐이다. 직원들은 분석보다 정보를 찾는데 더 많은 시간을 들인다. 많은 경우에 직원들은 데이터의 홍수 속에 포기해버린다. 그들의 결정은 정보가 거의 없이 이뤄진다. 그들의 회사는 결코 그들의 정보를 전략적인 정보, 경쟁력있는 자산으로 바꿀 기회를 얻지 못한다. 일부 회사들은 내부 데이터 인프라스트럭처를 창조하고 싶어한다. 이들의 첫 단계는 내외부에서 수집된 데이터 소스에 그들과 관련된 아이덴티티를 부여하는 것이다. 그들은 순위를 정해 데이터를 캡처하는 메커니즘을 만들어간다. 이를 통해 그들은 초보적인 분석을 할 수 있는 데이터 구조를 세우며, 이 지점에서 성숙의 단계를 밟아갈 기초를 닦는다. 이런 조직은 회랑에서 걸어내려와 전례없는 움직임을 고려해야 할 필요가 있다. 그들은 빅데이터 분석 데이블에 법률, 정보화 거버넌스 이해관계자를 초대할 필요가 있다. 이는 빅데이터 분석과 정보화 거버넌스, 이디스커버리 등의 통합을 시작하는 중요한 절차다. ■3단계 적합한 데이터 세번째 모습은 양질의 데이터를 사용하는 조직이다. 이들은 문맥과 관련성을 그들의 데이터...
댓글 쓰기
자세한 내용 보기