这篇文章主要围绕评估NoSQL数据库的几大标准和评估nosql数据库的几大标准是什么展开，旨在为您提供一份详细的参考资料。我们将全面介绍评估NoSQL数据库的几大标准的优缺点，解答评估nosql数据库

这篇文章主要围绕评估NoSQL数据库的几大标准和评估nosql数据库的几大标准是什么展开，旨在为您提供一份详细的参考资料。我们将全面介绍评估NoSQL数据库的几大标准的优缺点，解答评估nosql数据库的几大标准是什么的相关问题，同时也会为您带来Atitit.nosql api 标准化 以及nosql数据库的实现模型分类差异、MySql与NoSQL比较：如何评估不同数据库的性能、nosql-redis-网络资料学习-05-nosql数据库的四大分类、NoSQL数据库的主主备份的实用方法。

本文目录一览：

• 评估NoSQL数据库的几大标准（评估nosql数据库的几大标准是什么）
• Atitit.nosql api 标准化 以及nosql数据库的实现模型分类差异
• MySql与NoSQL比较：如何评估不同数据库的性能
• nosql-redis-网络资料学习-05-nosql数据库的四大分类
• NoSQL数据库的主主备份

评估NoSQL数据库的几大标准（评估nosql数据库的几大标准是什么）

1 简介

在大多数企业中，关系型数据库有着充分的理由长期占据着市场。支撑传统应用的关系型数据库能够满足当前的业务需求，这些关系型数据库有着广泛生态系统工具的支持，并且有大量有能力的人员来实现和维护这些产品。

但是现在，越来越多的企业正在考虑替换传统关系型数据库。在一些情况下，这种替换动机是技术性的，例如在现存系统的功能下需要扩展或提高性能；而在其他情况下，企业是则是由寻找可替代品来替换昂贵的专有软件的意愿所驱动的；第三种动机则是开发的敏捷性和速度要求，为企业寻求更快地适应市场和获得敏捷开发的方法。

这种驱动力同时适用于分析和事务应用。公司把离线、分析的工作负载迁移到 Hadoop上，并用一种新类型数据管理技术来搭建网上、业务应用，如 Nosql 数据库。

开发团队在技术选择过程中有着强有力的发言权。通过调查发现，很多场景下，关系型数据模型不能很好的与应用需求保持一致。例如：

1.开发人员正在使用新类型数据，结构化的、半结构化的、非结构化的以及多态数据，并且这些数据的量是巨大的。

2.传统的应用程序使用 12-18 个月的瀑布开发周期。现在小团队以敏捷冲刺、快速迭代以及每一周或两周甚至每天提交代码的效率工作。

3.面向对象编程是一种常态，而开发人员也需要一个数据模型与这种方法相结合。

4.企业正通过使用通过 PC 服务器与云计算，从传统单点架构转向水平扩展架构。

Nosql 系统有几个关键的特征。当与关系型数据库比较时，Nosql 系统具有更好的可扩展性与更优越的性能。当评估 Nosql 产品时，用户应该考虑到 5 个关键指标来让应用程序和企业来做出正确的选择。在这篇文章中，我们描述了这些要素，并且表明了为什么SequoiaDB 是企业的正确选择。

2 数据模型

Nosql 数据库与关系型数据库最主要的区别在于数据模型。

2.1文档型模型

关系型数据以行和列的形式存储数据，而文档型数据库则以文档的形式存储。这些文件通常使用类似 JSON（JavaScript Object Notation）的结构，而 JSON 是一种在开发人员之间流行的数据编码格式。文件提供了一个直观自然的方式来建模数据，这与面向对象编程紧密保持一致，同时每个文件可以看作是一个对象。文件包含一个或多个字段，每个字段包含了一个类型值，如字符串类型、日期类型、二进制类型或者数组类型。不同于每条记录平均分散于多个列和表中，每条记录和它相关数据通常是存储在一个单一的文件中。这简化了数据访问、减少甚至消除了连接和复杂事务的需求。

在文档型数据库中，数据模型的概念是动态的，每个文件可以包含不同的字段。这种灵活性对于建模非结构化数据和多态数据是非常有用的。这也使得在开发过程中改进应用程序非常容易（例如增加新字段）。特别是，在文档中，数据是可以基于任何字段进行查询的。

应用：文档型数据库由于其数据模型的灵活性、查询任何字段的能力,以及在现代编程语言中文档数据模型到对象的自然映射，使其对于各类应用程序都是通用的。

示例：MongoDB，SequoiaDB 和 CouchDB

2.2图形模型

图形数据库使用带有节点、边以及属性的图形结构来表示数据。本质上，数据是作为特定元素之间的网络关系来建模的。尽管图形模型可能需要一些时间来理解，但是它能广泛地用于许多应用。它最主要的吸引力在于能让应用程序中的实体建模关系变得更容易。

应用：图形数据库在以实体关系作为应用程序核心的场景下是非常有用的，如社交网络。

示例：Neo4j 和 HypergraphDB

2.3键值对和宽表存储模型

从数据模型的角度来看，键值对存储是 Nosql 数据库最基本的类型。在数据库中的每个项都被存储作为一个属性名或者键，并且与其值一起存储。但是，这个值对于系统来说是完全不透明的，数据只能通过键查询。这个模型用于表示多态数据和非结构化数据是非常有用的。

宽表存储，或者列存储，是使用一个稀疏的、分布式多维分类映射来存储数据。每条记录能够存储在多个列中，并且列可以嵌套在其他列中，被嵌套的列称为超级列。列可以以列族的形式组合在一起，或者列可以跨越多个不同的列族。数据通过每个列族的主键值被检索。

应用：键值对存储和宽表存储对于只由一个键值查询数据的应用是有用的。这种系统的吸引力在于他们的高性能和可扩展性，以及由于数据访问模式的简化而能够被高度优化。

