自1996年开始使用SAP IQ以来，我参与了大量使用该技术的客户旅程。我还帮助塑造了产品，并帮助设计了SAP HANA dynamic tiering、SAP Nearline Store for Business Warehouse、，以及针对SAP应用程序的SAP信息生命周期管理。在这段旅程中，我积累了大量使用SAP IQ构建新的创新系统的经验。主要成果是SAP IQ Hardware Sizing Guide(https://www.sap.com/documents/2017/02/363ddfab-a77c-0010-82c7-eda71af511fa.html)我所做的然而，我们开始注意到，客户实现的规模越来越大，然而我们倾向于看到，它们的架构、部署和操作管理都与小型系统一样。本博客的主要焦点将是分享我构建这些系统的经验，不仅从硬件和资源层面，而且还包括也是从操作的角度来看。

为了这个博客和使用的各种计算和算法，假设正在构建的系统是一个SAP IQ多路复用系统，有40个节点，数据库总大小为1 PB（压缩后）。每个节点将有80个内核和2 TB RAM。

SAP IQ有一个手册部分，云产品，介绍了SAP IQ的绝对限制。这在"SAP IQ简介"手册中有介绍：https://help.sap.com/viewer/a896c6a184f21015bcf4c7a967df07/16.1.2.0/en-US/a59810dd84f2101588df81a6f71e8ba3.html

需要注意的是，这些是SAP的绝对程序限制，可能不同于实际或最佳实践限制。

在处理大规模系统时，有些事情只会花费更长的时间。例如，备份100TB的数据库比备份1000TB（1PB）大10倍的系统要快。我们必须现实地设定期望值，这样我们就不会以不切实际的期望值为失败做好准备。我们必须准备好改变我们全面看待运营任务的方式，而忘记我们会怎样做在1-10%大小的系统上执行相同的任务。

数据库一致性检查

数百TB甚至1 PB或更大的系统将不得不更改一致性检查的方式。虽然这些检查的内部结构已经有所改进，这些系统的规模仍然会增加这些检查的运行时间。我们不能像在较小的系统上那样使用整个数据库一致性检查。虽然发出一条语句并检查输出要容易得多，但对于大型系统来说，效率还不够。

非常有效的方法是简单地检查此维护周期内的对象子集。一些客户已实施每周计划，其中每个对象每季度检查一次，但是这个过程每周在一个滚动的表子集上运行。

对于非常大的系统来说，非常有效的方法是使用IQ中可用的一些对象元数据。每个表都有一个数据上次更改的时间戳。如果数据自上次运行一致性检查以来没有更改，则几乎不需要更改再次运行一致性检查。随着时间的推移，这将导致更高效、更集中的一致性检查。当然，第一次运行进程时，必须检查所有对象，因为以前从未运行过。不过，在下次运行期间，只有自上次检查以来数据发生更改的表才需要再次检查。

备份和恢复

每个数据库都需要备份，以实现高可用性和灾难恢复保护。问题是传统的机制无法在这种规模下工作。以5 TB/小时的速度将数据库备份到磁盘或表非常有效对于大小小于50-100 TB的系统，在这种速度下，备份1PB数据库需要200小时（超过8天），恢复时间至少与此一样长。然后，您必须考虑到保存如此大的备份所需的磁带数量，如果使用磁带。

IQ客户使用超过15年的一种解决方案是使用存储级备份。简而言之，利用存储技术将IQ数据库复制/复制到备用存储基础结构。这将使所需的磁盘空间增加一倍，达到2 PB，但它确实提供了近乎即时的恢复，因为它是数据库的镜像，不需要恢复过程。此备份副本还用于执行一致性检查，以免影响生产。由于一致性检查通常是干净的，所以我们不会浪费生产资源。当确实发生异常时，它将在生产系统中得到解决，以便下一次对备份运行的检查是干净的。

另一种解决方案，已经获得了一些吸引力，就是在SAP IQ中使用多个数据库空间来存储不同的数据集。历史数据不变，企业交流软件，只需备份一次。如果该数据位于专用的数据库空间中，则可以备份一次，直到其数据发生更改后再进行操作。此处的目标是将备份的数据总量减少到只有发生更改的数据，而不是静态的历史信息。

数据加载

使用此大小的系统，很常见的一种架构必须支持数据加载和不断运行的聚合，将SAP IQ节点的一个子集专用于数据加载非常重要。这将允许一致的加载性能，并允许对系统进行适当调整以加载数据。我不建议让节点同时处理查询和数据加载。我们希望将主要任务（读和写）隔离到专用于此的节点目的，甚至可以进一步分解，使专门加载的节点进一步专门加载某些表

最终用户查询