Размер таблицы SQL и производительность запросов

Question

У нас есть несколько элементов, поступающих из веб-службы; каждый элемент, содержащий неизвестное количество свойств. Мы храним их в базе данных со следующей схемой.

Предметы
- ItemID
- ItemName

Свойства
- PropertyID
- PropertyName
- PropertyValue
- PropertyValueType
- TransmitTime
- ItemID [fk]

Таблица свойств становится достаточно большой, поскольку в ней хранятся свойства для каждого элемента при каждом вызове веб-службы. У меня такой вопрос: в какой момент мы должны прекратить добавлять новые записи в таблицу свойств и архивировать старые записи свойств в соответствии с временем их передачи? Когда таблица свойств становится слишком большой и занимает слишком много времени для запроса? Есть ли эмпирическое правило?

Спасибо.

Answer 1

Я не уверен насчет MS SQL Server, но большинство баз данных, похоже, имеют возможность разбивать таблицы. То есть создайте виртуальную таблицу из множества небольших таблиц и разделите данные между ними на основе некоторых простых правил.

Это очень хорошо для данных, основанных на времени, как это. Разделите таблицу на период времени, например, день или час. Затем один раз за промежуток времени добавьте новый раздел таблицы и удалите самый старый раздел таблицы. Гораздо эффективнее, чем выполнять УДАЛИТЬ ГДЕ время <сейчас - '1 час' или что-то еще. </p>

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

Answer 2

Эмпирического правила не существует

Некоторые мысли:

• определить "большой" (у нас есть 160 миллионов таблиц строк)
• У вас сейчас есть проблемы? если нет, не исправляй это
• Вы запустили профилировщик или несколько изумительных dmvs, чтобы обнаружить узкие места (отсутствующие индексы и т. Д.)
• если вам нужны данные для хранения, вы не можете заархивировать их
• вы можете разбить таблицу, хотя

Answer 3

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

Несколько факторов для рассмотрения:
- сценарий использования
- Характеристики серверного оборудования
- Характер работы с БД (например, больше прочитано, чем записано ?, вставлено и не обновлено?)

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

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

Answer 4

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

В вашем примере:
Item = Subject,
Property = Observation,
PropertyName = ObservationType.Name,
PropertyValueType = ObservationType.IsTrait

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

- Измерение и черта являются типами наблюдения. Измерение является численное наблюдение, как высота. Черта - это описательное наблюдение, как цвет.