2019大数据产业峰会|中国信通院王妙琼：时序数据库性能测试基准解读
|
智能网联汽车，现在新能源汽车数据上云需求非常大。这个例子中，汽车GPS位置数据、发动机状态、停车时长等数据都会按一定时间传输到云上。按每隔10秒传一次，两万辆汽车同时往上传，每天会有100亿个数据点的数据量，75G/天。会统计车辆一段时间的运行轨迹、停车时长、运行时长等等。 我们从这两个典型案例中提炼出5大性能考察项，覆盖了时序数据库的主要应用特征：写入能力、查询能力、数据聚合能力、数据批量导入能力、压缩效率。 在设计数据集的时候，其实我们争论了很久，开了两次会议，大概80%的时间都在讨论数据集应该怎么设计，这里提3个数据集应该考虑的特点： 时间线。时序数据中有一个重要的概念：测点，可以通俗的理解为一个不断产生数据的传感器，一个测点在一段时间内产生的数据为一条时间线，测点数量、时间长度和密度可以决定数据量的大小。这里有个小的例子，每个配电柜有三个传感器也就是三个指标，每时每刻都在不停的产生数据，横向是一个时间轴，在这个时间轴里面会产生时间线，时间线包含着每个传感器在这段时间里面产生的所有数据。数据集的设计其实需要设计到测点数量的概念，测点数量和时间长度会影响时序数据的写入性能和最后分析的性能。 数据类型。在刚刚提到的两个场景中，对数据类型的要求是不一样的。智能网联汽车场景里面主要会涉及到大比例的Double和Long类型的数据，比如GPS数据、CAN总线数据，此外还包含Bytes数据和String数据。电厂监控不涉及string数据，更多是float数据和Bool数据。我们需要考虑这几个数据类型的配比问题。 实时/历史数据源。为什么区别这两种数据源？传统的数据库测试一般都会使用历史数据源，相当于摆一大桌子菜在桌子上，大家能吃多少就吃多少，能吃多快吃多快，也能测出性能。但是时序数据库的场景不一样，好比旋转寿司店，小碟子在不停的传过来，如果不吃掉就转走了，数据也一样，传过来如果不能及时处理掉，可能造成数据积压或丢失。在典型的时序数据库场景里面数据是源源不断生成的，比如有十万个传感器，每秒产生一个数据点，每秒就有十万条数据。如何及时处理数据是需要考虑的关键性问题，所以在时序数据性能测试场景当中不能仅仅考虑历史数据源导入问题，还需要设计实时数据源。 除了刚刚提到的这些数据集的注意点，为了让测试基准更贴近现场需求，我们也设计了读写混合的场景及其他一些细节。比如在工厂现场，不会把所有实时数据写入的进程都停掉再做数据的分析，所有数据读取和分析都是在数据写入的同时进行的。我们在用例设计上也会设计这类测试，在保证实时数据源进入的同时，考核它的读取和聚合的性能。会考察单机性能和集群性能，看能力的扩展，这些也是用户关注的内容。另外对是结果进行可信的比较，比如所有数据操作要选取相同时间段，选取多个不同长度时间段，还有选取多个相同时间段的操作求平均，以此来保证结果的公平性。 最后列举一下设计的测试用例的情况，我们这一版本设计了6个用例： 1、实时写入。在固定测点，固定时间间隔，固定持续写入时间的情况下，保证写入数据集相同，考察它的平均时延和最大、最小时延。 2、历史数据导入。这里设计两个数据集，一个是较少测点，另外一个是大量测点的数据集，两个数据集持续时长有些区别，这样能在写入时和分析当中都能体现出一些具体性能上的差别。 3、实时写入+实时读取。实时写入情况下考察实时读取的性能，这主要是为了一些监控类型的场景，实时数据收集过来后能不能及时反馈出当前最新的数据。 4、在实时写入的情况下对历史数据进行数据聚合的操作，看具体聚合的时延。 5、历史数据读取。纯粹的没有数据写入的时候做历史查询是什么样的情况。 6、数据压缩比。时序数据库特有的一个考察项就是压缩性能，在数据存入数据库之后所占用空间和原先数据集大小比例是多少，能有多大的压缩性能。 本次演讲最后，再次感谢一下时序数据库性能项目组的付出，我们的参与单位：百度云、麦杰科技、腾讯云、朗坤智慧、涛思数据、天数智芯、庚顿数据、网易。时序数据库下半年会开启性能测试项目，希望大家继续关注我们的工作。 （编辑：牡丹江站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
