데이터베이스 유형별 실제 사례 (실제 사례)

데이터베이스 유형별 실제 사례 (실제 사례)

---

다른 목적을위한 여러 유형의 데이터베이스가 있지만 일반적으로 MySQL은 가장 잘 알려진 데이터베이스이기 때문에 모든 것에 사용됩니다. 우리 회사에서 빅 데이터 애플리케이션의 초기 단계에 MySQL 데이터베이스가있는 예를 들어 보자면, 믿을 수없고 회사에 심각한 결과를 가져올 것입니다. 왜 MySQL인가? 아무도 다른 DBMS를 사용해야하는 방법과시기를 알지 못하기 때문입니다.

그래서 제 질문은 공급 업체가 아니라 데이터베이스 유형에 관한 것입니다. 사용을 적극 권장하는 각 유형의 데이터베이스에 대한 특정 상황 (또는 앱)의 실제 예를 제공 할 수 있습니까?

예:

• 소셜 네트워크는 Y 때문에 유형 X를 사용해야합니다.

• MongoDB 또는 couch DB는 거래를 지원할 수 없으므로 Document DB는 은행 또는 경매 사이트의 앱에 적합하지 않습니다.

등등...

---

관계형 : MySQL , PostgreSQL , SQLite , Firebird , MariaDB , Oracle DB , SQL 서버 , IBM DB2 , IBM Informix , Teradata

개체 : ZODB , DB4O , Eloquera , Versant , Objectivity DB , VelocityDB

그래프 데이터베이스 : AllegroGraph , Neo4j , OrientDB , InfiniteGraph , graphbase , sparkledb , flockdb , BrightstarDB

주요 가치 저장소 : Amazon DynamoDB , Redis , Riak , Voldemort , FoundationDB , leveldb , BangDB , KAI , hamsterdb , Tarantool , Maxtable , HyperDex , Genomu , Memcachedb

컬럼 패밀리 : Big table , Hbase , hyper table , Cassandra , Apache Accumulo

RDF 상점 : Apache Jena , Sesame

다중 모델 데이터베이스 : arangodb , Datomic , Orient DB , FatDB , AlchemyDB

문서 : Mongo DB , Couch DB , Rethink DB , Raven DB , terrastore , Jas DB , Raptor DB , djon DB , EJDB , denso DB , Couchbase

XML 데이터베이스 : BaseX , 세드나 , 존재

계층 구조 : InterSystems Caché , @Laurent Parenteau 덕분에 GT.M

---

이 주제에 대한 두 가지 인상적인 기사를 찾았습니다. highscalability.com에 대한 모든 크레딧 . 이 답변의 정보는 다음 기사에서 복사되었습니다.

다음 NoSQL 데이터베이스 선택을위한 35 개 이상의 사용 사례

도대체 NoSQL을 실제로 사용하는 이유는 무엇입니까?

---

애플리케이션에 필요한 경우 ...

• 복잡한 트랜잭션 은 데이터 손실을 감당할 수 없기 때문에 또는 간단한 트랜잭션 프로그래밍 모델을 원할 경우 관계형 또는 그리드 데이터베이스를 살펴 봅니다.

• 예 : 전체 ACID를 원하는 인벤토리 시스템 . 나는 내가 제품을 샀을 때 매우 불행했고 그들은 나중에 재고가 없다고 말했습니다. 보상 거래를 원하지 않았습니다. 나는 내 아이템을 원했다!

• 확장 하면 NoSQL 또는 SQL이 작동 할 수 있습니다. 확장, 파티셔닝, 머신의 실시간 추가 및 제거,로드 밸런싱, 자동 분할 및 재조정, 내결함성을 지원하는 시스템을 찾으십시오.

• 고 가용성이 필요하기 때문에 항상 데이터베이스 에 쓸 수 있도록하고 최종 일관성을 제공하는 Bigtable Clones 를 살펴 봅니다 .

• 휘발성 일 수있는 소규모 연속 읽기 및 쓰기를 많이 처리 한 다음 빠른 메모리 내 액세스를 제공하는 문서 또는 키-값 또는 데이터베이스를 살펴 봅니다. 또한 SSD를 고려하십시오 .

