Skip to main content
Enterprise applications
简体中文版经机器翻译而成，仅供参考。如与英语版出现任何冲突，应以英语版为准。

部分文件分层

贡献者
PDF

由于FabricPool在块级别工作、因此可能会更改的文件可以部分分层到对象存储、同时也可以部分保留在性能层上。

这在数据库中很常见。已知包含非活动块的数据库也是FabricPool层的候选数据库。例如、供应链管理数据库可能包含历史信息、这些信息在需要时必须可用、但在正常操作期间不会访问。可以使用FabricPool有选择地重新定位非活动块。

例如、使用的FabricPool卷上运行的数据文件 tiering-minimum-cooling-days 90天期限将在性能层上保留前90天访问的任何块。但是、任何在90天内未访问的内容都会重新定位到容量层。在其他情况下、正常应用程序活动会将正确的块保留在正确的层上。例如、如果数据库通常用于定期处理前60天的数据、则要低得多 tiering-minimum-cooling-days 可以设置期限、因为应用程序的自然活动可确保不会过早重新定位块。

。 auto 对数据库使用策略时应谨慎。许多数据库都定期开展活动、例如季度末流程或重新编制索引操作。如果这些操作的期限大于 tiering-minimum-cooling-days 可能会发生性能问题。例如、如果季度末处理需要1 TB的数据、而这些数据在其他情况下未被触及、则这些数据现在可能位于容量层上。从容量层读取的速度通常非常快、可能不会出现发生原因性能问题、但具体结果取决于对象存储配置。

策略

。 tiering-minimum-cooling-days 策略应设置得足够高、以保留性能层上可能需要的文件。例如、如果数据库中可能需要最新60天的数据且性能最佳、则需要设置 tiering-minimum-cooling-days 期限为60天。根据文件的访问模式、也可以实现类似的结果。例如、如果需要最近90天的数据、而应用程序正在访问这90天的数据、则数据将保留在性能层上。设置 tiering-minimum-cooling-days 在数据变得不太活跃后、将立即对数据进行分层。

。 auto 要对这些块进行层化、需要使用策略、因为只有 auto 策略会影响活动文件系统中的块。

备注 任何类型的数据访问都会重置热图数据。因此、数据库完整表扫描甚至读取源文件的备份活动都会阻止分层、因为需要分层 tiering-minimum-cooling-days 从未达到阈值。