当与关系型数据库比较时，NoSQL系统具有更好的可扩展性与更优越的性能。当评估NoSQL产品时，用户应该考虑到5个关键指标来让应用程序和企业来做出正确的选择。在这篇文章中，我们描述了这些要素，并且表明了为什么SequoiaDB是企业的正确选择。
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的增加。
结论
NoSQL系统最大的区别在于查询数据有效性。
文档型数据库提供了最丰富的查询功能，这使得他们能够满足各种各样的应用。
键值对存储和宽表存储提供了通过主键值访问数据的方式。他们提供有限的查询功能，以及可能需要强加更多的开发成本和应用程序级需求，来提供额外的查询功能。
4 一致性模型
NoSQL系统通常保存了数据的多个副本用来提供系统的可用性和可扩展性需求。在这些架构中，关于数据副本之间的一致性有着不同的实现。NoSQL系统往往有强一致性和最终一致性之分。
在强一致性系统中，应用程序的写在后续的查询中都是立即可见的。在最终一致性系统的写则是不会立即可见的。例如，在一个产品目录中反映产品的库存水平，一旦库存水平通过应用程序更新，强一致性系统的每个查询都将查询到当前库存；而在最终一致性的系统中，在给定的时间查询库存水平可能并不是准确的，但是最终会是准确的。出于这个原因，最终一致性系统中的应用程序代码往往是不同的，而不是通过目前的库存更改之，然后在去读取它。一般来说，最终一致性系统很少被用于涉及交易等强一致性的场景，而更多地涉及分析或一些互联网类应用。
4.1强一致性系统
每个应用对于数据一致性都有着不同的需求。对于许多应用，时刻保持数据一致性是必须的。随着开发团队已经在关系型数据库强一致性模型下工作几十年，这种方法便是更自然更熟悉的了。在其他情况下，最终一致性是一个可以接受的折中办法，为允许系统可用性的灵活性。
文档型数据库和图形数据库能够是强一致性和最终一致性的。SequoiaDB提供可调节的一致性。默认情况下，数据是最终一致性的写，读取数据从副本。作为一种选择，读查询可以是对主副本的。当读取的数据来自于从副本时，数据时最终一致的；而当读取数据来自于主副本时则是强一致性。同时，SequoiaDB提供了强一致写的特性，即使用户从从节点读取数据也能够保证系统的强一致性。
4.2最终一致性系统
最终一致性系统有一段时间所有副本的数据并不是完全同步的。在只读的应用程序中以及类似历史档案不经常更改的存储数据中是可以接受的。出于同样的理由，对于频繁写的场景也是合适的，这些场景例如从数据库或操作系统捕获信息（如日志），这些信息只会在稍后的时间点被读出。键值对存储和宽表存储是典型的最终一致性。
最终一致性系统必须能够解决在单条记录中更新冲突。因为写操作可以被应用到数据的任何一个副本，写冲突是可能的，而且也是常见的。类似Riak的一些系统使用向量时钟来标识事件发生的顺序；而类似CouchDB的其他系统则保留所有冲突值，而且允许用户解决冲突。类似Cassandra的另外一种方法则是简单的假设最大的值是正确的。对于这些原因，写往往能在最终一致性系统中表现不错，但是读和更新往往涉及复杂应用程序的权衡。
结论
大多数应用程序和开发团队期望强一致性系统。
不同的一致性模型构成了应用程序在一致性和可用性方面的权衡标准。
SequoiaDB提供了定义在查询层的可变一致性。
最终一致性系统提供了写优势，为此付出了更高更复杂的读和更新成本。
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的支持。
结论
API的程序和功能在NoSQL产品上各不相同。
SequoiaDB友好的驱动程序简化了新员工培训时间和应用程序开发。
用户可以通过PostgreSQL使用SQL语言读写SequoiaDB。
6 商业支持和社区力量
选择一个数据库是一个重大的投资。一旦一个应用程序搭建在一个给定的数据库上，迁移至另一个不同的数据将会是昂贵且富有挑战的。而NoSQL系统是相对较新的，而且在市场上有许多选择，只有少量的产品将经得起时间的考验。
6.1商业支持
当评估一个数据库的时候，用户应该考虑公司或项目的健康。不仅仅该产品能够继续存在，而且还要发展提供新的功能是很重要的。有一个强大的、经验丰富的提供本地化支持的团队是非常重要的。
一些NoSQL数据库尽管在北美拥有庞大的用户市场，但是对于企业来说，本土企业毕竟很难与没有强大本地化支持团队的产品对接。SequoiaDB则存在一个强大的技术支持团队，能够为所有本地企业提供24×7的技术支持与定制化的产品开发。
6.2社区力量
一个有着强大社区的技术是有着显著的优势的，特别是数据库。一个有着强大用户社区的数据库让寻找和雇佣熟悉这个产品的开发人员变得更容易，也更容易的找到信息、文档和代码示例。
结论
SequoiaDB提供了强大的本地支持团队，提供24×7的技术支持与定制化产品开发。
7 总结
随着技术的演变，企业需要详细地评估每种NoSQL数据产品。媒体大力宣扬关于NoSQL数据库却缺少相关明确的市场，这使得企业了解可用解决方案之间的差异变得很重要。正如本文所讨论，评估这些技术的关键标准是：数据模型、查询模型、一致性模型、API以及商业支持。我们鼓励技术决策者详细评估这些因素，判断SequoiaDB等NoSQL数据库是否能够满足自身的需要。
8 关于 SequoiaDB
SequoiaDB 作为 NoSQL 数据库，重新设计了数据的管理方式，并推动了大数据行业的发展。SequoiaDB 数据模型的设计，使用户能够更加敏捷地开发易扩展的系统架构。SequoiaDB 支持多种类型的应用，提供了良好的用户体验，加速产品发布时间，并降低企业的运营成本。