• 소셜 네트워크 운영 을 구현 하려면 먼저 그래프 데이터베이스를 원하거나 두 번째로 관계를 지원하는 Riak 과 같은 데이터베이스를 원할 수 있습니다 . 간단한 SQL 조인이있는 인 메모리 관계형 데이터베이스는 작은 데이터 세트에 충분할 수 있습니다. Redis 'set 및 list 작업도 작동 할 수 있습니다.

• 다양한 액세스 패턴 및 데이터 유형에 대해 작동 한 다음 문서 데이터베이스를 살펴 보려면 일반적으로 유연하고 성능이 좋습니다.

• 대규모 데이터 세트가 포함 된 강력한 오프라인보고 후 Hadoop을 먼저 살펴 보고 MapReduce 를 지원하는 제품 을 살펴 봅니다 . MapReduce를 지원하는 것은 잘하는 것과 다릅니다.

• 여러 데이터 센터 에 걸쳐있는 경우 Bigtable Clones 및 긴 지연 시간을 처리 할 수 ​​있고 파티션 허용 기능 을 제공하는 분산 옵션을 제공하는 기타 제품 을 살펴 봅니다 .

• CRUD 앱 을 구축 한 다음 문서 데이터베이스를 살펴보면 조인없이 복잡한 데이터에 쉽게 액세스 할 수 있습니다.

• 내장 검색 후 Riak 을 살펴 봅니다 .

• 목록, 집합, 대기열, 게시-구독과 같은 데이터 구조 에서 작동하려면 Redis 를 살펴 봅니다 . 분산 잠금, 제한 로그 등에 유용합니다.

• JSON, HTTP, REST, Javascript와 같은 프로그래머 친화적 인 데이터 유형의 형태로 프로그래머 친 화성 . 그런 다음 먼저 문서 데이터베이스를 살펴본 다음 키-값 데이터베이스를 살펴 봅니다.

• 실시간 데이터 피드를 위해 구체화 된 뷰 와 결합 된 트랜잭션 은 VoltDB 를 봅니다 . 데이터 롤업 및 시간 창에 적합 합니다.

• 엔터프라이즈 수준의 지원 및 SLA 는 해당 시장에 적합한 제품을 찾습니다. Membase 가 그 예입니다.

• 일관성 보장이 전혀 필요하지 않을 수있는 연속적인 데이터 스트림 을 기록하려면 일반적으로 많은 쓰기를 처리 할 수있는 분산 파일 시스템에서 작동하므로 Bigtable Clones 를 살펴보십시오 .

• 가능한 한 간단하게 운영하고 호스팅 또는 PaaS 솔루션을 찾으십시오. 모든 작업을 수행 할 것입니다.

• 기업 고객에게 판매 될 경우 관계형 기술에 사용되기 때문에 관계형 데이터베이스를 고려합니다.

• 동적 속성 이있는 개체 간의 관계 를 동적으로 구축 하려면 그래프 데이터베이스를 고려합니다. 종종 스키마가 필요하지 않고 프로그래밍을 통해 모델을 점진적으로 구축 할 수 있기 때문입니다.

• 대용량 미디어 를 지원하려면 S3 와 같은 스토리지 서비스를 찾습니다 . MongoDB 에는 파일 서비스가 있지만 NoSQL 시스템은 큰 BLOBS 를 처리하지 않는 경향이 있습니다.

• 대량 의 데이터를 빠르고 효율적 으로 대량 업로드 한 다음 해당 시나리오를 지원하는 제품을 찾습니다. 대부분은 대량 작업을 지원하지 않기 때문에 그렇지 않습니다.

• 더 쉬운 업그레이드 경로 는 전체 스키마 마이그레이션 프레임 워크를 구축 할 필요없이 선택적 필드, 필드 추가 및 필드 삭제를 지원하므로 문서 데이터베이스 또는 키-값 데이터베이스와 같은 유동 스키마 시스템을 사용합니다.

