Как оптимизировать таблицу только для быстрых вставок?

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

Есть ли способ гарантировать, что веб-приложениям не нужно ждать этих вставок? Например, я знаю, что добавление большого количества индексов замедляет вставки, поэтому я не буду. Что еще там? Не следует ли добавлять первичный ключ? (Каждую ночь таблица будет закачана в базу данных отчетов, в которой будет много ключей/индексов)

Ответ 1

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

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

Рекомендовать очевидное: как часть ночных отчетов запустить, очистить содержимое таблицы. Кроме того, никогда reset размер файла базы данных (команда olde shrink database); через неделю или около того для обычного использования файлы базы данных должны быть такими же большими, какими они когда-либо будут, и вам не придется беспокоиться о быстром росте производительности файла.

Ответ 2

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

не имеют первичного ключа, он выполняется с помощью индекса
не имеют никакого другого индекса
Создайте базу данных достаточно большой, чтобы у вас не было роста базы данных.
Поместите базу данных на свой собственный диск, чтобы избежать конфликтов.
Избегайте программного RAID-массива
поместите базу данных на зеркальный диск, сохраните расчет, сделанный на RAID 5

Ответ 3

Нет ключей, нет ограничений, нет подтверждения, нет триггеров, Нет расчетных столбцов

Если вы можете, службы должны вставить async, чтобы не дождаться результатов (если это приемлемо).

Можно даже попытаться вставить в "ежедневную" таблицу, которая должна быть меньше записей, а затем переместите это поперек до того, как партия начнет работать ночью.

Но в основном на столе NO KEYS/Validation (ПК и уникальные индексы убьют вас)