作者 | dbLenis
责编 | 郭芮
出品 | CSDN 博客
当今数据库供应商风头正茂的,要数这三家公司:Amazon、google、Microsoft。没错,他们都是云计算提供者。火热的三款看家产品分别是:Amazon RDS,Google Cloud SQL,Azure Database for PostgreSQL。
A厂CTO说,AWS最火的产品是什么呢?是 Aurora 数据库,它同时兼容 PostgreSQL 与 MySQL。他还指出,Hadoop 也好,Spark、Kafka 也罢,都在极力推动 SQL 接口来让更多的服务 API 暴露给程序员。
从 A 厂产品的销量来说,企业比较青睐于这些有标准 SQL 接口的产品,而对于各类只能用编程语言,比如JAVA才能正常取数的产品,显得声音大,却雨点小,少有肯买帐的。
我举个 ElasticSearch 的例子,你感受下为什么 ES 的 DSL 会让人望而却步:
POST crm_comment/_search
{
"size":0,
“query":{
"term":{"accountName”:"Apple"}
},
"aggs":{
"count_over_time":{
"date_histogram":{
"field":"CREATED",
"interval":"month"
},
"aggs":{
"sum_of_sales":{
"sum":{"field":"salesamount"}
}
}
}
}
}
再比如,我们存日志的 MongoDB,它的官方语言是 JavaScript:
看上去,这比 ElasticSearch 好看一些,每个字段都加了一个 $ 符号,请问为什么 total 就不用加呢?
原本这些数据(搜索用的 ElasticSearch, 日志用的 MongoDB)都存在 SQL 数据库中,使用 SQL 一劳永逸的搞定所有查询。但现在要花点时间熟悉 ES 和 MongoDB 的古怪语法了,还要搞清楚,数据在流转过程中是否有丢失——带来的复杂度不仅仅是一点点。
什么,你说程序员不就是应该拼命学的嘛?这是福报。嗯,这样的福报谁爱要,谁拿去,反正我不!
1.历史
让我们一起回忆下SQL关系型数据库的起源。这要追溯到IBM发表关系型数据库论文的那个年代,1970年。1970年时,关系型数据计算已经非常火热了。但这种关系运算的查询,只掌握在少数天才人的手里。普通人只能看着眼馋。
来,一起领略下当时的关系运算:
事实证明,哪里有黑盒,哪里就会产生魔法师,总有天才领袖为劳苦大众着想。Donald Chamberlin 和 Raymond Boyce 就是这样的天才!他们发明了 System R(关系型数据库原型),又在自然语言的研究方向上,发明了结构化英语查询语言(Structured English Query Lanuage, SEQUEL, 这也是为什么大家经常会把SQL读成 see-ku-er的原因)。后因商标之争,SEQUEL更名为 SQL。
那么 SQL 相比上面的数学表达式有啥好处?感受下:
前后两个运算都是在找出薪水比自己经理还高的那些员工。前者是关系数据表达式,只有数学大师才懂的符号;后者是 SQL 表达式,任何人在一星期绝对可以掌握的技术。
后来的事情,相信只要你不是00后,应该都有所耳闻了。IBM DB2、Oracle、SQL Server、MySQL 都如雨后春笋般地出来了。有了 System R 这般的磐石,有了 SQL 这代新型武器,各自造就了兵工厂,开疆扩土。
战争一直打到现在。
如果不是因为 ARPANET 这位默默在墙角自习的好青年,恐怕拉里森这位Oracle家长还要嘚瑟个好多年。经过多年的沉寂修炼,ARPANET终于在我们这个时代成长成一个壮实的大小伙了——也就是今天的互联网!
来,见识下当年那一小撮默默地在加利福尼亚学习的小伙伴:
革命不成功,壮士不歇息。尽管有这么多人兢兢业业的付出,但撼动关系型数据库的江山还远不够实力,也不到时候——直到这位哥们的出现。你看,任何历史性的转折都要依靠一位伟人来带动,说不定下一位就是你,努力吧少年!
这位 Tim 老兄在1989年,发明了万维网,一下子把数据的洪荒世界之门给打开了。数据以前所未有的体量和速度冲了进来,此时的关系型数据库也就慢慢有了吃力和老态的迹象。
历史再一次证明, 不被人胖揍,永远不知道自己几斤几两。
怪兽冲了进来,总要有奥特曼来对付吧。没错,这时候两位英雄人物出场了,一位是 Google,一位是 Amazon。Google 的 MapReduce(2004)和 BigTable(2006)打破了分布式计算和存储的瓶颈。A厂在整个云计算时代都有它的份儿,闪亮的光芒甚是耀眼。它的 Dynamo 数据库,采用了键值对存储,集合了各种眼花缭乱的云计算技术,号称能保障高可用服务。
磐石有了,兵工厂就不会远了。跟 SQL 的发展很像,之后很快各个公司就有了 Hadoop、Hive、Cassandra、MongoDB,也玩起了 MapR。又是一番你追我赶的厮杀,历史是何等的相像。
而这一波厮杀,不仅仅是在堂兄弟、表兄弟之间展开,还要去抢叔叔伯伯们的地盘。这不,蚂蚁金服的OceanBase前两天还动了一下Oracle大叔的地盘,抢掉了它2010年打下的TCP-C排行榜榜首的位置。
2.现实
年轻人始终有着一股子血气方刚,认为凭着自己年富力强,无所畏惧就要去动大人的奶酪。打仗光靠蛮力怎么可以,它还需要致胜的最本质基础,那就是群众的支持。
每个年轻人都有自己的魅力,有自己的武器都很好,很酷。乾坤圈、金箍棒看着都炫酷,但在如来的眼里,他代表的可是天地万物,说一句代替苍生治治你,分分钟就把你给秒了。那可是群众的力量代表。
上面的 ElasticSearch、MongoDB给我们的感觉都很棒,全文搜索极快,日志存储不费劲,但要去拿起来用,你得好好的去顺顺他们的脾气,要不就给你枣子吃。就如现在很多年轻人,做事情是要哄着做,哪像那些无产阶级革命前辈,都是抢着做。
如果说 OLTP 产品,我们摸索一下 redis、MongoDB、Kafka 也就算了,能忍就忍吧,毕竟一次投入,永久使用。但 OLAP 产品,Impala、Hive、Presto、Kylin 等都互不连通,还要整一套 ETL 来打通,这谁的脾气能好咯。我做一个报表,还要用 Spark 去每家每户报信,搞不好哪家那天脾气特别大,不待见,数据都取不出来。典型的就是 JOIN 信使,经常吃闭门羹。
当然,被群众(市场)教训过后,年轻人也开始反思。Cloudera 与 Hortonworks 就是典型代表,他俩选择联起手来一块干点事儿。推出了 SQL 级的方言,用来封装自己复杂的外表,原理就是 SQL ON Hadoop。
Hadoop 负责存储,而 SQL 负责计算,存储引擎与计算引擎分离开来,拉拢了不少 SQL 群众,开始铺设广泛的群众基础。
3.王者归来
第一次小弟们像大佬妥协,就是推出自己的 SQL-On-Hadoop 产品。虽然嘴上说着是 Not Only SQL, 那也不过是年轻人在坚持他们最后的傲娇而已。
接着,历史又再一次重演。只要一个现象被认可,一群现象就跟风而来。H-Store、Spanner、CockroachDB,最出众的还要数 Postgre,在历经关系数据库、NoSQL之后,尽在旁边捡漏,好东西都往自己身上加,像 Json、FullText Search、MPP、JIT 等特性。
当然,整个历史的转变,总要有人总结陈词。NoSQL的运动者是谁?还记得嘛?没错就是 Google 的三驾马车。那么终结它也只能由Google来官宣,搬起石头砸自己的脚,疼不您咧?
G 厂在2017年的 Spanner 论文中怎么说的?精简一下,“我们 Google 要从 Nosql 转到 SQL 阵营来,SQL 即将成为一切数据访问的基础,就酱”!
声明:本文为CSDN博主「dbLenis」的原创文章,版权归作者所有。
【End】
主题:《医疗影像小数据场景中的前沿技术与实践》
介绍:目前腾讯优图涉及眼底、宫颈、脑出血病因分析等多个落地项目,使用的数据格式也不太一样,眼底和宫颈是2D的RGB图像,脑出血是3D CT图像,相比起来,标注 3D 数据的难度比 2D 数据高不少。腾讯优图是如何针对3D CT / MRI 数据提出自监督研究的?研究成果是如何落地于工程中?如何应用在脑出血病因分类和脑肿瘤分割案例中?