• 무결성 제약 조건 을 구현하려면 SQL DDL 을 지원하는 데이터베이스를 선택 하거나 저장 프로 시저에서 구현하거나 애플리케이션 코드에서 구현합니다.

• 매우 깊은 조인 깊이 는 엔티티 간 빠른 탐색을 지원하기 때문에 그래프 데이터베이스를 사용합니다.

• 동작을 데이터에 가깝게 이동 하여 데이터가 네트워크를 통해 이동할 필요가 없도록 한 다음 한 종류 또는 다른 종류의 저장 프로 시저를 살펴 봅니다. 관계형, 그리드, 문서 및 키-값 데이터베이스에서도 찾을 수 있습니다.

• BLOB 데이터 를 캐시하거나 저장 한 다음 키-값 저장소를 확인합니다. 캐싱은 웹 페이지의 일부를 처리하거나 관계형 데이터베이스에 결합하는 데 비용이 많이 드는 복잡한 개체를 저장하고 대기 시간을 줄이는 등의 작업을 수행 할 수 있습니다.

• 데이터를 손상시키지 않고 일반적으로 작동하는 것과 같은 입증 된 실적 은 확립 된 제품을 선택하고 스케일링 (또는 기타 문제)에 도달하면 일반적인 해결 방법 (스케일 업, 튜닝, memcached, 샤딩 , 비정규 화 등) 중 하나를 사용 합니다.

• 데이터가 본질적으로 표 형식이 아니거나 유연한 수의 열이 필요하거나 복잡한 구조를 가지고 있거나 사용자 (또는 무엇이든)에 따라 다르기 때문에 유동적 인 데이터 유형을 선택한 다음 문서, 키-값 및 Bigtable 클론 데이터베이스 를 살펴 봅니다. . 각각의 데이터 유형에는 많은 유연성이 있습니다.

• 다른 사업부 에서 빠른 관계형 쿼리 를 실행 하므로 모든 것을 다시 구현 한 다음 SQL을 지원하는 데이터베이스를 사용할 필요가 없습니다.

• 클라우드에서 작동하고 클라우드 기능을 자동으로 최대한 활용하려면 아직 존재하지 않을 수 있습니다.

• 보조 인덱스를 지원 하므로 다른 키로 데이터를 조회 한 다음 관계형 데이터베이스와 Cassandra 의 새로운 보조 인덱스 지원을 볼 수 있습니다.

• 거의 액세스되지 않는 계속 증가하는 데이터 세트 (실제로 BigData )를 생성 한 다음 분산 파일 시스템에 데이터를 분산시킬 Bigtable Clone 을 살펴보십시오 .

• 다른 서비스와 통합 하려면 데이터베이스가 일종의 write-behind 동기화 기능을 제공하는지 확인하여 데이터베이스 변경 사항을 캡처하고 일관성을 보장하기 위해 다른 시스템에 공급할 수 있습니다.

• 내결함성 검사는 정전, 파티션 및 기타 오류 시나리오에 직면 한 쓰기 내구성을 확인합니다.

• 아무도 가지 않을 것 같은 방향으로 기술적 한계를 밀어 붙인 다음 스스로 구축하는 것입니다.

• 모바일 플랫폼 에서 작업하려면 CouchDB / Mobile couchbase 를 살펴 보십시오 .

---

일반 사용 사례 (NoSQL)

• 거대 함 . NoSQL은 빅 데이터, 많은 수의 사용자, 많은 수의 컴퓨터, 큰 공급망, 큰 과학 등을 지원하는 새로운 데이터 스택의 핵심 부분으로 간주됩니다. 무언가가 너무 방대 해져서 대량으로 분산되어야 할 때, 모든 NoSQL 시스템이 큰 것을 목표로하는 것은 아니지만 NoSQL이 있습니다. 크기는 많은 디스크 공간을 사용하는 것이 아니라 다양한 차원에 걸쳐있을 수 있습니다.

