01关系数据库帝国公元2009年，关系帝国统治了我们30多年，时间太长了。1970年，Codd提出了关系模型。1974年，张伯伦和博伊斯创建了SQL，帝国迅速确立了统治地位。从北美到欧洲，从欧洲到亚洲，无数程序员臣服于他的脚下。Empire为我们提供了很好的好处：简单而强大的关系模型，灵活的SQL，以及我们非常喜欢的事务和ACID，让我们摆脱了底层并发的细节。利用这些优势，程序员开发了无数系统，每个系统的核心都是关系数据库。时代在不断变化，编程语言的掌门人也在不断更换王者的旗帜，但表中存储的数据却一直没有变。数据永远是企业最宝贵的资产。但帝国也给我们戴上了沉重的枷锁：模式化和规范化。帝国规定必须提前定义好schema（表结构）才能保存数据！所有数据至少要满足第一范式，甚至第二范式、第三范式、BCNF范式！如果达不到，就会被投入监狱。对于一些部落来说，哪怕是做一个简单的多余的田地，都会遭到别人的嘲笑。帝国号称的SQL可移植性也欺骗了我们。尽管SQL是标准化的，但每个供应商的DB2、Oracle和SQLServer都有自己的方言！特别是在计算日期和字符串操作方面。还有存储过程，几乎每个厂家都会自己做，根本移植不了！02危机20世纪90年代，面向对象技术的普及给帝国带来了严重的危机：对象-关系的阻抗失配。“对象”有继承、子类、父类、关联、聚合、多态；而关系数据库是一个简单的表！他们天差地别，简直水火不容，矛盾不可调和。当时在帝国东方出现了一个叫做面向对象数据库OODB的部落，号称可以在OODB中直接存储Java对象、C#对象、Ruby对象等。将对象直接保存到数据库？这真是一个很棒的功能。但是OODB实在是让人失望，很快就平息了，徘徊在几个小领地里。2001年，一个名叫GavinKing的27岁男孩开发了一种叫做Hibernate的东西，它在对象和关系之间架起了一座桥梁，叫做O/RMapping。这一下子赢得了Java程序员的心。Hibernate再接再厉，推出了NHibernate，进入了.NET的版图。随着iBatis、JPA等更多O/RMapping工具和接口的出现，关系型数据库帝国成功度过了这场危机。后来好人MartinFowler居然写了一本书《企业应用架构模式》，里面总结了各种O/RMapping模式：“SingleTableInheritance”，“ClassTableInheritance”，“ActivityRecord”。.....这种风骚操作，延续了关系型数据库帝国20多年的生命。03新希望没过多久，互联网大潮来了，历史又给了我们一次机会。上网人数这么大，并发数这么高，是我们没有想到的。数据量之大，数据种类之丰富，更是让我们目瞪口呆。文字、图片、链接、日志、社交关系，大量的数据涌入，单机上的数据库很快就支撑不住了。帝国先是拼命扩容，想把一台机器做成1024G内存和1024T硬盘，这叫纵向扩容。但机器越厉害，越贵，臣民的税负也越来越重，很快就会不堪重负。没办法，帝国不得不横向扩展，将数据分布在多台机器上，这需要仔细规划，需要程序员和应用程序准确记住每条数据的放置位置。更何况，这种方法失去了帝国引以为豪的好处：交易和一致性04抵抗我决定反抗这个庞大的帝国，我偷偷带领一群志同道合的兄弟离开，我们要建立一个新的自由领地.我们仔细研究了关系帝国的短板，派出几个小队分头进攻。我们在宣誓的时候，对这四个团队提出了同样的要求：支持分布式和集群！！！第一队以redis为队长，以memcached为副。他们很快就成功了，因为他们击中了关系帝国最大的短板：高并发下，数据库IO很慢。Redis和memcached做了一个大胆的决定，抛弃了硬盘，选择了比硬盘快数万倍的内存，将数据以key-value的形式放入其中。超快的速度让程序员非常喜欢。他们不仅将会话、配置信息和购物车数据放入其中。后来，它们被简单地用作缓存。第二个团队由Mongodb领导并由CouchDB协助，他们敏锐地瞄准了难以存储在关系表中的数据。Ordertolineitemandpayment，lineitemtoproduct是典型的一对多关系，也就是说数据是一个树状结构，那为什么不直接用一个JSON文档来表示呢？{"orderId":"1","userId":"123","lineItems":[{"productId":"1356","qty":"1"},{"productId":"2375","qty":"2"}],"shippingAddress":{"type":"xxx","address":"xxx"},"payment":{"type":"alipay","time":"xxxx》}}MongoDB还可以和JavaScript、Node.js挂钩，将浏览器发送过来的JSON数据直接存储到MongoDB中，简单方便。第三个团队的领导者是Neo4j。这家伙很擅长图结构。非常适合表示社交网络和推荐系统的数据。第四个团队由HBase领导，其次是Cassandra。它们都是列式数据库，百亿行*百万列的数据对它们来说很常见。这个小团队也取得了巨大的成功。移动互联网产生的海量数据，如日志、聊天记录、监控数据、物联网数据等，结构化程度不高，非常适合存储在HBase等列式数据库中。05NewEmpire几年后，四支小队都招揽成功，都带回了一大批程序员粉丝，因为适合自己的才是最好的。一个可以与关系型数据库抗衡的新帝国已经悄然形成。经过一番激烈的讨论，我们给这个帝国起了一个响亮的名字：NoSQL。这意味着没有SQL！但是，加入NoSQL帝国的程序员发现，我们也有非常明显的弱点：缺乏schema（如表结构）、数据完整性约束弱、对事务的支持弱或不支持，这引起了程序员的哗然和抗议。初尝NoSQL之后，很多人抛弃了我们，重新回到了SQL的怀抱。我们决定和关系型数据库帝国讲和，告诉他们NoSQL意味着NotOnlySQL，我们两个帝国应该相互学习，和平共处。经历了数年战火的关系型数据帝国，也看清了IT趋势，欣然接受。从此，数据库进入了混合存储时代！
