Visual Guide to NoSQL Systems | Beany http://blog.beany.co.
kr/archives/275
개발 그리고 공유..
Home Cloud DataBase OS Programming Server Tools
GuestBook
1 of 9 11-04-2014 12:11
Visual Guide to NoSQL Systems | Beany http://blog.beany.co.kr/archives/275
21 Visual Guide to NoSQL Systems
03 2011
SANG HUN LEE | 참고자료 | 6
자료 출처 : http://blog.nahurst.com/visual-guide-to-nosql-systems
번역 : http://blog.outsider.ne.kr/519
Visual Guide to NoSQL Systems
There are so many NoSQL systems these days that it’s hard to get a
quick overview of the major trade-offs involved when evaluating
relational and non-relational systems in non-single-server environments.
I’ve developed this visual primer with quite a lot of help (see credits at
the end), and it’s still a work in progress, so let me know if you see
anything misplaced or missing, and I’ll fix it.
Without further ado, here’s what you came here for (and further
explanation after the visual).
Note: RDBMSs (MySQL, Postgres, etc) are only featured here for
comparison purposes. Also, some of these systems can vary their
features by configuration (I use the default configuration here, but will
try to delve into others later).
As you can see, there are three primary concerns you must balance
when choosing a data management system: consistency, availability, and
partition tolerance.
Consistency means that each client always has the same view of
the data.
2 of 9 11-04-2014 12:11
Visual Guide to NoSQL Systems | Beany http://blog.beany.co.kr/archives/275
Availability means that all clients can always read and write.
Partition tolerance means that the system works well across
physical network partitions.
»
According to the CAP Theorem, you can only pick two. So how does
«
this all relate to NoSQL systems?
One of the primary goals of NoSQL systems is to bolster horizontal
scalability. To scale horizontally, you need strong network partition
tolerance which requires giving up either consistency or availability.
NoSQL systems typically accomplish this by relaxing relational abilities
and/or loosening transactional semantics.
In addition to CAP configurations, another significant way data
management systems vary is by the data model they use: relational,
key-value, column-oriented, or document-oriented (there are others, but
these are the main ones).
Relational systems are the databases we’ve been using for a while
now. RDBMSs and systems that support ACIDity and joins are
considered relational.
Key-value systems basically support get, put, and delete
operations based on a primary key.
Column-oriented systems still use tables but have no joins ( joins
must be handled within your application). Obviously, they store
data by column as opposed to traditional row-oriented databases.
This makes aggregations much easier.
Document-oriented systems store structured “documents” such
as JSON or XML but have no joins ( joins must be handled within
your application). It’s very easy to map data from object-oriented
software to these systems.
Now for the particulars of each CAP configuration and the systems that
use each configuration:
Consistent, Available (CA) Systems have trouble with partitions and
typically deal with it with replication. Examples of CA systems include:
Traditional RDBMSs like Postgres, MySQL, etc (relational)
Vertica (column-oriented)
Aster Data (relational)
Greenplum (relational)
Consistent, Partition-Tolerant (CP) Systems have trouble with
availability while keeping data consistent across partitioned nodes.
Examples of CP systems include:
BigTable (column-oriented/tabular)
Hypertable (column-oriented/tabular)
3 of 9 11-04-2014 12:11
Visual Guide to NoSQL Systems | Beany http://blog.beany.co.kr/archives/275
HBase (column-oriented/tabular)
MongoDB (document-oriented)
Terrastore (document-oriented)
Redis (key-value)
Scalaris (key-value)
MemcacheDB (key-value)
Berkeley DB (key-value)
Available, Partition-Tolerant (AP) Systems achieve “eventual
consistency” through replication and verification. Examples of AP
systems include:
Dynamo (key-value)
Voldemort (key-value)
Tokyo Cabinet (key-value)
KAI (key-value)
Cassandra (column-oriented/tabular)
CouchDB (document-oriented)
SimpleDB (document-oriented)
Riak (document-oriented)
Self promotion and Credits
If you’re a developer and looking for a job or if you’re hiring
developers and these data systems are important to you, consider
coming to Hirelite: Speed Dating for the Hiring Process on
Tuesday.
This guide draws heavily from a recent Ruby meetup (by Matthew
Jording and Michael Bryzek) and a recent MongoDB presentation
(given by Dwight Merriman).
Thanks to DBNess and ansonism for their help with validating
system categorizations.
Thanks to those who helped shape the post after it was written:
Stan, Dwight, and others who commented here and on this
Hacker News thread.
Update: Here’s a print version of the Visual Guide To NoSQL Systems if
you need one quickly (warning: it’s not all that pretty and I may not
keep it updated, but as of 3/17/2010, it’s current).
Like 3 트윗 4 Share
Share
cap, nosql
StumbleUpon
CENTOS 에서 SVN, APACHE 연동 설치
LINUX 디스크 디렉토리 파일 용량 사이즈 확인
4 of 9 11-04-2014 12:11
Visual Guide to NoSQL Systems | Beany http://blog.beany.co.kr/archives/275
6 thoughts on “Visual Guide to NoSQL Systems”
Adriana가 말하길
2012-02-25 6:49 오후
thanks for share!
응답
Interview Question: Compare relational (RDBMS) and noSQL
databases | My Experiments with Technology가 말하길
2012-07-24 12:29 오후
[...] Brewer stated that a distributed computer system cannot
simultaneously provide three attributes namely consistency,
availability and partition tolerance. According to him, a system
can provide at the most two of the three attributes. RDBMSs are
CA systems while noSQL databases can be either CP or AP
systems. Example of CP systems are Google BigTable, MongoDB,
Hbase. Example of AP systems are Amazon Dynamo, SimpleDB,
CouchDB. For more details visit this excellent reference. [...]
응답
Jimmy가 말하길
2012-08-28 3:29 오전
Great article!
Couple thoughts….
(1) RIAK is key-pair value store, yes it has some properties like
secondary indexes, but still it is not true document store, its
perhaps closer to object store http://wiki.basho.com
/Concepts.html
(2) I would include Graph Databases and perhaps Object
databases to keep the list complete
응답
Pablo가 말하길
2013-04-21 7:58 오전
To me, Redis is AP (instead of CP), due to its replication is
asynchronous between master and slaves.
5 of 9 11-04-2014 12:11
Visual Guide to NoSQL Systems | Beany http://blog.beany.co.kr/archives/275
응답
Introduction to NoSQL Databases | Matthew Stokeley가 말하길
2013-06-16 10:09 오전
[...] I’ve focused my attention on Document Stores like MongoDB
and CouchDB. A quick look at the handy visual guide to the CAP
Theorem (which also highlights the different data models) shows
where MongoDB and CouchDB separate – [...]
응답
21 NoSQL Innovators to Look for in 2020 | Parity Research가 말하
길
2013-11-18 12:26 오후
[…] another view, courtesy of Beany Blog, describes the database
space as […]
응답
댓글 남기기
이메일은 공개되지 않습니다. 필수 입력창은 로 표시되어 있습니
다.
이름
이메일
웹사이트
CAPTCHA Code
댓글
다음의 HTML 태그와 속성을 사용할 수 있습니다: <a href=""
title=""> <abbr title=""> <acronym title=""> <b>
6 of 9 11-04-2014 12:11
Visual Guide to NoSQL Systems | Beany http://blog.beany.co.kr/archives/275
<blockquote cite=""> <cite> <code class="" title=""
data-url=""> <del datetime=""> <em> <i> <q cite="">
<strike> <strong> <pre class="" title="" data-url="">
<span class="" title="" data-url="">
댓글 알림 이메
일 받기
새 글 알림 이메
일 받기
주인장
이상훈
(imfjbh@gmail.com)
Categories
open all | close all
Cloud (19)
DataBase (37)
Programming (34)
Server (32)
OS (33)
Tools (39)
7 of 9 11-04-2014 12:11
Visual Guide to NoSQL Systems | Beany http://blog.beany.co.kr/archives/275
Calendar
4월 2014
월 화 수 목 금 토
1 2 3 4 5
7 8 9 10 11 12
14 15 16 17 18 19
21 22 23 24 25 26
28 29 30
« Mar
최근 글
8 of 9 11-04-2014 12:11
Visual Guide to NoSQL Systems | Beany http://blog.beany.co.kr/archives/275
OpenLDAP 사용자 정
보 변경시 오류 :
Insufficient access
OpenLDAP Log 활성
화 및 Log Level 변경
하기
OpenLDAP 명령어 참
고
OpenLDAP RootDN
Password 변경
Redmine 2.4.2 Log
Level 설정
9 of 9 11-04-2014 12:11
