vertica 最佳实践之 ROS Bundling

最新推荐文章于 2020-12-22 16:48:37 发布

weiha666

最新推荐文章于 2020-12-22 16:48:37 发布

阅读量512

点赞数

分类专栏： vertica 文章标签：数据库大数据

原文链接：https://www.vertica.com/kb/ROSBundling/Content/BestPractices/ROSBundling.htm

版权

vertica 专栏收录该内容

14 篇文章 2 订阅

订阅专栏

Vertica 7.2引入了一种新的磁盘存储格式，将数据文件和索引文件存储在一个文件中，以减少小文件带来的碎片问题。ROS Bundling功能减少了文件数量，优化备份和恢复速度，但不会影响查询性能。升级到7.2后，可通过COMPACT_STORAGE()函数转换文件格式。最佳实践是在升级后、首次备份前执行转换。

摘要由CSDN通过智能技术生成

ROS Bundling

在Vertica 7.2之前，每列有两个文件-数据文件和索引文件。从Vertica 7.2开始，此格式不再存在。现在，这两个部分都存储在一个文件中。此外，多个数据文件和索引文件也可以存储在一个文件中。

Vertica file architecture

下图说明了Vertica文件体系结构，以及如何将表和投影简化为文件：

在这里插入图片描述

New storage format

Vertica旨在处理大型数据集。磁盘上的文件大小从数百兆字节到数百千兆字节不等。Tuple Mover有助于管理数据存储。内存中的缓冲区吸收trickle 流负载，并且当内存缓冲区已满时，Tuple Mover mergeout 操作会将数据写入ROS容器。为了管理磁盘上的文件数，Tuple Mover mergeout 操作会合并大小相似的ROS容器以创建更大的容器。有关更多信息，请参见 Tuple Mover最佳实践。

尽管此方法适用于大多数表，但它可能会在包含大量小文件的表上出现问题。如果您的数据集满足以下任一条件，则可能会发生这种情况：

宽表包含NULL值列
分区范围很小，例如按分钟分区。不建议这样做。
启用了Local segmentation，并且将因子设置为更高的数字。不建议这样做。

这些因素会在磁盘上创建小文件，从而导致很多碎片，从而影响节点的恢复和备份操作。为解决此问题，Vertica工程师开发了新的磁盘存储格式和设计，从而减少了磁盘上存储的文件数量。

How is the new format different?

现在，数据文件及其索引文件存储在一个文件中。例如，在Vertica 7.2之前，一个具有两列的投影，一个存储容器存储了六个文件。在Vertica 7.2和更高版本中，该容器存储三个文件。如果这些文件小于1MB，则Vertica会将它们捆绑在一起，并将它们存储为一个文件。

Does the new functionality bundle all projection files?

不，捆绑仅发生在一个存储容器内和一个存储位置内。小于MaxBundleableROSSizeKB的列文件捆绑在一起；其他列文件则作为独立的列文件保存在存储容器中。

Why is ROS bundling useful?

捆绑减少了存储容器中文件的数量，从而减轻了对底层文件系统的压力，并促进了更快的备份和还原操作以及恢复。捆绑不会减少目录的大小，也不会消除ROS pushback error。Bundling 不会更改读取列文件时使用的文件句柄数。

What configuration parameters are associated with the bundling functionality?

哪些配置参数与捆绑功能相关联？

参数	数据类型/默认值	描述
启用存储捆绑	Boolean/True	启用或禁用存储捆绑。
MaxBundleableROSSizeKB	Integer/1024	可以设置为1024 KB。如果有多个数据文件低于此大小限制，则在同一容器和存储位置中，文件将捆绑在一起。
CompactStorageJobSizeMB	Integer/ 2048	控制函数COMPACT_STORAGE（）的作业大小。

What is the upgrade impact from Vertica 7.1 to Vertica 7.2?

从Vertica 7.1升级到Vertica 7.2有什么影响？
升级不会自动将现有文件从旧格式转换为新格式。升级后，可以使用函数COMPACT_STORAGE（）转换现有文件的文件格式。如果EnableStorageBundling设置为true，则将发生以下行为：

