《设计数据密集型应用》第二章(1) 数据模型

本章讲述了数据应用中的两个基本概念：

Data Models
Query Languages

本节先记录Data Models相关的读书笔记。

数据模型（Data models）是软件开发中最重要的部分，不仅仅在于数据模型决定了软件是如何开发的，更关键的是，它体现了开发者在面对待解决的问题时，是如何思考的。

本章介绍了数据模型中的：关系型模型（relational model），文档模型（document model）和基于图的数据模型（graph-based data models）等。这里重点介绍前两种的模型的特点，实际应用中常常会遇到的也是这两种模型之间的选择。

关系型模型

大家对关系型模型可能都已经很熟悉了，SQL就是最出名的模型。关于SQL中的两个概念，和关系型模型的关系，这里简单回顾一下：

数据组织成关系，关系即SQL中的表
每个关系中的一组无序元组，对应SQL中的一行

关系型数据库的出现最早在19世纪60年代，当时主要是为了解决商业数据处理的问题，这类场景目前仍是非常常见的，比如销售、银行交易、航线预定、股票交易等。

关系型数据库的优点在于处理Many-to-One和Many-to-Many的数据结构。关系型数据模型，可以容易地将数据结构拆解为一系列的由外键关联的表，这些表之间的JOIN操作是很方便的。

各类查询优化器（Query optimizer）在经过多年的研究已经很成熟了，在使用关系型数据库时，如果需要新的查询模式，只需要对查询的字段新建索引，在查询时就会自动使用最合适的索引，完全不需要改变查询SQL。

以下是用户简历的数据结构设计，这里需要注意的是，region和industry都进行相应的ID编码。ID编码和直接使用字符串存储相比，好处主要有以下几点：

避免了字符串可能引起的歧义
容易修改，只需修改编码出的名称，无需对每行数据进行修改
容易搜索，ID搜索币字符串搜索更简单，并且可以扩展范围

Relational Model

文档模型

NoSQL在20世纪初，作为关系型模型统治的挑战者而出现。它的出现主要是用来解决关系型模型的问题，比如对大数据集和高写入量的处理、对特殊查询操作的支持、以及更加动态和灵活的数据结构。

文档模型最适合处理的是One-To-Many的数据模型。JSON这类的数据结构，有着更高的本地性（locality），使得可以在一次查询得到关联的信息，而不需要通过复杂的关联查询。

以下是用户简历通过JSON来进行存储的结果。

{
    "user_id": 251,
    "first_name": "Bill",
    "last_name": "Gates",
    "summary": "Co-chair of the Bill & Melinda Gates... Active blogger.",
    "region_id": "us:91",
    "industry_id": 131,
    "photo_url": "/p/7/000/253/05b/308dd6e.jpg",
    "positions": [{
        "job_title": "Co-chair",
        "organization": "Bill & Melinda Gates Foundation"
    }, {
        "job_title": "Co-founder, Chairman",
        "organization": "Microsoft"
    }],
    "education": [{
        "school_name": "Harvard University",
        "start": 1973,
        "end": 1975
    }, {
        "school_name": "Lakeside School, Seattle",
        "start": null,
        "end": null
    }],
    "contact_info": {
        "blog": "http://thegatesnotes.com",
        "twitter": "http://twitter.com/BillGates"
    }
}

由于存储的是One-To-Many的关系，文档模型更像一个树状模型，上述的例子可以画成以下的图形结构。

Document Model

文档模型对关联的支持不好，这使得此类查询需要在代码中，多次查询数据库，并模拟关联操作才能实现。因此，有些数据模型，在设计初期时是不需要关联的，但随着发展，数据特性之间存在更加互联的趋势时，文档模型就不再合适了。

数据模型的选择

以下是影响应用开发选用数据模型的几个问题：

简化应用代码

如果我们的数据是更偏向于文档结构的，那么使用文档模型往往是个好主意。但需要注意，在文档模型中，无法直接指向文档中的一个具体元素，而需要逐层递进的指定，这对于层次较深的结构，可能会比较麻烦。

如果应用中需要使用Many-To-Many关系的话，那么使用关系型模型会更好。因为文档模型需要进行关联操作的模拟，在增加代码复杂性的同时，并不一定会有好的性能。

表结构的灵活性

文档性数据库通常被称为无结构的（schemaless），其实更准确的提法应该是读取时获取表结构（schema-on-read），也就是数据结构是隐形的，只要当读取数据时才会解析。

与之相对的关系型数据，它可以被称为是写入时获取表结构（schema-on-write），也就是表结构的显性的，数据库保证了写入数据的格式与表结构相符。

对于关系型数据库来说，修改表结构的代码是高昂的，需要在表中增加一列，并将新列的值设置为NULL，这些操作是非常耗时的。

比如以下的例子，将原来保存用户全名的字段，改为只保存用户的first_name。关系型数据库需要进行以下操作：

ALTER TABLE users ADD COLUMN first_name text;
UPDATE users SET first_name = split_part(name, ' ', 1); -- PostgreSQL
UPDATE users SET first_name = substring_index(name, ' ', 1); -- MySQL

而文档性数据库，只需要将新的字段作为key构造数据JSON，然后保存在数据库中即可。

if (user && user.name && !user.first_name) {
    // Documents written before Dec 8, 2013 don't have first_name
    user.first_name = user.name.split(" ")[0];
}

所以在字段不确定，或容易受到外部系统影响而修改时，建议使用文档性数据库，减小表结构修改的成本。

查询时的数据本地性

本地存储（storage locality）是指数据被分在不同的表中时，倾向于将所有表保存在同一位置。这样做的好处是可以在同一时刻获取大量的数据。

对于文档型数据库来说，修改文档中的任一值，都需要将所有信息读取出来，进行更新然后写回数据库，这是一个很明显的浪费，也限制了很多文档性数据库的使用场景。

文档性和关系型数据库的融合

目前新升级的关系型数据库也支持JSON等格式的存储，而文档性数据库，也在增加对关联操作的支持。这两种数据库正在取长补短，朝着最大化满足数据开发者需要的方向发展。

总结

数据模型的选择，通常和数据的组织结构有关。一般情况下，如果是One-To-Many的数据结果，优先考虑使用文档型模型；如果是Many-To-One或Many-To-Many的数据结构，优先考虑使用关系型模型。当然还需要考虑项目可能的新特性，使得数据结构可能变化。把握好这一主要因素，这两种数据模型就不会选错了。