nosql数据库学习总结

大数据时代的数据库选择：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. 现有产品的不够成熟：大多数产品都还处于初创期，和关系型数据库几十年的完善不可同日而语


;
========

8种主流NoSQL数据库系统特性对比和最佳应用场景

这篇文章主要介绍了8种主流NoSQL数据库系统特性对比和最佳应用场景,对选择一个NoSQL数据库来说是 一个不错的参考文章,需要的朋友可以参考下 ..曾在多家大公司任职的软件架构师兼顾问Kristóf Kovács在博客中对主流的NoSQL数据库（Cassandra 、Mongodb、CouchDB、Redis、Riak、Membase、Neo4j以及HBase）进行了全方位的对比。 虽然SQL数据库是非常有用的工具，但经历了15年的一支独秀之后垄断即将被打破。这只是时间问题：被 迫使用关系数据库，但最终发现不能适应需求的情况不胜枚举。 但是NoSQL数据库之间的不同，远超过两SQL数据库之间的差别。这意味着软件架构师更应该在项目开始 时就选择好一个适合的NoSQL数据库。针对这种情况，这里对 Cassandra、 Mongodb、CouchDB、Redis、 Riak、 Membase、Neo4j和HBase进行了比较： 注：NoSQL是一项全新的数据库革命性运动，NoSQL的拥护者们提倡运用非关系型的数据存储。现今的计 算机体系结构在数据存储方面要求具 备庞大的水平扩 展性，而NoSQL致力于改变这一现状。目前Google 的 BigTable 和Amazon 的Dynamo使用的就是NoSQL型数据库。 1. CouchDB 所用语言： Erlang 特点：DB一致性，易于使用 使用许可： Apache 协议： HTTP/REST 双向数据复制， 持续进行或临时处理， 处理时带冲突检查， 因此，采用的是master-master复制（见编注2） MVCC – 写操作不阻塞读操作 可保存文件之前的版本 Crash-only（可靠的）设计 需要不时地进行数据压缩 视图：嵌入式 映射/减少 格式化视图：列表显示 支持进行服务器端文档验证 支持认证 根据变化实时更新 支持附件处理 因此， CouchApps（独立的 js应用程序） 需要 jQuery程序库 最佳应用场景：适用于数据变化较少，执行预定义查询，进行数据统计的应用程序。适用于需要提供数 据版本支持的应用程序。 例如： CRM、CMS系统。 master-master复制对于多站点部署是非常有用的。 注：master-master复制：是一种数据库同步方法，允许数据在一组计算机之间共享数据，并且可以通过 小组中任意成员在组内进行数据更新。 2.Redis 所用语言：C/C++ 特点：运行异常快 使用许可： BSD 协议：类 Telnet 有硬盘存储支持的内存数据库， 但自2.0版本以后可以将数据交换到硬盘（注意， 2.4以后版本不支持该特性！） Master-slave复制（见编注3） 虽然采用简单数据或以键值索引的哈希表，但也支持复杂操作，例如 ZREVRANGEBYSCORE。 INCR & co （适合计算极限值或统计数据） 支持 sets（同时也支持 union/diff/inter） 支持列表（同时也支持队列；阻塞式 pop操作） 支持哈希表（带有多个域的对象） 支持排序 sets（高得分表，适用于范围查询） Redis支持事务 支持将数据设置成过期数据（类似快速缓冲区设计） Pub/Sub允许用户实现消息机制 最佳应用场景：适用于数据变化快且数据库大小可遇见（适合内存容量）的应用程序。 例如：股票价格、数据分析、实时数据搜集、实时通讯。 注：Master-slave复制：如果同一时刻只有一台服务器处理所有的复制请求，这被称为 Master-slave复 制，通常应用在需要提供高可用性的服务器集群。 3. MongoDB 所用语言：C++ 特点：保留了SQL一些友好的特性（查询，索引）。 使用许可： AGPL（发起者： Apache） 协议： Custom,binary（ BSON） Master/slave复制（支持自动错误恢复，使用 sets 复制） 内建分片机制 支持 javascript表达式查询 可在服务器端执行任意的 javascript函数 update-in-place支持比CouchDB更好 在数据存储时采用内存到文件映射 对性能的关注超过对功能的要求 建议最好打开日志功能（参数 –journal） 在32位操作系统上，数据库大小限制在约2.5Gb 空数据库大约占 192Mb 采用 GridFS存储大数据或元数据（不是真正的文件系统） 最佳应用场景：适用于需要动态查询支持；需要使用索引而不是 map/reduce功能；需要对大数据库有性 能要求；需要使用 CouchDB但因为数据改变太频繁而占满内存的应用程序。 例如：你本打算采用 MySQL或 PostgreSQL，但因为它们本身自带的预定义栏让你望而却步。 4. Riak 所用语言：Erlang和C，以及一些Javascript 特点：具备容错能力 使用许可： Apache 协议： HTTP/REST或者 custom binary 可调节的分发及复制(N,R,W) 用 JavaScript or Erlang在操作前或操作后进行验证和安全支持。 使用JavaScript或Erlang进行 Map/reduce 连接及连接遍历：可作为图形数据库使用 索引：输入元数据进行搜索（1.0版本即将支持） 大数据对象支持（ Luwak） 提供“开源”和“企业”两个版本 全文本搜索，索引，通过 Riak搜索服务器查询（ beta版） 支持Masterless多站点复制及商业许可的 SNMP监控 　　最佳应用场景：适用于想使用类似 Cassandra（类似Dynamo）数据库但无法处理 bloat及复杂性的 情况。适用于你打算做多站点复制，但又需要对单个站点的扩展性，可用性及出错处理有要求的情况。 例如：销售数据搜集，工厂控制系统；对宕机时间有严格要求；可以作为易于更新的 web服务器使用。 5. Membase 所用语言： Erlang和C 特点：兼容 Memcache，但同时兼具持久化和支持集群 使用许可： Apache 2.0 协议：分布式缓存及扩展 非常快速（200k+/秒），通过键值索引数据 可持久化存储到硬盘 所有节点都是唯一的（ master-master复制） 在内存中同样支持类似分布式缓存的缓存单元 写数据时通过去除重复数据来减少 IO 提供非常好的集群管理 web界面 更新软件时软无需停止数据库服务 支持连接池和多路复用的连接代理 最佳应用场景：适用于需要低延迟数据访问，高并发支持以及高可用性的应用程序 例如：低延迟数据访问比如以广告为目标的应用，高并发的 web 应用比如网络游戏（例如 Zynga） 6. Neo4j 所用语言： Java 特点：基于关系的图形数据库 使用许可： GPL，其中一些特性使用 AGPL/商业许可 协议： HTTP/REST（或嵌入在 Java中） 可独立使用或嵌入到 Java应用程序 图形的节点和边都可以带有元数据 很好的自带web管理功能 使用多种算法支持路径搜索 使用键值和关系进行索引 为读操作进行优化 支持事务（用 Java api） 使用 Gremlin图形遍历语言 支持 Groovy脚本 支持在线备份，高级监控及高可靠性支持使用 AGPL/商业许可 最佳应用场景：适用于图形一类数据。这是 Neo4j与其他nosql数据库的最显著区别 例如：社会关系，公共交通网络，地图及网络拓谱 7. Cassandra 所用语言： Java 特点：对大型表格和 Dynamo支持得最好 使用许可： Apache 协议： Custom,binary (节约型) 可调节的分发及复制(N,W) 支持以某个范围的键值通过列查询 类似大表格的功能：列，某个特性的列集合 写操作比读操作更快 基于 Apache分布式平台尽可能地 Map/reduce 我承认对 Cassandra有偏见，一部分是因为它本身的臃肿和复杂性，也因为 Java的问题（配置，出现异 常，等等） 最佳应用场景：当使用写操作多过读操作（记录日志）如果每个系统组建都必须用 Java编写（没有人因 为选用 Apache的软件被解雇） 例如：银行业，金融业（虽然对于金融交易不是必须的，但这些产业对数据库的要求会比它们更大）写 比读更快，所以一个自然的特性就是实时数据分析 8. HBase （配合 ghshephard使用） 所用语言： Java 特点：支持数十亿行X上百万列 使用许可： Apache 协议：HTTP/REST （支持 Thrift，见编注4） 在 BigTable之后建模 采用分布式架构 Map/reduce 对实时查询进行优化 高性能 Thrift网关 通过在server端扫描及过滤实现对查询操作预判 支持 XML,Protobuf,和binary的HTTP Cascading,hive,and pig source and sink modules 基于 Jruby（ JIRB）的shell 对配置改变和较小的升级都会重新回滚 不会出现单点故障 堪比MySQL的随机访问性能 最佳应用场景：适用于偏好BigTable:)并且需要对大数据进行随机、实时访问的场合。 例如： Facebook消息数据库（更多通用的用例即将出现） 注：Thrift 是一种接口定义语言，为多种其他语言提供定义和创建服务，由Facebook开发并开源。 当然，所有的系统都不只具有上面列出的这些特性。这里我仅仅根据自己的观点列出一些我认为的重要 特性。与此同时，技术进步是飞速的，所以上述的内容肯定需要不断更新。我会尽我所能地更新这个列 表。 ========