江苏龙网

  1. 首页 > 生活 > >

数据量超大的实时查询，怎样设计方案

这个是分布式时序数据库的典型场景。提供一个使用DolphinDB解决类似场景的案例。
（1) 客户几百个业务场景，每天产生200多亿条时序日志记录（每条记录10个字段左右，维度+指标），所有数据写入采用双副本，并提供强一致性保证。每天产生数据2个T，双副本大概4个T，压缩之后1个T。数据保留15天左右。
（2）写入的同时有并发的查询和计算。大概分三种。
根据业务场景和时间范围，读取原始数据，每次读取最近一个小时左右的数据，约几十万条数据
按设备或按业务场景等维度进行分类统计过去24小时内每分钟的统计量（均值）
按设备或按业务场景等维度进行分类统计过去24小时内各种指标的95百分位，供实时监控使用。
这三种query涉及的数据量都比较大，每分钟大概2000~3000个这样的query。单个查询和计算的延迟在几十毫秒到2秒之间。
（3）部署了6台(36核，256G内存的服务器）物理机的DolphinDB集群解决上面的场景。实际上内存和cpu的使用率都不是很高，可以使用更少的资源来完成。
你的场景数据量少很多，但是要保留更长的时间。一台16~24核，128~256G内存，6~12个hdd硬盘的物理机（售价6~10万），安装DolphinDB时序数据库就可以搞定。你的业务场景非常简单，数据在DolphinDB中按照日期和设备两个维度分区就可以了。日期采用值分区，每天一个，设备采用范围或哈希分区，分成100个。这样每个分区的数据量大概在100万条左右，非常好的平衡了查询延时和吞吐量。


■网友
每日数据量近亿，说大也不大，但是对于设计方案，就要结合你的需求场景，什么样的查询需求？
1、虽然ES在日志全文检索领域很强大，但是如果存储10几天以上，也就是数据大小10几亿的话，会随着数据大小增大，性能会下降明显。
需要做很多优化处理，比如：对index进行分割，按天存储；如果不害怕丢数据，尽量少副本；缩短索引有效期等等。
这时候往往可以需求上面做一些妥协优化
2、如果后期没有全文检索的需求，只是根据设备、根据用户、根据时间查询，拉取日志等，完全可以使用hbase，存储TB级别无压力，基本的搜索无压力。
当然过程中，使用一些redis做一些缓存，肯定是有很大帮助的。

■网友
几点参考：
1、分析业务需求，支持的查询数据范围，是要求全量数据还是时间段内数据。
2、collection 按天归档，按设备、按天的统计数据，定时生成好，通过aggregate聚合计算。
3、选好索引，复合索引 与 查询条件顺序一致，优化查询条件使其命中的小范围数据（必要时可加冗余字段用于查询）
4、MongoDB分片集群
5、ElasticSearch热数据查询 + MongoDB近期数据 + 冷数据打包
基本思路就是把查询支持在一定范围内的数据量上，不要支持全量查询、不要支持全量查询、不要支持全量查询

■网友
设备每天10条数据，假设你1000万设备，每条数据100B，存储3个月，那么数据量是10*10M*100*90=900G。虽然这个量并不大，但是考虑到你还有查询，还要求平稳写入（设备数据持续产生，写不进去数据可能丢掉），单机数据库一般有些吃力了，所以你需要一个能扩展的数据库，或者说分布式数据库。
只要一个数据库敢说自己是分布式数据库，数据量肯定是没问题了。接下来还有几点你要考虑的，
哪些查询条件：简单的按PK查找，还是复杂的join，group by等？对查询延时的要求如何：10ms级别返回，还是秒级别返回成本：贵的数据库可能每年百万，功能多，省事直接用；便宜的可能每年数万，功能少一些，也许得自己做一些开发工作，要看情况

■网友
如果对于单机数据库这个数据量算大，每日亿级别增量，对于分布式数据库还好，在OB支撑的业务中，有单日增量为3亿的表，题主的需求很模糊，你得查询特点是什么？每台设备10条记录，那按单个设备查询不是问题，按天查的需求是什么？对设备分组分析吗？查询要求的返回时间在什么级别？ms还是s？如果要按天查询够快，那势必要利用分布式数据库的并行能力，可以将表按两个纬度分片，时间+设备id来提高并行度如果数据不能删除，那必然有热数据和冷数据的需求，考虑成本还需要切分成在线库和历史库，历史库可以用更廉价的磁盘和更差的CPU机型来存储，节约成本


推荐阅读


上一篇：农学研究生转行计算机，靠谱吗

下一篇：怎样评价微信2015年年会阳光普照奖为人手一台iPhone6S plus?