Mongodb Hbase oracle

Mongodb/hbase	Oracle
减少表 实现十分复杂的数据形式的存储 (大对象)	传统   (小对象)
分片,集群 维护方便	分区麻烦
海量数据TB级别 (更大的要用hbase)	小数据量 GB级别
文档存储 / 列式存储	ACID
性价比高(廉价的硬盘)	成本高

HBase的优点：
分布式，易扩展，高性价比，运维成本低都是它的优点。HBase可以支持海量数据，单张表的数据量不上T，都不好意思出来打招呼。甚至可以拿很烂的SATA盘来作为存储，由于依赖底层的HDFS。新装的机器甚至可以不用做硬RAID。
HBase可以在任何时候随时宕掉2，3台机器，就当什么都没发生似的(当然master除外，但是HBase，hadoop的master节点负载都很”清闲“)。这是HBase本身分布式的架构，先天性的优势。


那么MongoDB究竟应该怎么用呢？
首先，忘记SQL
你应该忘记你学过的那些优雅无敌的SQL，不是说为了提升检索性能，扔索引就有好处。
有一个简单的事实如下：只有一个默认的_id 索引，此时插入性能为1，你再加一个索引，插入性能约1/2,再加一个约1/3 ,以此类推......
如果这个事实对你是很震撼的，那说明你还没有忘记SQL，接着忘。
MongoDB的索引对插入性能有着不可忽略的拖后腿效应，所以，我们应该使用且仅使用 _id 作为插入key，作为查询key，作为所有的那个key。
其次，直接忘记搜索这件事。
把MongoDB当做你的硬盘，给他文件名去操作文件.这就是Key-Value数据库的做法，你稍加设计就能这么用。
那么其实你所有的操作可以简化为两个指令，逻辑上 就是一个字典
你给他_id,往字典里插一个数据，或者拿一个数据。
Save({_id:xxx,.....})
FindOne({_id:xxx})
要想高性能，善用那个_id,把你原来准备当主键的那个玩意，hash成_id.
把你原来准备的查询条件，什么？查询，拿_id来，别的全砍掉。
第三、这不是数据表
记住，这不是数据表，一个_id对应的东西不是一行数据，而是一个文件。
文件存储和表存储有什么不同呢？
我举个例子，比如我们要存储用户列表和每个用户的道具列表。
数据表的做法是建一张用户表，一张道具表，道具表里有个字段表示他属于哪个用户。
然后，你就离不开万恶的查询了。
然后如果一个用户有100条道具，100万用户意味着道具表有一亿条记录。
这时候就开始考验你的小数据库了，但这都是过去式了，这一亿的道具，用MongoDB，根本不是个事儿
因为MongoDB的方法是当做文件存，只设计一个用户集合，每个用户的信息是一个文件，然后这100个道具就分开存在每个用户的文件里。
然后来比较一下，我们取得用户的记录，然后从中拿出100个道具，NoSQL方法。
查一亿的表，找出属于某个用户的记录。
熟快熟慢？
然后你可能回想，SQL方法，我也可以搞个道具字段，把用户的100个道具用某种协议打包，然后操作啊，一样可以取得巨大的优化呀。
没错，你的想法很好，你正在用NOSQL的方式用SQL。
第四、文件存储的精华之处
如果问题止于此处，MongoDB就毫无优势可言了，如果这个方法在SQL数据库上也是如此容易使用，那还费劲搞MongoDB干什么？
我们再折腾一点，如果每个道具还要存100条转手记录，你还是可以打包，但你这个打包字段已经1M了。
于是每次存取这个打包字段都是一个系统工程了，还要负担1M的流量。
MongoDB这边呢？我们可以直接对文件的一部分进行读写，比如我只返回一个用户的第二个道具的信息，和返回第二个道具的第1~30条转手记录。
这，是一种怎样的差距啊。
你想要一张美女的照片，你朋友有，但是他只有一个压缩包，他那里没有解包工具，于是他把整个包传给了你。他想问你要一张照片，但是他没有压缩工具，为了存档需要，他让你再压进包里传给他。
这个朋友就是你的用户表的一行，如果换成真实世界的事件是多么的不可思议，这就是在一个字段里打包数据的问题。
MongoDB的一条记录就是一个脑筋更正常的朋友，你要他一张照片，他从包里找出来给你。你给他一张照片，他分门别类的放置到他的包里去。
用文件的思维去访问，MongoDB是一个更好的朋友。
审视一下你项目中的大部分的数据需求，是不是都可以用这种方式去组织呢？
如果是，加入NOSQL吧，我们的口号是：很暴力不SQL