Оптимизация базы данных для использования в сети (намного больше чтения, чем написания)

Question

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

Всякий раз, когда мы перечисляем участников, мы планируем показывать сводную информацию об участниках. Что-то похожее на очки репутации и значки, которые использует stackoverflow. Вместо того, чтобы выполнять подзапрос для поиска информации каждый раз, когда мы выполняем поиск, я хотел иметь «вычисляемое» поле в таблице элементов.

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

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

Мой вопрос: это подходящий подход к оптимизации базы данных? Или подзапросы достаточно быстрые, чтобы производительность не пострадала.

Answer 1

Есть две части:

1. Кэширование
2. настроенный запрос
   2. Индексированные представления (материализованные представления AKA)
   3. Настроенный стол

Лучшее решение требует как можно меньшего количества запросов к базе данных, что потребует кэширования. Но вам все еще нужен запрос, чтобы заполнить этот кеш, и кеш нужно обновлять, когда он устарел ...

Индексированные представления являются следующим соображением. Поскольку они индексируются, запросы к ним выполняются быстрее, чем обычное представление (что эквивалентно подзапросу). Некластеризованные индексы можно применять и к индексированным представлениям. Проблема в том, что индексированные представления (материализованные представления в целом) очень ограничены тем, что они поддерживают, - они не могут иметь недетерминированных функций (IE: GETDATE ()), чрезвычайно ограниченную поддержку агрегатов и т. Д.

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

Answer 2

Первое правило оптимизации программы: не делайте этого.
Второе правило оптимизации программы (только для экспертов!): Пока не делайте этого.

Майкл А. Джексон

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

Подход, который вы описываете, в целом хорош; Вы можете получить некоторые предварительно вычисленные значения, либо используя триггеры / SP для сохранения согласованности данных, либо выполняя задание для периодического обновления этих значений.

Answer 3

Самый дешевый запрос к базе данных - это тот, который вообще не нужно выполнять с базой данных.

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

Answer 4

Все базы данных более чем на 85% только для чтения! Обычно тоже девяностые годы.

Настройте его, когда вам нужно, а не раньше.