大数据时代的数据库选择：sql还是Nosql？
执行大数据项目的企业面对的关键决策之一是使用哪个数据库，sql还是Nosql?sql有着骄人的业绩，庞
大的安装基础;而Nosql正在获得可观的收益，且有很多支持者。我们来看看两位专家对这个问题的看法
一、专家简介
VoltDB公司首席技术官Ryan Betts表示，sql已经赢得了大型企业的广泛部署，大数据是它可以支持的另
一个领域。
Couchbase公司首席执行官Bob Wiederhold表示，Nosql是可行的选择，并且从很多方面来看，它是大数
据的最佳选择，特别是涉及到可扩展性时。
二、sql经历时间的考验，并仍然在蓬勃发展
结构化查询语言(sql)是经过时间考验的胜利者，它已经主宰了几十年，目前大数据公司和组织(例如谷
歌、Facebook、Cloudera和Apache)正在积极投资于sql。
在成为主导技术(例如sql)后，有时候我们很容易忘记其优越性。sql的独特优势包括：
1. sql能够加强与数据的交互，并允许对单个数据库设计提出问题。这是很关键的特征，因为无法交互
的数据基本上是没用的，并且，增强的交互性能够带来新的见解、新的问题和更有意义的未来交互。
2. sql是标准化的，使用户能够跨系统运用他们的知识，并对第三方附件和工具提供支持。
3. sql能够扩展，并且是多功能和经过时间验证的，这能够解决从快写为主导的传输到扫描密集型深入
分析等问题。
4. sql对数据呈现和存储采用正交形式，一些sql系统支持JSON和其他结构化对象格式，比Nosql具有更
好的性能和更多功能。
虽然Nosql的出现带来了一些影响，但sql仍然主导着市场，并在大数据领域赢得了很多投资和广泛部署
。
Nosql的说法很含糊，对于本次讨论，我借用Rick Cattell对Nosql的定义，即提供简单操作(例如密钥/
数值存储)或简单记录和索引，并专注于这些简单操作的横向可扩展性的系统。
很显然，现在很多新的数据库并不是都一样，认识每种数据库背后的原理以及潜在问题是成功的关键。
Nosql的主要特点使其更适合于特定的问题。例如，图形数据库更适合于数据通过关系组织的情况，而专
门的文本搜索系统更适合于需要实时搜索的情况。
在这里，让我们看看sql系统的主要优势和差异化功能：
* sql可实现交互性。 sql是一种声明性查询语言。用户说出他们想要什么(例如，显示过去五年三月份
期间顶级客户的地理位置)，数据库内部就会构件算法并提取请求的结果。相比之下，Nosql编程创新
MapReduce是一种程序性查询技术。在用户提出请求时，MapReduce要求用户不仅说出自己想要什么，而
且要求他们陈述如何产生答案。
这听起来像一个无趣的技术差异，但这很关键，原因在于：首先，声明性SQL查询更容易通过图形化工具
以及点击报告构建器来构建。这让分析师、操作员、管理者和其他不具备软件编程能力的员工进行数据
库查询;其次，数据库引擎可以利用内部信息来选择最有效的算法。改变数据库的物理布局或数据库，最
佳算法仍然能够计算出来。而在程序性系统中，编程人员需要重新访问和重新编程算法，这是非常昂贵
且容易出错的过程。
市场理解这个关键区别。在2010年，谷歌宣布部署sql来补充MapReduce，主要受内部用户需求所驱动。
最近，Facebook发布了Presto(一种sql部署)来查询其PB级HDFS集群。根据Facebook表示：“随着我们的
仓库增长到PB级，以及我们的需求变化，我们清楚地意识到，我们需要一个提供低延时查询的互动系统
。”此外，Cloudera也正在构建Impala—另一个基于HDFS的sql部署。
* sql是标准化的。 虽然供应商有时候会添加自己的语言到sql界面，但sql的核心是标准化的，还有其
他规格(例如ODBC和JDBC)提供广泛可用的稳定界面到sql存储。这带来了一个管理和操作工具生态系统，
可以在sql系统之上设计、监控、检查、探索和构建应用程序。
sql用户和程序员可用跨多个后端系统重复使用其API和UI知识，减少了应用程序的开发时间。标准化还
允许声明性第三方提取、转换、加载(ETL)工具，使企业可以在数据库之间以及跨系统传输数据。
* sql可扩展。 认为sql必须牺牲以获得可扩展性的看法，完全是错误的。如前所述，Facebook创建了一
个sql界面来查询PB级数据。sql能够非常有效地运行极快的ACID传输。sql对数据存储和索引提供的抽象
[注]化允许跨各种问题和数据集大小的一致使用，让sql可以跨集群复制数据存储有效地运行。使用sql
作为界面独立于构建云、规模或HA系统，sql中并没有什么在阻止和限制容错、高可用性和复制。事实上
，所有现代sql系统支持云友好型横向可扩展性、复制和容错性。
* sql支持JSON。 几年前，很多sql系统增加了XML文档支持。现在，随着JSON成为一种流行的数据交换
格式，sql供应商也纷纷加入了JSON型的支持。基于现在灵活的编程过程和web基础设施的正常运行时间
要求，我们很需要结构化数据类型的支持。Oracle 12c、Postgresql 9.2、VoltDB和其他支持JSON的数
据库，通常具有优于“原生”JSON的性能。
sql将继续赢得市场份额，并会继续看到新的投资和部署。Nosql数据库提供专有查询语言或简单的键值
语义，而没有更深层次的技术差异化。现代sql系统提供可扩展性的同时，还支持更丰富的查询语义，并
有庞大的用户安装基础，广泛的生态系统整合和深度企业部署。
三、Nosql更适合大数据应用程序
Nosql越来越多地被认为是关系型数据库的可行替代品，特别是对于大数据应用程序。此外，无模式数据
模型通常更适合于现在捕捉和处理的数据种类和类型。
当我们谈论Nosql领域的大数据时，我们指的是从操作数据库读取和写入。不要将操作数据库与分析数据
库混淆，这通常会查看大量数据，并从这些数据获取可视性。
虽然操作数据库的大数据看起来不具有可分析性，但操作数据库通常会存储超大量用户的大型数据集，
这些用户经常需要访问数据来实时执行交易。这种数据库的操作规模也解释了Nosql的关键特性，也就是
为什么Nosql是大数据应用程序的关键的原因。
四、Nosql是可扩展性的关键
每次技术行业经历硬件发展的根本性转变时，都会出现一个拐点。在数据库领域，从纵向扩展到横向扩
展的转变推动了Nosql的发展。关系型数据库(包括来自甲骨文和IBM的数据库)是纵向扩展。也就是说，
它们是集中式、共享一切的技术，只能通过增加更多昂贵的硬件来扩展。
而Nosql数据库是分布式横向扩展技术。它们使用了分布式节点集(称为集群)来提供高度弹性扩展功能，
让用户可以添加节点来动态处理负载。
分布式横向扩展的做法通常要比纵向做法更加便宜。商业关系型数据库的授权费用也让人望而却步，因
为他们的价格是按每台服务器来计算。另一方面，Nosql数据库通常是开源技术，按照运行的服务器集群
收费，而且价格相对便宜。
五、Nosql是灵活性的关键
关系型数据库和Nosql数据模型有很大的不同。关系型模式获取数据，并将数据分配到很多相互关联的表
中，这些表通过外键相互应用。
当用户需要对数据集运行查询时，所需信息需要从多个表中收集(通常涉及数百个企业应用程序)，并结
合这些信息，再提供给应用程序。同样地，当写入数据时，需要在多个表协调和执行写入。当数据相对
较少，并且，数据以较慢速度流入数据库时，关系型数据库通常能够捕捉和存储信息。然而，现在的应
用程序通常需要快速写入(和读取)海量数据。
Nosql数据库采用非常不同的模式。在其核心，Nosql数据库其实是“NoREL”，或者说非关系型，这意味
着它们没有依赖于表以及表之间的联系，以存储和组织信息。例如，以文档为导向的Nosql数据库获取你
想要存储的数据，并采用JSON格式整合到文档中。每个JSON文档可以被你的应用程序视为一个对象。
JSON文档可能会提取跨越25个表的数据，将数据集成到一个文档中。
聚合这些信息可能会导致信息重复，但由于存储已不再是一个成本问题，数据模型灵活性、发布所产生
文档的简便性以及读取和写入性能提高，让这成为不错的选择。
六、Nosql是大数据应用程序的关键
通过第三方(包括社交媒体网站)，数据正变得越来越容易捕捉和访问。这些数据包括：个人用户信息、
地理位置数据、用户生产的内容、机器记录数据和传感器产生的数据。企业还可以依赖于大数据来推动
其关键任务型应用程序。同时，企业正在转向到Nosql数据库，因为这种数据库非常适合现在新型的数据
类型。
开发人员想要一个灵活的数据库，可以很容易适应新的数据类型，并且，不会受第三方数据供应商的内
容结构变化的影响。大多数新数据是非结构化和半结构化，因此，开发人员也需要能够有效存储这些数
据的数据库。然而，关系型数据库采用的严格定义的基于模式的做法让其不可能快速整合新数据类型，
并且很不适合于非结构化和半结构化数据。
总体来说，随着web和移动应用程序的增加、新的趋势、网上消费者行为的转变以及新的数据类型的出现
，行业需要能够提供可扩展的灵活的数据库技术来管理和访问数据。Nosql技术是有效满足这些需求的唯
一可行解决方案。
========
初识Nosql Nosql数据库入门 Nosql数据库基础知识
大家有没有听说过“Nosql”呢？大家可能会误以为是“No！sql”的缩写，但实际上，它是“Not Only
sql”的缩写。它的意义是：适用关系型数据库的时候就使用关系型数据库，不适用的时候也没有必要非
使用关系型数据库不可，可以考虑使用更加合适的数据存储。
..做了一年的大一年度项目了，对于关系型数据库结构还是有些了解了，有的时候还是觉得这种二维表
不是很顺手。在看过一篇文章之后，对Nosql有了初步的了解，
（https://keen.io/blog/53958349217/analytics-for-hackers-how-to-think-about-event-data）。
这篇文章写的很好，确实写出来了在实际情况下Nosql的“用武之地”，而且用了MineCraft作分析，但
是也许不够全面。比如文章中只是提到了，entity数据用关系型怎么存，event数据用Nosql怎么存，我
想借我这篇文章，来分析一下event类型的数据原始的关系型数据库是怎样存数据的，然后再对这两种储
存方式做一种对比，算是对原文都一种补充吧。
对于这种死亡事件，有这样的两条数据，一个是关于creeper的爆炸，一种是掉进岩浆。如果必须用关系
型二维表数据库，我会这样存储。（如果您还不知道是什么样的数据，可以先看之后的Nosql储存方法，
那样看起来更清楚。）
这种情况的数据可以说是数据库设计中比较复杂的一种情况了，因为它包含两种情况（当然不止这两种
情况，那么就会产生更多的结构），不同情况的数据表结构是不同的，这非常麻烦。我们一般的解决方
案是设计四个表格，利用关系型数据库的关系性。设计如下四张表格。（在这里我就简写了）
第一张表
?123456 id #首先用于关联，主表需要有个id，这个倒不是什么区别，因为Nosql一般也会有个_id的预
设 timestamp #所有共同部分就可以存在一张表中。 cause player_UID player_experience
player_age #对于player_inveneory_id 因为这是一个可以任意长度的数组，又只能保存在另一个表
中了
第二张表（用于保存creeper死亡方式的死亡事件的）
?123456 id #这是这张表的id以后可以跟别的表格关联 mid #用于关联主表 enemy_type
enemy_power enemy_distance enemy_age
第三张表（用于保存lava死亡方式的死亡事件的）
?12345 id #这是这张表的id以后可以跟别的表格关联 mid #用于关联主表 place_x place_y place_z
第四张表（用于保存player_inveneory）
?123 id #这是这张表的id以后可以跟别的表格关联 mid #用于关联主表 inveneory
至此关系性数据库就将这种有不同结构的事件存放方式规定好了，接下来存放如下（我就不画表格了）
?123456789101112131415161718 1. id timestamp cause player_UID
player_experience player_age 1 "2013-05-23T1:50:00-0600" "creeper" "99234890823"
8873729 228 2 "2013-05-24T23:25:00-0600" "lava" "99234890823" 88737
22 2. id mid enemy_type enemy_power enemy_distance enemy_age 1 1
"creeper" .887 3.34 .6677 3. id mid place_x place_y place_z 1 2
45.366 -13.333 -39.288 4. id mid inveneory 1 1 "diamend sword" 2 1
"torches" 3 2 "stone"
至此，我们就用关系性数据库将这两个事件数据存下了。（好麻烦是吧！）
我们再看Nosql的储存方法，因为每条数据并不受字段（列名）限制，完全可以直接保存，不用分表。（
比如JSON格式）
?123456789101112131415161718192021222324252627282930313233 #第一条数据 { "timestamp":
"2013-05-23T1:50:00-0600","cause":"creeper","enemy":{ "type":"creeper"
"power": .887 "distance_from_player":3.34 "age":.6677 },"player": {
"UID":"99234890823","experience": 8873729,"age": 228,"inveneory":["diamend
sword","torches"] } } #第二条数据 { "timestamp": "2013-05-24T23:25:00-0600",
"cause":"lava","place":{ x:45.366 y:-13.333 z:-39.288 } "player": {
"UID":"99234890823","experience": 88737,"age": 22,"inveneory":["stone"] }
}
下面我们分析Nosql对这种数据存放方式的好处
1.首先是把分散的表结构整合了，让应该在一起的数据在一起了。
这就像C语言中开多个数组储存还是用一个结构体数组的区别，将一些有关系的数据放在一起是人类一种
自然的想法，当然会让人更加舒服，而且可以提高关联性和升级扩展的简易程度。
2.存放变得方便
让我们来考虑有数据来了我们怎么储存。
对于二维表数据库：
1.分析数据是那种类型的
2.存放主表数据，并获得返回id
3.分支，加上主表id在不同情况下向lava或creeper表中存放数据
4.开循环，向inveneory表中插入多条记录
这还只是一个简述，还要考虑到对多个表格操作时的数据回滚问题，实际写起来30行左右，那么出
错的可能就大大提高了。
对于Nosql类型
一句话：
insert(data);#伪码
其实想想便知道，取数据时原来的关系性数据库也会同样麻烦。
3.Nosql更利于动态生成存放方式，灵活性高了很多，至少我们可以在存放数据的时候再设计数据库了（
虽然可能预先设计会好一些）
当然，如果存储的不是事件性或者类似此类数据那么就另当别论了，二维表还是有很多它本身的优势的
。以上是我的一些个人的分析，当然还有很多普遍认同的观点，以下是一些普遍认同的关于两种数据库
模式的优缺点分析，我也基本同意。
关系性优势：
1.事务处理---保持数据的一致性；
2.由于以标准化为前提，数据更新的开销很小（相同的字段基本上只有一处）；
3.可以进行Join等复杂查询。
关系型缺点：
1. 扩展困难：由于存在类似Join这样多表查询机制，使得数据库在扩展方面很艰难;
2. 读写慢：这种情况主要发生在数据量达到一定规模时由于关系型数据库的系统逻辑非常复杂，使
得其非常容易发生死锁等的并发问题，所以导致其读写速度下滑非常严重;
3. 成本高：企业级数据库的License价格很惊人，并且随着系统的规模，而不断上升;
4. 有限的支撑容量：现有关系型解决方案还无法支撑Google这样海量的数据存储;
Nosql优势，主要体现在下面几点：
1. 简单的扩展：典型例子是Cassandra，由于其架构是类似于经典的P2P，所以能通过轻松地添加新
的节点来扩展这个集群;
2. 快速的读写：主要例子有Redis，由于其逻辑简单，而且纯内存操作，使得其性能非常出色，单
节点每秒可以处理超过10万次读写操作;
3. 低廉的成本：这是大多数分布式数据库共有的特点，因为主要都是开源软件，没有昂贵的
License成本;
Nosql数据库还存在着很多的不足，常见主要有下面这几个：
1. 不提供对sql的支持：如果不支持sql这样的工业标准，将会对用户产生一定的学习和应用迁移成
本;
2. 支持的特性不够丰富：现有产品所提供的功能都比较有限，大多数Nosql数据库都不支持事务，
也不像MS sql Server和Oracle那样能提供各种附加功能，比如BI和报表等;
3. 现有产品的不够成熟：大多数产品都还处于初创期，和关系型数据库几十年的完善不可同日而语
;
========