Масштабируемая архитектура для многих применений и большого объема данных (MSMQ?)

Question

Я проектирую систему, в которой несколько пользователей будут загружать большой объем данных.Мой первоначальный пример - 100 пользователей, загружающих 100 МБ каждый день.

Мне нужно получить данные, вставить их в базу данных, обработать данные в базе данных (ETL) и затем использовать «полированные» данные для анализа..

Загруженные файлы будут получены кусками по 65 Кб (первоначальный дизайн).

Чтобы избежать узких мест, я думаю о создании этого с использованием MSMQ, где я помещаю данные в MQ, а затем передаю их различным «программам / инструментам», которые будут обрабатывать данные и, в свою очередь, сигнализировать ETLинструмент через MSMQ, чтобы начать делать свое дело.

В качестве альтернативы я думаю о "линейном" подходе:

--> receive data 
--> save data to sql 
--> wait for upload finish (run the two above until no more chunks)
--> signal the ETL to do its thing
--> When ETL is done report "Done" to callee

Какой подход кажется лучшим?Есть ли альтернативы для изучения?Цель состоит в том, чтобы иметь несколько тысяч пользователей ... Насколько я вижу, такой подход блокирует клиент / загрузчик.

Answer 1

Я предпочитаю первый подход.Преимущество по сравнению со вторым подходом состоит в том, что вы можете отправлять и обрабатывать сообщения MSMQ асинхронно и обеспечивать их транзакционную безопасность с минимальными усилиями.

Не то, чтобы второй efford не работал - но первый выглядит намного меньшеусилия для меня.

Я также предлагаю вам взглянуть на некоторые фреймворки, расположенные поверх MSMQ.Как программист C # я могу порекомендовать NServiceBus - но я не знаю, что вы могли бы использовать.

Answer 2

Я предлагаю, чтобы после получения данных вы отсортировали их в соответствии с наиболее часто используемым индексом целевой таблицы. Вы должны сделать это в ОЗУ, и вы можете отсортировать его по 100 МБ за раз или все 100 * 100 МБ (это всего 10 ГБ ОЗУ) в одну большую сортировку. Таким образом, вставка блока будет быстрее (компонент индексирования будет выполнять меньше), и последующие операции выбора будут находить связанные строки более сгруппированными (физически рядом друг с другом на диске) и меньше случайным образом распределяться внутри таблицы. Это приведет к меньшему количеству физических чтений для данного выбора, тем самым улучшая время выполнения.