当你须要ACID属性来保护数据间的关系时，可以用关系型数据库。对于其他的数据存储，须要斟酌更适合的对象。实用于在体系架构中引入新数据或数据构造时。在选择最适合的存储对象时，要斟酌数据量、存储空间响应时光的请求、关系以及其他多种身分。

RDBMS供给了最好的事务完全性，但相对于其他存储选择，这种数据库很难扩愚且扩大成本高，可用性低。为数据选择准确的存储对象。不要因为你习习用数据库拜访数据，就总用关系数据库存储数据。

关系数据库治理体系(RDBMS)(如Oraclei和MYSQL)是以EdgarF.Codd于1970年宣布的论文“年夜型共享数据库数据的关系模子”(“ARelationalModelofDataforLargeSharedDataBanks”)中的关系模子为基本的。年夜多半RDBMS对于存储数据有两年夜利益。第一个利益是应用ACID属性确保了事务完全性，关于ACID的界说，请参阅表2-1。第二个利益在于表内和表间的关系型构造。为了最小化数据冗余，进步事务的处置才能，年夜多半联机事务处置理(OLTP)体系中的表都被规范化为第三范式即表中的所有记载都有雷同的字段，所有非主症结字的字段都不克不及只依附于组合症结字的一部门，所有非主症结字字段必需依附于主症结字。

表中的每一列数据都要依附于表中的其他列数据。表之间的关系平日以外键表现。固然应用RDBMS有这两点利益，但它们也是限制了扩大性的原因。为了确保ACID属性，扩大RDBMS比扩大其他数据存储可贵多。为了在具有多个节点的RDBMS集群(如MYSQLNDB)中确保数据致性，要采取同步复制的功效能力包管所稀有据在提交时被写入多个节点。采取OracleRAC，会有一个中心数据库，然则数据库域的所有权倒是所有节点共享的。是以，对于写要求，要把数据所有权转移到响应的节点，而对于读要求，则要依次从要求者发送到主节点，再从主节点发送到拥有要读的数据的节点，再从它发还到要求者。最终，你会受到同步复制数据的节点数或它们的地舆地位的限制。

RDBMS中表内和表间的关系构造使得很难对数据库进行分片或分区操作。关于把工作分发到多台机械上的原则。在把表拆分到多个数据库的运用中，本来在单一数据中衔接两个表的简略査询就要被转换成两个查询来衔接数据。

总而言之，只有请求事务完全性或数据间有关系的数据，才须要应用RDBMS。既不请求数据间的关系，也不请求事务完全性的数据，最好采取其他的存储体系。我们来简略评论辩论几个可用的解决计划，以及若何用它们取代数据库，以到达更好的、性价比更高的、扩大性更高的后果种经常被疏忽的存储体系是文件体系。也许这是一种简略的存储方法，因为年夜多半法式员最初编程时，拜访的都是文件而不是数据库中的数据。一旦我们学会了在数据库中存储或获取数据，就再也不消文件。文件体系已经成长良久了，并且很多文件体系是专门为处置异常年夜量的文件和数据而设计的。

这些文件体系包含GoogleFileSystem(GFS)、Mogilefs和Ceph等。假如你的体系是“一次写，多次读”的，那么文件体系是个很好的选择。换句话说，假如不会产生读写冲突，不须要保护年夜量的数据关系，并不真正须要用到数据库事务，那么采取文件体系才是最好的选择。另一种存储策略叫做NOSQL。这一类存储技巧平日被划分为键一值存储、可扩大记载存储和文档存储。关于这种技巧分类，并没有同一的尺度，许多技巧可以被分到多个种类中。鄙人面的介绍中，我们参加了一些技巧的示例，但不要把它们当做最终的说明。斟酌到这些项目成长的速度，那么未来这种分类很可能加倍隐约。

键一值存储技巧包含Memcached、TokyoTyrant和Voldemort。这些产物中的数据都有一个键一值索引存储在内存中。有些产物可以或许把健值异步复制。经由过程简化的数据存储模子和键一值对，这类产物可以或许供给很高写人硬盘永远存储。有些产物会在节点间进行同步复制，而有的则进行的可扩大性和机能，但在能存储什么数据方面具有很年夜的限制。此外，依附同步复制的键一值数据存储仍然具有与RDBMS集群一样的限制，即在节点数目和地舆地位方面的限制。

可扩大记载存储技巧包含Google公司专有的BigTable和Facebook公司的(如今已经是开源的)Cassandra。这些产物采取的是可以拆分到节点的行列数据模子。可以依据主键对行进行拆分或分片，再对列进行分组，寄存到分歧的节点上。这种扩大办法与展现的AKF扩大立方中的X轴和Y轴拆分办法类似，X轴拆分是读取数据副本，Y轴是依据支撑的办事来朋分表。在这些产物中，行分片是主动履行的，然则列拆分则须要用户界说，与在RDBMS中的操作相似。这些产物应用的是异步复制，最终能到达一致性。这意味着，也许几毫秒或几小时后，最终所有节点上的数据将是一致的。