示例：Riak 和Redis（键值对存储）；HBase 和Cassandra （宽表存储）

3 查询模型

每个应用都有其自身的查询需求。在一些情况下，只能基于主键来访问记录的模式是可以被一些应用程序所接受的；然而，对于大多数应用程序而言，重要的是有能力根据每条记录中几个不同的值查询。例如，一个存储了用户数据的应用，不仅需要能够查询特定客户的数据，而且还要能够查询特定公司、特定交易规模、通过邮政区码或特定客户类型的客户数据。

应用程序更新记录是常见的，包括一个或多个字段的更新。为了满足这些需求，数据库需要能够根据二级索引查询数据。在这些情况下，文档型数据库可能是最合适的解决方案。

3.1文档型数据库

文档型数据库能够在文档中任何字段进行查询。一些如MongoDB，SequoiaDB的产品，提供了一组丰富的索引选项来优化各种查询，包括主键索引、复合索引、唯一索引等。此外，一些产品还提供了分析数据的能力。例如，SequoiaDB为复杂分析提供的聚合框架。关于更新，SequoiaDB则提供查找和修改功能，使得在文档中的值能够过一个简单的数据库语句被更新，而不用往返多次执行。

3.2图形数据库

这些系统往往会提供丰富的查询模式，在这些查询模式中，简单和复杂的关系能够被推出用来做出关于系统数据的直接和间接的结论。在这些系统中，关系类型分析往往是有效的，因此其他类型的分析可能会有相对较少的优化。

3.3键值对和宽表数据库

这些系统提供了基于主键检索和更新数据的能力。如需查询其他的值，建议用户手工建立二级索引。其中一些产品对二级索引仅提供受限的支持，而且还有不少其他的注意事项。要执行系统的更新，往返两次甚至多次可能都是必要的：首先找到该记录，然后更新它。在这些系统中，更新操作也许会被作为记录进行完整改写，造成整体I/O的增加。

4 一致性模型

Nosql系统通常保存了数据的多个副本用来提供系统的可用性和可扩展性需求。在这些架构中，关于数据副本之间的一致性有着不同的实现。Nosql系统往往有强一致性和最终一致性之分。

在强一致性系统中，应用程序的写在后续的查询中都是立即可见的。在最终一致性系统的写则是不会立即可见的。例如，在一个产品目录中反映产品的库存水平，一旦库存水平通过应用程序更新，强一致性系统的每个查询都将查询到当前库存；而在最终一致性的系统中，在给定的时间查询库存水平可能并不是准确的，但是最终会是准确的。出于这个原因，最终一致性系统中的应用程序代码往往是不同的，而不是通过目前的库存更改之，然后在去读取它。一般来说，最终一致性系统很少被用于涉及交易等强一致性的场景，而更多地涉及分析或一些互联网类应用。

4.1强一致性系统

每个应用对于数据一致性都有着不同的需求。对于许多应用，时刻保持数据一致性是必须的。随着开发团队已经在关系型数据库强一致性模型下工作几十年，这种方法便是更自然更熟悉的了。在其他情况下，最终一致性是一个可以接受的折中办法，为允许系统可用性的灵活性。

文档型数据库和图形数据库能够是强一致性和最终一致性的。SequoiaDB提供可调节的一致性。默认情况下，数据是最终一致性的写，读取数据从副本。作为一种选择，读查询可以是对主副本的。当读取的数据来自于从副本时，数据时最终一致的；而当读取数据来自于主副本时则是强一致性。同时，SequoiaDB提供了强一致写的特性，即使用户从从节点读取数据也能够保证系统的强一致性。

4.2最终一致性系统

最终一致性系统有一段时间所有副本的数据并不是完全同步的。在只读的应用程序中以及类似历史档案不经常更改的存储数据中是可以接受的。出于同样的理由，对于频繁写的场景也是合适的，这些场景例如从数据库或操作系统捕获信息（如日志），这些信息只会在稍后的时间点被读出。键值对存储和宽表存储是典型的最终一致性。

最终一致性系统必须能够解决在单条记录中更新冲突。因为写操作可以被应用到数据的任何一个副本，写冲突是可能的，而且也是常见的。类似Riak的一些系统使用向量时钟来标识事件发生的顺序；而类似CouchDB的其他系统则保留所有冲突值，而且允许用户解决冲突。类似Cassandra的另外一种方法则是简单的假设最大的值是正确的。对于这些原因，写往往能在最终一致性系统中表现不错，但是读和更新往往涉及复杂应用程序的权衡。

5 APIs

Nosql系统没有接口标准。每个系统为应用开发团队提供了不同的设计和功能。API的成熟对开发和维护底层Nosql系统的时间和开销有重大影响。

5.1友好驱动程序

有很多流行的编程语言，每一种语言都为处理数据和服务提供了不同的范式。友好的驱动程序是由某种编程语言专家和程序员，根据相应语言被大家公认所接受的风格特别创造的。这种方法可以在提供有效访问和处理数据的编程语言中充分利用其特征。

对于开发者，友好的驱动程序是易学和易用的，而且他们还能减少团队新员工培训时间与底层系统开始工作。例如，友好的驱动程序提供直接接口设置和获取文档中的文件或字段。其他类型的接口则可能需要检索和解析整个文档并导航到特定的值来设置和获取一个字段。

SequoiaDB支持多种语言的友好驱动程序，例如Java，.Net，PHP，C，C++，Python等。

5.2Thrift 或 RESTful APIs

有些系统提供了RESTful接口。这种方法拥有简单而又熟悉的吸引力，但是它依赖于与HTTP相关的固有延迟。它还把构建接口的负担转移到开发人员上，而且这个接口与其他编程接口可能会不一致。同样地，一些系统提供了Thrift接口，这是个很低的水平范式，它转移了开发者的负担到在开发他们应用中更抽象的接口。

