在日益复杂的信息管理世界中，我们知道有几件事是正确的：安全是至高无上的，蔓延是无处不在的，编目和治理是必不可少的。

在这些真理中，有一个简单的事实：数据随着时间的推移而变化。这意味着，为了控制蔓延，维护严密的安全性，并部署有效的编目和治理策略，组织必须确保其数据存储解决方案承认数据的变化和可变价值，允许轻松、实时地检索和分析任务关键信息和安全的，经济高效地存储静态、非活动数据。

这种从最常用数据到最少数据的基本分类称为数据分层，在SAP，我们对数据层使用简单的分类系统：热、温、冷。在我的同事Courtney Claussen最近的博客文章中，您可以阅读到关于数据分层的更全面的概述，但目前我们只需要简单的回顾：任务关键型热数据具有严格的性能要求，并且存储在SAP HANA中的内存中。在数据生命周期的另一端，冷数据很少被访问和只读，可以以较低的成本与内存数据库分开存储和管理。

热和冷数据层相对简单，大数据挖掘，存储选项相对简单。但是还有第三层，中间层warm data，它为组织提供了更多不同的存储选项。热数据不可操作，访问频率低于热数据。以前的SAP博客文章讨论了热数据存储选项，包括动态分层。在SAP HANA、SAP BW/4HANA和SAP HANA本机应用程序上使用SAP BW的客户还有另一个选项：扩展节点。

扩展节点选项存在于横向扩展的SAP HANA环境中，系统使用多个HANA工作节点，其中包括多个从节点和一个主节点。将扩展节点用于热数据的最小设置由两个主机组成—一个用于存储热数据的工作节点（必须是主节点）和一个用于存储热数据的扩展节点，如下图所示。扩展节点本身是从节点，它被配置为以独占方式处理热数据。查询数据库时，它会自动从相应的节点检索数据。另一个节点不参与，这将在两个节点之间创建块负载的清晰分离和数据集的清晰分离。这风景的美丽？这些节点在功能上是相同的；无论您对热数据做什么，企业云服务器，您都可以对热数据做什么，因此使用扩展节点存储热数据时没有固有的限制或例外。

虽然扩展节点选项允许以比内存热数据更低的价格存储热数据，由于CPU的大小和质量以及某些数据集可能需要从磁盘重新加载的事实，它们访问以进行处理可能比工作节点慢一些。

扩展节点的较低价位优势还在于内存容量。热数据工作节点在任何给定时间只能半满，例如，工作节点的内存容量为1TB，其有效存储容量为500GB。另一方面，扩展节点的实际存储容量是原来的两倍，而一TB的内存容量相当于两TB的热数据存储容量？扩展节点通过广泛利用磁盘来卸载和加载最初不适合内存的任何数据，从而提供了比热节点更多的存储容量。它需要应用程序中合适的数据布局（例如表分区）和查询设计，类似于BW-on-HANA和BW/4HANA中提供的内容。此外，快云服务器，扩展节点还受益于SAP HANA TDI 5的使用，该TDI 5基于工作负载驱动的SAP HANA大小调整，并带来了一个宽松的核心内存比率，允许内存容量和核心数量之间的灵活关系。这允许扩展节点对相同数量的内存使用较弱和较少的cpu。但是，对于SAP HANA本机应用程序，热节点和扩展节点的内存大小必须相同，称为对称内存大小调整。HANA上的BW和SAP HANA 2 SPS03上的SAP BW/4HANA允许不对称扩展节点大小调整，这意味着与热节点相比，扩展节点的内存大小可能更高或更低。

SAP客户可能想知道他们是否可以使用多个扩展节点。虽然这是可能的，但我们鼓励客户从一个扩展节点开始，并利用两个存储能力的因素，因为单个大型扩展节点比多个扩展节点更易于管理。但是，如果需要随着时间的推移而出现，则支持多个扩展节点和工作节点。

客户可能还想知道扩展节点与动态分层的区别。每个选项都提供了自己的价值主张：动态分层不支持完整的功能范围，但它以较低的价位提供了大量的解决方案，怎么做淘客推广，而扩展节点支持SAP HANA数据库的完整功能范围，它为内存中存储和检索热数据提供了与热数据相同的高级分析功能。尽管SAP BW用例不支持这两个热存储选项的混合使用，云服务器网站，但这两个选项可以共存，因为SAP BW用例是extension node用于分析而非事务性工作负载的价值的主要示例。

extension node提供了一个高效、经济的热数据存储解决方案，而不牺牲任何功能，它允许公司在数据生命周期的每一个阶段都保持对其数据的控制。