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

Question

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

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

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

Answer 1

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

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

ПРОЧИТАТЬ ПРИНЯТО

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

Поведение зачитываемого чтения зависит от настройки параметра базы данных read_committed_snapshot:

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

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

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

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

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

Answer 2

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

<Ол>

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

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

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

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

Answer 3

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

Answer 4

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