• 대규모 쓰기 성능. 이것은 아마도 구글의 영향을 기반으로 한 정식 사용 일 것입니다. 높은 음량. Facebook은 한 달에 1,350 억 개의 메시지 를 저장해야합니다 ^{(2010 년)} . 예를 들어 Twitter ^{는 2010 년에} 하루에 7TB / 데이터 를 저장하는 문제를 안고 있으며, 이 요구 사항은 매년 두 배로 늘어날 전망입니다. 이것은 데이터가 너무 커서 한 노드 문제에 맞지 않습니다. 80MB / s에서 7TB를 저장하는 데 하루가 걸리므로 쓰기를 클러스터에 분산해야합니다. 이는 키-값 액세스, MapReduce, 복제, 내결함성, 일관성 문제 및 나머지 모든 것을 의미합니다. 더 빠른 쓰기를 위해 메모리 내 시스템을 사용할 수 있습니다.

• 빠른 키-값 액세스. 이것은 아마도 일반적인 사고 방식에서 두 번째로 많이 인용 된 NoSQL의 장점입니다. 대기 시간이 중요한 경우 키에 대한 해싱을 이기고 메모리에서 직접 값을 읽거나 디스크 검색 한 번으로 값을 읽는 것이 어렵습니다. 예를 들어 모든 NoSQL 제품이 빠른 액세스에 관한 것은 아니며 일부는 안정성에 관한 것입니다. 그러나 사람들이 오랫동안 원했던 것은 더 나은 memcached 였고 많은 NoSQL 시스템이이를 제공합니다.

• 유연한 스키마 및 유연한 데이터 유형. NoSQL 제품은 모든 범위의 새로운 데이터 유형을 지원하며 이는 NoSQL의 주요 혁신 영역입니다. 열 지향, 그래프, 고급 데이터 구조, 문서 지향 및 키-값이 있습니다. 복잡한 개체는 많은 매핑없이 쉽게 저장할 수 있습니다. 개발자는 복잡한 스키마와 ORM 프레임 워크를 피하는 것을 좋아 합니다. 구조가 부족하면 훨씬 더 많은 유연성을 얻을 수 있습니다. 또한 JSON과 같은 프로그램 및 프로그래머 친화적 인 호환 데이터 유형이 있습니다.

• 스키마 마이그레이션. 스키마리스는 큰 걱정없이 스키마 마이그레이션을 쉽게 처리 할 수 ​​있도록합니다. 스키마는 런타임에 애플리케이션에 의해 부과되기 때문에 어떤 의미에서는 동적이므로 애플리케이션의 다른 부분은 스키마의 다른보기를 가질 수 있습니다.

• 쓰기 가용성. 당신의 글은 무슨 일이 있어도 성공해야합니까? 그런 다음 파티셔닝, CAP , 최종 일관성 및 모든 재즈에 들어갈 수 있습니다 .

• 보다 쉬운 유지 관리, 관리 및 운영. 이것은 매우 제품에 따라 다르지만 많은 NoSQL 공급 업체는 개발자가 쉽게 채택 할 수 있도록하여 채택을 확보하려고합니다. 그들은 사용의 용이성, 최소한의 관리 및 자동화 된 운영에 많은 노력을 기울이고 있습니다. 이렇게 사용하도록 의도 된 적이없는 시스템을 확장하기 위해 특수 코드를 작성할 필요가 없기 때문에 운영 비용이 절감 될 수 있습니다.

• 단일 장애 지점이 없습니다. 모든 제품이이를 제공하는 것은 아니지만 자동로드 밸런싱 및 클러스터 크기 조정을 통해 비교적 쉽게 구성하고 관리 할 수있는 고 가용성에 대한 확실한 수렴을보고 있습니다. 완벽한 클라우드 파트너.

• 일반적으로 사용 가능한 병렬 컴퓨팅. 우리는 MapReduce가 제품에 구워 져 향후 개발의 정상적인 부분이 될 병렬 컴퓨팅을 만드는 것을보고 있습니다.

