卷1：第13章 NoSQL生态系统.pdfVIP

卷1 ：第13章 NoSQL⽣态系统 作者：Adam Marcus 译 / iammutex 与本书中提到的其它主题不同，NoSQL不是⼀个⼯具，⽽是由⼀些具有互补性和 争 性的⼯具组成的⼀个概念，是⼀个⽣态圈。这些被称作NoSQL 的⼯具，在存储数据的 ⽅式上，提供了⼀种与 （基于SQL语⾔的）关系型数据库截然不同的思路。要想了解 NoSQL ，我们必须先了解现有的这些⼯具，去理解那些引导它们开拓出新的存储领域 的设计思路。 如果你正在考虑使⽤NoSQL ，你应该会马上发现你有很多种选择。 NoSQL系统舍弃了许了传统关系型数据库的⽅便之处，⽽把⼀些通常由关系型数据库 本⾝来完成的任务交给了应⽤层来完成。这需要开发⼈员更深⼊的去了解存储系统的 架构和具体实现。 13.1 NoSQL其名 在给NoSQL下定义之前，我们先来试着从它的名字上做⼀下解读，顾名思义，NoSQL 系统的数据操作接⼜应该是⾮SQL类型的。但在NoSQL社区，NoSQL被赋予了更具有 包容性的含义，其意为Not Only SQL ，即NoSQL提供了⼀种与传统关系型数据库不太 ⼀样的存储模式，这为开发者提供了在关系型数据库之外的另⼀种选择。有时候你可 能会完全⽤NoSQL数据库代替关系型数据加，但你也可以同时使⽤关系型和⾮关系型 存储来解决具体的问题。 在进⼊NoSQL 的⼤门之前，我们先来看看哪些场景下使⽤ 关系型数据库更合适，哪些使⽤NoSQL更合适。 13.1.1 SQL及其关联型结构 SQL是⼀种任务描述性的查询语⾔，所谓任务描述性的查询语⾔，就是说它只描述他 需要系统做什么，⽽不告诉系统如何去做。例如：查出39号员⼯的信息，查出员⼯的 名字和电话，只查找做会计⼯作的员⼯信息，计算出每个部门的员⼯总数，或者是对 员⼯表和经理表做⼀个联合查询。 简单的说，SQL让我们可以直接向数据库提出上述 问题⽽不必考虑数据是如何在磁盘上存储的，使⽤哪些索引来查询数据，或者说⽤哪 种算法来处理数据。在关系型数据库中有⼀个重要的组件，叫做查询优化器，正是它 来推算⽤哪种操作⽅式能够更快的完成操作。查询优化器通常⽐⼀般的数据库⽤户更 聪明，但是有时候由于没有充⾜的信息或者系统模型过于简单，也会导致查询优化器 不能得出最有效的操作⽅式。 作为⽬前应⽤最⼴的数据库系统，关系型数据库系统以 其关联型的数据模型⽽命名。在关联型的数据模型中，在现实世界中的不同类型的个 体被存储在不同的表⾥。⽐如有⼀个专门存员⼯的员⼯表，有⼀个专门存部门的部门 表。每⼀⾏数据又包含多个列，⽐如员⼯表⾥可能包含了员⼯号，员⼯⼯资，⽣⽇以 及姓名等，这些信息项被存在员⼯表中的某⼀列中。 关联型的模型与SQL是紧密想连 的。简单的查询操作，⽐如查询符合某个条件的所有⾏ （例：employeeid = 3, 或者 salary $ 0000 ）。更复杂⼀些的任务会让数据库做⼀些额外的⼯作，⽐如跨表的联 合查询 （例：查出3号员的部门名称是什么）。⼀些复杂的查询，⽐如统计操作 （例：算出所有员⼯的平均⼯资），甚⾄可能会导致全表扫描。 关联型的数据模型定 义了⾼度结构化的数据结构，以及对这些结构之间关系的严格定义。在这样的数据模 型上执⾏的查询操作会⽐较局限，⽽且可能会导致复杂的数据遍历操作。数据结构的 复杂性及查询的复杂性，会导致系统产⽣如下的⼀些限制： 复杂导致不确定性。使⽤ SQL 的⼀个问题就是计算某个查询的代价或者产⽣的负载⼏乎是不可能的。使⽤简单 的查询语⾔可能会导致应⽤层的逻辑更复杂，但是这样可以将存储系统的⼯作简单 化，让它只需要响应⼀些简单的请求。 对⼀个问题建模有很多种⽅式。其中关联型的 数据模型是⾮常严格的⼀种：表结构的定义规定了表中每⼀⾏数据的存储内容。如果 你的数据结构化并没有那么强，或者对每⼀⾏数据的要求⽐较灵活，那可能关联型的 数据模型就太过严格了。类似的，应⽤层的开发⼈员可能对关联型的数据结构并不满 意。⽐如很多应⽤程序是⽤⾯向对象的语⾔写的，数据在这些语⾔中通常是以列表、 队列或集合的形式组织的，程序员们当然希望他们的数据存储层也能和应⽤层的数据 模型⼀致。 当数据量增长到⼀台机器已经不能容纳，我们需要将不同的数据表分布到 不同的机器。⽽为了避免在不同机器上的数据表在进⾏联合查询时需要跨⽹络进⾏。 我们必须进⾏反范式的数据库设计，这种设计⽅式要求我们把需要⼀次性查询到的数 据存储在⼀起。这样做使得我们的系统变得就像⼀个主键查询系统⼀样，于是我们开 始思考，是否有其它更适合我们数据的数据模型。 通常来说，舍弃多