大数据下的数据问题-从很远很远的历史开始谈未来，谈谈阿里云ODPS的SQL复杂度，谈设计新的数据库，最终？

深夜爱学习。

文章要谈

大数据下的数据问题-从很远很远的历史开始谈未来，谈谈阿里云ODPS的SQL复杂度，mapreduce，谈设计新的数据库，人工智能，。。。。好多东西。

其实写的时候也不知道本文的目的是啥？分析SQL？分析数据库性能？设计新的数据库？ 连接池，负载均衡，并行查询？先写着吧，把自己知道的都先写下来。

一个近似理想主义的数据库的概念应该是：能够调用，存储程序和数据的系统

SELECT 数据，程序 WHERE 数据=， 程序=  

连接池？为啥要去“连接”数据库？

虽然自己没做过DBA但是，从最早带索引的文件存储到层次型数据库（IMS代表），到关系型数据库（ORACLE代表）和现在的NOSQL，几所类型的数据库都用了一遍，从我了解的谈谈所谓的数据库。如下：

数据文件存储数据

主要是VSAM，在大型机下开发了几年。这种数据类型主要是以KSDS为代表的带KEY值（索引）的，安记录（需要给定记录长度）的存储方式。数据冗余比较大，这种方式冗余也比较有意思。

来看下面这个问题，比如：

客户商品AITEM_AAITEM_BA…表1

客户商品1商品2商品3…AITEM_AITEM_B… 表2

表一中客户重复了，表二中商品字段要满足客户的最大要求。万一有的客户只有1种商品，有的客户有几百种商品，这个表的空间浪费很大。

但是从效率的角度来说，多次读取时间大于一次读取的时间。我们从大学的操作系统理论中就知道：内存的速度大于IO的速度。事实也是如此，想象原始的硬盘磁头去定位三条数并读取出来是多么的困难，但一条数据按照轨道读一大段就比较容易了。 从中也可以理解存储技术在发展时的一些轨迹，介质从卡片到磁带到硬盘到固态硬盘都是围绕提高定位和读取的速度发展的。

所以在设计的时候往往会选择（表2）的结构，是个经典的空间换时间的例子，当然一定要预留一定的扩展空间，否则当一个文件列不够用的时候只能从这个文件拷到一个更宽的文件中去了。

在操作的时候如果SQL用where 商品 = ITEM_A，这个在关系型非常常见的操作，按照表2的情况，就要用 if 商品1 == A or 商品2 == A or ....去找了。

当然你也可以自己写一个简单的语言解释器，把  where 商品 = ITEM_A 这个东西 转换成 if 商品1 == A or 商品2 == A or ...

从这里去通俗理解： SQL做性能优化之一，先recomplie下SQL语句， 其实也就是上面的过程。

很多在大型机上的项目至今还沿用这种结构。现在想想，现实中真的有这么多关系要处理吗？   

所以这种方式操作难， 性能复杂  分布式

～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～未完～～～～～～

层次型数据库

IMS在工作培训的时候用到过，大概3个月时间，期间还写了一个select的解释器。

关系型数据库

一直

NOsql

最近一个项目取WEBAPI的时候用到过，由于每次返回数据格式是JSON，把它拆开来insert到

不管文件也好，关系型数据库，或者非关系型数据库，其本质都是文件。当然刚刚学的人会涉及另外一个概念：数据库系统

2.SQL复杂度：先统计SQL语句中的关键字，再折算为SQL复杂度，具体如下： a) SQL关键字个数 = Join个数 + Group By个数 + Order By个数 + Distinct个数 + 窗口函数个数 + analyze个数 + max( insert into个数-1, 1) b)