Стратегия БД для вставки в таблицу с высоким уровнем чтения (Sql Server)

Question

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

Справочная информация:

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

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

ps. В настоящее время у нас нет бюджета или опыта для хранилища данных.

Проблема:

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

Я размышляю над несколькими идеями. Одна включает новые таблицы и довольно серьезную реструктуризацию, я не прошу помощи по этому вопросу. Другой включает создание избыточных данных (например, таблицы Visitor_Archive и Visitor_Small), где существуют большие таблицы посещений и посещений для вставок и истории / отчетов, меньшая таблица visitor1 будет существовать для управления потенциальными клиентами, отправки электронного письма ведущим, нуждающихся в телефонных телефонах номер, нужен мой список ведет, и т.д ..

Причина, по которой я обращаюсь, заключается в том, что мне хотелось бы узнать, как лучше синхронизировать таблицы Visitor_Archive и Visitor_Small ...

Тиражирование? Можно ли использовать репликацию для репликации только данных с определенным значением столбца (FooID = x)

Любые другие стратегии?

Answer 1

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

Вы можете разделить строки таблицы / индекса по нескольким физическим или логическим устройствам, и это специально предназначено для повышения производительности наборов данных, когда вам может понадобиться только известное подмножество данных для работы в любое время. Разделение таблицы по-прежнему позволяет вам взаимодействовать с ней как с одной таблицей (вам не нужно ссылаться на разделы или что-либо в ваших запросах), но SQL Server способен выполнять несколько оптимизаций для запросов, которые затрагивают только один раздел данных. Фактически, в Проектирование разделов для управления подмножествами данных примеры AdventureWorks в значительной степени соответствуют вашему точному сценарию.

Я бы провел небольшое исследование, начав здесь и продолжив свой путь: Секционированные таблицы и индексы .

Answer 2

Простое решение: создать отдельную таблицу, ненормализованную, со всеми полями в ней. Создайте хранимую процедуру, которая обновит эту таблицу в вашем расписании. Создайте задание SQl Agent для вызова SP.

Индексируйте таблицу, как видите, как она запрашивается.

Если вам нужно очистить историю, создайте другую таблицу для хранения ее и еще один SP для ее заполнения и очистите основную таблицу отчетов.

У вас может получиться несколько таблиц отчетов - все нормально - в наши дни пространство дешевое.