Блог

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

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

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

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

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

ЗАФИКСИРОВАНО ЧТЕНИЕ

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

Поведение ЗАФИКСИРОВАННОГО чтения зависит от настройки параметра базы данных READ_COMMITTED_SNAPSHOT:

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

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

(выделено мной)

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

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

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

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

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

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

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

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

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