NoSQL

概述

NoSQL (NoSQL = Not Only SQL)，意为 “不仅仅是SQL”。是非关系型数据库。NoSQL用于超大规模数据的存储。

为什么要使用NoSQL

今天我们通过第三方平台（例如QQ、微信、百度、微博等）可以很容易的访问和抓取数据。用户的个人信息，社交网络，地理位置，用户生成的数据和用户操作已经次方级的增长。如果要对这些用户数据进行挖掘，那SQL数据库已经不适用这些应用了，NoSQL数据库的发展却能很好的处理这些大数据。

RDBMS vs NoSQL

RDBMS:

• 高度组织化结构化数据

• 结构化查询语言

• 数据和关系都存储仔单独的表中

• 数据操纵语言、数据定义语言

• 严格的一致性

• 基础事务

NoSQL：

• 代表着不仅仅是SQL

• 没有声明性查询语言

• 没有预定义的模式

• 键值对存储，列存储，文档存储，图形数据库

• 最终一致性，而非ACID属性

• 非结构化和不可预知的数据

• CAP定理

• 高性能、高可用和可伸缩性

NoSQL发展简史

NoSQL一词最早出现于1998年，是Carlo Strozzi开发的一个轻量、开源、不提供SQL功能的关系数据库。

2009年，Last.fm的Johan Oskarsson发起了一次关于分布式开源数据库的讨论[2]，来自Rackspace的Eric Evans再次提出了NoSQL的概念，这时的NoSQL主要指非关系型、分布式、不提供ACID的数据库设计模式。

2009年在亚特兰大举行的"no:sql(east)"讨论会是一个里程碑，其口号是"select fun, profit from real_world where relational=false;"。因此，对NoSQL最普遍的解释是"非关联型的"，强调Key-Value Stores和文档数据库的优点，而不是单纯的反对RDBMS。

3V + 3高

大数据时代的3V：（描述问题）

• 海量（volume）

• 多样（variety）

• 实时（velocity）

大数据时代的3高：（对程序的要求）

• 高并发

• 高可拓

• 高性能

NoSQL四种类型

• 键值（Key-Value）数据库

  • 键值数据库就像在传统语言中使用的哈希表，可以通过key来添加、查询、删除数据，鉴于使用主键访问，所以会获得不错的性能和扩展性。

  • 产品：

    • Riak

    • Redis

    • Memcached

  • 有谁在用：

    • Github

    • Twitter

    • Instagram

    • Youtube

  • 适用场景：

    • 储存用户的信息，比如会话、配置文件、参数、购物车等。这些信息一般都和id（键）挂钩，这种情境下键值数据库是个很好的选择。

  • 不适用场景：

    • 取代通过键查询，而是通过值来查询。Key-Value数据库中根本没有通过值查询的途径

    • 需要存储数据之间的关系，在Key-Value数据库中不能通过两个或以上的键来关联数据

    • 事务的支持。在Key-Value数据库中故障产生时不可以进行回滚

• 面向文档（Document-Oriented）数据库

  • 面向文档数据库会将数据以文档的形式存储。每个文档都是自包含的数据单元，是一系列数据项的集合。每个数据项都有一个名称和对应的值，值既可以是简单的数据类型，如字符串、数字和日期等，也可以是复杂的类型，如有序列表和关联对象。数据存储的最小单位是文档，同一个表中存储的文档属性可以是不同的，数据可以使用XML、JSON或者JSONB等多种形式存储。

  • 产品：

    • MongoDB\CouchDB\RavenDB

  • 使用场景：

    • 日志。企业环境下，每个应用程序都有不同的日志信息。Document-Oriented数据库并没有固定的模式，所以我们可以使用它存储不同的信息。

    • 分析。鉴于它的弱模式结构，不改变模式下就可以存储不同的度量方法及添加新的度量

  • 不适用场景：

    • 在不同的文档上添加事务，Document-Oriented数据库并不支持文档间的事务，如果对这方面有需求则不应该选用这个解决方案

• 列存储（Wide Colum Store/Colum-Family）数据库

  • 列存储数据库将数据存储在列簇（column family）中，一个列簇存储经常被一起查询的相关数据。举个例子，如果我们有一个Person类，我们通常会一起查询他们的名字和年龄而不是薪资。这种情况下，姓名和年龄就会被放入一个列簇中，而薪资则在另一个列族中。

  • 产品：

    • Cassandra\HBase

  • 谁在使用：

    • Ebay

    • Instagram

    • NASA

    • Twitter

    • FaceBook

  • 适用场景：

    • 日志。因为我们可以将数据存储在不同的列中，每个应用程序可以将信息写入自己的列中

    • 博客平台。我们存储每个信息到不同的列族中。举个例子，标签可以存储在一个，类别可以在一个，而文章则在另一个

  • 不适用场景：

    • 如果我们需要ACID事务，Cassandra就不支持事务

    • 原型设计。如果我们分析Cassandra的数据结构，我们就会发现结构是基于我们期望的数据查询方式而定的。在模型设计之初，我们根本不可能去预测它的查询方式，而一旦查询方式改变，我们就必须重新设计列簇。

• 图（graph-Oriented）数据库

  • 图数据库允许我们将数据以图的方式存储，实体会被作为顶点，而实体之间的关系则会被作为边。比如我们有三个实体，雷军、金山和小米，则会有两个“founded by”的边将金山和小米连接到雷军。

  • 产品：

    • Neo4j

    • infinite graph

    • orientDB

  • 谁在使用：

    • Adobe

    • Cisco

    • t-mobile

  • 适用场景：

    • 在一些关系型强的数据中

    • 推荐引擎。如果我们将数据以图的形式表现，那么将会非常有益于推荐的定制

  • 不适用场景：

    • 不适合的数据模型。图数据库的适用范围很小，因为很小有操作涉及到整个图

NoSQL

原文：https://www.cnblogs.com/crowned/p/13229653.html