NoSQL：一个帝国的崛起

寒哥哥 發表於 2021-2-3 17:17:00

<h2>01关系数据库帝国</h2>
现在是公元2009年，关系帝国已经统治了我们30多年，实在是太久了。 
1970年，科德提出关系模型，1974年张伯伦和博伊斯制造出了SQL ，帝国迅速建立起了统治。 
从北美到欧洲，从欧洲到亚洲，  无数程序员臣服在他的脚下。 
帝国给我们提供了良好的福利：
简单而强大的关系模型
灵活的SQL
还有我们非常喜欢的事务和ACID，把我们从底层并发的细节中解放出来。 
使用这些福利，程序员们开发了无数的系统，每个系统的核心都是关系数据库。 
时代在不断地变迁，编程语言的城头不断变换大王旗，但是存储在表格中的数据，一直岿然不动。 
数据永远是一个企业最宝贵的资产。 
但是帝国也给我们套上了沉重的枷锁：模式和规范化。 
帝国规定：必须事先定义好模式（表结构）才能保存数据！ 
所有的数据至少得满足第一范式，甚至第二范式、第三范式、BCNF范式！
 如果实现不了，就会被投进监狱，对于某些部落来讲，即使是做一个简单的冗余字段，都会被别人耻笑。 
帝国宣称的SQL移植性也欺骗了我们，SQL虽然被标准化，但是每个厂商DB2, Oracle, SQL Server都有自己的方言！ 
尤其是在计算日期和字符串操作。还有存储过程，几乎每个厂商都会自己搞一套，根本无法移植！
 
<h2>
02 危机</h2>
 
上世纪90年代，面向对象技术的流行给帝国带来了一次严重的危机： 
对象-关系的阻抗不匹配。 
“对象（Object）”有继承，子类，父类，关联，聚合，多态； 
而关系数据库就是简单的表格！ 
他们是如此的不同，简直是水火不容，矛盾不可调和。
 <img src="https://img2020.cnblogs.com/blog/1148403/202102/1148403-20210203170221299-234379988.jpg">
那个时候，帝国的东边出现了一个叫面向对象数据库OODB的部落，号称可以把Java对象，C#对象，Ruby对象等等都一股脑地、直接存储到OODB当中去。 
把对象直接保存到数据库？这实在是一个美妙的特性。 
但是OODB实在是不争气，很快偃旗息鼓，在几个小领地苟延残喘。 
2001年，有个叫Gavin King的27岁小伙子，开发了一个叫做Hibernate 的东西，在对象和关系之间搭了一座桥，叫O/R Mapping。 
<img src="https://img2020.cnblogs.com/blog/1148403/202102/1148403-20210203170258914-980818249.jpg">
这一下子赢得了Java 程序员的芳心。 
Hibernate再接再励，又推出了NHibernate，打入了.NET的领地。 
随着iBatis, JPA等更多O/R Mapping工具和接口的出现，关系数据库帝国成功地度过了这一次的危机。 
后来有个好事者Martin Fowler，居然写了一本书《企业应用架构模式》，在里边一本正经地把各种O/R Mapping的模式都总结了一遍：“单表继承”，“类表继承”，“活动记录”。。。。。。 
这一番骚操作又替关系数据库帝国续命20年不止。 
 
<h2>
03 新希望</h2>
 
没过多久，互联网大潮来了，历史再次给了我们一个机会。 
互联网的用户数如此之多，并发数如此之高，让我们始料未及。 
数据量是如此巨大，数据种类如此丰富，更让我们目瞪口呆。 
文字、图片、链接、日志、社交关系，大量的数据蜂拥而至，单台机器上的数据库很快就撑不住了。  
帝国先是拼命扩容，恨不得把一台机器弄成1024G的内存，1024T的硬盘，还美名其曰垂直扩展。 
但是机器功能越强，价格就越贵，臣民们的税负越来越重，很快就受不了了。 
没办法，帝国只好做水平扩展，把数据分布在多台机器上，这需要精心的规划，还需要程序员和应用程序精确地记住每一份数据放在哪里。 
更要命的是，这种办法丢掉了帝国引以为傲的福利：事务和一致性 
<img src="https://img2020.cnblogs.com/blog/1148403/202102/1148403-20210203170532874-1463010759.jpg">
 
 
<h2>
04 反抗</h2>
 
