Лучшая база данных для высокой записи (10000+ вставок / час), низкого чтения (10 операций чтения в секунду)?

Question

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

У меня есть фоновый процесс, который вставляет до 10000 строк каждый час в одну конкретную таблицу. Эта таблица также считывается для отображения данных в веб-приложении. Когда запускается фоновый процесс, веб-приложение становится непригодным для использования, поскольку время ожидания подключения к базе данных истекло

В результате я подумываю о переходе на simpledb amazon для повышения производительности. SimpleDB от Amazon оптимизирован для этого варианта использования? Если нет, есть ли другое решение, которое я мог бы использовать?

Answer 1

Ваша проблема - уровень изоляции, который вы используете. Если вы не измените его, SQL Server (и многие другие базы данных) будут работать в режиме, который выбирает, будет блокировать незафиксированные чтения. Вы хотите изменить SQL Server таким образом, чтобы он вместо этого использовал MVCC (по умолчанию для Oracle; MySQL и SQL Server также имеют его), и ваша проблема исчезнет.

С УСТАНОВИТЬ УРОВЕНЬ ИЗОЛЯЦИИ СДЕЛКИ (Transact-SQL) :

ЧИТАЙТЕ КОМИТЕТ

Указывает, что операторы не могут читать данные, которые были изменены, но не совершенные другими транзакциями. это предотвращает грязное чтение. Данные могут быть изменено другими транзакциями между отдельные заявления в рамках текущая транзакция, в результате чего неповторимые чтения или фантомные данные. Этот параметр используется по умолчанию для SQL Server.

Поведение READ COMMITTED зависит на настройке READ_COMMITTED_SNAPSHOT база данных Опция:

• Если для READ_COMMITTED_SNAPSHOT установлено значение OFF (по умолчанию), компонент Database Engine использует общие блокировки для предотвращения других транзакции от изменения строк в то время как текущая транзакция выполняется операция чтения. Общие блокировки также заблокировать оператор от чтения строк изменено другими транзакциями до другая транзакция завершена. Тип общей блокировки определяет, когда это будет выпущено. Рядные замки выпущен до следующего ряда обработанный. Блокировки страниц снимаются когда следующая страница прочитана, и таблица блокировки снимаются при утверждении отделка.
• Если для READ_COMMITTED_SNAPSHOT установлено значение ON, компонент Database Engine использует строку управление версиями для представления каждого утверждения с транзакционной последовательностью снимок данных в том виде, в каком они существовали на начало заявления. Замки не используется для защиты данных от обновления другими транзакциями.

Когда READ_COMMITTED_SNAPSHOT опция базы данных включена, вы можете использовать READCOMMITTEDLOCK табличная подсказка для запросить общую блокировку вместо строки управление версиями для отдельных утверждений в транзакциях, запущенных на READ СОВЕРШЕННЫЙ уровень изоляции.

(выделение добавлено)

Измените конфигурацию базы данных, чтобы включить READ_COMMITTED_SNAPSHOT в значение ON.

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

Answer 2

Как уже говорили другие, объем данных, которые вы записываете в базу данных, не является проблемой. SQL Server может легко обрабатывать гораздо больше данных, чем это. Лично у меня есть таблицы, которые без проблем занимают от сотен тысяч до миллионов строк в час, и люди читают строки весь день без замедления.

1. Вам может потребоваться выполнить грязное чтение, изменив уровень изоляции операторов чтения или воспользовавшись подсказкой WITH (NOLOCK).

2. Вам следует взглянуть на использование объекта массовой загрузки в .NET для загрузки ваших данных в базу данных. Используйте партии 1000-5000 в зависимости от производительности, которую вы видите во время тестирования. Вам нужно будет играть с номером, чтобы получить лучшую производительность. Массовая вставка данных в таблицу даст вам значительно лучшую производительность, чем вставка записей построчно. Убедитесь, что вы не делаете всю загрузку в одной транзакции. Вы должны сделать одну транзакцию на партию.

3. Как выглядит дисковый ввод-вывод при записи в базу данных.

4. Какую модель восстановления вы установили для базы данных? Полное восстановление в базе данных потребует гораздо больше операций ввода-вывода, чем при использовании режима восстановления SIMPLE. Используйте ПОЛНОЕ восстановление только в том случае, если вам действительно нужно восстановление на определенный момент времени, которое идет с ним.

Answer 3

Менее 3 операций вставки в секунду не приведут к тренировке СУБД, если только объем данных, вставляемых в каждую операцию вставки, не является феноменальным. Аналогично, 10 операций чтения в секунду вряд ли приведут к чрезмерной нагрузке на любую компетентную СУБД, если только вы не упомянули какой-либо усложняющий фактор (например, «операции чтения представляют собой агрегаты агрегатов по всей СУБД, которые через определенный период времени будут накапливать миллиарды записей из ... ну, 100 000 часов для первого миллиарда записей, что составляет примерно 4000 дней или примерно 10 лет).

Answer 4

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