所有新的装入和插入均以新的存储格式写入。
合并后的现有存储将以新的存储格式写入。

Are the old and new formats compatible?

新旧格式兼容吗？
是。如果您升级数据库，并且表中同时包含大文件和小文件，则可以有选择地将小文件移至新格式，而将大文件保留为旧格式。

如何将数据从旧的存储格式移动到新的格式？

使用COMPACT_STORAGE（），如以下示例所示：

=> SELECT COMPACT_STORAGE(object-name,
object-name,
min-ros-filesize-kb,
small-or-all-files,
simulate);

该函数的示例输出如下所示：

compact_storage
---------------------------------------------------------------------------------------------------------------
Task: compact_storage
On node node01:
Projection Name :public.foo_super | selected_storage_containers :2 | selected_files_to_compact :12 | files_after_compact : 2 | modified_storage_KB :0
On node node02:
Projection Name :public.foo_super | selected_storage_containers :2 | selected_files_to_compact :12 | files_after_compact : 2 | modified_storage_KB :0
On node node03:
Projection Name :public.foo_super | selected_storage_containers :2 | selected_files_to_compact :12 | files_after_compact : 2 | modified_storage_KB :0

Success

如果我为min_ros_filesize_kb指定的值与当前MaxBundleableROSSizeKB不同，该怎么办？

COMPACT_STORAGE（）函数参数min_ros_filesize_kb独立于MaxBundleableROSSizeKB配置参数。该函数使用您为min_ros_filesize_kb指定的值。这对MaxBundleableROSSizeKB的值没有影响。如果要在新的合并和加载中捆绑较大文件，则必须更改MaxBundleableROSSizeKB的值。

什么时候是转换为新存储格式的最佳时间？

为了获得最佳结果，请在将Vertica数据库升级到7.2之后，但在执行第一次备份之前，转换现有文件。这有助于备份和还原，原因有两个：

减少文件数量，从而加快备份速度。
传输新存储，因此后续备份可以更快地运行。

您可以在运行compact_storage时使用数据库。

COMPACT_STORAGE（）是否会影响查询性能？

COMPACT_STORAGE（）在存储容器级别读取和写入文件。与合并操作相比，它使用较少的内存，但会抢占磁盘I / O。

COMPACT_STORAGE（）需要运行多长时间？

由于此功能会重写文件，因此执行时间取决于更改的数据量。通过将COMPACT_STORAGE（）函数参数Simulation设置为TRUE来运行模拟，以确定将更改多少存储空间。

您可以通过在表或投影级别上迭代运行COMPACT_STORAGE（）来增量地重写存储格式。

我如何知道我的数据库是否将从此功能中受益？

如果备份和还原操作很慢，则可能是因为许多大文件没有合并。您可以运行以下查询来查找节点上投影的中位数文件大小：

=> SELECT MEDIAN(size) OVER() AS median_fsize
FROM vs_ros AS ros, storage_containers AS cont
WHERE ros.delid=cont.storage_oid
AND cont.node_name=‘node'
AND cont.projection_name=‘proj_name' limit 1;

You can also run COMPACT_STORAGE() in simulation mode to see how many files it can reduce:

=> SELECT COMPACT_STORAGE(‘table_or_proj_name’, 1024, ‘small’, ‘true’);

我可以使用哪个系统表查看捆绑的存储容器？

查询系统表VS_BUNDLED_ROS以查看捆绑了哪些列文件：

node_name|   projection_id   |                  sal_storage_id                  |      ros_id       | size_bytes |    storage_id
---------+-------------------+--------------------------------------------------+-------------------+------------+-------------------

initiator| 45035996273721386 | 0262c017f1fb9eb26b8d8e6266a7005e00a0000000004041 | 45035996273721409 |       5    | 45035996273721409

initiator| 45035996273721386 | 0262c017f1fb9eb26b8d8e6266a7005e00a0000000004041 | 45035996273721413 |       5    | 45035996273721409

initiator| 45035996273721386 | 0262c017f1fb9eb26b8d8e6266a7005e00a0000000004041 | 45035996273721417 |       48   | 45035996273721409

(3 rows)

如果我有大的存储容器，是否可以使用100MB作为min_ros_filesize_kb的值？

