Tablestore Adhoc 分析性能测试白皮书

本文涉及的产品
对象存储 OSS,20GB 3个月
表格存储 Tablestore,50G 2个月
对象存储 OSS,恶意文件检测 1000次 1年
简介: 本文主要介绍 Tablestore 在 Adhoc 分析场景下的性能测试,主要包括测试环境、测试工具、测试方案、测试结果以及测试结论等。

本文主要介绍 Tablestore 在 Adhoc 分析场景下的性能测试,主要包括测试环境、测试工具、测试方案、测试结果以及测试结论等。

Tablestore 是什么

Tablestore 启发自 Google 的 Bigtable 论文,从2009年开始,在阿里云的飞天团队内,开始孵化。经过 10 年的锤炼,如今在集团、公有云和专有云积累了各式各样的客户和场景。

Tablestore 是一款 Serverless 云原生存储引擎,Serverless 相比实例售卖类型的产品,在业务有波峰波谷时天生就有较大的优势,基于 Bigtable 的主存储采用行的方式进行存储,可以支撑单表亿级别的 QPS。下面列了一些 Tablestore 的核心特性:

1.png

Tablestore 除了有强大的主存储满足海量业务的实时读写外,基于主存储的分布式日志提供了完整的数据派生能力(详情参考),海量实时写入 Tablestore 的数据,可以实时订阅进行消费。这样就满足了我们的实时计算需求。

Lambda 架构中除了实时数据写入,实时计算之前,全量数据需要提供高性能扫描能力,Tablestore 采用行列混合,双引擎的架构,在主存储之外内部通过通道服务实时构建一个列存储,支撑 PB 级别数据的高吞吐扫描。同时在海量的数据场景下,我们相信数据是需要分层存储,所以在构建自身列存的同时,我们会帮助用户构建推送云上数据湖的链路,通过全托管的数据湖投递,降低用户的存储成本。

2.png

基于 Tablestore 的 Lambda 架构

Tablestore 在专注于打造一款极致性能和成本的存储引擎同时,更加关注完整的计算生态,伴随产品核心功能迭代的过程中,我们和阿里云的几大核心计算引擎做了完善的对接具体包括:

  • MaxCompute 的对接,支持 MaxCompute 计算引擎通过外表的方式直读写 Tablestore

  • EMR Spark 对接,支持流批源表读,流批结果表写,集团内第一款全 Connector 支持的 KV 存储引擎

  • Blink 对接,支持流批源表读,流批结果表写,维表读,集团内第一款全 Connector 支持的 KV 存储引擎

  • DLA 对接,支持 SQL 直接读写 Tablestore 的数据

  • FC 对接,支持流式增量触发器

接下来,本文会介绍通过阿里云几个核心计算引擎结合 Tablestore,在在线离线两个场景分别进行 Adhoc 分析的性能测评。

测试环境

本次测试会用到表格存储、EMR、OSS、DLA等多个服务,以下是相关配置:

  • 表格存储

    • 实例类型:高性能实例

    • 实例地域: 华东1-杭州

    • 多元索引配置:ParallelScan MaxParallel = 512

  • EMR集群

    • 集群地域:华东1-杭州

    • 配置:Master (24核96GB) * 1,CORE(24核96GB) * 25

  • OSS

    • 地域:华东1-杭州
  • DLA

    • 地域:华东1-杭州

测试工具

  • 原始数据集

数据源选用 TPC-H 的 lineitem 表(CSV文件),大小为 1TB,总行数为 85 亿行。

测试方案

本次性能测试将通过运行几种典型场景的SQL查询,来进行Adhoc查询的性能测试。

测试范围

  • 在线场景

  • 离线场景

    • DLA + OSS

    • EMR + JindoFS + OSS,开启缓存

测试场景

  • Count table: 全表count

  • Key lookup: 基于主键的查询

  • Non-Key lookup: 非主键查询

  • Scan table with(/without) projection: 全表扫描

测试指标

本次测试主要包含以下几项指标:

  • SQL 执行总耗时:表示的是执行 SQL 的总时间,单位为秒(e.g. 37.122s)。其中,EMR + JindoFS + OSS方案中会开启缓存,SQL执行耗时将会展示先后的3次查询耗时。

  • SQL 执行吞吐量:表示的是 SQL 执行时的平均处理行数,其值为 SQL 扫描行数/执行总耗时,单位为(行/s)。

测试结果

在线场景

针对在线场景,我们主要通过 EMR Spark 测试访问 Tablestore 主表和多元索引的性能表现。

