求一个每月4亿日志的处理方法，谢谢

[Sdhjt]

问题是这样的，服务器会产生大量的日志，每月大概4亿条左右。日志insert后基本不会update，而是大量的查询操作。数据库目前的配置是Microsoft SQL Server 2008，4核+8G的1U服务器。
1、数据库至少要保存6个月的数据（大概24亿条左右），数据库能搞定吗？
2、请问这个规模的日志如何解决频繁查询的效率问题（查询性能优化）

另外，请问像这种大量插入与查询，很少更新的数据库用NoSQL会有优势吗？

求大神们解答，谢谢！

[ms2008]

这么多数据都是有效数据吗？怎么不考虑下压缩问题：将同类日志压缩为一条记录，更新timestamp（firstoccurrence and lastoccurrence）和tally

[Actrace]

MYSQL够了,MYISAM引擎的表,索引规划好,再使用延迟写入,性能上够用了.

[plan9]

试试fluentd

[bengtuo]

大数据啊 当然必须 hadoop hive 之类啊



喷我把....

[pfipdaniel]

如果楼主的厂子不太缺金的话可以考虑splunk，这个数据量基本轻松搞定，之前给运营商上过一套这玩意，他们数据量可大多了。
如果用开源软件的话，可以试试fluentd+mongodb+kibana，用开源软件的话还是建议应用栈尽可能简单一些，不然维护成本比较高，给自己找麻烦了

[halfbloodrock]

@pfipdaniel ＋1....splunk好贵。。。但是的确好用。。。

[plprapper]

还是觉得hadoop比较合适。
统计类的需求太灵活了，常规的DB index 不是什么好的选择。

[liushuaikobe]

@cloudqq redis明显不合适~

[feilaoda]

lz和我原来的公司，业务好像。

曾经用hadoop/lucene/katta(这玩意可以换成solr)/Cassanda(后来被换成mongodb，最后被换成hbase）做的。

前端收集日志，是改写的nginx，跑在nginx上的log server。

当时storm还没出来，实时统计做的不够好。

[cloudqq]

@misaka @liushuaikobe 请问两位，reids不适合的原因在哪里， 请赐教。

[Sdhjt]

目前正在测试Infobright，大数据神马的之后有时间研究研究，毕竟最近火的快成灰了:)

[richiefans]

@Sdhjt 想问下楼主 Infobright 方案使用情况如何？