• 프로그래머의 사용 용이성. 데이터 액세스는 쉬워야합니다. 관계형 모델은 회계사처럼 최종 사용자에게는 직관적이지만 개발자에게는 그다지 직관적이지 않습니다. 프로그래머는 키, 값, JSON, Javascript 저장 프로 시저, HTTP 등을 검색합니다. NoSQL은 프로그래머를위한 것입니다. 이것은 개발자 주도의 쿠데타입니다. 데이터베이스 문제에 대한 응답은 항상 정말 지식이 풍부한 DBA 를 고용하고 , 스키마를 올바르게 설정하고, 약간 비정규 화하는 등의 일 이 아닙니다 . 프로그래머는 스스로 작업 할 수있는 시스템을 선호 할 것입니다. 제품이 성능을 발휘하도록 만드는 것이 그렇게 어렵지 않아야합니다. 돈이 문제의 일부입니다. 제품을 확장하는 데 많은 비용이 든다면 더 저렴한 제품을 사용하지 않겠습니까? 제어하고 사용하기 쉽고 확장하기도 더 쉽습니다.

• 올바른 문제에 적합한 데이터 모델을 사용합니다. 다른 문제를 해결하기 위해 다른 데이터 모델이 사용됩니다. 예를 들어, 그래프 작업을 관계형 모델에 결합하는 데 많은 노력을 기울 였지만 작동하지 않습니다. 그래프 데이터베이스에서 그래프 문제를 해결하는 것이 더 낫지 않습니까? 우리는 이제 문제와 해결책 사이에 가장 적합한 것을 찾는 일반적인 전략을보고 있습니다.

• 벽을 치지 마십시오. 많은 프로젝트가 프로젝트에서 어떤 유형의 벽에 부딪 혔습니다. 시스템을 확장하거나 제대로 수행하기 위해 모든 옵션을 다 사용했으며 다음은 무엇일까요? 점진적으로 추가 된 리소스를 사용하여 선형 적으로 확장하여 벽을 뛰어 넘을 수있는 제품과 접근 방식을 선택하는 것은 편안합니다. 한때 이것은 불가능했습니다. 모든 것을 맞춤형으로 제작했지만 변경되었습니다. 우리는 이제 프로젝트에서 쉽게 채택 할 수있는 사용 가능한 기본 제품을보고 있습니다.

• 분산 시스템 지원. 모든 사람이 비 NoSQL 시스템에서 달성 할 수있는 것 이상의 확장 또는 성능에 대해 걱정하는 것은 아닙니다. 그들이 필요로하는 것은 딸꾹질없이 장애 시나리오를 처리하면서 데이터 센터를 확장 할 수있는 분산 시스템입니다. NoSQL 시스템은 규모에 초점을 맞추고 파티션을 악용하는 경향이 있고 엄격한 일관성 프로토콜을 사용하지 않는 경향이 있으므로 분산 시나리오에서 작동하기에 적합합니다.

• 조정 가능한 CAP 절충 . NoSQL 시스템은 일반적으로 CAP 스펙트럼에서 원하는 위치를 선택할 수있는 "슬라이더"가있는 유일한 제품입니다. 관계형 데이터베이스는 강력한 일관성을 선택하므로 파티션 실패를 용인 할 수 없습니다. 결국 이것은 비즈니스 결정이며 사례별로 결정되어야합니다. 앱이 일관성에 관심이 있습니까? 몇 방울도 괜찮습니까? 앱에 강력하거나 약한 일관성이 필요합니까? 가용성이 더 중요합니까 아니면 일관성이 있습니까? 다운되는 것이 잘못된 것보다 더 많은 비용이 듭니까? 당신에게 선택권을주는 제품이 있다는 것은 좋은 일입니다.

• 보다 구체적인 사용 사례

• 트랜잭션이 아닌 데이터의 대규모 스트림 관리 : Apache 로그, 애플리케이션 로그, MySQL 로그, 클릭 스트림 등

• 온라인 및 오프라인 데이터 동기화. 이것은 CouchDB 가 목표로 삼은 틈새 시장 입니다.

• 모든 부하에서 빠른 응답 시간.

• 복잡한 조인에 대한 쿼리로드가 RDBMS에 비해 너무 커질 때 과도한 조인을 피합니다 .