测试项 SQL 命令 访问方式 SQL 总耗时 吞吐量
Count table select
count(*)
from
lineitem_index_512;
Tablestore 多元索引 692s 1800万/s
Tablestore 表引擎 1056s 1200万/s
Key lookup select
count(*)
from
tpch1
where 
l_orderkey = 1;
Tablestore 多元索引 1s -
Tablestore 表引擎 0.9s -
Non-key lookup select
count(*)
from
tpch1
where
l_shipdate >= '1994-05-02'
and l_shipdate < '1994-11-30'
and l_discount < 0.03
and l_quantity < 4;
Tablestore 多元索引 6s 600万行/s
Tablestore 表引擎 1197s 1200万/s
Scan table with projection select
l_orderkey
from
lineitem_index_512
order by l_orderkey
limit 1;
Tablestore 多元索引 703s 1200万/s
Tablestore 表引擎 1069s 1200万/s
Scan table without projection select
*
from
tpch1
order by l_orderkey
limit 1;
Tablestore 多元索引 预计3200s 260万/s
Tablestore 表引擎 预计1860s 457万/s

-:表示该数据无法测量或者测量无意义。

离线场景

Tablestore 提供数据湖投递的能力,将主表数据同步到 OSS,以 parquet 文件的方式存储。详细文档请参考官方文档 - Tablestore 数据湖投递
利用数据湖投递可以实现如下场景需求:

  • 冷热数据分层
    数据湖投递结合表格存储的数据生命周期功能,可以快速实现 OSS 低成本存储全量数据,表格存储提供热数据的低延迟查询和分析的需求。

  • 全量数据备份
    数据湖投递可以自动将表格存储的全表数据投递到 OSS Bucket 中,作为备份归档数据。

  • 大规模实时数据分析
    数据湖投递可以实时(每2分钟)投递增量的表格存储数据到 OSS,投递的数据支持按系统时间分区、Parquet 列存格式存储;再利用 OSS 的高读带宽和列存面向扫描场景优化实现高效实时数据分析。

  • 加速 SQL 分析性能
    当表格存储数据未建立多元索引且查询条件中不包含主键列的过滤条件时,可以通过数据投递自动同步数据到 OSS,再利用 DLA+OSS 数据扫描实现 SQL 分析加速。

3.png

于是,针对离线场景,我们测试 Tablestore 数据湖方案中的查询性能表现。

测试项 SQL 命令 访问方式 SQL 总耗时 吞吐量
Count table select
count(*)
from
lineitem_index_512;
DLA + OSS 3s 28亿/s
EMR + jindoFS + OSS 先后3次查询耗时:
11s 4s 4s
21亿/s
Key lookup select
count(*)
from
tpch1
where
l_orderkey = 1;
DLA + OSS 2s 44亿/s
EMR + jindoFS + OSS 11s 3s 3s  30亿/s
Non-key lookup select
count(*)
from
tpch1
where
l_shipdate >= '1994-05-02'
and l_shipdate < '1994-11-30'
and l_discount < 0.03
and l_quantity < 4;
DLA + OSS 43s 2亿/s
EMR + jindoFS + OSS 10s 8s 9s 10亿/s
Scan table with projection select
l_orderkey
from
lineitem_index_512
order by l_orderkey
limit 1;
DLA + OSS 8s 10亿行/s
EMR + jindoFS + OSS 14s 5s 4s 21亿行/s
Scan table without projection select
*
from
tpch1
order by l_orderkey
limit 1;
DLA + OSS 178s 4775万/s
EMR + jindoFS + OSS 68s  50s  50s 1.7亿/s

测试结论

在线场景

  • 时效性:秒级

  • 主键查询建议使用 Spark 直接查询 Tablestore 表引擎,针对简单查询场景来说性价比较高

  • 非主键查询,复杂查询(如空间查询)建议使用 Spark 查询 Tablestore 多元索引,查询性能比表引擎提升明显,且支持更灵活的查询

离线场景

  • 时效性:分钟级(甚至小时级)

  • 冷热数据分层和大规模离线数据分析场景建议使用 Tablestore 数据湖投递功能,可选用的计算引擎有 DLA 和 EMR

欢迎加入

表格存储 Tablestore 推出了很多贴近用户场景的文章与示例代码,欢迎大家加入我们的钉钉公开交流群一起讨论,群号:23307953。(1 群已满员,欢迎加入 2 群)

tablestore 二维码.png

