infobright、mongodb优劣以及适用范围

　　一、infobright几大优点：
　　1、高压缩比率，平均压缩比可达10：1，甚至可以达到40:1，我用infobright把3.1G的数据存成不足300M。
　　2、列存储，即使数据量十分巨大，查询速度也很快。用于数据仓库，处理海量数据没一套可不行。
　　3、不需要建索引，就避免了维护索引及索引随着数据膨胀的问题。把每列数据分块压缩存放，每块有知识网格节点记录块内的统计信息，代替索引，加速搜索。
　　4、单一台服务器可以高效地读写30T数据。具有可扩展性，这里是指对于同样的查询，当数据量是10T时，它耗费的时间不应该比1T数据量时慢太多，基本是一个数量级内。
　　二、infobright与mysql对比：
　　1、infobright适用于数据仓库场合，即非事务、非实时、非多并发；分析为主；存放既定的事实（基本不会再变），例如日志，或汇总的大量的 数据。所以它并不适合于应对来自网站用户的请求。实际上它取一条记录比mysql要慢很多，但它取100W条记录会比mysql快。
　　2、mysql的总数据文件占用空间通常会比实际数据多，因为它还有索引。infobright的压缩能力很强大，按列按不同类型的数据来压缩。
　　3、服务形式与接口跟mysql一致，可以用类似mysql的方式启用infobright服务，然后原来连接mysql的应用程序都可以以类似的方式连接与查询infobright。这对熟练mysql者来说是个福音，学习成本基本为0。
　　infobright有两个发布版：开源的ICE及闭源商用的IEE。ICE提供了足够用的功能，但不能INSERT，DELETE，UPDATE，只能LOAD DATA INFILE。IEE除提供更充分的功能外，据说查询速度也要更快。
　　三、mongodb数据库做适合的事情
　　mongodb的文档里提到的user case包括实时分析、logging、全文搜索，国内也有人使用mongodb来存储分析网站日志，但我认为mongodb用来处理有一定规模的网站日志其实并不合适，最主要的就是它占空间过于虚高，原来1G的日志数据它可以存成几个G，如此下去，一个硬盘也存不了几天的日志。另一方面，数据量大了肯定要考虑sharding，而mongodb的sharding到现在为止仍不太成熟。由于日志的不可更新性的，往往只需APPEND即可，又因为对日志的操作往往只集中于一两列，所以最合适作为日志分析的还是列存储型的数据库，特别是像infobright那样的为数据仓库而设计的列存储数据库。
　　由于mongodb不支持事务操作，所以事务要求严格的系统（如果银行系统）肯定不能用它。
　　引用自不周山： http://www.wentrue.net/blog/?cat=4