Как я могу улучшить операции чтения на огромной таблице?

Question

У меня есть огромная таблица с примерно 350 миллионами строк, которые обновляются время от времени (примерно каждая строка - один раз в 5 минут), и обновление выполняется партиями (одновременное обновление нескольких строк по 100 строк одновременно)

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

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

Пожалуйста, укажите ваши входные данные / мысли / комментарии по этому вопросу.

С уважением Шрути

Answer 1

1 - убедитесь, что у вас правильная структура индекса. Имейте в виду, что индексы замедляют запись и обновление. Как правило, индекс EVERY обновляется при каждом добавлении или обновлении строки. Это также может привести к блокировке.

2 - Насколько важна согласованность между чтением и записью? Важно ли, чтобы в каждом запросе была самая последняя запись из каждой строки в последнем обновлении? Если это не так, вы можете использовать подсказки блокировки, такие как WITH (NOLOCK), в ваших операторах выбора, которые дадут вам потенциально устаревшие записи (если они обновляются по мере их чтения), но обойдут блокировки на уровне строк, и теперь дождитесь завершения UPDATE или INSERT.

Answer 2

Поскольку это чрезвычайно общий вопрос, я могу дать только очень общий ответ.

1) Индексы действительно увеличивают накладные расходы на вставки и т. Д., Но они часто незначительны по сравнению с повышением производительности в других местах.Используйте соответствующие индексы для улучшения производительности приложений.

2) Я предполагаю, что вы читаете чаще, чем пишете.Вы можете извлечь выгоду из того, что триггеры предварительно рассчитывают для вас промежуточный результат, сохраненный в другой таблице.В зависимости от характера записи вам может потребоваться удалить пересчет с нуля или просто рассчитать последствия изменения (используя таблицы deleted и inserted).

РЕДАКТИРОВАТЬ

Если вы отслеживаете конкретную запись;создайте триггер для таблицы.

Тогда вам нужно будет проверить только записываемые данные, а не всю таблицу.

Answer 3

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

ALTER DATABASE [your database]
SET READ_COMMITTED_SNAPSHOT ON;

Примечания: в этом случае 1) select не будет блокировать обновления, и наоборот 2) вы "увидите последние подтвержденные данные" 3) есть дополнительные издержки для хранения версий строк в tempdb.

См. Последние абзацы этого хорошего сообщения .

См. Также: Выбор уровней изоляции на основе версий строк

Answer 4

И пока вы занимаетесь этим, НЕ используйте запросы SELECT * на производстве, особенно если у вас есть объединения.Вы возвращаете больше данных, чем вам нужно (поля объединения содержат те же данные), что приводит к расточительству сетевых и серверных ресурсов.Потратьте лишние десять секунд один раз, чтобы заполнить только те поля, которые вам нужны, чтобы запрос выполнялся быстрее при каждом запуске

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