相关实践学习
借助OSS搭建在线教育视频课程分享网站
本教程介绍如何基于云服务器ECS和对象存储OSS,搭建一个在线教育视频课程分享网站。
目录
相关文章
|
6月前
|
机器学习/深度学习 人工智能 测试技术
深入分析自动化测试中的挑战与机遇
【5月更文挑战第27天】 随着软件开发周期的不断缩短和发布频率的增加,自动化测试成为确保软件产品质量的关键手段。本文将探讨在实施自动化测试过程中面临的主要挑战,包括维护成本、测试用例设计、与持续集成的融合等,并讨论如何通过最新的技术趋势如人工智能(AI)和机器学习(ML)来克服这些挑战,以及它们为自动化测试带来的新机遇。
|
29天前
|
缓存 监控 算法
软件测试中的性能瓶颈分析与优化策略
【10月更文挑战第6天】 性能测试是确保软件系统在高负载条件下稳定运行的重要手段。本文将深入探讨性能测试的常见瓶颈,包括硬件资源、网络延迟和代码效率等问题。通过具体案例分析,我们将展示如何识别并解决这些问题,从而提升软件的整体性能。最后,文章还将分享一些实用的性能优化技巧,帮助读者在日常开发和测试中更好地应对性能挑战。
75 3
|
2月前
|
监控 测试技术 持续交付
软件测试中的性能瓶颈分析与优化策略
性能瓶颈,如同潜伏于软件深处的隐形障碍,悄然阻碍着系统的流畅运行。本文旨在揭示这些瓶颈的形成机理,剖析其背后的复杂成因,并汇聚一系列针对性的优化策略,为软件开发者提供一套系统性的解决方案。
49 5
|
1月前
|
缓存 监控 测试技术
软件测试中的性能瓶颈分析与优化策略
本文深入探讨了在软件测试过程中,如何有效地识别和解决性能瓶颈问题。通过对性能瓶颈的定义、分类以及常见原因的分析,结合实际案例,提出了一系列针对性的优化策略和方法。这些策略旨在帮助测试人员和开发人员提高软件的性能表现,确保软件在高负载条件下依然能够稳定运行。
|
2月前
|
测试技术 持续交付 UED
软件测试的艺术与科学:平衡创新与质量的探索在软件开发的波澜壮阔中,软件测试如同灯塔,指引着产品质量的方向。本文旨在深入探讨软件测试的核心价值,通过分析其在现代软件工程中的应用,揭示其背后的艺术性与科学性,并探讨如何在追求技术创新的同时确保产品的高质量标准。
软件测试不仅仅是技术活动,它融合了创造力和方法论,是软件开发过程中不可或缺的一环。本文首先概述了软件测试的重要性及其在项目生命周期中的角色,随后详细讨论了测试用例设计的创新方法、自动化测试的策略与挑战,以及如何通过持续集成/持续部署(CI/CD)流程优化产品质量。最后,文章强调了团队间沟通在确保测试有效性中的关键作用,并通过案例分析展示了这些原则在实践中的应用。
70 1
|
2月前
|
监控 算法 测试技术
软件测试中的性能瓶颈分析与优化策略
本文旨在深入探讨软件测试过程中性能瓶颈的识别与优化方法。通过对性能瓶颈的概念、分类及其成因进行分析,结合实际案例,提出一套系统的性能瓶颈诊断流程和针对性的优化策略。文章首先概述了性能瓶颈的基本特征,随后详细介绍了内存泄漏、资源竞争、算法效率低下等常见瓶颈类型,并阐述了如何通过代码审查、性能监测工具以及负载测试等手段有效定位问题。最后,结合最佳实践,讨论了代码级优化、系统配置调整、架构改进等多方面的解决措施,旨在为软件开发和测试人员提供实用的性能优化指导。
69 4
|
3月前
|
前端开发 测试技术 UED
【测试效率对比】深入分析:为何UI自动化测试的投资回报率通常低于接口自动化测试?
这篇文章深入分析了UI自动化测试与接口自动化测试的投资回报率(ROI)问题,指出UI自动化测试在某些情况下的ROI并不低,反驳了没有实施过UI自动化就轻易下结论的观点,并强调了实践的重要性和自动化测试在项目迭代中的作用。
77 1
|
2月前
|
SQL 搜索推荐 测试技术
ChatGPT与测试分析
本产品需求文档(PRD)针对论坛网站的搜索功能优化,旨在提升搜索结果的准确性和速度,增强用户体验。文档涵盖项目背景、目标、功能需求(如搜索结果准确性、搜索速度优化、过滤和排序等)、非功能需求(如兼容性、性能、安全性等)、用户界面设计和技术架构等内容,并制定了详细的测试和上线计划,确保项目顺利实施。
28 0
|
5月前
|
存储 缓存 NoSQL
Redis性能测试实操记录与分析
Redis性能测试实操记录与分析
76 3
|
5月前
|
SQL 监控 中间件
【应急响应】拒绝服务&钓鱼指南&DDOS压力测试&邮件反制分析&应用日志
【应急响应】拒绝服务&钓鱼指南&DDOS压力测试&邮件反制分析&应用日志
下一篇
无影云桌面