IT 江湖之数据库篇

宸羽翔暮樱雪

天下武学，本就如江河分流，难分支派。然依然创新不断，新秀层出。


上次说到类似于剑学的内外兼修的机器学习，没料想事有凑巧，第二天就爆出 Google 机器人与人在围棋场的战争，这就还引发了 Google 和 Facebook 之间的撕扯(这事两方都有朋友围观，我就不在这公开八了)。不过基本大家可以一致的一个看法，就是 Google 的成功，一定程度上来自于对机器学习的应用，而成功更大的决定因素，其实是靠着大数据、海量计算、和工程师体力堆出来的。


然而话说回来，Google 有的是钱、优秀的PhD、和大量的工程师，他们几乎可以做出任何他们想做的东西。你知道咋回事并没有什么卵用，反正你做不出来。


所以当今 IT 界武艺的对决，重要的可能已经不再是招式的新奇，而更多的是对大数据的采集、存储、和应用。数据存储技术，已经如内家心法，是每个江湖支派必修的技艺。




从两大内功心法说起

九阳神功：该神功变化繁复，但是驱动之法具有固定套路。初步功夫是练大周天搬运，使一股真气从丹田向镇锁任、督、冲三脉的尾闾关，然后分两支上行，经腰脊第十四椎两旁的辘轳关，上行经背、肩、颈至玉枕，然后真气入头顶的百会穴，分五路上行，与全身气脉大会于膻中穴，再分主从两支会合于丹田，如此循环一周，练出氤氲紫气。九阳真气浑厚无比，张无忌在《倚天屠龙记》里凭借此功可以轻易运使乾坤大挪移跟七伤拳等绝技。


小无相功：逍遥派的上乘内功之一，可以不着迹象模仿其他门派的武学。本是道家之学，讲究清静无为，神游太虚，较之佛家武功中的无色无相之学，名虽略同，实质大异。小无相功博大精深，以无相两字为要旨，不着形相，无迹可寻，若非本人也是此道高手，决计看不出来。它的威力也决不在任何少林绝技之下。小无相功另一奇妙之处，是可以此功驾驭众多武林绝技，鸠摩智就曾以小无相功代替少林内功，修炼七十二绝技。小无相功精微渊深，以此为根基，少林寺的七十二绝技，倒也皆可运使，只不过细微曲折之处，不免有点似是而非罢了。


却说那日在缥缈峰上，虚竹和段誉各为心上人唏嘘感叹，只道：“是啊，佛说万法缘生，一切只讲缘份……不错……那缘份……当真是可遇不可求……。” 虽是各自心里认定的是不同的人，然因着两人各有一份不通世俗的呆气，竟然越说越投机。


次日，灵鹫宫诸女摆开筵席，虚竹和段誉便携手入座。诸洞岛群豪是灵鹫宫下属，自然谁也不敢上来和虚竹同席。虚竹不懂款客之道，见旁人不过来，也不出声相邀，只和段誉讲论。一个全心全意沉浸在对王语嫣的爱慕之中，没口子的夸奖，说她性情如何和顺温婉，姿容如何秀丽绝俗。另一个却以为说的是梦姑，见有人没口子夸奖这位姑娘，正合心意，便也随声附和，其意甚诚。两人各说各的情人，缠夹在一起，只因谁也不提这两位姑娘名字，言语中的榫头居然接得丝丝入扣。


酒过几旬，唠唠叨叨的谈到半夜。群豪起立告辞，虚竹和段誉酒意都有八九分了，仍是对饮讲论不休。


段誉问道：“二哥你出自少林，如今又练成了道家的小无相功。一你看来，这小无相功比起佛家的九阳神功又当如何?”


虚竹想了想，回道：“我哪里懂得那么许多，不过在我看来，二者最大的区别，可能在于对气在体内的收纳挪运之法不同吧。”


“打个比方，这九阳神功就好像传统的关系数据库，数据的存储和取出都是基于将数据很严格的用表格的方式来组织的。而小无相功讲究无形无相，这就好像 NoSQL 数据库中，数据是根据特定的应用来很灵活的存储数据。”




数据的存储模型

传统的关系数据库很好理解，大家常见的 Oracle DB，MySQL，PostgreSQL，都是这样的。因为数据的每一个属性，都以特定类型的属性值来表示，因此，数据库的数据很容易被想象成是一个表格。


相对而言，NoSQL 数据的存储模型就多种多样了。常见的，比如说：


Hirearchical 数据库，基于父子关系的类似于 tree 结构的模型。代表数据库如 IMS。


