Походит на довольно управляемую нагрузку на умеренный сервер - вы не сказали, какие операции чтения выполняются во время этих вставок и обновлений (кроме извлечений для Lucene) и размера (в байтах / тип данных) данных (количество элементов, которое вы указали, выглядит нормально).
На этом этапе я бы рекомендовал просто использовать обычные рекомендации SQL Server - определить подходящую схему (нормализовать, затем денормализовать только при необходимости), просмотреть планы выполнения , используйте мастер настройки индекса, используйте DMVs , чтобы найти неиспользуемые индексы и удалите их, тщательно выбирайте кластерные индексы , чтобы управлять разбиениями страниц, тщательно выбирайте типы данных и размер и используйте ссылочная целостность и ограничения, где это возможно, чтобы помочь оптимизатору как можно больше помощи . Кроме того, это счетчики производительности и настройка вашего аппаратного / программного обеспечения.
Во многих / большинстве случаев вам никогда не понадобится выходить за рамки этого, чтобы фактически перестроить вашу архитектуру.
Однако даже после всего этого, если нагрузка на чтение велика, вставки и обновления могут вызвать проблемы с блокировкой между чтениями и записью, а затем вы смотрите на архитектурные решения для вашего приложения.
Кроме того, миллион строк и 200 тыс. Обновлений в день меня не беспокоили, но вы упоминаете Lucene (то есть полнотекстовое индексирование), поэтому, вероятно, некоторые столбцы довольно большие. Обновление больших столбцов и их экспорт, очевидно, занимает гораздо больше времени - и гораздо большую пропускную способность и количество операций ввода-вывода. 30 столбцов в узкой миллионной таблице строк с традиционными столбцами типов данных - это совсем другая история. Возможно, вы захотите взглянуть на профиль обновления и посмотреть, нужно ли разделить таблицу по вертикали, чтобы переместить некоторые столбцы из строки (если они большие, они уже будут сохранены вне строки), чтобы улучшить поведение блокировки.
Итак, главное, когда у вас большая нагрузка на чтение: вставки и обновления должны быть максимально быстрыми, блокироваться как можно меньше (избегая эскалации блокировки), обновлять как можно меньше индексов для поддержки операции чтения.
Если нагрузка чтения слишком велика (так что вставки / обновления начинают конфликтовать), но не требует 100% актуальной информации (скажем, 5-минутная или 15-минутная задержка не заметна), вы можете прочитать только поддерживаемая версия базы данных (идентичная посредством репликации, по-разному индексируемая для производительности, денормализованная или по-разному смоделированная - как размерная модель). Возможно, ваши индексы Lucene могут содержать дополнительную информацию, так что все дорогостоящие операции чтения остаются в Lucene, т. Е. Lucene покрывает многие крупные операции чтения, тем самым снижая нагрузку чтения в базе данных до необходимых операций чтения, которые поддерживают вставки / обновления (обычно это небольшое чтение) и транзакционная часть вашего приложения (т. е., скажем, экран информации об обслуживании клиентов будет использовать обычную базу данных, в то время как ваша почасовая панель мониторинга будет использовать вторичную базу данных).