这是一个创建于 4421 天前的主题，其中的信息可能已经有所发展或是发生改变。
问题是这样的，服务器会产生大量的日志，每月大概4亿条左右。日志insert后基本不会update，而是大量的查询操作。数据库目前的配置是Microsoft SQL Server 2008，4核+8G的1U服务器。
1、数据库至少要保存6个月的数据（大概24亿条左右），数据库能搞定吗？
2、请问这个规模的日志如何解决频繁查询的效率问题（查询性能优化）
另外，请问像这种大量插入与查询，很少更新的数据库用NoSQL会有优势吗？
求大神们解答，谢谢！
1、数据库至少要保存6个月的数据（大概24亿条左右），数据库能搞定吗？
2、请问这个规模的日志如何解决频繁查询的效率问题（查询性能优化）
另外，请问像这种大量插入与查询，很少更新的数据库用NoSQL会有优势吗？
求大神们解答，谢谢！
 | 1 angelface 2013-11-18 11:47:11 +08:00  1 没有使用场景， 这个问题不好说。 |
 | 2 cloudqq 2013-11-18 11:53:33 +08:00 1 建议整理查询需求，使用实时动态统计，只保留统计内容。 |
 | 3 Sdhjt OP |
| 4 cloudqq 2013-11-18 12:01:53 +08:00 1 这是个很适合使用NoSQL的场景， 用NoSQL保留6个月，问题不大， 除了动态产生实时统计外，因为你保留了就近6个月的数据，这样要查细节的时候也是很方便的。 看描述貌似是一个游戏公司对用户行为的分析。 |
 | 5 xunyu 2013-11-18 12:18:30 +08:00 gfw？ |
 | 6 mahone3297 2013-11-18 12:23:11 +08:00 @cloudqq 用什么nosql？ |
| 7 cloudqq 2013-11-18 12:24:38 +08:00 redis 可以考虑。 |
 | 8 ritksm 2013-11-18 12:28:14 +08:00 1 每天我就3000w条数据。。。直接用mongodb（用了tokumx，压缩数据减少空间）。。。查询也方便 |
 | 9 wys163 2013-11-18 12:33:11 +08:00 为何不用hbase，在海量的数据存储中发挥的效果更佳 |
 | 10 refresh 2013-11-18 12:43:56 +08:00 不能每天都统计汇总么，然后大部都查询这个汇总数据？我瞎说啊，这方面完全没经验 |
 | 11 lisztli 2013-11-18 12:50:37 +08:00 1 我们使用过infobright， 你可以试试。 在处理日志这种只加不改的场景，特别好用。 前面那些说hbase、redis的，到底处理没处理过日志…… |
 | 12 wodemyworld 2013-11-18 12:58:55 +08:00 雇个dba 系统设计有问题，按月入库也有问题，光建立索引就得很长时间，平时都干嘛了 花钱雇人重新设计吧 |
 | 13 misaka 2013-11-18 13:00:31 +08:00 via Android 刚看到前面说 Redis 的，顿时一口老血喷屏幕上了。。。 多么不负责任的回答。。 |
| 14 misaka 2013-11-18 13:03:00 +08:00 via Android @wodemyworld 你在说什么啊？另外楼主啥时候说按月入库了？ |
| 15 wodemyworld 2013-11-18 13:13:01 +08:00 @misaka 哦。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。 按天入库也没辙，如果所有日志就在一个表里，就算入库一条也得重新建立索引 nosql其实也好不到哪去，反正我测试的时候没发现nosql性能有多么高，而且还给将来万一有关系型查询的场景制造了障碍 主要跟数据库设计有关了，更新频繁的字段垂直分表的时候划出去，而且查询语句一定要注重性能，经过dba审核（对，没有dba，还是雇一个吧，你总不能把你们企业内部的数据库表结构给我们说吧） |
 | 16 lookhi 2013-11-18 13:26:00 +08:00 4核+8G的1U服务器 升级到16 32 64G |
 | 17 min 2013-11-18 13:27:13 +08:00 既然现在用的是ms sqlserver，应该去找个懂analysis service的dba去问问 |
 | 18 humiaozuzu 2013-11-18 13:30:00 +08:00 2 beaver -> redis -> logstash -> elasticsearch -> Kibana 包搞定 |
| 19 Sdhjt OP 谢谢大家的回复哈~~~感谢已发送 综合了各位前辈的思路，我决定试试 infobright 和 beaver -> redis -> logstash -> elasticsearch -> Kibana 两条思路 |
 | 20 pindleskin 2013-11-18 15:50:58 +08:00 elasticsearch+kibana目前看起来是后端最好的组合，前面我们是用lumberjack+logstash，对logstash性能不满意，但目前还没看到太好方案可以灵活而高效地parse日志。前端还有好些不同的日志收集程序，如flume，fluentd，但目前还没看到能代替logstash的。 |
 | 21 ms2008 2013-11-18 16:25:08 +08:00 这么多数据都是有效数据吗？怎么不考虑下压缩问题：将同类日志压缩为一条记录，更新timestamp（firstoccurrence and lastoccurrence）和tally |
 | 22 Actrace 2013-11-18 16:33:27 +08:00 MYSQL够了,MYISAM引擎的表,索引规划好,再使用延迟写入,性能上够用了. |
 | 23 plan9 2013-11-18 18:18:54 +08:00 1 试试fluentd |
 | 24 bengtuo 2013-11-18 18:23:00 +08:00 大数据啊 当然必须 hadoop hive 之类啊 喷我把.... |
 | 25 pfipdaniel 2013-11-18 19:38:19 +08:00 2 如果楼主的厂子不太缺金的话可以考虑splunk，这个数据量基本轻松搞定，之前给运营商上过一套这玩意，他们数据量可大多了。 如果用开源软件的话，可以试试fluentd+mongodb+kibana，用开源软件的话还是建议应用栈尽可能简单一些，不然维护成本比较高，给自己找麻烦了 |
 | 26 halfbloodrock 2013-11-18 20:12:00 +08:00 @pfipdaniel ＋1....splunk好贵。。。但是的确好用。。。 |
 | 27 plprapper 2013-11-18 21:25:17 +08:00 还是觉得hadoop比较合适。 统计类的需求太灵活了，常规的DB index 不是什么好的选择。 |
 | 28 liushuaikobe 2013-11-19 08:46:48 +08:00 @cloudqq redis明显不合适~ |
 | 29 feilaoda 2013-11-19 11:41:40 +08:00 1 lz和我原来的公司，业务好像。 曾经用hadoop/lucene/katta(这玩意可以换成solr)/Cassanda(后来被换成mongodb，最后被换成hbase）做的。 前端收集日志，是改写的nginx，跑在nginx上的log server。 当时storm还没出来，实时统计做的不够好。 |
| 30 cloudqq 2013-11-19 16:31:29 +08:00 @misaka @liushuaikobe 请问两位，reids不适合的原因在哪里， 请赐教。 |
| 31 Sdhjt OP 目前正在测试Infobright，大数据神马的之后有时间研究研究，毕竟最近火的快成灰了:) |
 | 32 richiefans 2013-12-12 17:58:32 +08:00 @Sdhjt 想问下楼主 Infobright 方案使用情况如何？ |
Select Language