网络数据库，和 Hirearchical 数据库很类似，但是数据模型是有向无环图而不是树。代表数据库如 IDMS。


面向对象数据库，因为不是存实际属性数据，而是存指针，扩展性很强。代表数据库如 Versant。


XML 数据库，数据以 XML 格式组织，如 MarkLogic


基于 Document 的数据库。这种情况每一列没有固定的类型。常见的数据格式比如 CSV 和 MS Excel，甚至是 JSON 数据或文件集合。代表数据库如 MongoDB 和 CouchDB。


最常见的 NoSQL 数据库可能数 Key-Value Store了，这和基于 Document 的数据库有时没有一个很明确的界限，甚至更经常的是把基于 Document 的数据模型作为一种特殊的 Key-Value 来看待。比如 MongoDB，它是用类似于 JSON 的 ducument 来组织数据，通过一个动态的 schema 来支持 indexing。




性能的取舍

段誉点点头道：“是这样了，然所有武功，强便是弱，弱便是强。虽说无形无相必见长于灵巧，但想来也有它的不足之处吧?”


NoSQL 的流行，正是因为这几年对大数据的应用，以及 FLAG(注1) 等公司近几年在 web 2.0 (注2) 应用上的需求。 由于这些应用产生的数据多种多样，NoSQL 首先就在于设计的简单化，和对数据表示的灵活性。


注1：FLAG 即 Facebook，Linkedin，Amazon/Apple，Google。


注2：web 2.0 即强调用户生成内容、对话、和交互等的新一代互联网，区别于大部分内容只是用户静态来阅读的web 1.0。


此外，当数据量大到一个程度时，对机器集群的 “horizontal” 扩展就成了一个必要的需求，而这正是传统关系数据库系统的一个弱点。因此，NoSQL 在数据的 scalability 和 availability 上的优化是它最明显的优势。


那么这样的灵活性是以什么为代价呢?


一个最明显的，NoSQL 是用 consistency 来换取 scalability 的。什么意思呢?在每个分布式计算模型中都有一个数据一致性问题，这个一致性可以简单想象成系统有写操作后后续的读是不是都能立马读取到最新的更新值。分布式系统的一致性的强一致性通常称为 ACID (Atomicity, Consistency, Isolation, Durability) ，这是传统关系型数据库大都可以做到的。分布式系统的一致性的弱一致性的一个典型也被称为 BASE (Basically Available, Soft state, Eventual consistency) ，而我们所说的很多 NoSQL 系统都只能达到数据的 BASE 一致性。当然，不同系统也可能达到这两种一致性的某个中间值。


这就是计算机理论中 CAP 理论的一个体现。CAP 理论说的是什么呢?简单说来，就是在分布式计算系统中，下面三个 guarantee 最多能达到两个：

宸羽翔暮樱雪

Consistency (all nodes see the same data at the same time)

Availability (a guarantee that every request receives a response about whether it succeeded or failed)

Partition tolerance (the system continues to operate despite arbitrary partitioning due to network failures)

换句话说，NoSQL 系统大都是用数据一致性来换取高可用性和高容错性。

当然，不同的 NoSQL 系统可能还面临着别的问题，比如不能任意 JOIN 多个表，或是没有一个正规化的接口，或是和现有数据库间的数据转化和兼容的问题等等。


问题驱动创新

既然 NoSQL 有着这样的问题，而实际应用中，有时候我们对数据库是同时需要 ACID 的保证和高可用的需求，因此，就有了一些新的数据库系统应运而生。之前我的文章提到的 Google Spanner 和蚂蚁金服的 OceanBase 都是分布式事务领域高可用数据库的典型。

今天想提的，是另一个数据库系统 Vertica。Vertica 这个数据库虽然还是被划分为关系型数据库，因为它的数据模型还是基于表格的。然后 Vertica 与传统的关系型数据库至少有两点不同：

Vertica 是面向 Analytic 的而不是面向事务的。换句话说，相对于数据库的写，Vertica 应用更广泛的领域是大量的读以及对数据的 aggregation 等。

Vertica 的存储模型是用一种基于列存储的叫做 Projections 的概念，简单来说，这种存储模式让数据的 partition 和 segmentation 变得更灵活易操作。

Vertica 并不是一个被广泛应用的数据库系统，这里为什么要举这个例子呢?
一方面，我们之前说了因为 CAP 理论，通常的数据库系统总有一个利弊的取舍。但是如果针对一个特定的应用来设计一个系统，并且做出对底层硬件和体系结构的合理的选择和架构，就有可能最大程度的针对某一特定应用最大化的达到性能取舍上的一个平衡。

