Самый эффективный способ хранения большого количества строковых сообщений в SQL Server?

Question

Мое приложение получает примерно 2000 строковых сообщений в секунду, каждое сообщение имеет длину около 300 символов.

Мне нужно хранить все сообщения в БД.Я использую SQL Express 2008 и. NET .

Я думаю о том, чтобы хранить все данные в памяти, пока они не достигнут определенного предела (10000 сообщений =Например, 5 секунд), а затем запишите все сразу.

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

Достаточно ли хорош мой подход?Какой подход следует использовать для достижения следующих результатов?

1. сообщения не накапливаются в памяти
2. Жесткий диск не совершит самоубийство:)

Примечание: нет необходимости анализировать строки, единственное, что нужно сохранить - это в порядке поступления.

Answer 1

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

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

Индекс можно построить с помощью Lucene.NET и чтоВаш индекс может быть сведен к минимуму, так как я надеюсь, что вам не нужно будет искать абсолютно все, что вы храните в этих текстовых файлах.

Answer 2

Быстрый расчет показывает, что вы можете использовать до 50 ГБ данных в день. Если для этих данных нет специфической обработки SQL, то не представляется возможным сохранить ее в базе данных.

Следующим решением будут файлы на диске, и, поскольку вы работаете с простым текстом (не двоичным), возможно, быстрое сжатие также поможет. Однако, поскольку файлы будут такими маленькими (300 байт), сжатие не даст никаких ощутимых результатов. Данные должны быть сгруппированы в большие файлы, например, один фрагмент данных на строку и один такой файл в день. Этот файл будет достаточно большим, чтобы сжатие могло дать удовлетворительные результаты, если на диске возникнет проблема.

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

Для хранения и доступа к большому количеству файлов лучше использовать хранилище многораздельных папок. То есть каждый файл должен иметь уникальное имя и затем будет помещен в определенную иерархию папок в соответствии с его именем. Этот подход имеет несколько преимуществ:

• сохраняет количество файлов в папке управляемым (когда это число увеличивается, нужно всего лишь углубиться на одну иерархию папок, чтобы экспоненциально увеличить «доступность хранилища»)
• легко найти местоположение файла или место для хранения файла в соответствии с соглашением об именах

Пример разбиения:

• имена файлов имеют следующий формат: yyyymmddhhss-<counter>.txt (например: 201104252345-1.txt, 201104252345-2.txt и т. Д.)
• структура папок соответствует временным частям: \yyyy\mm\dd\ или yyyy\mm\dd\hh\ и т. Д. (Столько уровней, сколько требуется решению для поддержания количества управляемых файлов)
• Результат: 201104252345-1.txt сохраняется как 2011\04\25\201104252345-1.txt и т. Д.

Answer 3

Я не буду этого делать в вашей ситуации. Предполагая, что:

(2000 * 300) / 1024 (КБ) / 1024 (МБ) = около 0,54 МБ в секунду.

Один день: 60 (с) * 60 (мин) * 24 (час) = 86400 секунд.

0,54 * 86400 = 43200 МБ в день.

Если вы будете использовать кодировку UTF-8, размер будет в два раза больше! (varchar против nvarchar)

Это означает, что вы будете получать 40 ГБ в день. Ваш экспресс-сервер не выживет, даже если вы будете вставлять запрос вставки каждые 5 секунд или 10 или 20 секунд. Рассмотрите возможность перестроения индексов для обеспечения высокой производительности запросов, резервного копирования базы данных за определенный период времени и других вещей, которые вы должны иметь при себе. Ваша база данных не будет обрабатывать запросы.

Я бы порекомендовал вам хранить строки в текстовых файлах (, если ваш текст будет редко читаться конечным пользователем, в противном случае я рекомендую использовать какой-нибудь механизм индекса (возможно, Lucene) ) и кеш их на сервере приложений. Хранить только путь к этим файлам в базе данных.

Примечание. Это только мое собственное решение, основанное на некоторых фактах и ​​опыте.

EDIT

Используя приложение, вы получите больше контроля над своими данными. Вы можете отправлять файлы через HTTP на другой сервер, можете сжимать файлы и т. Д.