前几天上了水木社区，发现还是有大牛的，看了关于大数据和数据库的讨论，发现还是蛮有意思的，限于篇幅和版面，我做了部分的整理。 先看看这位人士的分析，对于行业的现状还是很有了解，不是大学教授就是行业先锋。 ##################################### 大数据是一种方案，而不是一种模型。方案有方案的压力，  只能使出各种绝招来“解决”问题。既然是方案，就包括了存贮，运算，输入和输出等等。 就运算模型上，因为要更好地采用廉价硬件，实践出如hadoop/mapreduce这样的计算模型， 还有就是storm，以及其他模型。在存贮方面，也有很大的变化。     其实大数据最需要解决的存贮系统问题很大程度上是I/O与计算任务的关系。 RDBM虽然已经考虑了存储系统的特点，设计时考虑了读写数据带来的代价， 但这些分析和研究是基于70年代，80年代的硬件架构。现在的硬件架构下， 包括网络架构，和70年代80年代的差别已经很大。 比如80年代是不可以想象 个人电脑有2T的硬盘，即使是90年代末，这么大的存贮系统是必须上磁盘矩阵， 现在一个单碟硬盘就能解决。然而硬盘磁头这种机械组件并没有象容量一样升级， 不单还是以前那样龟速（当然要快很多，但还是慢），而且还是象以前一样脆弱。 这个直接 导致了人们纷纷质疑RDBMS中的范式的合理性：解决冗余所即省的空间意义不大，但随机读写让磁头速度问题突显。     回到大数据与数据库的关系。数据库其实有很多模型。关系模型只是其中一种。 然而关系模型的基础，关系代数，在数学层面解决了大量数据存贮相关的问题 （比如笛卡尔积让独立存贮的不同数据源能无限扩展进一张虚拟表，映射则又解决了表或虚拟表数据的选择与定位，使得无论 存贮表有多大，还是多小，数据的存贮， 查找都不是问题）。正因为关系模型的理论支撑，让关系数据库有了统一天下的现状。 然而数据存贮方案还是有很多种的。key-value是其中一种，oodb也是一种， 即使是直接存贮json也可以是一种。这些存贮模式没有象关系模型那样的数学支持，  使得他们从一开始就是二等公民，三等公民。但二等公民也是公民，无论他们有多萎缩。     另一种就是NewSQL。这种数据库采用的还是关系数据库模型，但relax normalization。 也就是说数据存储和查询还是二维关系模型，笛卡尔积，projection这些还是数据库 的根本，而SQL也很容易在这些数据库上实现和使用，唯一不同的是他们建议人们不要 使用范式，而是利用“冗余”数据 带来的“好”处让数据库效率更高。比如列式数据库就是 一种典型的newSQL数据库。列式数据库提出数据的存贮和读取上，列关联远强与行关联， 这表现为大多数时候用户关注的是同一列，或同几列，而不是同一行的所有列；从存贮上， 他们还发现同一列的数据相似性很高，如果把这些数据放在一起存贮，有可能引入非常好的 压缩算法（未列是压缩）。比如有一个列是国藉，传统RDBM会有一个表存贮国家，然后 获得一个nation_id，在其他地方使用id而不是国家名称。然而New SQL的思想是直接在所有用到国藉的地方直接写上国家名称，因为全世界就那么几个国家，如果有  一百万条记录，其他真正有意义的就是一百多条记录，压缩一下根本就不是个事。这样的好处就是每次查询不需要用笛卡尔积护展另一张表，而只需要读同一个地方，数据就出来了。 也就是磁头重新定位的机会少很多。     还有就是索引。在rdbm上，索引是用来加速查询的。然而索引的使用，让读和写的速度两三个数量组的下降。为了解决这个问题，有的人就提出直接复制一次数据，而不是使用索引。 也就是说，如果有A, B, C三列，A和B都做索引，就存成 , B, C一张表，A, , C 另一张表。需要A做索引时取