kai_ding的专栏

除此之外，对于某些导入模型，例如 Routine Load，我们还可以降低 Job 的并发 Task 数量来降低对象存储的写入频率，我们可以观察 BE 日志中每个 Task 的单次 KafKa 消费数据量，如果发现量较小，那我们就可以降低 并发 Task 数量来降低对象存储写入次数。由于 StarRocks 使用了多版本存储机制，用户通过 show data 命令看到的表的大小与表实际在对象存储可能会有所差距，因此，我们建议用户应当特别关注在对象存储上实际占据的存储容量。

我们可以为存算分离表每个表指定特定的 Storage Volume，可以在建表时通过属性设置，具体可参考文档 https://docs.starrocks.io/zh/docs/sql-reference/sql-statements/data-definition/CREATE_TABLE/。可以在单个集群内创建多个 Storage Volume（数量无限制），且为不同的表指定不同的 Storage Volume，这样不同的表数据可以存储在不同的地方，可带来更好的数据隔离性。

StarRocks 存算分离新架构使用采用数据多版本技术，每次导入会产生新的数据版本，用户通过对象存储观察到存储空间使用是所有历史版本的容量之和，而用户通过 show data 查看到的则是当前最新版本的数据容量，这两者之间可能存在一些差异，这属于正常现象。然后，用户可以根据解析出相应的 DB id、Table id、Partition id 等信息，然后在系统中查询该 Table、Partition 等是否存在，如果不存在，可以安全地删除对象存储上的数据（直接使用对象存储的命令行工具物理删除即可）。

StarRocks 存算分离模式架构中，数据导入后，会被写入远端对象存储。而对象存储由于其访问延迟较高特性，如果没有任何优化，每次查询直接访问后端对象存储，那么性能就会变得非常差，也就失去了 StarRocks 的性能优势。一般而言，在存算分离架构下需要在计算节点上使用本地磁盘来缓存系统经常访问的热点数据，这样，当查询访问到这些数据时，直接访问本地磁盘中的缓存即可，可以提供与存算一体架构同等的查询性能。

使用 StarRocks 存算分离功能的同学可能之前常常被 DDL （常见的如增加列等）所困扰，主要在于 DDL 的执行时间过长并可能由此引发的一系列问题（如超时失败等），用户可能有时候不得不采用其他方式来替代（如按照新的 Schema 来重建表并重新导入数据）。幸运的是，在 3.3.0 版本中即将推出的 Fast Schema Evolution 能力让这一困扰我们许久的问题彻底变为历史。

除此之外，对于某些导入模型，例如 Routine Load，我们还可以降低 Job 的并发 Task 数量来降低对象存储的写入频率，我们可以观察 BE 日志中每个 Task 的单次 KafKa 消费数据量，如果发现量较小，那我们就可以降低 并发 Task 数量来降低对象存储写入次数。由于 StarRocks 使用了多版本存储机制，用户通过 show data 命令看到的表的大小与表实际在对象存储可能会有所差距，因此，我们建议用户应当特别关注在对象存储上实际占据的存储容量。