另一方面，这个数据库系统的原型称为 C-Store，最开始，是学术界的一个 research project，经过长达七年才演变成一个成功的业界的产品。可见，数据库系统的设计面对当今应用的新的挑战，也正是一个有待英雄辈出的契机。


身边的公司用的是什么?

如果你去看看硅谷的一些公司对数据库系统的应用，除了 Google 这种泰山级公司可能会开发一套完整的自己的存储系统，大部分中小公司如 Twitter，Airbnb，Pinterest 等数据库系统都不是单一的，而是多个系统并存。通常的配置是这样的：

核心事务和数据都还是使用 MySQL，少数会使用 PostgreSQL

某种 NoSQL 数据库如 Cassandra 或 MongoDB 来满足对非核心数据的高可用。

若干分布式内存缓存系统，如 Memcached 和 Redis

视具体情况的别的数据存储系统。

当然 ，Twitter 一年多前也搭建了自己的数据库系统，叫做 Manhattan。Manhattan 的 blog 上是这么说的：

Many of Twitter’s applications fit very well into the eventually consistent model. We favor high availability over consistency in almost all use cases, so it was natural to build Manhattan as an eventually consistent system at its core.

说白了，就是用 consistency 来换取 high availability 的典型。


End.

作者：朱赟
来源：微信公众号 董老师在硅谷

宸羽翔暮樱雪

Consistency (all nodes see the same data at the same time)

Availability (a guarantee that every request receives a response about whether it succeeded or failed)

Partition tolerance (the system continues to operate despite arbitrary partitioning due to network failures)

换句话说，NoSQL 系统大都是用数据一致性来换取高可用性和高容错性。

当然，不同的 NoSQL 系统可能还面临着别的问题，比如不能任意 JOIN 多个表，或是没有一个正规化的接口，或是和现有数据库间的数据转化和兼容的问题等等。


问题驱动创新

既然 NoSQL 有着这样的问题，而实际应用中，有时候我们对数据库是同时需要 ACID 的保证和高可用的需求，因此，就有了一些新的数据库系统应运而生。之前我的文章提到的 Google Spanner 和蚂蚁金服的 OceanBase 都是分布式事务领域高可用数据库的典型。

今天想提的，是另一个数据库系统 Vertica。Vertica 这个数据库虽然还是被划分为关系型数据库，因为它的数据模型还是基于表格的。然后 Vertica 与传统的关系型数据库至少有两点不同：

Vertica 是面向 Analytic 的而不是面向事务的。换句话说，相对于数据库的写，Vertica 应用更广泛的领域是大量的读以及对数据的 aggregation 等。

Vertica 的存储模型是用一种基于列存储的叫做 Projections 的概念，简单来说，这种存储模式让数据的 partition 和 segmentation 变得更灵活易操作。

Vertica 并不是一个被广泛应用的数据库系统，这里为什么要举这个例子呢?
一方面，我们之前说了因为 CAP 理论，通常的数据库系统总有一个利弊的取舍。但是如果针对一个特定的应用来设计一个系统，并且做出对底层硬件和体系结构的合理的选择和架构，就有可能最大程度的针对某一特定应用最大化的达到性能取舍上的一个平衡。

另一方面，这个数据库系统的原型称为 C-Store，最开始，是学术界的一个 research project，经过长达七年才演变成一个成功的业界的产品。可见，数据库系统的设计面对当今应用的新的挑战，也正是一个有待英雄辈出的契机。


身边的公司用的是什么?

如果你去看看硅谷的一些公司对数据库系统的应用，除了 Google 这种泰山级公司可能会开发一套完整的自己的存储系统，大部分中小公司如 Twitter，Airbnb，Pinterest 等数据库系统都不是单一的，而是多个系统并存。通常的配置是这样的：

核心事务和数据都还是使用 MySQL，少数会使用 PostgreSQL

某种 NoSQL 数据库如 Cassandra 或 MongoDB 来满足对非核心数据的高可用。

若干分布式内存缓存系统，如 Memcached 和 Redis

视具体情况的别的数据存储系统。

当然 ，Twitter 一年多前也搭建了自己的数据库系统，叫做 Manhattan。Manhattan 的 blog 上是这么说的：

Many of Twitter’s applications fit very well into the eventually consistent model. We favor high availability over consistency in almost all use cases, so it was natural to build Manhattan as an eventually consistent system at its core.

说白了，就是用 consistency 来换取 high availability 的典型。


End.

作者：朱赟
来源：微信公众号 董老师在硅谷