Источники событий/кластеризованный индекс CQRS и секционирование

Я работаю в компании по обработке налогов, используя SQL Server 2016. Мы обрабатываем миллионы налоговых деклараций и настраиваем параллельную, многопоточную, параллельную систему обработки.

  1. Для хранилища событий записи с параллельной обработкой, какой должен быть кластеризованный индекс? на UniqueIdentifier Guid или (кластеризованный индекс на Identity (1,1) с Ncx на guid Uniqueidentifier)? Или без кластеризованного индекса (используйте кучу)?

  2. Вы обычно рекомендуете секционировать таблицу хранилища событий записи?

  3. Когда мы обновляем нашу модель чтения для запросов, должны ли мы по-прежнему использовать параллельную обработку для обновления модели чтения? Или надо проводить однопотоковое обновление?

  4. Кроме того, опять же, каким должен быть кластерный индекс в модели чтения-события, UniqueIdentifierGuid или (кластеризованный индекс в Identity (1,1) с Ncx в guid Uniqueidentifier)?

  5. должны ли мы разбивать таблицу модели чтения или любые другие методы?

Существует общее правило, согласно которому индексы по uniqueidentifierguid являются плохим кластеризованным индексом, вызывают массивную фрагментацию страниц, медленную запись ввода-вывода и большой объем дискового пространства. 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/


sql-server cqrs database-design indexing event-sourcing
person Community    schedule 11.09.2017    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Ваши индивидуальные потребности будут зависеть от архитектуры вашей уникальной системы. Как правило, вам нужно иметь возможность тестировать, измерять и профилировать, чтобы определить, какие у вас есть (или будут) узкие места.

Например, количество узлов, которые вы одновременно записываете параллельно, и пропускная способность, которая вам нужна в любой момент.

Два совета для начала:

  • Вероятно, вам нужен идентификатор GUID (индексированный) и второй столбец для кластеризованного индекса. Я использую столбец Identity (порядковый номер) в качестве моего Clusered Index, потому что он создается в базе данных. Как правило, вы не будете физически записывать на диск параллельно (даже если попытаетесь сделать это параллельно), поэтому просто сделайте это быстро и просто (и профилируйте его!).

  • Для каждой созданной вами «Модели чтения» вам, как правило, потребуется обрабатывать события последовательно. У вас может быть несколько «моделей чтения», и если данные изолированы, вы можете строить их параллельно.

Я не уверен, насколько вы знакомы с EventSourcing, но я не могу рекомендовать эти два ресурса в достаточной мере.

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

person Daniel Little    schedule 11.09.2017
comment
Привет, Даниэль, в большинстве случаев ответ выглядит хорошо, в одной части я, вероятно, буду писать вставки параллельно, многопоточно в таблицу, поэтому я буду «параллельно писать на диск» - person ; 11.09.2017
comment
@BlueCar У вас может быть много потоков, записывающих в файл, но если этот диск не поддерживает одновременную запись, а я не знаю таких, параллельная вставка не будет быстрее, чем последовательная запись. - person Daniel Little; 12.09.2017