V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
Sdhjt
V2EX  ›  问与答

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

  •  
  •   Sdhjt · 2013-11-18 11:41:22 +08:00 · 9882 次点击
    这是一个创建于 3784 天前的主题,其中的信息可能已经有所发展或是发生改变。
    问题是这样的,服务器会产生大量的日志,每月大概4亿条左右。日志insert后基本不会update,而是大量的查询操作。数据库目前的配置是Microsoft SQL Server 2008,4核+8G的1U服务器。
    1、数据库至少要保存6个月的数据(大概24亿条左右),数据库能搞定吗?
    2、请问这个规模的日志如何解决频繁查询的效率问题(查询性能优化)

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

    求大神们解答,谢谢!
    32 条回复    1970-01-01 08:00:00 +08:00
    angelface
        1
    angelface  
       2013-11-18 11:47:11 +08:00   ❤️ 1
    没有使用场景, 这个问题不好说。
    cloudqq
        2
    cloudqq  
       2013-11-18 11:53:33 +08:00   ❤️ 1
    建议整理查询需求,使用实时动态统计,只保留统计内容。
    Sdhjt
        3
    Sdhjt  
    OP
       2013-11-18 11:57:17 +08:00
    @angelface 一般是做这样的查询:
    某IP在某时间做了什么事情
    某时间段内有哪些IP做了什么事情
    某时间段内在做X事情的IP有哪些
    还做一些统计:
    某IP的访问次数,频率
    一天、一周、一个月的访问量统计


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

    谢谢以上两位的解答,感谢已发送
    cloudqq
        4
    cloudqq  
       2013-11-18 12:01:53 +08:00   ❤️ 1
    这是个很适合使用NoSQL的场景, 用NoSQL保留6个月,问题不大, 除了动态产生实时统计外,因为你保留了就近6个月的数据,这样要查细节的时候也是很方便的。 看描述貌似是一个游戏公司对用户行为的分析。
    xunyu
        5
    xunyu  
       2013-11-18 12:18:30 +08:00
    gfw?
    mahone3297
        6
    mahone3297  
       2013-11-18 12:23:11 +08:00
    @cloudqq 用什么nosql?
    cloudqq
        7
    cloudqq  
       2013-11-18 12:24:38 +08:00
    redis 可以考虑。
    ritksm
        8
    ritksm  
       2013-11-18 12:28:14 +08:00   ❤️ 1
    每天我就3000w条数据。。。直接用mongodb(用了tokumx,压缩数据减少空间)。。。查询也方便
    wys163
        9
    wys163  
       2013-11-18 12:33:11 +08:00
    为何不用hbase,在海量的数据存储中发挥的效果更佳
    refresh
        10
    refresh  
       2013-11-18 12:43:56 +08:00
    不能每天都统计汇总么,然后大部都查询这个汇总数据?我瞎说啊,这方面完全没经验
    lisztli
        11
    lisztli  
       2013-11-18 12:50:37 +08:00   ❤️ 1
    我们使用过infobright, 你可以试试。 在处理日志这种只加不改的场景,特别好用。 前面那些说hbase、redis的,到底处理没处理过日志……
    wodemyworld
        12
    wodemyworld  
       2013-11-18 12:58:55 +08:00
    雇个dba
    系统设计有问题,按月入库也有问题,光建立索引就得很长时间,平时都干嘛了
    花钱雇人重新设计吧
    misaka
        13
    misaka  
       2013-11-18 13:00:31 +08:00 via Android
    刚看到前面说 Redis 的,顿时一口老血喷屏幕上了。。。
    多么不负责任的回答。。
    misaka
        14
    misaka  
       2013-11-18 13:03:00 +08:00 via Android
    @wodemyworld 你在说什么啊?另外楼主啥时候说按月入库了?
    wodemyworld
        15
    wodemyworld  
       2013-11-18 13:13:01 +08:00
    @misaka 哦。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
    按天入库也没辙,如果所有日志就在一个表里,就算入库一条也得重新建立索引
    nosql其实也好不到哪去,反正我测试的时候没发现nosql性能有多么高,而且还给将来万一有关系型查询的场景制造了障碍
    主要跟数据库设计有关了,更新频繁的字段垂直分表的时候划出去,而且查询语句一定要注重性能,经过dba审核(对,没有dba,还是雇一个吧,你总不能把你们企业内部的数据库表结构给我们说吧)
    lookhi
        16
    lookhi  
       2013-11-18 13:26:00 +08:00
    4核+8G的1U服务器 升级到16 32 64G
    min
        17
    min  
       2013-11-18 13:27:13 +08:00
    既然现在用的是ms sqlserver,应该去找个懂analysis service的dba去问问
    humiaozuzu
        18
    humiaozuzu  
       2013-11-18 13:30:00 +08:00   ❤️ 2
    beaver -> redis -> logstash -> elasticsearch -> Kibana
    包搞定
    Sdhjt
        19
    Sdhjt  
    OP
       2013-11-18 13:57:48 +08:00
    谢谢大家的回复哈~~~感谢已发送
    综合了各位前辈的思路,我决定试试
    infobright

    beaver -> redis -> logstash -> elasticsearch -> Kibana
    两条思路
    pindleskin
        20
    pindleskin  
       2013-11-18 15:50:58 +08:00
    elasticsearch+kibana目前看起来是后端最好的组合,前面我们是用lumberjack+logstash,对logstash性能不满意,但目前还没看到太好方案可以灵活而高效地parse日志。前端还有好些不同的日志收集程序,如flume,fluentd,但目前还没看到能代替logstash的。
    ms2008
        21
    ms2008  
       2013-11-18 16:25:08 +08:00
    这么多数据都是有效数据吗?怎么不考虑下压缩问题:将同类日志压缩为一条记录,更新timestamp(firstoccurrence and lastoccurrence)和tally
    Actrace
        22
    Actrace  
       2013-11-18 16:33:27 +08:00
    MYSQL够了,MYISAM引擎的表,索引规划好,再使用延迟写入,性能上够用了.
    plan9
        23
    plan9  
       2013-11-18 18:18:54 +08:00   ❤️ 1
    试试fluentd
    bengtuo
        24
    bengtuo  
       2013-11-18 18:23:00 +08:00
    大数据啊 当然必须 hadoop hive 之类啊



    喷我把....
    pfipdaniel
        25
    pfipdaniel  
       2013-11-18 19:38:19 +08:00   ❤️ 2
    如果楼主的厂子不太缺金的话可以考虑splunk,这个数据量基本轻松搞定,之前给运营商上过一套这玩意,他们数据量可大多了。
    如果用开源软件的话,可以试试fluentd+mongodb+kibana,用开源软件的话还是建议应用栈尽可能简单一些,不然维护成本比较高,给自己找麻烦了
    halfbloodrock
        26
    halfbloodrock  
       2013-11-18 20:12:00 +08:00
    @pfipdaniel +1....splunk好贵。。。但是的确好用。。。
    plprapper
        27
    plprapper  
       2013-11-18 21:25:17 +08:00
    还是觉得hadoop比较合适。
    统计类的需求太灵活了,常规的DB index 不是什么好的选择。
    liushuaikobe
        28
    liushuaikobe  
       2013-11-19 08:46:48 +08:00
    @cloudqq redis明显不合适~
    feilaoda
        29
    feilaoda  
       2013-11-19 11:41:40 +08:00   ❤️ 1
    lz和我原来的公司,业务好像。

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

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

    当时storm还没出来,实时统计做的不够好。
    cloudqq
        30
    cloudqq  
       2013-11-19 16:31:29 +08:00
    @misaka @liushuaikobe 请问两位,reids不适合的原因在哪里, 请赐教。
    Sdhjt
        31
    Sdhjt  
    OP
       2013-11-19 18:07:55 +08:00
    目前正在测试Infobright,大数据神马的之后有时间研究研究,毕竟最近火的快成灰了:)
    richiefans
        32
    richiefans  
       2013-12-12 17:58:32 +08:00
    @Sdhjt 想问下楼主 Infobright 方案使用情况如何?
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2883 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 11:33 · PVG 19:33 · LAX 04:33 · JFK 07:33
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.