文档存储技巧包含COUCHDB、亚马逊的Simpledb和雅虎的PNUTS。这种技巧采取的数据模子固然被称为“文档”，但其实称为多索引对象模子更确实。这些多索引对象(或者说“文档”)可以集合到多索引对象的聚集(平日称为“城”)中，然后可以对这比值合成情由查询。文档存储技巧不支撑ACID属性，相反地，它们采取的是异步复制办法，最终能使数据到达一致。

NOSQL解决计划把对象和实体之间的关系限制到了起码。恰是因为削减了关系，所以可以或许把体系分发到多个节点上，在保持事务完全性息争决读写冲突的同时，实现了更年夜的可扩大性。

平日情形下，我们都须要对体系的可扩大性和灵巧性进行衡量，在读过前面的介绍之后，也许你已经有了决议。数据实体之间的关系是进行权衡的症结，跟着关系增多，灵巧性会增长。灵巧性增长，会使成本增长，可扩大性下降。从扩大体系的成本(和限制)与数据实体之间的关系水平这两个方面临比了RDBMS、NOSQL和文件体系这三种解决计划。图4-2则从灵巧性和体系许可应用的关系水平两方面进行了比较。成果很显然，关系带来了灵巧性，但下降了可扩大性。正因如斯，我们不想滥用关系数据库，而是要采取合适任何的对象，使体系获得更年夜的扩大性。

在这个原则中，我们要介绍的另一种数据存储办法是Goge的Mapreduce办法リ。简而言之，Mapreduce办法具有两个功效，即Map和Reduce。Map功效的输入是一个键一值对，生成一个中央键一值对。输入的键可能是一个文档名或者指向文档中的某一段的指针。值可能是文档中的所有文字。Map功效的输出将输入到Reduce功效，该功效应用个法式对文字和文字段分组，而且把值添加到一个列表中。这是个不算庞杂的法式，依据键对数据进行排序和分组。这种技巧最年夜的利益是可以或许把异常年夜的数据集的盘算分发到很多办事器上。

Apache的Hadoop则是采取两种存储办法的组合的一个实例。它采取了Google的Mapreduce技巧和GoogleFileSystem，这两种办法前面都介绍过。Hadoop既是具有高可扩大性的文件体系，又可以或许散布式地存储和获取数据。

很多替代数据库的数据存储办法，那么在决议选择哪种办法时，应当斟酌数据的哪些特点呢?与存储办法有许多选择一样，须要斟酌的数据特点也有许多。最主要的几个是数据元素间的联系关系水平，解决计划的成长速度以及数据的读写比例(可能还稀有据是否更新)。最后，我们关怀的是若何把数据变现(换句话说，是否有利可图)，因为我们不想让本身的体系成本超越收益。

成本和开辟时光。例如，假设把一个涉及用户、付款、采购等信息的事务存储在一个键一值存储中，然后在采购申报内表现个中的信息片断，想象一下有何等艰苦吧。固然你可以采取文件体系或者NOSQL存储办法实现它，但向用户交付成果须要的开辟投入和时光成本都很高。

预期的增加速度异常主要，原因许多。最终，这个增加速度会影响体系的成本和客户响应时光。假如数据实体间须要高度的接洽，那么我们可能须要应用所有的硬件和处置才能来支撑单一的整合数据库，促使我们把数据库拆分成多个实例。

读写比例异常主要，因为它有助于我们懂得须要什么样的体系。只写一次而读多次的数据可以采取文件体系外加某种运用、文件或对象缓存。图像就是采取文件体系进行存储的典范例子。写过之后须要更新的数据，或者具有很高写读比例的数据，最好采取NOSQL存储或RDBMS。这些须要斟酌的身分组成了另一个立方体，分离用X轴、Y轴和Z轴表现了这三个身分。跟着这三个身分的值增长，最终解决计划的成本也会增长。假如我们请求体系间有高度的联系关系、高速增加、可以或许解决读写冲突，那么最好采取几个较小的RDBMS体系，如许在开辟、体系保护甚至数据库允许方面的成本可能相对较高。假如增加速度较慢，范围较小，然则关系许多须要解决读写冲突，那么可以应用单个的年夜型数据库(具有高可用性的集群)。

假如数据间的关系不长短常多，那么在任何程度的读写冲突和几乎任何程度的增加速度下，都可以应用NOSQL存储技巧。这里，我们再次看到了关系对成本和庞杂度的影响水平，我们将在第8章中商量这个主题。采取NOSQL技巧的成本较低。最后，假如数据关系不多，不关怀读写冲突，那么可以采取成本更低的文件体系。

我们必需懂得网站制造数据的泉币价值，因为很多公司在艰苦起步时代都阅历过，用A级存储免费寄存TB级的用户数据，很快就会把资金消费完。较好的办法是分层存储数据，依据拜访日期，一直地把较老的数据下推到较廉价的拜访较慢的存储媒体上。这种情形叫做成本一数据价值的困境，即跟着时光流逝，数据价值会下降，然则保留数据的成本会增长。