前几天上了水木社区，发现还是有大牛的，看了关于大数据和数据库的讨论，发现还是蛮有意思的，限于篇幅和版面，我做了部分的整理。
先看看这位人士的分析，对于行业的现状还是很有了解，不是大学教授就是行业先锋。
#####################################
大数据是一种方案，而不是一种模型。方案有方案的压力，
只能使出各种绝招来“解决”问题。既然是方案，就包括了存贮，运算，输入和输出等等。 就运算模型上，因为要更好地采用廉价硬件，实践出如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做索引时取, B, C，需要B做索引时另一张。这种方法看起来很笨，但很有效。当然，数据量也出现了几倍的提升，这是一个不得不考虑的问题。
第三就是数据的更新。以前总以为要更新数据库找到原来的记录，改一改数据就行。 但现在发现，改一个记录和写大量记录的差别不大，如果改的量大时，后者优势更大。 所以现在很多数据库系统实质上是read-only database，也就是只能添记录，不能改记录。 记录的改动是通过添加一条新记录，并记录添加时间，然后在读出时和原有的记录合并。
有了read-only，数据的存贮就可以大大优化。比如一个block的记录直接用lzo算法 压缩起来放到hdfs上 —— 相象一下如果要改动一个压缩了的记录是多让人头痛的事。
话锋一处，马上产生了共鸣。看看这位人士的分析。
##########################################
1. 非常同意大数据是个平台的观点，它不仅仅关系到数据的存储和访问，还涉及到数据的导入，导出，分析，应用等。
2. 大数据的核心问题是分布式，包含分布式数据存储，分布式计算（包含分布式SQL引擎，分布式数据挖掘算法， 。。。）。很多MPP数据库可以认为也是大数据范畴的东西，比如Teradata, Oracle ExaData, Greenplum, IBM DPF...
3. 相对于数据冗余，我觉得范式主要解决的是数据一致性的问题。这个在事务性应用中比较关键。
4. 关系数据库中的很多特性都很好，比如范式、一致性约束、索引、基于统计信息的SQL优化器等，不是大数据平台不想要，而是由于CAP准侧的约束，这些特性在分布式系统上的实现都很困难，所以必须做些取舍或是针对性的开发不同的版本来满足不同的应用。
很多的SQL on Hadoop/SQL on HDFS都在开发基于统计信息的SQL优化器，也在添加 一些比较简单的索引。
不知道怎么说着说着，一不小心就扯到rac和exadata了，看看他们怎么说的。
##########################################
oracle/rac和oracle exadata不是一个东西。exadata存储之上可以架普通的oracle server,也可以架oracle rac。
share nonthing架构不一定廉价，Teradata就卖的很贵。基于hadoop的方案之所以cost effective，是因为1.hdfs提供的数据冗余能够保证一个节点的宕机不会造成数据丢失以及整个系统宕机,从而能够使得这些方案能够在廉价硬件上部署。
2.hadoop/yarn/tez/spark等提供了免费且开源的分布式计算框架，从而使得在上面进行大数据方案开发成本降低。 大数据本质上是分布式计算，share nothing是分布式计算中可扩展性的必然选择； 因为share的越多，可扩展性就越弱
最后还不忘拿pg和mongo来做一个比较，这是约架的节奏啊。
########################################
mongodb的内存管理太原始，如果活动数据大于内存，性能急剧下降。同时无schema导致数据体积大，吃更多内存。
postgresql和mongodb都有空间索引支持，能力应该类似。postgresql的事务支持又秒杀mongodb. postgresql 9.4后性能有不错提升。
所以mongodb在这方面不如pg
java企业级通用权限安全框架源码 SpringMVC mybatis or hibernate+ehcache shiro druid bootstrap HTML5