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

[Sdhjt]

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

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

求大神们解答，谢谢！

[angelface]

没有使用场景， 这个问题不好说。

[cloudqq]

建议整理查询需求，使用实时动态统计，只保留统计内容。

[Sdhjt]

@angelface 一般是做这样的查询：
某IP在某时间做了什么事情
某时间段内有哪些IP做了什么事情
某时间段内在做X事情的IP有哪些
还做一些统计：
某IP的访问次数，频率
一天、一周、一个月的访问量统计


@cloudqq 只保留统计内容可能会丢失一些细节，有些查询是需要细节的。

谢谢以上两位的解答，感谢已发送

[cloudqq]

这是个很适合使用NoSQL的场景， 用NoSQL保留6个月，问题不大， 除了动态产生实时统计外，因为你保留了就近6个月的数据，这样要查细节的时候也是很方便的。 看描述貌似是一个游戏公司对用户行为的分析。

[xunyu]

gfw？

[mahone3297]

@cloudqq 用什么nosql？

[cloudqq]

redis 可以考虑。

[ritksm]

每天我就3000w条数据。。。直接用mongodb（用了tokumx，压缩数据减少空间）。。。查询也方便

[wys163]

为何不用hbase，在海量的数据存储中发挥的效果更佳

[refresh]

不能每天都统计汇总么，然后大部都查询这个汇总数据？我瞎说啊，这方面完全没经验

[lisztli]

我们使用过infobright， 你可以试试。 在处理日志这种只加不改的场景，特别好用。 前面那些说hbase、redis的，到底处理没处理过日志……

[wodemyworld]

雇个dba
系统设计有问题，按月入库也有问题，光建立索引就得很长时间，平时都干嘛了
花钱雇人重新设计吧

[misaka]

刚看到前面说 Redis 的，顿时一口老血喷屏幕上了。。。
多么不负责任的回答。。

[misaka]

@wodemyworld 你在说什么啊？另外楼主啥时候说按月入库了？

[wodemyworld]

@misaka 哦。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
按天入库也没辙，如果所有日志就在一个表里，就算入库一条也得重新建立索引
nosql其实也好不到哪去，反正我测试的时候没发现nosql性能有多么高，而且还给将来万一有关系型查询的场景制造了障碍
主要跟数据库设计有关了，更新频繁的字段垂直分表的时候划出去，而且查询语句一定要注重性能，经过dba审核（对，没有dba，还是雇一个吧，你总不能把你们企业内部的数据库表结构给我们说吧）

[lookhi]

4核+8G的1U服务器 升级到16 32 64G

[min]

既然现在用的是ms sqlserver，应该去找个懂analysis service的dba去问问

[humiaozuzu]

beaver -> redis -> logstash -> elasticsearch -> Kibana
包搞定

[Sdhjt]

谢谢大家的回复哈~~~感谢已发送
综合了各位前辈的思路，我决定试试
infobright
和
beaver -> redis -> logstash -> elasticsearch -> Kibana
两条思路

[pindleskin]

elasticsearch+kibana目前看起来是后端最好的组合，前面我们是用lumberjack+logstash，对logstash性能不满意，但目前还没看到太好方案可以灵活而高效地parse日志。前端还有好些不同的日志收集程序，如flume，fluentd，但目前还没看到能代替logstash的。