目前做一监控系统，底层数据上传多尔快，据粗略统计，在100个设备同时工作时，两分钟内有160万条数据上传，目前采用的数据采集程序数据延迟时间太长（包括数据从底层读出并将其解析保存到数据库），目前系统上线在即，相当担心数据采集这一块，而且web页面需要显示监控对象的实时状态，对页面的压力也是相当大。大家有做过类似项目的？或遇到过此类难题的？望能提供些解决思路，万分感谢，望版主给定下哈。1分钟80W条，平均每秒1.3W条要写入数据库中。
不知道你这个是峰值速度还是平均速度，如果是平均速度，这事情难度还是相当不小的。
所谓实时状态，一般来说还是抽样的，这个取决于怎么抽样和频度问题，这个还算好说点点。可以采用内存数据库，利用oracle的oci接口批量入库，并且文件不要放在数据库的磁盘上，这样会占用数据库的磁盘IO，而且要实现分布式数据库，单台数据库又入又查肯定是会比较慢了，要读写分开我的建议采用两级处理，第一级建立队列，所有数据扔到队列里，等待执行，第二季为数据存储，放弃使用关系数据库，用无事务控制的nosql数据库，比如mongodb，hbase等，插入效率极高。利用消息队列做缓冲，是程序的处理线程时间变短。数据是不是可以分优先级，优先级高的可优先执行存储，优先级低的排队。当然这个可以扩展到几级。
页面上可以采用flex的数据自动推送技术，也可以用node.js这样的技术来搞定 路过瞧瞧
至少给点延伸信息吧。。。
这样建议也可以多点。。。
比如：
采集可以考虑分集群；
采集表与统计表分离设计；
采集表分区降低并发竞争；
采集表尽可能去除索引提升插入速度；
采集时采用批写入而非单笔写入；
采集时不入库，直接入文件；
采集指标与入库操作分离；
......
即便这样，其实用硬件负载均衡也可以实现后端实际上多台服务器进行处理。
另外，可以考虑用内存数据库或MemCache来处理标签对应问题，只要某标签有3个以上探测器检测到，应该就可以大致模糊定位了吧。N个mangoDB+N个mysql，mangoDB接收实时数据，再通过ETL后进入关系型数据持久，mysql中到一定时间清掉，或转到一个历史库做归档。可以采用缓存技术，数据采集和数据入库动作分开，这样可以缓解服务器压力。
也就是说，数据采集后，先将数据放入缓存中，然后前台页面显示时每次都从缓存里面读取，这样可以减少和数据的交互动作，提高读取效率，然后，缓存中的数据在慢慢的进行入库。现在比较常用的缓存：ecache、memcache
希望能帮到楼主。可以用一個A表保存 采集数据， 写个A表触发器， 更新到插入B表中八下万条，建议还是采样吧，即取一个小段时间的数据，其它丢失处理，或者平平均之后再入库