5.3sql 支持

sql经历了几十年的洗礼，早已经成为业界公认的标准。现在，一些Nosql数据库尝试由自身提供sql的变种（sql-like），或结合一些sql插件进行sql语言的支持。

SequoiaDB提供了Postgresql数据库的接口插件，可以在Postgresql中自由定义来自SequoiaDB数据库的外部数据表，实现标准sql语言、ODBC与JDBC的支持。

6 商业支持和社区力量

选择一个数据库是一个重大的投资。一旦一个应用程序搭建在一个给定的数据库上，迁移至另一个不同的数据将会是昂贵且富有挑战的。而Nosql系统是相对较新的，而且在市场上有许多选择，只有少量的产品将经得起时间的考验。

6.1商业支持

当评估一个数据库的时候，用户应该考虑公司或项目的健康。不仅仅该产品能够继续存在，而且还要发展提供新的功能是很重要的。有一个强大的、经验丰富的提供本地化支持的团队是非常重要的。

一些Nosql数据库尽管在北美拥有庞大的用户市场，但是对于企业来说，本土企业毕竟很难与没有强大本地化支持团队的产品对接。SequoiaDB则存在一个强大的技术支持团队，能够为所有本地企业提供24x7的技术支持与定制化的产品开发。

6.2社区力量

一个有着强大社区的技术是有着显著的优势的，特别是数据库。一个有着强大用户社区的数据库让寻找和雇佣熟悉这个产品的开发人员变得更容易，也更容易的找到信息、文档和代码示例。

7 总结

随着技术的演变，企业需要详细地评估每种Nosql数据产品。媒体大力宣扬关于Nosql数据库却缺少相关明确的市场，这使得企业了解可用解决方案之间的差异变得很重要。正如本文所讨论，评估这些技术的关键标准是：数据模型、查询模型、一致性模型、API以及商业支持。我们鼓励技术决策者详细评估这些因素，判断Nosql数据库是否能够满足自身的需要。

Atitit.nosql api 标准化 以及nosql数据库的实现模型分类差异

Atitit.nosqlapi标准化以及nosql数据库的实现模型分类差异

1.常用的nosql数据库MongoDBCassandra1

1.1.查询>db.blogposts.find({"author.name":"Jane"})1

1.2.保存saveinsert1

1.3.Update，delete2

1.4.MongoDB与RDBMSWhere语句比较2

1.5.MongoDBOR条件2

1.5.1.实例3

1.6.AND和OR联合使用3

2.对比4

3.参考5

1.Keyword

Zaijson中实现表达式的表达，用json来表示sql的表达式

2.常用的nosql数据库MongoDBCassandra

举例2：在一个关系型数据库中，一篇博客（包含文章内容、评论、评论的投票）会被打散在多张数据表中。在MongoDB中，能用一个文档来表示一篇博客，评论与投票作为文档数组，放在正文主文档中。这样数据更易于管理，消除了传统关系型数据库中影响性能和水平扩展性的“JOIN”操作。

2.1.查询>db.blogposts.find({"author.name":"Jane"})

2.2.保存saveinsert

>db.blogposts.save({title:"MyFirstPost",author:{name:"Jane",id:1},
comments:[{by:"Abe",text:"First"},239); font-size:10.5pt">{by:"Ada",text:"Goodpost"}]})

2.3.Update，delete

作者::绰号:老哇的爪子（全名：：AttilaxAkbaralRapanui阿提拉克斯阿克巴阿尔拉帕努伊）汉字名：艾龙，EMAIL:1466519819@qq.com

转载请注明来源：http://blog.csdn.net/attilax

2.4.MongoDB与RDBMSWhere语句比较

如果你熟悉常规的sql数据，通过下表可以更好的理解MongoDB的条件语句查询：

操作	格式	范例	RDBMS中的类似语句
等于	{<key>:<value>}	db.col.find({"by":"菜鸟教程"}).pretty()	whereby='菜鸟教程'
小于	{<key>:{$lt:<value>}}	db.col.find({"likes":{$lt:50}}).pretty()	wherelikes<50
小于或等于	{<key>:{$lte:<value>}}	db.col.find({"likes":{$lte:50}}).pretty()	wherelikes<=50
大于	{<key>:{$gt:<value>}}	db.col.find({"likes":{$gt:50}}).pretty()	wherelikes>50
大于或等于	{<key>:{$gte:<value>}}	db.col.find({"likes":{$gte:50}}).pretty()	wherelikes>=50
不等于	{<key>:{$ne:<value>}}	db.col.find({"likes":{$ne:50}}).pretty()	wherelikes!=50

2.5.MongoDBOR条件

MongoDBOR条件语句使用了关键字$or,语法格式如下：

>db.colfind(

{

$or:[

{key1value1},key2value2}

]

}).pretty()

2.5.1.实例

以下实例中，我们演示了查询键by值为菜鸟教程或键title值为MongoDB教程的文档。

({:[{"by":"菜鸟教程""title""MongoDB教程"}]}).(){

"_id"ObjectId("56063f17ade2f21f36b03133"),

"title",251); font-size:9pt">"description""MongoDB是一个Nosql数据库""by""url""http://www.runoob.com""tags""mongodb""database""Nosql"

],251); font-size:9pt">"likes"100}>

2.6.AND和OR联合使用

以下实例演示了AND和OR联合使用，类似常规sql语句为：'whereurl='http://www.runoob.com'AND(by='菜鸟教程'ORtitle='MongoDB教程')'

