一
旗帜鲜明地先说结论:之所以新的分布式数据库又开始支持关系模型了,是因为大部分程序员的数据库水平太糟糕。
二
论证之前惯例先吐个小槽。咱们就不吐槽题主的问题描述本身是不是就已经论证了我的观点,比如啥“良好的查询语言”是不是等于SQL等于关系模型,又比如“比关系数据库多了一层”是什么奇怪的说话。我还是来讲两个真实的小故事吧。
大概4、5年前,大家还在老老实实地用RDBMS实现业务数据库,一段时间过去发现查询变得很慢,大家纷纷议论:要不要换成NoSQL啊?
然后我被派去做帮助做数据库优化,然后加了几个索引,把查询的时间从30多秒优化到了30多毫秒。
大概4、5个月前,大家已经开始快快乐乐地在新业务的数据库上用上NoSQL了,结果发现查询也开始变得很慢,大家纷纷议论:要不要用文档数据库来加个索引啊?
然后我又被派来做NoSQL优化了,改了些partition key,重新定义了一些row key,拆了几个entity,然后查询时间从20多秒变成了20多毫秒。
三
要回答为什么新的分布式数据库又开始支持关系模型了,需要先搞明白两件事情:
数据库说得复杂特别复杂,但说得简单,它就解决了两个问题:数据怎么存放和数据怎么查询。
而且这两个问题互相关联。举个程序员都能明白的例子:如果你把数据存成了数组,那搜索查询就只能是O(n)的效率了,如果你存成了二叉树,那么查询效率就变成了O(logn)。
业务查询可不像搜索一个key值这么简单,常常复杂得要死,本来查询就很难写了,现在还得考虑数据物理存放方式来决定怎么执行查询更高效,这不是要逼死人嘛?所以早期的数据库开发人员苦啊,什么层级数据库、网状数据库写完查询都得自己定义access path啊。
然后就有了关系模型。
关系模型彻底改变了数据库程序员的生活:不用管数据怎么存了,你只要用SQL写好查询,然后查询优化器会帮你把面向业务的查询逻辑转换成可以高效在数据的物理结构上执行的物理查询。这简直就像一下从汇编时代跨越到了高级语言的时代啊。早期的数据库还需要大家自己思考怎么建索引,相当于告诉查询优化器哪些列是在查询中有用,后来数据库已经可以自动提示你该加什么索引了,大部分程序员终于可以欢乐地彻底扔掉数据库存储引擎的知识了。
当然仍然有一小挫掌握了超能力的人,是可以手写执行计划,用Plan Guide强制执行的,他们说:查询优化器是什么?可以吃吗?若干年后他们拯救了世界也打开了黑暗的大门(大误...
四
好日子一直持续到数据库负载大到不得不开始走向分布为止。分布式最大的问题是网络延迟问题,而网络延迟是物理问题,没这么容易解决。跨机事务做不了啊,查询优化器再牛逼也优化不了跨网络的join啊。
但业务还是得做啊,于是解决方案只有一个了:回到手工根据查询来决定数据物理分布(这样可以最大程度上避免跨网络的join),手工决定查询的物理执行计划,手工保证事务性的老路。
既然都已经全手工了,那还要原来的RDBMS干嘛,于是NoSQL产品诞生了。搭配一些会手写执行计划手写事务的超能力者使用,战斗力简直有105这么高。
大家很快就忘记了NoSQL其实是一个对现实妥协的产物,只有搭配一些精通数据存储引擎知识的人才能用好。
推广开来之后,广大吃瓜群众表示NoSQL一点也不好用啊,自己要管的东西太多啦,我怎么知道要怎么设计数据的物理分布啊,瞎设计一下查询起来就效率感人了啊,最终一致又是一个什么鬼啦,想象一下讨论怎么严格保证一个“改动了3个entity且有不少if-else分支的方法”的最终一致性,感觉结论必然只有“呵呵”啊。
于是为了让广大吃瓜群众用得开心,NoSQL的开发者不得不又开始走上了关系模型的老路。
五
题外话:你要问我这是不是一件好事,我当然觉得这是一件好事。什么东西都先解决了有没有,再解决好不好,分布式数据库的发展也一样。就像原来写程序要懂体系结构,后来写程序只要懂指针,再后来写程序连指针也不需要了。
写数据库应用,却不需要很好的数据库水平,这其实对大部分人来说都是一件值得开心的事情。为了能实现这一点,当然需要做数据库的同学们多加努力了。
本站所有内容均为互联网搜索引擎提供的公开搜索信息,本站不存储任何数据与内容,任何内容与数据均与本站无关,如有需要请联系相关搜索引擎包括但不限于百度,google,bing,sogou 等
© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有