公司会计系统的特点是由于历史信息的积累，数据库的容量逐渐增加。 随着时间的流逝，数据库的大小可能达到这样的大小，从而在性能，维护，可用磁盘空间等方面引发许多问题。 今天，我们考虑了两种解决此问题的方法：增加硬件资源和折叠历史数据。
引言
本文讨论了在MS SQL Server平台上折叠特别大的数据库的问题。 使用Softpoint的复制技术DBREPLICATION描述了此问题的解决方案。
发行
每种类型的会计系统都可能开始表现出自己的特定功能。 例如，在基于1C平台的系统中，诸如更新配置，更新1C平台之类的常规操作会出现问题。 随着数据库的增长，情况逐渐恶化；迟早必须采取措施。
方法一：硬件
最明显且技术上透明的解决方案是增加硬件资源。 这既可以是购买效率更高的服务器，磁盘存储等，也可以是在第三方数据中心或云中租用功能更强大的设备。
如果您采用这种方式，那么一个不错的选择是将数据库放置在Microsoft Azure云中。 Azure提供了几种用于承载数据库的体系结构选项：Azure虚拟机上的MS SQL，以及云中Azure SQL数据库的三个选项。 因此，可以根据特定数据库的特性及其操作条件来选择最佳的放置选项。
与购买自己的设备相比，Azure具有许多优势。 主要功能之一是Azure可以提供的强大硬件功能。 以及根据实际负载灵活使用这些容量的方法。 例如，您可以在业务“旺季”期间或报告期结束时购买额外的容量，以便高峰可以顺利通过。 在其余时间中，请使用预算更多的资源。 因此，一方面，您可以在正确的时间访问Azure的巨大资源潜力（顺便说一句，它一直在增长），另一方面，当您不需要它们时，您不能为多余的容量支付过多的费用。
但是，尽管它相对简单，但是增加硬件资源并不是通用的解决方案。 首先，积极影响通常远不与金融投资成正比（有很多投资，几乎没有影响）。 第二，影响是暂时的，因为基础不断增长，需要更多的资源和更多的金融投资。
无论如何，这种方法都有生命权，并且被广泛使用。 但是，我们不再赘述，因为本文的主要目的不是“硬件”方法，而是下文所述的“软件”方法。
方法2：基础卷积
一个更根本的解决方案是数据库的卷积，即从数据库中删除不相关的历史数据。 在已折叠的数据库中，只有相对较小的运营时间段的数据，通常不超过1-2年。 显然，每种情况下的减少程度是不同的，并且很难命名任何特定的数字。 但是，作为指导方针，我们将指示基数减少50-70％，即减少2-3倍，最常见的减少幅度是相同的，实际上，减少幅度较小，反之亦然，这是罕见的。
我们将不讨论产生的奖金。 显然，如果将基数减少2-3倍或更多倍，则性能效果将非常强大且长期有效，并且可以避免对硬件组件的额外投资。 卷积机制一旦开发和运行，就可以在将来重用。 通常，这是一种有效的解决方案，可以保证结果。
卷积实现的复杂性
但是，卷积尽管具有全部有效性，但仍然存在一个非常大的问题。 而且，甚至不需要开发卷积机制本身。 是的，这种开发也是一项艰巨的任务，但是可以通过某种方式解决。 事情有所不同。 当数据库的大小为数百GB或超过TB时，事实证明执行折叠操作在物理上非常困难。 不可避免地会出现一系列相互联系的困难，让我们考虑一下。
- 折叠操作的资源强度-设备负担沉重。
- 卷积过程中，不仅物理删除了一个大数据数组，而且还执行了许多相关的资源密集型操作：各种选择，检查，组，索引，日志记录，在表之间移动数据等。 这个事实尤为重要，因为通常可折叠数据库已经负担很重，并且没有过多的容量。
- 对用户的干扰。
- 由于卷积过程会产生大量的额外负载和锁，因此与用户的工作并行地在工作数据库中直接执行卷积是非常困难或不可能的。
- 没有技术窗口。
- 当用户不工作时，足够长时间的技术窗口根本无法卷积。 毕竟，这种规模的数据库的折叠过程通常需要数十小时或几天。
- 直接折叠到工作台时存在高风险。
- 当将卷积算法直接应用于工作库时，由于多种原因，该方法本身具有很高的风险。 其中之一-对卷积结果进行最终验证的可能性非常有限（没有时间）。
- 迭代方法的持续时间不可接受。
- 您可以尝试避免瓶颈-技术窗口，并直接在生产基础中对迭代的小部分进行迭代，选择每个部分的大小，使其适合现有的技术窗口。 但是这种方法通常也不适用，因为首先，修整过程会花费不可接受的长时间（数周或数月），其次，折叠机制的复杂性增加，确保如此长的修整过程的总成本，整个项目的风险正在急剧增加。
- 如何压缩数据文件中的空隙！
- 在从数据库中删除历史信息的过程中，其数据文件实际上并没有减少（通常甚至略有增加），只是在其内部创建了巨大的空白。 而且您需要以某种方式摆脱它们，以便减少数据文件。 否则，就失去了磁盘空间。 一种选择是执行典型的收缩。 在这种情况下，这是一个非常漫长的过程（许多小时，甚至数十小时）。
因此，卷积是一项非常重要的任务。 开发卷积机制还不够，还需要应用它。 而且，应用程序经常成为瓶颈。
注意：接下来，无论创建什么手段，我们都将卷积机制本身（换句话说，用于删除历史数据的算法）的发展放在后面。 而且，我们仅关注已实施机制在战斗中的应用。
使用DBREPLICATION的解决方案
这似乎是一个死胡同。 但是仍然有解决方案。 有一种有效的技术可以使您解开所有难题，消除风险并保证达到目标。 它涉及DBREPLICATION数据交换技术的使用。 该解决方案适用于传统的基础架构选项和基于云的Microsoft Azure。 简而言之，实质如下。
- 创建数据库的克隆，并使用DBREPLICATION配置克隆与主数据库之间的单向数据交换。 允许将主数据库和/或其克隆放置在Microsoft Azure云中（两者或其中之一）。
- 在克隆中，用户不工作，卷积过程开始。 由于折叠过程不会打扰任何人，因此折叠过程可以整天持续不间断，只要花费时间即可。 因此，与技术窗口持续时间的链接消失了！
- 不受干扰的用户可以在主数据库中工作。 DBREPLICATION技术自动将所有更改从主数据库高速传输到可折叠的数据库。 因此，就操作数据而言，克隆是最新的。
- 卷积完成后，通常，在客户的技术专家和业务用户的参与下，对结果进行详细的验证。 此过程可能会持续很长时间（几个小时或几天）。 在所考虑的方法中，实际上没有时间限制，因此可以根据需要分配验证时间。
- 卷积和验证完成后，所有用户都将切换到受限制的克隆，从那时起，它便成为主要基础。 原始的未割礼的基础是历史数据的档案。
- 另一个优点是，当用户切换到最小化的数据库时，可以以相反的方向切换复制。 这提供了额外的安全性，因为如果“出事了”，您可以快速将用户切换回未割礼的数据库，而不会丢失输入的数据。
- 如果需要使存档数据库保持最新，则可以将复制切换到相反的方向，并将更改从最小化数据库转移到存档数据库。
图1。 使用DBREPLICATION技术修整数据库的示意图。
图2。 选择在MS Azure云中托管可折叠数据库。
因此，克隆数据库中描述的卷积技术扩展了所有瓶颈。 消除了对技术窗口的依赖。 在克隆中，包裹不会打扰任何人，也没有人打扰她。 您可以安全地使用克隆的最大资源，也可以对最终验证给予足够的重视。
尚需了解该方案中可以使用哪种交换技术？ 为什么选择DBReplication？
为什么选择DBReplication？
在所描述的方法中，关键要素是交换技术，该技术确保了整理后的数据库与主数据库的同步。 原则上，只要满足三个基本关键条件，交换技术就可以是任何一种：
示例：如果我们折叠1C数据库，则并非每种交换技术都与1C基本结构兼容，特别是经典MS事务复制不兼容，因为它会更改表结构。
- 性能。 必须保证交换技术能够应对卷积期间工作基础中发生的变化。
说明：在本文中，我们主要是指具有高数据更改率的高负载数据库。 卷积将持续数十个小时，可能需要几天，甚至可能会有不止一次的卷积迭代。 在此期间，用户将进行巨大的更改。 许多共享技术都无法应对。 而且您不仅需要应付，还建议应付供应。
说明：也许这点是不言而喻的，但是我们还是可以挑出来。 即：不要忘记源数据库中的数据和克隆中的数据不相等！ 这个事实会基于事务日志的同步自动清除一整套强大而高效的技术-始终打开，日志传送，镜像等。
此外，交换技术应在其他指标方面有效：
- 功能的可靠性和自治性。 由于我们谈论的是海量数据的传输，并且在相当长的时间内，项目团队将根本没有物理能力来手动处理交换问题，冲突和故障，检查数据质量等。 因此，交换技术就传输数据的质量而言应尽可能可靠，并应尽可能自动和自动化。
- 用于控制和管理的高质量用户界面。
- 易于部署和配置。 交换技术不应对其调整的专家资格提出过高的要求。
没有这些品质，交换技术就有可能从方法学的一个关键要素变成其“薄弱环节”，带来严重的风险并威胁到整个项目。 然后，最初的想法失去了意义。
但是，DBReplication技术无疑可以满足所有要求并确保汇总项目的成功。
请注意完成此任务成功的主要因素：
- 汇率很高。 请注意一些提供速度的功能：
- DBReplication是事务复制，在提交事务后，每个更改都立即开始传输；
- 传输子系统的内部体系结构使用诸如队列的多线程并行处理，流水线方法，流压缩，批处理事务处理，批量插入的使用等解决方案。
- 传输是在Windows服务的基础上实现的，配备了许多功能，以确保流畅运行。 这些功能包括：通信中断后自动恢复交换，在不稳定的不稳定通信通道上工作，自动处理版本冲突（用于双向交换），在业务应用程序的表结构发生更改时自动进行调整等。
- 有保证的数据传递机制。 在转移变更时严格遵守交易的完整性和一致性。
- 不修改业务应用程序的表结构。 因此，尤其是在折叠1C数据库时可以成功使用它。
- 开发的用户界面使您可以“从一个窗口”集中管理交换系统，所有服务信息都可以收集并在线显示。
- 易于部署和配置。
- 适用于1C平台。 用户不使用表，而是使用熟悉的1C元数据对象。
- 从2005年开始，从标准版到企业版的任何版本的MS SQL，都在本地部署并位于MS Azure的云中； 从Azure的角度来看，允许使用虚拟机托管和Azure SQL DB托管选项，包括Azure SQL数据库的托管实例 （ 托管实例 ）。
- DBReplication是一种现成的可靠解决方案，已通过许多项目的各种条件和任务进行了测试。
- 如果在单向交换模式下使用DBREPLICATION，则可以切换交换方向。
此外，我们注意到另一个重要功能：
- 当可以在参与交换的所有数据库中同时输入/更改数据时，DBREPLICATION可以在双向交换模式下运行。 可以包含在交换电路中的碱基数没有限制。
实际应用实例
一家大型俄罗斯公司拥有一个基于1C 8 + MS SQL Server平台的应用程序计费系统。 主要的运营基础已经超过了2 TB，并且还在继续增长。 同时，负载越来越大：事务性和分析性。 最后，形成了底部卷积的许多原因。 决定修剪2017年初的历史数据。 选择了此处使用DBReplication描述的技术。
本身，卷积算法决定主要由TSQL实施，并包含少量的典型1C工具。 由于并非所有应用的对象（表）都可以在计划的日期之前崩溃，因此任务变得复杂，因为业务功能要求在许多最大的子系统中，历史数据要完整显示5-7年。 因此，从数据库量的角度来看，卷积的影响没有我们想要的那么大。 进行了初步分析，结果显示，考虑到客观限制，约33％的初始量将被切断。 但这被客户评价为一个很好的结果，因为收益不仅来自数据库本身，而且还来自单个表的速度，并且折叠子系统的表的容量减少了33％以上-从46％减少到77％（在2- 3次）。
让我们仔细看看卷积实际使用的一些指标和事实。 直接数据卷积的持续时间约为12小时。 使用DBREPLICATION同步累积的更改大约需要1个小时。 该项目的重点之一是由客户专家对最小化基础进行最终验证。 特别值得一提的是它的持续时间-这个过程耗时约1周。 该持续时间是由于以下事实：验证非常深入和全面，并且各种配置文件的专家参与其中，包括在外部系统中构建数据模型。 一直以来，最小化基础通过DBREPLICATION自动与当前作战数据库同步。 验证成功。 然后用户被切换到崩溃的数据库。 先前的数据库已转换为归档状态，并且具有只读访问权限。 不需要随后的同步，因此复制被禁用。
项目总结：
- 由于有足够的时间完成卷积本身以及全面验证数据，因此所应用的技术完全得到了回报，从根本上将跳过某些错误并切换到崩溃的数据库的风险降到了最低。
- 卷积成功完成：
- 业务数据库的总量减少了33％。 由于某些大型子系统折叠的限制，出于客观原因，我们无法对数据库的容量产生更大的影响。
- 折叠子系统活动表的使用量减少了46-77％（2-3倍）。
结论
DBReplication是一种现成的可靠解决方案，已在市场上存在多年，并已通过各种项目在各种条件下进行了测试。 在考虑中的卷积技术中，DBReplication完全承担了关键的子任务之一-数据库同步。 在数据库特别大的情况下，对交换系统提出了非常严格的要求，而DBReplication完全满足了它们。 它可靠，有效地解决了任务，从而确保了整个项目的成功。
您还可以使用DBREPLICATION执行哪些其他任务
一组功能和竞争优势使DBReplication可用于解决许多问题。 作为参考，我们列出了它们。
- 数据库冗余和容错能力。
- 负载平衡：在2个或更多同步数据库实例之间重新分配。
- 控制过渡到新软件版本（MS SQL，1C），该技术类似于卷积技术。
- 基于DBReplication构建具有高速交换的分布式信息系统。 特别是，用更高效，更高效的DBREPLICATION代替现有的公司交换技术。