({"likes"$gt:50[{}

3.对比

Cassandra教程资料较为少，crud语句类似sql了。。不是nosql了。。

MongoDB的资料多，更加容易oo

不过百度查询MongoDB百度为您找到相关结果约3,110,000个

Cassandra的数量是mongodb的俩被。。

Hbase百度为您找到相关结果约6,000个

至于hbase，文档少，貌似比较复杂不好用。

4.下图是Nosql家族的进化图，我们可以看到这样的进化：Key-Value时代，BigTable时代，Document时代，全文搜索时代，和Graph数据库时代：

（陈皓注：注意图中sql说的那句话，Nosql再这样发展下去就是sql了，哈哈。）

数据模型的进化：

·Key-Value键值对存储是非常简单而强大的。下面的很多技术基本上都是基于这个技术开始发展的。但是，Key-Value有一个非常致命的问题，那就是如果我们需要查找一段范围内的key。（陈皓注：学过hash-table数据结构的人都应该知道，hash-table是非序列容器，其并不像数组，链接，队列这些有序容器，我们可以控制数据存储的顺序）。于是，有序键值（OrderedKey-Value）数据模型被设计出来解决这一限制，来从根本上提高数据集的问题。

OrderedKey-Value有序键值模型也非常强大，但是，其也没有对Value提供某种数据模型。通常来说，Value的模型可以由应用负责解析和存取。这种很不方便，于是出现了BigTable类型的数据库，这个数据模型其实就是map里有map，map里再套map，一层一层套下去，也就是层层嵌套的key-value（value里又是一个key-value），这种数据库的Value主要通过“列族”（columnfamilies），列，和时间截来控制版本。（陈皓注：关于时间截来对数据的版本控制主要是解决数据存储并发问题，也就是所谓的乐观锁，详见《多版本并发控制(MVCC)在分布式系统中的应用》）

Documentdatabases文档数据库改进了BigTable模型，并提供了两个有意义的改善。第一个是允许Value中有主观的模式（scheme），而不是map套map。第二个是索引。FullTextSearchEngines全文搜索引擎可以被看作是文档数据库的一个变种，他们可以提供灵活的可变的数据模式（scheme）以及自动索引。他们之间的不同点主要是，文档数据库用字段名做索引，而全文搜索引擎用字段值做索引。

Graphdatamodels图式数据库可以被认为是这个进化过程中从OrderedKey-Value数据库发展过来的一个分支。图式数据库允许构建议图结构的数据模型。它和文档数据库有关系的原因是，它的很多实现允许value可以是一个map或是一个document。

4.0.0.1.Nosql数据模型摘要

本文剩下的章节将向你介绍数据建模的技术实现和相关模式。但是，在介绍这些技术之前，先来一段序言：

Nosql数据模型设计一般从业务应用的具体数据查询入手，而不是数据间的关系：

关系型的数据模型基本上是分析数据间的结构和关系。其设计理念是：“WhatanswersdoIhave?”

Nosql数据模型基本上是从应用对数据的存取方式入手，如：我需要支持某种数据查询。其设计理念是”WhatquestionsdoIhave?”

Nosql数据模型设计比关系型数据库需要对数据结构和算法的更深的了解。在这篇文章中我会和大家说那些尽人皆知的数据结构，这些数据结构并不只是被Nosql使用，但是对于Nosql的数据模型却非常有帮助。

数据冗余和反规格化是一等公民。

关系型数据库对于处理层级数据和图式数据非常的不方便。Nosql用来解决图式数据明显是一个非常好的解决方案，几乎所有的Nosql数据库可以很强地解决此类问题。这就是为什么这篇文章专门拿出一章来说明层级数据模型。

4.1.下面是Nosql的分类表，也是我用来写这篇文章时做实践的产品：

Key-Value存储:OracleCoherence,Redis,KyotoCabinet

类BigTable存储:ApacheHBase,ApacheCassandra

文档数据库:MongoDB,CouchDB

全文索引:ApacheLucene,ApacheSolr

图数据库:neo4j,FlockDB

5.参考

排名前十的sql和Nosql数据库-CSDN.NET.htm

8天学通MongoDB——第一天基础入门-一线码农-博客园.htm

MongoDB查询文档菜鸟教程.htm

分布式Key-Value存储系统：Cassandra入门.htm

Cassandra2.x中文教程（2）：执行简单的CQL操作屁民部落.htm

Nosql数据建模技术-CSDN.NET.htm

HBase使用教程-推酷.htm

MySql与NoSQL比较：如何评估不同数据库的性能

随着数据科学的不断发展，越来越多的应用程序需要处理大规模的数据。为了存储和管理这些数据，不同类型的数据库已经被开发出来。其中，关系型数据库和非关系型数据库是最常见的两种类型数据库，而mysql和nosql则是它们中最受欢迎的代表。

在本文中，将介绍如何评估MySQL和NoSQL两种不同数据库的性能，并讨论它们的优缺点及适用范围。

性能评估标准

对于数据库的性能评估，通常会参考以下几个指标：

1. 可扩展性：数据库应该能够处理大量数据，并且能够在不影响性能的情况下水平扩展。
2. 数据一致性：当多个用户同时访问数据库时，数据库应该保证数据一致性。
3. 可靠性和可用性：数据库应该能够在意外故障或者断电情况下恢复并保持可用状态。
4. 灵活性：数据库应该能够支持不同类型的数据和查询，并能够灵活适应业务需求。
5. 性能：数据库应该具有高效查询、写入和更新数据等特性。

MySQL性能评估

MySQL是一种关系型数据库，已经被广泛应用于Web应用和企业级应用程序中。以下是MySQL的性能特征和评估标准：

1. 可扩展性：MySQL可以通过水平分区来扩展，分区可以根据某些规则将表的行垂直拆分到不同的物理服务器上，例如按时间或地理位置。
2. 数据一致性：MySQL使用ACID事务，确保在任何情况下都专注于数据一致性。
3. 可靠性和可用性：MySQL支持多种备份和复制方法，例如主从复制和集群，确保在服务器奔溃的情况下数据不会丢失。
4. 灵活性：MySQL支持存储不同类型的数据，例如整数、文本、日期等。它还支持各种查询语句，例如SELECT、UPDATE、DELETE等。
5. 性能：MySQL性能非常高，它可以处理大量数据并给出快速的查询结果，特别是在使用索引的情况下。

NoSQL性能评估

NoSQL是非关系型数据的代表，它是一种非常适合处理大数据集和高效查询的数据库，很多应用程序都用它来处理海量数据。以下是NoSQL的性能特征和评估标准：

1. 可扩展性：NoSQL是一种可水平扩展的数据库，可以处理大量数据，并且采用分布式架构，增加了容错能力。
2. 数据一致性：NoSQL使用BASE的一致性模型，其中，C代表强一致性，A代表可用性，SE代表最终的一致性。
3. 可靠性和可用性：NoSQL对于硬件故障和网络故障具有很好的容错能力。它可以通过副本集和分片来支持高可用性和可靠性。
4. 灵活性：NoSQL支持各种类型的数据和查询，因此可以适应不同类型的业务需求。
5. 性能：NoSQL的性能非常高，特别是在查询大量数据时。由于它不是基于关系模型的，因此可以充分利用现代计算机的内存和处理器，从而提高整体性能。

MySQL和NoSQL的适用范围

MySQL和NoSQL两种数据库都有它们各自的优点和适用范围。以下是一些应用场景：

1. 对于需要事务支持，并且需要更加精确的数据一致性和可靠性的应用程序，例如电子商务、财务应用程序等，MySQL是最好的选择。
2. 对于需要处理大量时间序列数据的应用程序，例如物联网、日志分析等，NoSQL是最好的选择。因为NoSQL数据库能够轻松地处理大量数据并支持水平扩展。
3. 对于需要高可用性的应用程序，例如社交网络、在线游戏等，建议使用NoSQL数据库，因为它能够容忍硬件故障和分布式系统的问题。

总结

MySQL和NoSQL两种数据库都有它们各自的优点和适用范围。MySQL适合处理相对小型的数据集，并需要ACID事务的应用程序，但在处理大型数据集方面的性能可能受到限制。NoSQL数据库则适合处理大规模的数据集，特别是时间序列数据，但在强一致性和可靠性方面可能不如MySQL。通过对两种数据库进行评估，我们可以根据应用程序的要求，选择适合的数据库。

以上就是MySql与NoSQL比较：如何评估不同数据库的性能的详细内容，更多请关注php中文网其它相关文章！

nosql-redis-网络资料学习-05-nosql数据库的四大分类

nosql数据库的四大分类

1、NoSql数据库的四大分类

kv、列值、文档、图

## 1.1 kv 键值 ##
应用举例（16年数据）

• 新浪：BerkeleyDB+redis
• 美团：redis+tair
• 阿里、百度：memcache+redis
• 列表项目

1.2 文档型数据库(bson格式比较多)

例如

• CouchDB
• MongoDB
  MongoDB 是一个基于分布式文件存储的数据库。由 C++ 语言编写。旨在为 WEB 应用提供可扩 展的高性能数据存储解决方案。MongoDB 是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。

1.3 列存储数据库

例如

• Cassandra
• HBase

1.4 图关系型数据库

它不是放图形的，放的是关系比如:朋友圈社交网络、广告推荐系统，社交网络，推荐系统等。专注于构建关系图谱

例如：

• Neo4J
• InfoGrid

NoSQL数据库的主主备份

《Nosql数据库的主主备份》要点：
本文介绍了Nosql数据库的主主备份，希望对您有用。如果有疑问，可以联系我们。

翻译 | 贺雨言

Tarantool DBMS的高性能应该很多人都听说过,包含其丰富的工具套件和某些特定功能.比如,它拥有一个非常强大的on-disk存储引擎Vinyl,并且知道怎样处理JSON文档.然而,大部分文章往往忽略了一个关键点：通常,Tarantool仅仅被视为存储器,而实际上其最大特点是能够在存储器内部写代码,从而高效处理数据.如果你想知道我和igorcoding是怎样在Tarantool内部建立一个系统的,请继续往下看.

如果你用过Mail.Ru电子邮件服务,你应该知道它可以从其他账号收集邮件.如果支持OAuth协议,那么在收集其他账号的邮件时,我们就不必要让用户提供第三方服务凭证了,而是用OAuth令牌来代替.此外,Mail.Ru Group有很多项目要求通过第三方服务授权,并且必要用户的OAuth令牌才能处理某些应用.因此,我们决定建立一个存储和更新令牌的服务.

我猜大家都知道OAuth令牌是什么样的,闭上眼睛回忆一下,OAuth结构由以下3-4个字段组成：

• 拜访令牌(access_token)——允许你执行动作、获取用户数据、下载用户的好友列表等等；

• 更新令牌(refresh_token)——让你重新获取新的access_token,不限次数；

• 过期时间(expires_in)——令牌到期时间戳或任何其他预定义时间,如果你的access_token到期了,你就不能继续拜访所需的资源.

现在我们看一下服务的简单框架.设想有一些前端可以在我们的服务上写入和读出令牌,还有一个独立的更新器,一旦令牌到期,就可以通过更新器从OAuth服务提供商获取新的拜访令牌.

如上图所示,数据库的结构也十分简单,由两个数据库节点(主和从)组成,为了说明两个数据库节点分别位于两个数据中心,二者之间由一条垂直的虚线隔开,其中一个数据中心包含主数据库节点及其前端和更新器,另一个数据中心包含从数据库节点及其前端,以及拜访主数据库节点的更新器.

面临的困难

我们面临的主要问题在于令牌的使用期(一个小时).详细了解这个项目之后,也许有人会问“在一小时内更新1000万条记录,这真的是高负载服务吗?如果我们用一个数除一下,结果大约是3000rps”.然而,如果因为数据库维护或故障,甚至服务器故障(一切皆有可能)导致一部分记录没有得到更新,那事情将会变得比拟麻烦.比如,如果我们的服务(主数据库)因为某些原因持续中断15分钟,就会导致25%的服务中断(四分之一的令牌变成无效,不能再继续使用)；如果服务中断30分钟,将会有一半的数据不能得到更新；如果中断1小时,那么所有的令牌都将失效.假设数据库瘫痪一个小时,我们重启系统,然后整个1000万条令牌都需要进行快速更新.这算不算高负载服务呢?

一开始一切都还进展地比拟顺利,但是两年后,我们进行了逻辑扩展,增加了几个指标,并且开始执行一些辅助逻辑…….总之,Tarantool耗尽了cpu资源.尽管所有资源都是递耗资源,但这样的结果确实让我们大吃一惊.

幸运的是,系统管理员帮我们安装了当时库存中内存最大的cpu,解决了我们随后6个月的cpu需求.但这只是权宜之计,我们必须想出一个解决方法.当时,我们学习了一个新版的Tarantool(我们的系统是用Tarantool 1.5写的,这个版本除了在Mail.Ru Group,其他地方基本没用过).Tarantool 1.6大力提倡主主备份,于是我们想：为什么不在连接主主备份的三个数据中心分别建立一个数据库备份呢?这听起来是个不错的计划.

三个主机、三个数据中心和三个更新器,都分别连接自己的主数据库.即使一个或者两个主机瘫痪了,系统仍然照常运行,对吧?那么这个方案的缺点是什么呢?缺点就是,我们将一个OAuth服务提供商的哀求数量有效地增加到了三倍,也就是说,有多少个副本,我们就要更新几乎相同数量的令牌,这样不行.最直接的解决办法就是,想办法让各个节点自己决定谁是leader,那样就只需要更新存储在leader上的节点了.

选择leader节点

选择leader节点的算法有很多,其中有一个算法叫paxos,相当复杂,不知道怎样简化,于是我们决定用Raft代替.Raft是一个非常通俗易懂的算法,谁能通信就选谁做leader,一旦通信连接失败或者其他因素,就重新选leader.具体实施方法如下：

Tarantool外部既没有Raft也没有paxos,但是我们可以使用net.Box内置模式,让所有节点连接成一个网状网(即每一个节点连接剩下所有节点),然后直接在这些连接上用Raft算法选出leader节点.最后,所有节点要么成为leader节点,要么成为follower节点,或者二者都不是.

如果你觉得Raft算法实施起来有困难,下面的Lua代码可以帮到你：

现在我们给远程服务器发送哀求(其他Tarantool副本)并计算来自每一个节点的票数,如果我们有一个quorum,我们就选定了一个leader,然后发送heartbeats,告诉其他节点我们还活着.如果我们在选举中失败了,我们可以发起另一场选举,一段时间之后,我们又可以投票或被选为leader.

只要我们有一个quorum,选中一个leader,我们就可以将更新器指派给所有节点,但是只准它们为leader服务.

这样我们就规范了流量,由于任务是由单一的节点派出,因此每一个更新器获得大约三分之一的任务,有了这样的设置,我们可以失去任何一台主机,因为如果某台主机出故障了,我们可以发起另一个选举,更新器也可以切换到另一个节点.然而,和其他分布式系统一样,有好几个问题与quorum有关.

“废弃”节点

如果各个数据中心之间失去联系了,那么我们必要有一些适当的机制去维持整个系统正常运转,还必要有一套机制能恢复系统的完整性.Raft成功地做到了这两点：

假设Dataline数据中心掉线了,那么该位置的节点就变成了“废弃”节点,也就是说该节点就看不到其他节点了,集群中的其他节点可以看到这个节点丢失了,于是引发了另一个选举,然后新的集群节点(即上级节点)被选为leader,整个系统仍然坚持运转,因为各个节点之间仍然坚持一致性(大半部分节点仍然互相可见).

那么问题来了,与丢失的数据中心有关的更新器怎么样了呢?Raft说明书没有给这样的节点一个单独的名字,通常,没有quorum的节点和不能与leader联系的节点会被闲置下来.然而,它可以本身建立网络连接然后更新令牌,一般来说,令牌都是在连接模式时更新,但是,也许用一个连接“废弃”节点的更新器也可以更新令牌.一开始我们并不确定这样做有意义,这样不会导致冗余更新吗?

这个问题我们必要在实施系统的过程中搞清楚.我们的第一个想法是不更新：我们有一致性、有quorum,丢失任何一个成员,我们都不应该更新.但是后来我们有了另一个想法,我们看一下Tarantool中的主主备份,假设有两个主节点和一个变量(key)X=1,我们同时在每一个节点上给这个变量赋一个新值,一个赋值为2,另一个赋值为3,然后,两个节点互相交换备份日志(就是X变量的值).在一致性上,这样实施主主备份是很糟糕的(无意冒犯Tarantool开发者).

如果我们必要严格的一致性,这样是行不通的.然而,回忆一下我们的OAuth令牌是由以下两个重要因素组成：

• 更新令牌,本色上永久有效；

• 拜访令牌,有效期为一个小时；

我们的更新器有一个refresh函数,可以从一个更新令牌获取任意数量的拜访令牌,一旦发布,它们都将保持一个小时内有效.

我们考虑一下以下场景：两个follower节点正在和一个leader节点交互,它们更新自己的令牌,接收第一个拜访令牌,这个拜访令牌被复制,于是现在每一个节点都有这个拜访令牌,连接中断了,所以,其中一个follower节点变成了“废弃”节点,它没有quorum,既看不到leader也看不到其他follower,然而,我们允许我们的更新器去更新位于“废弃”节点上的令牌,如果“废弃”节点没有连接网络,那么整个方案都将停止运行.尽管如此,如果发生简单的网络拆分,更新器还是可以维持正常运行.

一旦网络拆分结束,“废弃”节点重新加入集群,就会引发另一场选举或者数据交换.注意,第二和第三个令牌一样,也是“好的”.

原始的集群成员恢复之后,下一次更新将只在一个节点上发生,然后备份.换句话来说,当集群拆分之后,被拆分的各个部分各自独立更新,但是一旦重新整合,数据一致性也因此恢复.通常,需要N/2+1个活动节点(对于一个3节点集群,就是需要2个活动节点)去保持集群正常运转.尽管如此,对我们而言,即使只有1个活动节点也足够了,它会发送尽可能多的外部哀求.

重申一下,我们已经讨论了哀求数量逐渐增加的情况,在网络拆分或节点中断时期,我们能够提供一个单一的活动节点,我们会像平时一样更新这个节点,如果出现绝对拆分(即当一个集群被分成最大数量的节点,每一个节点有一个网络连接),如上所述,OAuth服务提供商的哀求数量将提升至三倍.但是,由于这个事件发生的时间相对短暂,所以情况不是太糟,我们可不希望一直工作在拆分模式.通常情况下,系统处于有quorum和网络连接,并且所有节点都启动运行的状态.

分片

还有一个问题没有解决：我们已经达到了cpu上限,最直接的解决方法就是分片.

假设我们有两个数据库分片,每一个都有备份,有一个这样的函数,给定一些key值,就可以计算出哪一个分片上有所必要的数据.如果我们通过电子邮件分片,一部分地址存储在一个分片上,另一部分地址存储在另一个分片上,我们很清楚我们的数据在哪里.

有两种办法可以分片.一种是客户端分片,我们选择一个返回分片数量的连续的分片函数,比如CRC32、Guava或Sumbur,这个函数在所有客户端的实现方式都一样.这种办法的一个明显优势在于数据库对分片一无所知,你的数据库正常运转,然后分片就发生了.

然而,这种办法也存在一个很严重的缺陷.一开始,客户端非常繁忙.如果你想要一个新的分片,你需要把分片逻辑加进客户端,这里的最大的问题是,可能一些客户端在使用这种模式,而另一些客户端却在使用另一种完全不同的模式,而数据库本身却不知道有两种不同的分片模式.

我们选择另一种办法—数据库内部分片,这种情况下,数据库代码变得更加复杂,但是为了折中我们可以使用简单的客户端,每一个连接数据库的客户端被路由到任意节点,由一个特殊函数计算出哪一个节点应该被连接、哪一个节点应该被控制.前面提到,由于数据库变得更加复杂,因此为了折中,客户端就变得更加简单了,但是这样的话,数据库就要对其数据全权负责.此外,最困难的事就是重新分片,如果你有一大堆客户端无法更新,相比之下,如果数据库负责管理自己的数据,那重新分片就会变得非常简单.

具体怎样实施呢?

六边形代表Tarantool实体,有3个节点组成分片1,另一个3节点集群作为分片2,如果我们将所有节点互相连接,结果会怎样呢?根据Raft,我们可以知道每一个集群的状态,谁是leader服务器谁是follower服务器也一目了然,由于是集群内连接,我们还可以知道其他分片(例如它的leader分片或者follower分片)的状态.总的来说,如果拜访第一个分片的用户发现这并不是他需要的分片,我们很清楚地知道应该指导他往哪里走.

我们来看一些简单的例子：

假设用户向驻留在第一个分片上的key发出哀求,该哀求被第一个分片上的某一个节点接收,这个节点知道谁是leader,于是将哀求重新路由到分片leader,反过来,分片leader对这个key进行读或写,并且将结果反馈给用户.

第二个场景：用户的哀求到达第一个分片中的相同节点,但是被哀求的key却在第二个分片上,这种情况也可以用类似的方法处理,第一个分片知道第二个分片上谁是leader,然后把哀求送到第二个分片的leader进行转发和处理,再将结果返回给用户.

这个方案十分简单,但也存在必定的缺陷,其中最大的问题就是连接数,在二分片的例子中,每一个节点连接到其他剩下的节点,连接数是6*5=30,如果再加一个3节点分片,那么连接数就增加到72,这会不会有点多呢?

我们该如何解决这个问题呢?我们只需要增加一些Tarantool实例,我们叫它代理,而不叫分片或数据库,用代理去解决所有的分片问题：包括计算key值和定位分片领导.另一方面,Raft集群保持自包含,只在分片内部工作.当用户拜访代理时,代理计算出所需要的分片,如果需要的是leader,就对用户作相应的重定向,如果不是leader,就将用户重定向至分片内的任意节点.

由此产生的复杂性是线性的,取决于节点数量.现在一共3个节点,每个节点3个分片,连接数少了几倍.

代理方案的设计考虑到了进一步规模扩展(当分片数量大于2时),当只有2个分片时,连接数不变,但是当分片数量增加时,连接数会剧减.分片列表存储在Lua配置文件中,如果想要获取新列表,我们只必要重载代码就好了.

综上所述,首先,我们进行主主备份,应用Raft算法,然后加入分片和代理,最后我们得到的是一个单块,一个集群,所以说,目前这个方案看上去是比拟简单的.

剩下的就是只读或只写令牌的的前端了,我们有更新器可以更新令牌,获得更新令牌后把它传到OAuth服务提供商,然后写一个新的拜访令牌.

前面说过我们的一些辅助逻辑耗尽了cpu资源,现在我们将这些辅助资源移到另一个集群上.

辅助逻辑主要和地址簿有关,给定一个用户令牌,就会有一个对应的地址簿,地址簿上的数据量和令牌一样,为了不耗尽一台机器上的cpu资源,我们显然需要一个与副原形同的集群,只需要加一堆更新地址簿的更新器就可以了(这个任务比较少见,因此地址簿不会和令牌一起更新).

最后,通过整合这两个集群,我们得到一个相对简单的完整结构：

令牌更新队列

为什么我们本可以使用标准队列却还要用本身的队列呢?这和我们的令牌更新模型有关.令牌一旦发布,有效期就是一个小时,当令牌快要到期时,需要进行更新,而令牌更新必须在某个特定的时间点之前完成.

假设系统中断了,但是我们有一堆已到期的令牌,而在我们更新这些令牌的同时,又有其他令牌陆续到期,虽然我们最后肯定能全部更新完,但是如果我们先更新那些即将到期的(60秒内),再用剩下的资源去更新已经到期的,是不是会更合理一些?(优先级别最低的是还有4-5分钟才到期的令牌)

用第三方软件来实现这个逻辑并不是件容易的事,对于Tarantool来说却不费吹灰之力.看一个简单的方案：在Tarantool中有一个存储数据的元组,这个元组的一些ID设置了基础key值,为了得到我们必要的队列,我们只必要添加两个字段：status(队列令牌状态)和time(到期时间或其他预定义时间).

现在我们考虑一下队列的两个主要功能—put和take.put就是写入新数据.给定一些负载,put时本身设置好status和time,然后写数据,这就是建立一个新的元组.

至于take,是指建立一个基于索引的迭代器,挑出那些等待办理的任务(处于就绪状态的任务),然后核查一下是不是该接收这些任务了,或者这些任务是否已经到期了.如果没有任务,take就切换到wait模式.除了内置Lua,Tarantool还有一些所谓的通道,这些通道本质上是互联光纤同步原语.任何光纤都可以建立一个通道然后说“我在这等着”,剩下的其他光纤可以唤醒这个通道然后给它发送信息.

等待中的函数(等待发布任务、等待指定时间或其他)建立一个通道,给通道贴上适当的标签,将通道放置在某个地方,然后进行监听.如果我们收到一个紧急的更新令牌,put会给通道发出通知,然后take接收更新任务.

Tarantool有一个特殊的功能：如果一个令牌被意外发布,或者一个更新令牌被take接收,或者只是出现接收任务的现象,以上三种情况Tarantool都可以跟踪到客户端中断.我们将每一个连接与指定给该连接的任务联系起来,并将这些映射关系坚持在会话保存中.假设由于网络中断导致更新过程失败,而且我们不知道这个令牌是否会被更新并被写回到数据库.于是,客户端发生中断了,搜索与失败过程相关的所有任务的会话保存,然后自动将它们释放.随后,任意已发布的任务都可以用同一个通道给另一个put发送信息,该put会快速接收和执行任务.

实际上,具体实施方案并不必要太多代码：

Put只是接收用户想要插入队列的所有数据,并将其写入某个空间,如果是一个简单的索引式FIFO队列,设置好状态和当前时间,然后返回该任务.

接下来要和take有点关系了,但仍然比拟简单.我们建立一个迭代器,等待接收新任务.Taken函数只需要将任务标记成“已接收”,但有一点很重要,taken函数还能记住哪个任务是由哪个进程接收的.On_disconnect函数可以发布某个特定连接,或者发布由某个特定用户接收的所有任务.

是否有可选方案

当然有.我们本可以使用任意数据库,不管我们选用什么数据库,我们都要建立一个队列用来处理外部系统、处理更新等等问题.我们不能仅仅按需更新令牌,因为那样会产生不可预估的工作量,不管怎样,我们需要坚持我们的系统充满活力,但是那样,我们就要将延期的任务也插入队列,并且保证数据库和队列之间的一致性,我们还要被迫使用一个quorum的容错队列.此外,如果我们把数据同时放在RAM和一个(考虑到工作量)可能要放入内存的队列中,那么我们就要消耗更多资源.

在我们的方案中,数据库存储令牌,队列逻辑只必要占用7个字节(每个元组只必要7个额外的字节,就可以搞定队列逻辑!),如果使用其他的队列形式,必要占用的空间就多得多了,大概是内存容量的两倍.

总结

首先,我们解决了连接中断的问题,这个问题十分常见,使用上述的系统让我们解脱了这个困扰.

分片赞助我们扩展内存,我们将连接数从二次方减少到了线性,优化了业务任务的队列逻辑：如果发生延期,更新我们所能更新的一切令牌,这些延期并非都是我们的故障引起的,有可能是Google、Microsoft或者其他服务端对OAuth服务提供商进行改造,然后导致我们这边出现大量的未更新的令牌.

去数据库内部运算吧,走近数据,你将拥有方便、高效、可扩展和灵活的运算体验!

《Nosql数据库的主主备份》是否对您有启发，欢迎查看更多与《Nosql数据库的主主备份》相关教程，学精学透。小编PHP学院为您提供精彩教程。

今天关于评估NoSQL数据库的几大标准和评估nosql数据库的几大标准是什么的分享就到这里，希望大家有所收获，若想了解更多关于Atitit.nosql api 标准化 以及nosql数据库的实现模型分类差异、MySql与NoSQL比较：如何评估不同数据库的性能、nosql-redis-网络资料学习-05-nosql数据库的四大分类、NoSQL数据库的主主备份等相关知识，可以在本站进行查询。

本文标签：

• 评估
• Nosql数据库
• 几大标准
• SEO规范