要确定min_ros_filesize_kb的值，请在模拟模式下运行COMPACT_STORAGE（）以确定资源使用情况。例如，如果您有一个包含100个数据文件的存储容器，每个文件小于1MB，COMPACT_STORAGE（）会将它们从200个文件更改为1个文件。在这种情况下，将min_ros_filesize_kb的值指定为100MB或1MB没什么区别。

如果您有另一个包含100个数据文件的容器，每个文件大约40MB，COMPACT_STORAGE（）会将它们从200个文件更改为1个文件。在这种情况下，指定100MB会产生积极的影响。如果我们指定1MB，则容器将从200个文件变为100个文件。

要确定为min_ros_filesize_kb设置什么值，请按照以下步骤操作：

选择一个投影。
确定文件数量和投影的中值文件大小。
在模拟模式下运行COMPACT_STORAGE（），其值的范围从中位数到100MB。
根据模拟产生的值，确定数据库的最佳位置。
以下示例显示了如何分析compact_storage对更新的Vertica数据库的需求和影响，以及如何确定min_ros_filesize_kb的最佳值：

检查文件计数是否未捆绑：

=> SELECT COUNT(distinct (salstorageid))
* 2 /* one fdb and one pidx */
FROM v_internal.vs_ros
WHERE bundleindex < 0;  -- older versions dont have bundleindex
count
---------
1379533
(1 row)

查找未捆绑的文件的大小和数量，按投影和节点分组：

=> SELECT CASE WHEN segment_lower_bound is not null  THEN 'SEGMENTED' ELSE 'REPLICATED' END AS type,
schema_name,
projection_name,
max(used_bytes) max_used_bytes,
min(used_bytes) min_used_bytes,
CASE  WHEN segment_lower_bound is not null THEN count (distinct colid) ELSE count (distinct colid), count(distinct rosid) AS nFiles
FROM storage_containers join v_internal.vs_ros ON (delid = storage_oid)
WHERE bundleindex < 0 -- older versions dont have bundleindex
GROUP BY 1,2,3 ,segment_lower_bound
ORDER BY 7 desc
;

type      | schema_name | projection_name | max_used_bytes | min_used_bytes | nCols | nFiles
----------+-------------+-----------------+----------------+----------------+-------+--------
SEGMENTED | schema      | clients_b1      |       92368520 |          14778 |    13 |    650
SEGMENTED | schema      | clients_b0      |       47906279 |          14728 |    13 |    611
SEGMENTED | schema      | clients_b0      |      100868741 |          18776 |    13 |    572
SEGMENTED | schema      | clients_b0      |       59835832 |          15173 |    13 |    572
SEGMENTED | schema      | clients_b1      |       58541167 |          15441 |    13 |    507
SEGMENTED | schema      | clients_b1      |       61792636 |          14728 |    13 |    507

