再次说明，这是摘要。。当然其中由于避免语义的断裂，会增加一点点点过度文字，但是基本上不会改变愿意。

--------------------------------------------------------------------------------------------------------------------------------

@H_301_5@关系型数据库的价值：

1. 获取持久化数据；
2. 并发（a.多个用户一起访问同一份数据体，并可能修改；b.“事务”便于控制数据访问，并发时可以良好运行；c.“事务”可以回滚，保证数据不受破坏）；
3. 集成（共享数据库集成(shared database integration)，多个应用程序将数据保存在同一数据库中，便于使用彼此的数据，数据库的并发机制也可以应对多个应用程序）；
4. 近乎标准的模型（以近乎标准的方式，提供了上述核心优势；开发人员和数据库专家可以学习基本的关系模型，并将其运用到项目中；尽管各关系型数据库之间仍有差异，但其核心机制相同：sql方言(dialect)相似，“事物”操作方式几乎一样）。

阻抗失衡

“阻抗失衡”，是指关系模型和内存中的数据结构之间存在差异。这也是最令应用程序开发者失望的。

关系模型把数据组织成“表(table)”和“行(row)”，更准确的说，是“关系(relation)”和“元组(tuple)”。在关系模型中，元组是由“键值对”构成的集合，而关系则是元组的集合。sql操作所使用及返回的数据都是“关系”，于是就形成了关系代数（relational algebra）。

建立在“关系”基础的数据库，虽有几分优雅和简洁，但是也产生了一些局限，特别是“关系元组(relational tuple)”中的值必须很简单才行。它们不能包含“嵌套记录(nested record)”或“列表(list)”等任何结构。而内存中的数据结构则无此限制，它可以使用的数据组织形式比“关系”更丰富。这样，如果在内存中使用了较为丰富的数据结构，那么在保存到磁盘之前，必须将其转换成“关系”形式。于是，“阻抗失衡”发生了：需要在两种不同的表示形式之间转译。

现在，随处可见的“对象-关系映射框架(object-relational mapping framework)”可以轻松解决阻抗失衡问题，例如“hibernate”，“ibatis”。它们实现了著名的“映射模式(mapping pattern)”。然而，映射问题依然存在。“关系-对象映射框架”简化了很多工作，但如果过分依赖它而刻意不使用数据库的话，那么这套框架本身就成了问题：因为查询性能会下降。

“应用程序数据库”和“集成数据库”

1.sql充当了应用程序之间的一种集成机制，在这种情况下，成了“集成数据库(integration database)”：由不同团队所开发的多个应用程序，将其数据存储在一个公用的数据库中。这提高了数据通信的效率，因为所有应用程序都在操作内容一致的持久数据。

但是其也有缺点：为了能将很多应用程序集成起来，数据库的结构必须设计得复杂一些。事实上，它比单个应用程序所用到的结构复杂很多。

2.“应用程序数据库”，其内容只能由一个应用程序的代码库直接访问，而这份代码库由一个团队来维护。这样一来，模式的维护和更新就更容易了。

一旦决定使用应用程序数据库，那么选择具体数据库技术的余地就更大了。由于内部数据库与外部通信服务之间已经解耦，所以外界并不关心数据如何存储，这样就可以选用非关系型数据库了。此外，关系型数据库的许多特性，诸如安全性等，对应用程序用处不大，因为它们可以交给使用该数据库的外围应用程序(enclosing application)来做。

尽管应用程序数据库很自由，但它却不会对其他数据存储方式造成很大冲击。大多数愿意采用应用程序数据库的团队，还是无法摆脱关系型数据库。

蜂拥而至的集群

关系型数据库并不是设计给集群用的。Oracle RAC或sql Server这种适用于集群的关系型数据库，要依靠一种名为“共享磁盘子系统(shared disk subsystem)”的概念才能运行。它们使用一种可以支持集群的文件系统，但这样一来，磁盘子系统就成了整合集群的“软肋(a single point of failure)”。关系型数据库也可以对数据库分片，虽然这样能将负载分散到多个服务器中，但是应用程序必须控制所有分片，而且，查询、参照完整性(referential integrity)、事务、一致性控制(consistency control)等操作也都无法以跨分片的方式执行了。

除了技术问题外，还有一个更麻烦的地方，就是许可费。商用的关系型数据库通常按单台服务器计费，所以在集群中使用会非常贵。

Nosql登场

(此部分主要讲了Nosql的由来和理念，无法很好的摘要，有兴趣的，可以读一下原书~)

事实上，本书假定Nosql数据库作为应用程序数据库来用，我们觉得集成数据库一般不宜采用Nosql技术。这不应视为Nosql的缺陷，相反，即便不使用Nosql，也应该考虑把集成数据库中的数据转到应用程序数据库中，并将其封装起来，改用web服务来在应用程序间通信，这是个良好的迁移方向。

记住选用Nosql的两个@H_301_5@主要原因：

1. 待处理的数据量很大，或对数据访问的效率要求很高，从而必须将数据放在集群上；
2. 想采用一种更为方便的数据交互方式来提高应用程序开发效率。

要点：

• 由于关系模型与内存中的数据结构不匹配，所以应用程序开发人员一直为这种阻抗失谐问题所困扰。
• 数据库领域的迁移趋势是：原来，各个应用程序都把同一份数据库当成公用的集成点(integration point)，而现在，各个应用程序都会封装自己的数据库，并通过服务彼此集成。
• 促使数据存储方式发生变化的重要原因是：需要在集群上运行大量数据，而关系型数据库不能在集群上高效运行。
• 各种Nosql数据库的共同特性：不使用关系模型；在集群中运行良好；开源；适用于21世纪互联网公司；无模式
• Nosql崛起产生的重要影响：混合持久化

----------------------------------------------------------------------------------------------------------------------------

这章主要讲的是一些Nosql产生的背景，对背景有了一定的了解，才能更好的接受Nosql这个技术。