Существует ли быстрое и масштабируемое решение для сохранения данных?

Question

Я разрабатываю сервис, который должен быть масштабируемым на платформе Windows.

Первоначально он будет получать приблизительно 50 соединений в секунду (каждое соединение будет отправлять приблизительно 5 КБ данных), но его необходимо масштабировать, чтобы получать более 500 в будущем.

Невозможно (я полагаю) сохранить полученные данные в общей базе данных, такой как Microsoft SQL Server.

Есть ли другое решение для сохранения данных? Учитывая, что он будет получать более 6 миллионов «записей» в день.

Есть 5 шагов:

1. Получение данных через обработчик http (c #);
2. Сохранить полученные данные; <- ЗДЕСЬ </strong>
3. Запрос сохраненных данных для обработки;
4. обработка запрошенных данных;
5. Сохранить обработанные данные. <- ЗДЕСЬ </strong>

Мое предварительное решение:

1. Получение данных через обработчик http (c #);
2. Сохранить полученные данные в Очередь сообщений ;
3. Запрос от MSQ сохраненных данных для обработки с использованием служб Windows;
4. обработка запрошенных данных;
5. Сохранение обработанных данных в Microsoft SQL Server (вот узкое место);

Answer 1

6 миллионов записей в день не кажутся особенно огромными. В частности, это , а не 500 в секунду в течение 24 часов в день - вы ожидаете, что трафик будет "бурным"?

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

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

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

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

Answer 2

Я думаю, что вы преждевременно оптимизируете.Если вам нужно отправить все в базу данных, то посмотрите, может ли база данных справиться с этим, прежде чем предполагать, что база данных является узким местом.

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

Answer 3

Почему бы не сделать это:

1.) Получение данных
2.) Обработка данных
3.) Сохранение исходных и обработанных данных одновременно

Это избавило бы вас от необходимости запрашивать его снова, если оно у вас уже есть. Я бы больше беспокоился о вашей структуре таблицы и вашей машине базы данных, чем о реальном потоке. Я уверен, что ваши вкладыши как можно дешевле. Если это невозможно, то постановка в очередь имеет смысл. Я бы не использовал очередь сообщений сам. Предполагая, что у вас приличный компьютер с SQL Server, 6 миллионов записей в день - это нормально, если вы не пишете тонну данных в каждой записи.