如何进行海量数据的查询
我们对于海量数据,一般不会直接查询原始的数据结构,因为数据量太大了,一般是使用流计算和批计算先进行一次或者多次的汇聚 过滤 计算,将计算结果落到另外一个存储系统中,然后由这个存储系统来提供查询支持
常见的流计算诸如Flink Storm 这种实时的计算,批计算是Map-Reduce或者Spark这种非实时计算
点击流或者监控这种数据往往是TB级别的,计算后可以减少到GB级别
但是有些业务,计算后的数据仍然还是一个海量的级别
对于这种海量数据,如何才能让查询更快一些
一般查询海量数据的系统,大多数都是离线分析类系统,我们简单的理解为报表的系统,主要是对数据做统计分析,重度依赖于存储,所以我们需要先考虑存储系统和数据结构,然后在查看相关的性能
分析型数据库对于存储的需求一般是,存储要求能保存海量的数据
能对海量数据进行聚合和查询,速度保证分钟级别即可
数据大多数都是异步的写入,对于性能和响应时延,要求不高
我们看下相关的存储产品,系统数据量在GB级别以下,MySQL是可以考虑的,这个系统可以应对大部分分析系统的需求
如果超过了MySQL的极限,可以考虑列式的数据库,比如HBase,Cassandra ClickHouse,对海量数据由好的查询性能,但是这种查询性能带来的副作用就是功能上缩水,导致对于数据的组织方式有一定的限制,查询也不是那么的灵活,需要按照预定的姿势使用
当然,我们可以考虑使用ES,ES是利用了结构化的数据的存储和查询,利用Map-Reduce的方式进行并行的查询,而且查询的灵活性很好,但是ES有一个缺点,就是需要一个大内存的服务器
当数据量超过TB级别的时候,对如此大数量级的数据进行分析,无论什么存储系统,都不会快,这时候的性能在于磁盘的IO和网络的带宽,所以我们可以考虑定时的将数据聚合好,然后对结果进行二次的查询,这种大量级的数据,一般都是存在HDFS,配合Map-Reduce,Spark Hive等大数据生态圈的产品做数据聚合和计算
对于海量的数据,根据体量去选择存储系统是不明智的,不同的存储方式应对的方面是不同的,在其擅长的领域或者场景下,会有很好的性能表现
最近比较火的RocksDB和LevelDB,存储结构换为了LSM-Tree,就是日志和跳表的组合,单从数据结构的时间复杂度来说,没有任何本质的提升,但是方便和日志结合,所以存储系统的选择,没有银弹,不要指望更换一种数据库,就可以解决数据量大的问题
我们要根据具体的查询来选择数据结构和存储系统,就比如全文搜索,ES的倒排索引就比B+树快
京东的内部智能补货系统,可以根据历史的物流记录,对未来做出一定的趋势,所以保证快速的下单后送达,这个系统后,就需要分析几亿条的数据,每条又需要细分到几段或者几十段
对于这种系统,必须设计单独的数据结构,利用单独的数据库进行解决所有的问题
对于上面的京东智能补货,可以将数据按照区域进行划分,汇总一个全国的跨区物流,先保证每个查询落到对应地点的分片上
总体来说,对于海量数据,一般支持的是离线分析类业务的查询,可以分别选择,关系型数据库,列式数据库,大数据存储
而且对于存储来说,没有真实的银弹,重要的是转变思想,根据业务,反推使用什么样的存储系统,如何分片,如何组织,同样的数据,要根据不同的查询需求,组织为不同的数据结构