在不同的桶中分配文件大小以查看分布情况`

=> SELECT
WIDTH_BUCKET (used_bytes, 0, 1024*1024*1024, 999) AS bucket, -- 1GB size of max bucket, 1000 buckets, (i.e. 1MB each bucket)
count(rosid) fileCnt
FROM
storage_containers JOIN v_internal.vs_ros ON (delid = storage_oid)
WHERE
schema_name = 'schema'
AND projection_name='clients_b1'
AND bundleindex < 0 -- older versions dont have bundleindex
GROUP BY 1
ORDER BY 1
;

bucket | fileCnt
-------+---------
1      |     715           <=== so many small 1 MB or less files
4      |      13
5      |      26
10     |      26
14     |      39
15     |      52
16     |      65
17     |      26
18     |      52
19     |      39
20     |     299
21     |      39
23     |      13
24     |      13
25     |      13
29     |      13
31     |      13
32     |      39
40     |      26
41     |      13
42     |      13
44     |      13
45     |      39
48     |      13
49     |      13
55     |      13
58     |      13
86     |      13
(28 rows)

在本例中，我们选择5MB作为压缩存储的大小。首先，进行预演，看看效果如何

=> SELECT COMPACT_STORAGE('schema.clients_b1', 5*1024, 'SMALL', true);  - 
                                 compact_storage
----------------------------------------------------------------------------------------------------------------

Task: compact_storage
On node v_scrutinload_node0001:
Projection Name :schema.clients_b1 | selected_storage_containers :50 | selected_files_to_compact :1012 | files_after_compact : 50 | modified_storage_KB :35584
On node v_scrutinload_node0002:
Projection Name :schema.clients_b1 | selected_storage_containers :39 | selected_files_to_compact :730 | files_after_compact : 39 | modified_storage_KB :16566
On node v_scrutinload_node0003:
Projection Name :schema.clients_b1 | selected_storage_containers :39 | selected_files_to_compact :728 | files_after_compact : 39 | modified_storage_KB :23126
Success

执行COMPACT_STORAGE ()。这将使用IO和资源。通过投影执行此操作可以在执行时进行更多的控制:

=> SELECT COMPACT_STORAGE('schema.clients_b1', 5*1024, 'SMALL', false);
                                    compact_storage

----------------------------------------------------------------------------------------------------------------

Task: compact_storage
On node v_scrutinload_node0001:
Projection Name :schema.clients_b1 | selected_storage_containers :50 | selected_files_to_compact :1212 | files_after_compact : 50 | modified_storage_KB :230564
On node v_scrutinload_node0002:
Projection Name :schema.clients_b1 | selected_storage_containers :39 | selected_files_to_compact :928 | files_after_compact : 39 | modified_storage_KB :221211
On node v_scrutinload_node0003:
Projection Name :schema.clients_b1 | selected_storage_containers :39 | selected_files_to_compact :926 | files_after_compact : 39 | modified_storage_KB :227449
Success

查看文件的新分发版

=> SELECT
WIDTH_BUCKET (used_bytes, 0, 1024*1024*1024, 999) AS bucket, -- 1GB size OF max bucket, 1000 buckets, (i.e. 1MB each bucket)
count(rosid) fileCnt
FROM
storage_containers JOIN v_internal.vs_ros ON (delid = storage_oid)
WHERE
schema_name = 'schema'
AND projection_name='clients_b1'
AND bundleindex < 0 -- older versions dont have bundleindex
GROUP BY 1
ORDER BY 1
;

bucket | fileCnt
-------+---------
14     |       1    <== small files are gone, largest one is 14MB ....
15     |       3
16     |       7
17     |       4
18     |       6
19     |       6
20     |      46
21     |       4
23     |       2
24     |       2
25     |       2
29     |       2
31     |       2
32     |       6
40     |       4
41     |       2
42     |       2
44     |       2
45     |       9
48     |       3
49     |       3
55     |       3
58     |       3
86     |       7
(24 rows)

比较buddy投影(b1)以查看影响

=> SELECT
CASE WHEN segment_lower_bound is not null  THEN 'SEGMENTED' ELSE 'REPLICATED' END AS type,
schema_name,
projection_name,
max(used_bytes) max_used_bytes,
min(used_bytes) min_used_bytes,
CASE  WHEN segment_lower_bound is not null THEN count (distinct colid) ELSE count (distinct colid) END as nCols,
count(distinct rosid) as nFiles
FROM storage_containers JOIN v_internal.vs_ros ON (delid = storage_oid)
WHERE bundleindex < 0 -- older versions dont have bundleindex
GROUP BY 1,2,3 ,segment_lower_bound
ORDER BY 7 desc;

type      | schema_ | projection_| max_used_bytes | min_used_bytes | nCols | nFiles
----------+---------+------------+----------------+----------------+-------+--------
SEGMENTED | schema  | clients_b0 |    47906279    |    14728       |    13 |    611
SEGMENTED | schema  | clients_b0 |   100868741    |    18776       |    13 |    572
SEGMENTED | schema  | clients_b0 |    59835832    |    15173       |    13 |    572
SEGMENTED | schema  | clients_b1 |    61792636    | 16300430       |     3 |     44     <=== better !
SEGMENTED | schema  | clients_b1 |    92368520    | 14086909       |     7 |     44
SEGMENTED | schema  | clients_b1 |    58541167    | 15202738       |     3 |     43
(6 rows)