我决定反抗这个庞大的帝国，  我偷偷地带领着一帮志同道合的兄弟离开了，我们要新建一块清新自由的领地。  
我们仔细地研究了关系帝国的缺点，派出了几只小分队分头出击。 
誓师出征之时，我们对这四只小分队都提出了同样的要求：支持分布式和集群!!! 
第一支小分队由redis担任队长，memcached 担任副手，他们很快便取得了成功，因为他们打击到了关系帝国最大的缺点：高并发下，数据库IO非常缓慢。 
redis和memcached 做了一个大胆的决定，抛弃了硬盘，选择了比硬盘快几万倍的内存，把数据以key-value的方式放入其中。 
超快的速度让程序员们非常喜欢，他们不仅把session，配置信息，购物车的数据放入其中。 
后来干脆把他俩当成了缓存来使用。 
<img src="https://img2020.cnblogs.com/blog/1148403/202102/1148403-20210203170617154-2047183484.jpg">
 
第二支小分队由Mongodb带领，CouchDB辅佐，他们敏锐地瞄准了用关系数据表保存起来很别扭的数据。
 
<img src="https://img2020.cnblogs.com/blog/1148403/202102/1148403-20210203170636203-1431301500.jpg">
 
<img src="data:image/gif;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVQImWNgYGBgAAAABQABh6FO1AAAAABJRU5ErkJggg==" data-type="gif" data-w="1">
订单到订单项和支付，订单项到产品是典型的一对多关系，意味着数据是树状结构，那为什么不直接用一个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，这家伙非常擅长图结构，对于社交网络、推荐系统的数据，用它来表示非常合适。
<img src="https://img2020.cnblogs.com/blog/1148403/202102/1148403-20210203170703406-1471873046.jpg">
 
第四支小分队由HBase带领， Cassandra殿后，他们都是列式数据库，百亿行 * 百万列的数据对于他俩来说稀松平常。
 <img src="https://img2020.cnblogs.com/blog/1148403/202102/1148403-20210203170727896-796354624.jpg">
 这个小分队也获得了巨大的成功，移动互联网所产生的海量数据，如日志、聊天记录，监控数据，物联网的数据，结构化并不强，非常适合用HBase这种列式数据库来存放。
 
<h2>
05 新的帝国</h2>
 
几年以后，四支小分队顺利班师，都带回了大批的程序员拥趸，因为适合的才是最好的。 
一个新的、可以和关系数据库抗衡的帝国悄然成型。 
经过一番激烈讨论，我们给帝国起了一个响亮的名称：NoSQL。 
意思是不要SQL！ 
但是，加入NoSQL帝国的程序员发现我们也有非常明显的弱点： 
缺乏模式（如表结构）、数据完整性约束很弱、对事务的支持很弱，甚至干脆没有，这引起了程序员的强烈不满和抗议。 
有不少人短暂尝鲜NoSQL以后，又抛弃了我们，重回SQL的怀抱。 
我们决定和关系数据库帝国议和，告诉他们说NoSQL的意思是Not Only SQL，我们两大帝国应该取长补短，和平共处。 
经历了几年战火的关系数据帝国也看清楚了IT趋势，欣然接受。 
从此，数据库进入了混合存储的时代！ 
 
公众号码农翻身
 
<img src="https://img2020.cnblogs.com/blog/1148403/202102/1148403-20210203171153948-983078700.png"> 
来源：https://www.cnblogs.com/onlyliuxin/p/14368077.html

頁: [1]

琼殿技术论坛's Archiver

NoSQL：一个帝国的崛起