事件溯源/CQRS 聚集索引和分区

Question

我在税务处理公司工作，使用 SQL Server 2016。我们处理数百万个税务信息申报表，并设置并发、多线程、并行处理系统。

1. 对于并行处理写入事件存储，聚集索引应该在什么位置？在 UniqueIdentifier Guid 上，还是（在 Identity(1,1) 上使用 Ncx 在 Uniqueidentifier guid 上的聚集索引）？，或者没有聚集索引（利用堆）？

2. 您一般建议对写事件存储表进行分区吗？

3. 当我们更新读取模型以进行查询时，是否仍应使用并行处理来更新读取模型？还是我们应该进行单流更新？

4. 另外，在读取事件模型、UniqueIdentifierGuid 或（Identity(1,1) 上的聚集索引和 Uniqueidentifier guid 上的 Ncx）上的聚集索引应该是什么？

5. 我们应该分区读取模型表还是其他方法？

uniqueidentifierguids 上的索引通常是错误的聚集索引，会导致大量页面碎片、较慢的 io 写入和较大的磁盘空间。 https://blogs.msdn.microsoft.com/sqlserverfaq/2010/05/27/guid-vs-int-debate/

但是，identity(1,1) 整数列上的索引会导致锁存器争用，最后一页会在并行处理中插入“热点”。 http://www.sqlpassion.at/archive/2014/04/15/an-ever-increasing-clustered-key-value-doesnt-scale/

Answer 1

您的个人需求将取决于您独特系统的架构。通常，您需要能够测试、测量和分析以确定您的瓶颈是（或将是）。

例如，您在任何时候并行写入的节点数量将和您在任何时刻所需的吞吐量。

这里有两个提示可以帮助您入门：

• 您可能需要一个 GUID id（索引）和一个用于聚集索引的第二列。我使用标识（序号）列作为我的聚集索引，因为它是在数据库中生成的。通常，您不会在物理上并行写入磁盘（即使您尝试并行执行），因此只需使其快速简单（并对其进行分析！）。

• 对于您生成的每个“读取模型”，您通常需要串行处理事件。您可以拥有多个“读取模型”，如果数据被隔离，您可以并行构建它们。

我不确定您对 EventSourcing 的熟悉程度，但我无法充分推荐这两个资源。

http://docs.geteventstore.com/introduction/4.0.2/event-sourcing-basics/ https://leanpub.com/esversioning