기본 콘텐츠로 건너뛰기

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초 이상으로 변경해주어야 합니다. ...
댓글 쓰기
자세한 내용 보기

Cron expression

초 0-59 , - * / 분 0-59 , - * / 시 0-23 , - * / 일 1-31 , - * ? / L W 월 1-12 or JAN-DEC , - * / 요일 1-7 or SUN-SAT , - * ? / L # 년(옵션) 1970-2099 , - * / * 모든 값 ? 특정 값 없음 - 범위 지정에 사용 , 여러 값 지정 구분에 사용 / 초기값과 증가치 설정에 사용 L 지정할 수 있는 범위의 마지막 값 W 월~금요일 또는 가장 가까운 월/금요일 # 몇 번째 무슨 요일 2#1 => 첫 번째 월요일 예제) Expression Meaning 초분시일월주(년) "0 0 12 * * ?" 아무 요일, 매월, 매일 12:00:00 "0 15 10 ? * *" 모든 요일, 매월, 아무 날이나 10:15:00 "0 15 10 * * ?" 아무 요일, 매월, 매일 10:15:00 "0 15 10 * * ? *" 모든 연도, 아무 요일, 매월, 매일 10:15 "0 15 10 * * ? 2005" 2005년 아무 요일이나 매월, 매일 10:15 "0 * 14 * * ?" 아무 요일, 매월, 매일, 14시 매분 0초 "0 0/5 14 * * ?" 아무 요일, 매월, 매일, 14시 매 5분마다 0초 "0 0/5 14,18 * * ?" 아무 요일, 매월, 매일, 14시, 18시 매 5분마다 0초 "0 0-5 14 * * ?" 아무 요일, 매월, 매일, 14:00 부터 매 14:05까지 매 분 0초 "0 10,44 14 ? 3 WED" 3월의 매 주 수요일, 아무 날짜나 14:10:00, 14:44:00 "0 15 10 ? * MON-FRI" 월~금, 매월, 아무 날이나 10:15:00 "0 15 10 15 * ?...
댓글 쓰기
자세한 내용 보기