• 짧은 대기 시간이 중요한 소프트 실시간 시스템. 게임이 한 예입니다.

• 다양한 쓰기, 읽기, 쿼리 및 일관성 패턴을 지원해야하는 애플리케이션. 50 % 읽기 50 % 쓰기, 95 % 쓰기 또는 95 % 읽기에 최적화 된 시스템이 있습니다. 빠른 속도와 복원력, 간단한 쿼리가 필요한 읽기 전용 애플리케이션은 약간 오래된 데이터를 허용 할 수 있습니다. 적당한 성능, 읽기 / 쓰기 액세스, 간단한 쿼리, 완전히 신뢰할 수있는 데이터가 필요한 애플리케이션. 복잡한 쿼리 요구 사항이있는 읽기 전용 응용 프로그램입니다.

• 데이터 및 사용량 집중을 수용하고 마이크로 프로세서를 계속 바쁘게 유지하기위한 부하 분산.

• 실시간 삽입, 업데이트 및 쿼리.

• 스레드 토론 및 부품 폭발과 같은 계층 적 데이터.

• 동적 테이블 생성.

• 빠른 NoSQL 인터페이스를 통해 짧은 대기 시간 데이터를 사용할 수 있지만 대기 시간이 긴 Hadoop 앱 또는 기타 낮은 우선 순위 앱을 통해 데이터 자체를 계산하고 업데이트 할 수있는 2 계층 애플리케이션.

• 순차적 데이터 읽기. 올바른 기본 데이터 스토리지 모델을 선택해야합니다. B- 트리는 순차 읽기에 가장 적합한 모델이 아닐 수 있습니다.

• 더 나은 성능 / 확장 성이 필요할 수있는 서비스의 일부를 자체 시스템으로 분리합니다. 예를 들어, 사용자 로그인은 고성능이어야하며이 기능은 이러한 목표를 달성하기 위해 전용 서비스를 사용할 수 있습니다.

• Caching. A high performance caching tier for websites and other applications. Example is a cache for the Data Aggregation System used by the Large Hadron Collider. Voting.

• Real-time page view counters.

• User registration, profile, and session data.

• Document, catalog management and content management systems. These are facilitated by the ability to store complex documents has a whole rather than organized as relational tables. Similar logic applies to inventory, shopping carts, and other structured data types.

• Archiving. Storing a large continual stream of data that is still accessible on-line. Document-oriented databases with a flexible schema that can handle schema changes over time.

• Analytics. Use MapReduce, Hive, or Pig to perform analytical queries and scale-out systems that support high write loads.

• Working with heterogeneous types of data, for example, different media types at a generic level.

• Embedded systems. They don’t want the overhead of SQL and servers, so they use something simpler for storage.

• A "market" game, where you own buildings in a town. You want the building list of someone to pop up quickly, so you partition on the owner column of the building table, so that the select is single-partitioned. But when someone buys the building of someone else you update the owner column along with price.

• JPL is using SimpleDB to store rover plan attributes. References are kept to a full plan blob in S3. ^(source)

• Federal law enforcement agencies tracking Americans in real-time using credit cards, loyalty cards and travel reservations.

• Fraud detection by comparing transactions to known patterns in real-time.

• Helping diagnose the typology of tumors by integrating the history of every patient.

• In-memory database for high update situations, like a website that displays everyone's "last active" time (for chat maybe). If users are performing some activity once every 30 sec, then you will be pretty much be at your limit with about 5000 simultaneous users.

• Handling lower-frequency multi-partition queries using materialized views while continuing to process high-frequency streaming data.

• Priority queues.

• Running calculations on cached data, using a program friendly interface, without having to go through an ORM.

• Uniq a large dataset using simple key-value columns.

• To keep querying fast, values can be rolled-up into different time slices.

• Computing the intersection of two massive sets, where a join would be too slow.

• A timeline ala Twitter.

Redis use cases, VoltDB use cases and more find here.

---

