大(海)量数据采集以及处理方式?

sdudubing 2013-06-27 06:22:38
目前做一监控系统,底层数据上传多尔快,据粗略统计,在100个设备同时工作时,两分钟内有160万条数据上传,目前采用的数据采集程序数据延迟时间太长(包括数据从底层读出并将其解析保存到数据库),目前系统上线在即,相当担心数据采集这一块,而且web页面需要显示监控对象的实时状态,对页面的压力也是相当大。大家有做过类似项目的?或遇到过此类难题的?望能提供些解决思路,万分感谢,望版主给定下哈。
...全文
677 16 打赏 收藏 转发到动态 举报
写回复
用AI写文章
16 条回复
切换为时间正序
请发表友善的回复…
发表回复
yongtree 2013-07-10
  • 打赏
  • 举报
回复
我的建议采用两级处理,第一级建立队列,所有数据扔到队列里,等待执行,第二季为数据存储,放弃使用关系数据库,用无事务控制的nosql数据库,比如mongodb,hbase等,插入效率极高。利用消息队列做缓冲,是程序的处理线程时间变短。数据是不是可以分优先级,优先级高的可优先执行存储,优先级低的排队。当然这个可以扩展到几级。 页面上可以采用flex的数据自动推送技术,也可以用node.js这样的技术来搞定
onemy 2013-07-08
  • 打赏
  • 举报
回复
N个mangoDB+N个mysql,mangoDB接收实时数据,再通过ETL后进入关系型数据持久,mysql中到一定时间清掉,或转到一个历史库做归档。
小伙 2013-07-05
  • 打赏
  • 举报
回复
可以用一個A表保存 采集数据, 写个A表触发器, 更新到插入B表中
sdudubing 2013-07-04
  • 打赏
  • 举报
回复
引用 12 楼 ldh911 的回复:
[quote=引用 7 楼 sdudubing 的回复:] 另外不知道为啥底层设备上传的服务器IP和端口内置了,只能用一台服务器进行接收
即便这样,其实用硬件负载均衡也可以实现后端实际上多台服务器进行处理。 另外,可以考虑用内存数据库或MemCache来处理标签对应问题,只要某标签有3个以上探测器检测到,应该就可以大致模糊定位了吧。[/quote] 恩,对的,谢谢了
MiceRice 2013-07-03
  • 打赏
  • 举报
回复
引用 7 楼 sdudubing 的回复:
另外不知道为啥底层设备上传的服务器IP和端口内置了,只能用一台服务器进行接收
即便这样,其实用硬件负载均衡也可以实现后端实际上多台服务器进行处理。 另外,可以考虑用内存数据库或MemCache来处理标签对应问题,只要某标签有3个以上探测器检测到,应该就可以大致模糊定位了吧。
小丑哥_V5 2013-07-02
  • 打赏
  • 举报
回复
路过瞧瞧
sdudubing 2013-07-02
  • 打赏
  • 举报
回复
MiceRice 2013-07-01
  • 打赏
  • 举报
回复
引用 5 楼 sdudubing 的回复:
谢谢大家给的建议。
至少给点延伸信息吧。。。 这样建议也可以多点。。。 比如: 采集可以考虑分集群; 采集表与统计表分离设计; 采集表分区降低并发竞争; 采集表尽可能去除索引提升插入速度; 采集时采用批写入而非单笔写入; 采集时不入库,直接入文件; 采集指标与入库操作分离; ......
sdudubing 2013-07-01
  • 打赏
  • 举报
回复
引用 8 楼 yinzisheng 的回复:
可以采用缓存技术,数据采集和数据入库动作分开,这样可以缓解服务器压力。 也就是说,数据采集后,先将数据放入缓存中,然后前台页面显示时每次都从缓存里面读取,这样可以减少和数据的交互动作,提高读取效率,然后,缓存中的数据在慢慢的进行入库。现在比较常用的缓存:ecache、memcache 希望能帮到楼主。
yinzisheng 2013-07-01
  • 打赏
  • 举报
回复
可以采用缓存技术,数据采集和数据入库动作分开,这样可以缓解服务器压力。 也就是说,数据采集后,先将数据放入缓存中,然后前台页面显示时每次都从缓存里面读取,这样可以减少和数据的交互动作,提高读取效率,然后,缓存中的数据在慢慢的进行入库。现在比较常用的缓存:ecache、memcache 希望能帮到楼主。
sdudubing 2013-07-01
  • 打赏
  • 举报
回复
引用 6 楼 ldh911 的回复:
[quote=引用 5 楼 sdudubing 的回复:] 谢谢大家给的建议。
至少给点延伸信息吧。。。 这样建议也可以多点。。。 比如: 采集可以考虑分集群; 采集表与统计表分离设计; 采集表分区降低并发竞争; 采集表尽可能去除索引提升插入速度; 采集时采用批写入而非单笔写入; 采集时不入库,直接入文件; 采集指标与入库操作分离; ......[/quote] 项目是RFID定位应用项目,每个标签可以同时被多个读写器读到,读写器将标签位置信息上传给服务器,设计初期时是采用统计的方式对标签进行定位,但现在同一标签对应的多个读写器信息不是及时上传的。。。。。 公司用的自己开发的设备,第一次实际使用,设备上传的数据不稳定是个大问题,另外不知道为啥底层设备上传的服务器IP和端口内置了,只能用一台服务器进行接收。。。。。哎,扯淡啊。
sdudubing 2013-06-29
  • 打赏
  • 举报
回复
谢谢大家给的建议。
  • 打赏
  • 举报
回复
八下万条,建议还是采样吧,即取一个小段时间的数据,其它丢失处理,或者平平均之后再入库
eagleking012 2013-06-28
  • 打赏
  • 举报
回复
可以采用内存数据库,利用oracle的oci接口批量入库,并且文件不要放在数据库的磁盘上,这样会占用数据库的磁盘IO,而且要实现分布式数据库,单台数据库又入又查肯定是会比较慢了,要读写分开
MiceRice 2013-06-27
  • 打赏
  • 举报
回复
1分钟80W条,平均每秒1.3W条要写入数据库中。 不知道你这个是峰值速度还是平均速度,如果是平均速度,这事情难度还是相当不小的。 所谓实时状态,一般来说还是抽样的,这个取决于怎么抽样和频度问题,这个还算好说点点。
sdudubing 2013-06-27
  • 打赏
  • 举报
回复
望高手们指点一二,自己先顶下

25,980

社区成员

发帖
与我相关
我的任务
社区描述
高性能WEB开发
社区管理员
  • 高性能WEB开发社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