最近，我们测试了在处理大量数据（数百GB）时称为QDM的方法。 作为任务的一部分，我们处理了12-24百万条记录，并将五重奏解决方案的性能与普通表中的类似功能进行了比较。
我们没有做出任何新发现，但是证实了我们先前提出的假设：有条件的“茶壶”手中的通用设计师在专业配置的数据库中损失了多少。
我们现在也知道在这种情况下该怎么做-该解决方案非常简单且可靠，并且我们在组织针对任意大数据的折衷解决方案方面经验丰富。
在开发报告对帐系统的过程中，我们需要下载其中一种报告表格的数据，其中每个报告日期最多包含2400万条记录。 应该有7年每日计算的数据。 坦率地说，Volume不是针对通用设计人员，而是针对高度专业化的系统，但是我们已经参与了这项事业，我们不得不寻找解决方案。
用户仅在一个报告日期内使用此大数据集，因此，在参考系统中，所有这些数据均存储在按该日期划分的表中。 其余26个数据字段的索引未用于此表单。
当然，我们要做的第一件事是在构造函数中创建所需的数据结构，并在其中加载多个日期。 下载最小的日期之一大约需要14个小时，时间太长，这是无法接受的：具有27个属性的1,250万条记录，通过三个索引的构造，从5个字段中放入了十亿条记录，其中两个索引是复合的。
磁盘上此数据的总量略大于18 GB。
值得注意的是此表单的两个功能：
- 相比之下，它几乎不适合进行规范化，例如，来自先前出版物中讨论的Form 110
- 它不对记录的属性使用索引-用户等待一分钟比在索引上花钱更有利可图
这可以说是您可以选择进行比较的最根本的情况。 在大多数情况下，QDM数据量与常规数据库的差异不是很大，甚至很小 。
为了进行比较，将相同的数据加载到关系数据库中的常规表中需要花费2.3 GB（少8倍）以及按日期进行索引，并且下载它们需要不到半小时（快28倍）。 在这两种情况下，数据都是直接从文件中以10万条记录的部分插入的，而不会禁用索引。
考虑到将构造函数用于此类数据量并不现实，我们仍然进行了性能测试：对于不同的情况，我们将记录的大量处理与构造函数和非索引表进行了比较。 我们需要确定数据量的边界，此后我们将使用常规表而不是构造函数。
正如我们预期的那样，例如在单独的帐户或客户上使用小型数据集，在设计器中看起来很舒服（响应时间在一秒钟内），这与没有索引的表不同，在表中您必须等待几分钟才能做出响应。 同时，应用程序的主要任务-各个部分中的大量采样和数据汇总-在设计人员中可能要花费数倍的时间。
以下是我们为逐步增加聚合数据量而制作的样本的摘要结果：
在可能的情况下，在选择统计数据并通过帐号掩码选择记录数之后，我们进行了几次测量。
下表和图表显示，与使用索引对超过5％的数据进行采样相比，一天之内完成一组完整数据的汇总花费的时间明显更少。 这就是为什么RDBMS查询优化器在这种情况下会忽略索引，而此时我们的服务引擎却没有这种机会。
使用对数刻度以图形方式显示相同结果，以比较不同阶数：
设计人员在处理完整数据集时的速度几乎比常规表低一个数量级，这对设计者而言是很正常的-避免雪崩般的性能下降非常重要，并且这一目标已经实现。
研究表明，数据库中的记录数实际上对五重奏数据模型中构建页面，导航和小样本的速度没有影响。 凭借多达10,000条记录的已处理数据量（这是信息系统中任何业务实体实例的相关数据的最大选择），您可以轻松使用数百GB或更大的数据库。
接下来，我们教我们的表插件（ 在此进行了描述）调用一个连接到任意数据库的连接器，以使其透明地与五重数据模型和传统表一起使用。
从用户的角度来看，他不在乎使用哪个数据源，而是可以在熟悉的界面中为他完成重要的工作，并接收报告：
现在，我们将在单独的存储中取出其余类似的大表（在我们的数据库中，只有数百个表中有二十个），以便与它们舒适地工作。
因此，我们可以将构造函数用于需要通过任意属性进行密集搜索和聚合的中小型表，并将大型非索引对象存储在平面传统表中，从第三方存储或专用数据库（Hadoop和其他NoSQL）中调用它们。
该设计器最适合CRM系统和类似产品，其中用户与单个客户，帐户或其他实体一起工作，并且分析功能移至单独的专用存储中。