This question is almost impossible to answer because of the generality. I think you are looking for some sort of easy answer problem = solution. The problem is that each "problem" becomes more and more unique as it becomes a business.

What do you call a social network? Twitter? Facebook? LinkedIn? Stack Overflow? They all use different solutions for different parts, and many solutions can exist that use polyglot approach. Twitter has a graph like concept, but there are only 1 degree connections, followers and following. LinkedIn on the other hand thrives on showing how people are connected beyond first degree. These are two different processing and data needs, but both are "social networks".

If you have a "social network" but don't do any discovery mechanisms, then you can easily use any basic key-value store most likely. If you need high performance, horizontal scale, and will have secondary indexes or full-text search, you could use Couchbase.

If you are doing machine learning on top of the log data you are gathering, you can integrate Hadoop with Hive or Pig, or Spark/Shark. Or you can do a lambda architecture and use many different systems with Storm.

If you are doing discovery via graph like queries that go beyond 2nd degree vertexes and also filter on edge properties you likely will consider graph databases on top of your primary store. However graph databases aren't good choices for session store, or as general purpose stores, so you will need a polyglot solution to be efficient.

What is the data velocity? scale? how do you want to manage it. What are the expertise you have available in the company or startup. There are a number of reasons this is not a simple question and answer.

---

A short useful read specific to database selection: How to choose a NoSQL Database?. I will highlight keypoints in this answer.

Key-Value vs Document-oriented

Key-value stores

If you have clear data structure defined such that all the data would have exactly one key, go for a key-value store. It’s like you have a big Hashtable, and people mostly use it for Cache stores or clearly key based data. However, things start going a little nasty when you need query the same data on basis of multiple keys!

Some key value stores are: memcached, Redis, Aerospike.

Two important things about designing your data model around key-value store are:

• You need to know all use cases in advance and you could not change the query-able fields in your data without a redesign.
• Remember, if you are going to maintain multiple keys around same data in a key-value store, updates to multiple tables/buckets/collection/whatever are NOT atomic. You need to deal with this yourself.

Document-oriented

If you are just moving away from RDBMS and want to keep your data in as object way and as close to table-like structure as possible, document-structure is the way to go! Particularly useful when you are creating an app and don’t want to deal with RDBMS table design early-on (in prototyping stage) and your schema could change drastically over time. However note:

• Secondary indexes may not perform as well.
• Transactions are not available.

Popular document-oriented databases are: MongoDB, Couchbase.

Comparing Key-value NoSQL databases

memcached

• In-memory cache
• No persistence
• TTL supported
• client-side clustering only (client stores value at multiple nodes). Horizontally scalable through client.
• Not good for large-size values/documents

Redis

• In-memory cache
• Disk supported – backup and rebuild from disk
• TTL supported
• Super-fast (see benchmarks)
• Data structure support in addition to key-value
• Clustering support not mature enough yet. Vertically scalable (see Redis Cluster specification)
• Horizontal scaling could be tricky.
• Supports Secondary indexes

Aerospike

• Both in-memory & on-disk
• Extremely fast (could support >1 Million TPS on a single node)
• Horizontally scalable. Server side clustering. Sharded & replicated data
• Automatic failovers
• Supports Secondary indexes
• CAS (safe read-modify-write) operations, TTL support
• Enterprise class

Comparing document-oriented NoSQL databases

MongoDB

• Fast
• Mature & stable – feature rich
• Supports failovers
• Horizontally scalable reads – read from replica/secondary
• Writes not scalable horizontally unless you use mongo shards
• Supports advanced querying
• Supports multiple secondary indexes
• Shards architecture becomes tricky, not scalable beyond a point where you need secondary indexes. Elementary shard deployment need 9 nodes at minimum.
• Document-level locks are a problem if you have a very high write-rate

Couchbase Server

• Fast
• Sharded cluster instead of master-slave of mongodb
• Hot failover support
• Horizontally scalable
• Supports secondary indexes through views
• Learning curve bigger than MongoDB
• Claims to be faster

ReferenceURL : https://stackoverflow.com/questions/18198960/practical-example-for-each-type-of-database-real-cases