Я ищу рекомендации по дизайну для нижеприведенного варианта использования. Я разрабатываю приложение, которое может обрабатывать файлы EXCEL/CSV/JSON. Все они содержат одинаковые столбцы/атрибуты. Имеется около 72 столбцов/атрибутов. Эти файлы могут содержать до 1 миллиона записей.
Теперь у меня есть два варианта обработки этих файлов.
Опция 1
- Сервис 1: чтение содержимого из данного файла, преобразование каждой строки в JSON, сохранение записей в таблицу SQL путем пакетной обработки (3 тыс. записей на пакет).
- Сервис 2: Извлеките эти записи JSON из таблицы базы данных (которые сохраняются на шаге 1), обработайте их (проверка и расчет) и сохраните окончательные результаты в отдельной таблице.
Вариант 2 (с использованием Rabbit MQ)
- Сервис 1: чтение содержимого из данного файла и отправка каждой строки в виде сообщения в очередь. Допустим, если файл содержит 1 миллион записей, то эта служба будет отправлять 1 миллион сообщений в очередь.
- Сервис 2: прослушайте очередь, созданную на шаге 1, и обработайте эти сообщения (проверка и расчет) и сохраните окончательные результаты в отдельной таблице.
Опыт POC с Вариантом 1:
- Чтение и пакетное сохранение данных в таблицу на 100 тыс. записей заняло 5 минут. (работа службы 1)
- If application is trying to process multiple files parallelly which contain 200K records in each of them some times i am seeing deadlocks.
- No indexes or relation ships are created on this batch processing table.
- Сохранение 3000 записей в пакете во избежание блокировок таблиц.
- Пока сервисы обрабатываются, результаты можно отслеживать и запрашивать ход выполнения. Допустим, для файла 1.JSON - 50000 записей успешно обработаны, а остальные 1000 находятся в процессе.
- Если служба 1 завершит работу правильно и если что-то пойдет не так со службой 2, у нас все еще будет лучший контроль над повторной обработкой этих записей, поскольку они сохраняются в базе данных.
- Я планирую удалить данные в таблице пакетной обработки с помощью ночного задания SQL, если все записи уже обработаны службой 2, поэтому эта таблица будет свежей и готовой для хранения данных для обработки на следующий день.
Опыт POC с вариантом 2:
- Для создания (служба 1) и использования сообщений (служба 2) для файла записи размером 100 КБ потребовалось около 2 часов 30 минут.
- Нет хранения файловых данных в базе данных, поэтому нет взаимоблокировок (как вариант 1)
- Результаты не так отслеживаются, как вариант 1, пока сервисы обрабатывают записи. - Делиться статусом с клиентами, отправившими файл на обработку. Мы можем видеть статус сообщений на экране управления Rabbit MQ для целей мониторинга.
- Если служба 1 частично считывает данные из заданного файла и выдает ошибку из-за некоторых проблем, то, насколько мне известно, нет возможности откатить уже опубликованные сообщения в Rabbit MQ, поэтому потребитель продолжает работать над этими опубликованными сообщениями.
Я могу горизонтально масштабировать приложение в обоих этих вариантах, чтобы ускорить процесс.
Согласно приведенным выше фактам, оба варианта имеют свои преимущества и недостатки. Это хороший вариант использования Rabbit MQ? Целесообразно ли производить и потреблять миллионы записей через RabbitMQ? Есть ли лучший способ справиться с этим вариантом использования, кроме этих двух вариантов. Пожалуйста, порекомендуйте.
*** Я использую .Net Core 5.0 и SQL Server 2019. Служба 1 и Служба 2 являются рабочими службами .net core (задания Windows). Все тесты выполняются на моем локальном компьютере, а Rabbit MQ установлен на Docker (докер находится на моем локальном компьютере).
