h**o
发帖数: 548 | 1 大概几十台servers, 每台server每天分析几十GB公司自己格式的web log.
目前是用c 语言分析,结果存成每日的xml.
然后有一台management server, 每天从 这几十台servers 收集 xml结果，
再用 perl parse 这些 xml 并和已有的历史文件（也是xml）合并生成 一个新的历史
文件。
记录包括daily，weekly, monthly的各种信息。
现在问题是这个xml文件太大不好parse。 想问能否用sql从新设计？
statistics 包括:
userID_$attr1_$attr2_$attr3_$attr4,
url_$attr1_$attr2_$attr3
sessionID_$attr3_$attr4
...
其中
$attrX is variable with a value. e.g. $attr3 is 手机类型 whose value can be
userID, url, sessionID are long lists of string.
收集的数据挺多得，但都还有关系。 如果用sql，把$attr1, $attr2, $attr3, $attr4
的各个values 排列组合一下大概几百张表吧。每张表就存诸如userID之类的一长串
string（目前大概几百万用户，以后可能增加）.一般是不是就是这样设计的?
用sql会不会数据库太大？有必要考虑big data NoSql？如果将来用户很大，到TB 级哪
？ |
s****a
发帖数: 9912 | 2 数据这么多，为什么没考虑直接WRITE IN DATABASE呢，
XML搞大量数据，慢就一个字，数据库数据库，是用来
存数据的，XML要能替代数据库，DBA都去喝西北风去了。
LOG数据这么重要，为什么不CUSTOMIZE写几个程序存进
数据库呢。与其成天去PARSE，为什么一开始没设计好 |
h**o
发帖数: 548 | 3 xml是前人写的。我要推翻重写。所以才来问。
请问这种例子是就普通 database 那, 还是考虑 NoSql 什么的。
【在 s****a 的大作中提到】
: 数据这么多，为什么没考虑直接WRITE IN DATABASE呢，
: XML搞大量数据，慢就一个字，数据库数据库，是用来
: 存数据的，XML要能替代数据库，DBA都去喝西北风去了。
: LOG数据这么重要，为什么不CUSTOMIZE写几个程序存进
: 数据库呢。与其成天去PARSE，为什么一开始没设计好
|
e****7
发帖数: 4387 | 4
每天web log 有多少gb 啊，以前在公司里专门做这个，我们每天只有只有6-7gb, data
mart 里存一年的，大概1.5T，然后所以数据转入OLAP。速度比数据库快多了。
【在 h**o 的大作中提到】
: 大概几十台servers, 每台server每天分析几十GB公司自己格式的web log.
: 目前是用c 语言分析,结果存成每日的xml.
: 然后有一台management server, 每天从 这几十台servers 收集 xml结果，
: 再用 perl parse 这些 xml 并和已有的历史文件（也是xml）合并生成 一个新的历史
: 文件。
: 记录包括daily，weekly, monthly的各种信息。
: 现在问题是这个xml文件太大不好parse。 想问能否用sql从新设计？
: statistics 包括:
: userID_$attr1_$attr2_$attr3_$attr4,
: url_$attr1_$attr2_$attr3
|
n******1
发帖数: 3756 | 5 我觉得首先要解决你们保存日志的需求是什么，要做什么用途
“再用 perl parse 这些 xml 并和已有的历史文件（也是xml）合并生成 一个新的历史
文件”，这个是周期归档，还是不停的merge
即使放到数据库，你还是要解决这个归档和休眠问题，不能因为开始放数据库方便就放
到数据库
【在 h**o 的大作中提到】
: 大概几十台servers, 每台server每天分析几十GB公司自己格式的web log.
: 目前是用c 语言分析,结果存成每日的xml.
: 然后有一台management server, 每天从 这几十台servers 收集 xml结果，
: 再用 perl parse 这些 xml 并和已有的历史文件（也是xml）合并生成 一个新的历史
: 文件。
: 记录包括daily，weekly, monthly的各种信息。
: 现在问题是这个xml文件太大不好parse。 想问能否用sql从新设计？
: statistics 包括:
: userID_$attr1_$attr2_$attr3_$attr4,
: url_$attr1_$attr2_$attr3
|
h**o
发帖数: 548 | 6 merge.
前一天的history information 和 当天的 information 汇总得出 新的 history
information。然后当天的information扔掉。
历史
【在 n******1 的大作中提到】
: 我觉得首先要解决你们保存日志的需求是什么，要做什么用途
: “再用 perl parse 这些 xml 并和已有的历史文件（也是xml）合并生成 一个新的历史
: 文件”，这个是周期归档，还是不停的merge
: 即使放到数据库，你还是要解决这个归档和休眠问题，不能因为开始放数据库方便就放
: 到数据库
|
h**o
发帖数: 548 | 7 十几GB/server,几十 servers.
data
【在 e****7 的大作中提到】
:
: 每天web log 有多少gb 啊，以前在公司里专门做这个，我们每天只有只有6-7gb, data
: mart 里存一年的，大概1.5T，然后所以数据转入OLAP。速度比数据库快多了。
|
n******1
发帖数: 3756 | 8 一年前的呢？三年前的呢？十年的呢？
【在 h**o 的大作中提到】
: merge.
: 前一天的history information 和 当天的 information 汇总得出 新的 history
: information。然后当天的information扔掉。
:
: 历史
|
h**o
发帖数: 548 | 9 目前只有daily, weekly, monthly, no yearly, 因为yearly 数据会很多，目前没法
parse. 再说目前只有一年前的数据。是否应该直接考虑NoSql之类的？
【在 n******1 的大作中提到】
: 一年前的呢？三年前的呢？十年的呢？
|
s**********o
发帖数: 14359 | 10 还想着NOSQL啊，人NOSQL是因为是BLOG,VIDEO和JPEG，
你没有这些搞什么NOSQL啊，就是因为当初的SOLUTION
是失败的，所以才搞不了YEARLY的，还抱着那个PARSE
人为的OVERHEAD不放。
【在 h**o 的大作中提到】
: 目前只有daily, weekly, monthly, no yearly, 因为yearly 数据会很多，目前没法
: parse. 再说目前只有一年前的数据。是否应该直接考虑NoSql之类的？
|
|
|
n******1
发帖数: 3756 | 11 当初用xml的人也是想，只有daily的数据，而且访问量也不大，xml作为中间文件容易
处理
【在 h**o 的大作中提到】
: 目前只有daily, weekly, monthly, no yearly, 因为yearly 数据会很多，目前没法
: parse. 再说目前只有一年前的数据。是否应该直接考虑NoSql之类的？
|
n****f
发帖数: 905 | 12 原始的 LOG 就不应该存成很大的文件。 比如每个文件存成 5M～20M 的LOG。
这样， 不仅仅主机的速度会很明显提高， 日后分析原始文件， 查找会很方便。
注意， 文件名中应该加入时间 STAMP， 要具体到秒 和序号。
这样的设计， 同时也会后台管理服务器更迅速地， 几乎是同步地分析前台的 LOG。
在安装服务器的时候， 应该把 LOG 文件， 单独存放在 RAID 10 的硬盘中。 这样就
可以避免和其他程序争夺读写资源。 RAID 10 是为了读写更快一些。
总之， 涉及的内容很多，要具体分析， 而不仅仅是逻辑层次上的设计。 |
e****7
发帖数: 4387 | 13
所以一年的数据有将近1T，是么？
可以找一下关于web analytics relation db schema, 建个数据库，数据用ETL 导入数
据库。然后再导入一个OLAP Engine, MS 的SSAS还不错。然后可以用EXCEL 接入来做分
析。
要不看看omniture, 他家做web analytics 好多年了。
【在 h**o 的大作中提到】
: 十几GB/server,几十 servers.
:
: data
|
s**********o
发帖数: 14359 | 14 人没说读写快慢，人说的是PARSE到数据库里慢，
存储那不是有TABLE PARTITION么，专门干这个的，
他这个就是数据库没设计好，搞成了XML慢死牛
不好用,也不需要SSAS，就是一个大TABLE
【在 n****f 的大作中提到】
: 原始的 LOG 就不应该存成很大的文件。 比如每个文件存成 5M～20M 的LOG。
: 这样， 不仅仅主机的速度会很明显提高， 日后分析原始文件， 查找会很方便。
: 注意， 文件名中应该加入时间 STAMP， 要具体到秒 和序号。
: 这样的设计， 同时也会后台管理服务器更迅速地， 几乎是同步地分析前台的 LOG。
: 在安装服务器的时候， 应该把 LOG 文件， 单独存放在 RAID 10 的硬盘中。 这样就
: 可以避免和其他程序争夺读写资源。 RAID 10 是为了读写更快一些。
: 总之， 涉及的内容很多，要具体分析， 而不仅仅是逻辑层次上的设计。
|
n****f
发帖数: 905 | 15 这段没看懂：
收集的数据挺多得，但都还有关系。 如果用sql，把$attr1, $attr2, $attr3, $attr4
的各个values 排列组合一下大概几百张表吧。每张表就存诸如userID之类的一长串
string（目前大概几百万用户，以后可能增加）.一般是不是就是这样设计的?
几百表？ 不会吧？WHY？
【在 h**o 的大作中提到】
: 大概几十台servers, 每台server每天分析几十GB公司自己格式的web log.
: 目前是用c 语言分析,结果存成每日的xml.
: 然后有一台management server, 每天从 这几十台servers 收集 xml结果，
: 再用 perl parse 这些 xml 并和已有的历史文件（也是xml）合并生成 一个新的历史
: 文件。
: 记录包括daily，weekly, monthly的各种信息。
: 现在问题是这个xml文件太大不好parse。 想问能否用sql从新设计？
: statistics 包括:
: userID_$attr1_$attr2_$attr3_$attr4,
: url_$attr1_$attr2_$attr3
|
n****f
发帖数: 905 | 16 别激动朋友。 请问这种 LOG 文件， 要如何做 PARTITION？
parse 之前要不要 DROP indexes?
parse 之后要不要重建 indexes?
呵呵， 慢， 仅仅是一个现象， 原因有很多。。。。
俺说说硬件不合法啊？
【在 s**********o 的大作中提到】
: 人没说读写快慢，人说的是PARSE到数据库里慢，
: 存储那不是有TABLE PARTITION么，专门干这个的，
: 他这个就是数据库没设计好，搞成了XML慢死牛
: 不好用,也不需要SSAS，就是一个大TABLE
|
s**********o
发帖数: 14359 | 17 存成XML文件本身就是个错误，你听谁说几百G的XML FILE BATCH JOB啊，
超过1G就要LOAD好长时间的，远不如CSV
【在 n****f 的大作中提到】
: 别激动朋友。 请问这种 LOG 文件， 要如何做 PARTITION？
: parse 之前要不要 DROP indexes?
: parse 之后要不要重建 indexes?
: 呵呵， 慢， 仅仅是一个现象， 原因有很多。。。。
: 俺说说硬件不合法啊？
|
h**o
发帖数: 548 | 18 谢谢大家。
对，瓶颈不在"分析web log."而在“把当天的xml和已有的历史文件（也是xml）
累积(是merge,不是简单的加)生成一个新的历史文件xml”这步。
前一年还好，现在客户多了，访问的量大了。累积量也大了，
历史文件 里 userID， url等 好多。没法parse了。
xml设计不是我做的。但现在要我重新设计。
客户需求类似于OLAP。
举个例子: userID_$attr1_$attr2_$attr3_$attr4：
$attr１ 包括 上传｜下传
$attr2 包括 各种 各种手机电脑类型 包括 爱风 | 安猪｜...
$attr3 包括 用户的 content 类型 包括 图型 | 文本 | 视频 | ...
$attr4 包括 公司的东西。 attr4A | attr4B | attr4C | attr4D | ...
例如 monthly report of userID_下传_爱风_视频_attr4A 目的是求：
每月有多少爱风手机用户下传attr4A的视频。注意每个符合要求的用户string都要存在
这张report里，否则将来merge时没法知道前天和当天出现的用户是不是同一个人，导
致重复计算。
如果每个report 是一个包含好多用户string的SQL table, 把$attr1, $attr2, $attr3
, $attr4 的各个值排列组合一下不就是一百张多张表吗。然后表还分monthly，daily,
weekly，yearly 这就变成几百张表。这还只是关于userID的表。还有别的类型的表.
不就几千张表了吗？
我不是做数据库的。所以想知道这种情况一般都是怎么做的。
有人告诉我象这种多维的报告就生成几百，几千张sql table 好了。我觉得应该不会这
样吧。
觉得eagle7说的OLAP是个解法。OLAP scalable 吗， 贵吗，还是有免费好用的软件？
另外，attrX 的分类目前是定下来的，不过将来肯定会增加。例如手机电脑类型，
content类型。还有将来还可能会有$attr5, 怎么处理？
另外，如果将来用户量，访问的量，储存量等大量增加,一般的DataBase 还能处理吗？
我问NoSql是因为想往比较热门的大数据方向靠. 这样自己就有机会学习了。但是要是
这种情况已经有
通用解法如OLAP，不适合大数据设计，那就算了。
【在 h**o 的大作中提到】
: 大概几十台servers, 每台server每天分析几十GB公司自己格式的web log.
: 目前是用c 语言分析,结果存成每日的xml.
: 然后有一台management server, 每天从 这几十台servers 收集 xml结果，
: 再用 perl parse 这些 xml 并和已有的历史文件（也是xml）合并生成 一个新的历史
: 文件。
: 记录包括daily，weekly, monthly的各种信息。
: 现在问题是这个xml文件太大不好parse。 想问能否用sql从新设计？
: statistics 包括:
: userID_$attr1_$attr2_$attr3_$attr4,
: url_$attr1_$attr2_$attr3
|
e****7
发帖数: 4387 | 19
我也想听听有没有OLAP以外的办法。
另外想提的就是OMNITURE，和google analytics .
微软的OLAP应该不贵，性价比还不错。open source 的也有，如pentaho cube, 不过一
分钱一分货吧。
weblog 这玩意本身就是一个多维数据，用OLAP可以解决很多aggregation 的计算，
data mart 有十几个表就差不多了。什么dimension hierarchy, aggregation 让OLAP
来完成就容易多了。按照时间或其它的attribute 也狠容易建立partition, 所以
scaling 应该不是大问题。
如果公司请人做OLAP的话，帮我递个简历吧，短期的也行啊，哈哈
【在 h**o 的大作中提到】
: 谢谢大家。
: 对，瓶颈不在"分析web log."而在“把当天的xml和已有的历史文件（也是xml）
: 累积(是merge,不是简单的加)生成一个新的历史文件xml”这步。
: 前一年还好，现在客户多了，访问的量大了。累积量也大了，
: 历史文件 里 userID， url等 好多。没法parse了。
: xml设计不是我做的。但现在要我重新设计。
: 客户需求类似于OLAP。
: 举个例子: userID_$attr1_$attr2_$attr3_$attr4：
: $attr１ 包括 上传｜下传
: $attr2 包括 各种 各种手机电脑类型 包括 爱风 | 安猪｜...
|
