海量日志数据存储用 elasticsearch 和 hbase 哪个好
从基本功能来说这两个确实有相似性，但是根据业务需求不同，我觉得有几点可以考虑：
1. 查询复杂度：HBase支持简单的行或者range查询，比如给一个PK查该行的数据，或者给一个begin/end查这个范围的数据，如果想完成更复杂的功能就不太容易。
而ES支持的查询比较丰富，或者说这些查询都带有一点复杂计算的味道了。
比如你有个论坛，你想查帖子里面是否包含敏感词，如果采用HBase就比较麻烦，使用HBase你可以将帖子存进来、读出去，但是要查内容里面的东西，只能一点点过滤；而ES是可以比较方便的帮助你完成这个功能的；
2. 数据量：按道理说两者都是支持海量数据的，但是据我个人感觉，HBase可能更容易支持更多的数据，因为其一开始设计就是解决海量问题的；而ES是后来慢慢增强其存储扩展性的；那么也就是说，HBase上手起来扩展性不太会阻碍你使用；ES可能要多费点劲。
当然，听说也有人写了ES基于Azure或者S3的存储插件，但是稳定性不知道如何；
3. 剩下的就是比较远的考虑，比如维护性，HBase基于Hadoop那一套，组件多，维护起来代价也不低，而ES自成体系，维护起来稍微好点；当然这个是相对的，绝对来说都不会容易。
比如新功能开发，比如成本控制等等。
。
。
大型网站的数据是怎么存储的?
转自网友文章:
大型网站数据库优化
千万人同时访问的网站，一般是有很多个数据库同时工作，说明白一点就是数据库集群和并发控制，这样的网站实时性也是相对的。
这些网站都有一些共同的特点：数据量大，在线人数多，并发请求多，pageview高，响应速度快。
总结了一下各个大网站的架构，主要提高效率及稳定性的几个地方包括：
1、程序
程序开发是一方面，系统架构设计（硬件+网络+软件）是另一方面。
软件架构方面，做网站首先需要很多web服务器存储静态资源，比如图片、视频、静态页等，千万不要把静态资源和应用服务器放在一起。
一个好的程序员写出来的程序会非常简洁、性能很好，一个初级程序员可能会犯很多低级错误，这也是影响网站性能的原因之一。
网站要做到效率高，不光是程序员的事情，数据库优化、程序优化这是必须的，在性能优化上要数据库和程序齐头并进！缓存也是两方面同时入手。
第一，数据库缓存和数据库优化，这个由dba完成（而且这个有非常大的潜力可挖，只是由于我们都是程序员而忽略了他而已）。
第二，程序上的优化，这个非常的有讲究，比如说重要一点就是要规范ＳＱＬ语句，少用in 多用or，多用preparestatement，另外避免程序冗余如查找数据少用双重循环等。
另外选用优秀的开源框架加以支持，我个人认为中后台的支持是最最重要的，可以选取spring＋ibatis。
因为ibatis直接操作SQL并有缓存机制。
spring的好处就不用我多说了，ＩＯＣ的机制可以避免new对象，这样也节省开销。
据我分析，绝大部分的开销就是在NEW的时候和连接数据库时候产生的，请尽量避免。
另外可以用一些内存测试工具来做一个demo说明hibernate和ibatis谁更快！前台你想用什么就用什么，struts,webwork都成，如果觉得自己挺牛X可以试试用tapestry。
用数据库也未必不能解决访问量巨大所带来的问题，作成静态文件硬盘的寻址时间也未必少于数据库的搜索时间，当然对资料的索引要下一翻工夫。
我自己觉得门户往往也就是当天、热门的资料点击率较高，将其做缓存最多也不过1~2G的数据量吧，举个例子：
◎ 拿网易新闻来说 /07/0606/09/3GA0D10N00011229.html
格式化一下，方便理解：http://域名/年/月日/新闻所属分类/新闻ID.html
可以把当天发布的、热门的、流揽量大的作个缓寸，用hashtable（key：年-月-日-分类-ID，value：新闻对象），静态将其放到内存（速度绝对快过硬盘寻址静态页面）。
通常是采用oracle存储过程＋2个weblogic，更新机制也几乎一样每签发一条新闻，就会生成静态页面，然后发往前端的web服务器，前端的web都是做负载均衡的。
另外还有定时的程序，每5-15分钟自动生成一次。
在发布新闻的同时将数据缓存。
当然缓存也不会越来越大，在个特定的时间段（如凌晨）剔除过期的数据。
做一个大的网站远没有想象中那么简单，服务器基本就要百十个的。
这样可以大大增加一台计算机的处理速度，如果一台机器处理不了，可以用httpserver集群来解决问题了。
2、网络
中国的网络分南北电信和网通，访问的ip就要区分南北进入不同的网络。
3、集群
通常会使用CDN与GSBL与DNS负载均衡技术，每个地区一组前台服务器群，例如：网易，百度使用了DNS负载均衡技术，每个频道一组前台服务器，一搜使用了DNS负载技术，所有频道共用一组前台服务器集群。
网站使用基于Linux集群的负载均衡，失败恢复，包括应用服务器和数据库服务器，基于linux-ha的服务状态检测及高可用化。
应用服务器集群可以采用apache+tomcat集群和weblogic集群等；web服务器集群可以用反向代理，也可以用NAT的方式，或者多域名解析都可以；Squid也可以，方法很多，可以根据情况选择。
4、数据库
因为是千万人同时访问的网站，所以一般是有很多个数据库同时工作的，说明白一点就是数据库集群和并发控制，数据分布到地理位置不同的数据中心，以免发生断电事故。
另外还有一点的是，那些网站的静态化网页并不是真的，而是通过动态网页与静态网页网址交换做出现的假象，这可以用urlrewrite这样的开源网址映射器实现。
这样的网站实时性也是相对的，因为在数据库复制数据的时候有一个过程，一般在技术上可以用到hibernate和ecache，但是如果要使网站工作地更好，可以使用EJB和websphere，weblogic这样大型的服务器来支持，并且要用oracle这样的大型数据库。
大型门户网站不建议使用Mysql数据库，除非你对Mysql数据的优化非常熟悉。
Mysql数据库服务器的master-slave模式，利用数据库服务器在主从服务器间进行同步，应用只把数据写到主服务器，而读数据时则根据负载选择一台从服务器或者主服务器来读取，将数据按不同策略划分到不同的服务器（组）上，分散数据库压力。
大型网站要用oracle，数据方面操作尽量多用存储过程，绝对提升性能；同时要让DBA对数据库进行优化，优化后的数据库与没优化的有天壤之别；同时还可以扩展分布式数据库，以后这方面的研究会越来越多；
如果我来设计一个海量数据库，可能首先考虑的就是平行扩容性，原因很简单，我没有办法预估将来的数据规模，那我也就没有边界可言，因此，基本上首选dbm类哈希型数据库，甚至，对于实时性要求很高的数据库，可能会自行设计库。
当我们使用业务描述脚本、事务批处理机、目录服务、底层存取来划分一个数据库系统之后，其实，所谓的海量数据需求，也就不是那么难办到了。
嗯，这样还有一个额外的好处，就是由于平行扩容性很好，因此，前期可以以较低成本搭建一个简单的架子，后期根据业务量逐出扩容。
这对很多企业来说，就是入门门槛很低，便于操作，且商业风险也小。
MySQL比起动辄几十万美金，搭建豪华的Oracle平台，成本低多了。
