Производительность DB с большим набором данных

Question

Я не спрашиваю об индексировании и разбиении на разделы, я спрашиваю о выборе между добавлением большого нет. столбцов или добавление данных в виде строк. Пояснение: в настоящее время у нас есть запрос на создание дизайна для обработки нескольких свойств и их значений для некоторых конкретных продуктов. продукты могут достигать 100 миллионов записей, и каждый продукт может иметь несколько свойств, поэтому таблица ProductProperties может достигать миллиардов. Некоторые люди думали о добавлении свойств в виде столбцов в таблице ProductProperties, Property1 и value1, Property2 и value2 и т. Д. Если продукт не содержит значений для свойства, связанные поля для этого свойства будут пустыми. Также они добавят свойство 80-100, чтобы динамически охватывать широкий диапазон свойств. Архитектор отказался от этого подхода, поскольку это не очень хороший дизайн. Может ли кто-нибудь сказать мне, как достичь хорошего дизайна плюс хорошая производительность. Спасибо

Answer 1

Я бы создал две таблицы: Product и ProductProperties.

Product будет содержать основные свойства одного продукта. Рода вещи, которые необходимы и общие между элементами таких как name, weight, selling_quantity и т.д.

ProductProperties будет содержать все остальное. Нормализуйте атрибуты свойств, назовите их и создайте таблицу. Все, что вам нужно, это FK до Product, и вы готовы к работе. 1: n между таблицами намного лучше, чем одна таблица с 80 или более свойствами, если большинство свойств пуст (я сомневаюсь, что каждый продукт нуждается в 80-100 свойствах, но я не знаю, какие продукты вы перечисляете) ,

У меня нет опыта из первых рук в использовании миллиардов строк, но базы данных должны быть нормализованы, а не заполнены пустыми столбцами. Этот ответ, кажется, поддерживает мои мысли: Optimal database structure - 'wider' table with empty fields or greater number of tables?

Я думаю, что ваша первая проблема возникает, когда ваша таблица ProductProperties имеет больше строк, чем может обрабатывать unsigned bigint. Это может занять некоторое время, я надеюсь ...

Answer 2

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

Подход 1: Общие поля на ряде + дополнительные метаданных

Первый подход вы предложили может быть немного изменены путем нормализации метаданных свойств продукта в свою таблицу:

• Создайте таблицу продуктов с помощью некоторых общих полей (Code1, Code2, IntVal1, IntVal2, FloatVal1 ...)

• Создайте дополнительный набор родительских дочерних ссылок таблицы ProductType и ProductAttribute (или некоторые такие), которые содержат руководство по тому, какие столбцы в вашей таблице продуктов содержат какие атрибуты.

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

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

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

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

Подход 2: сущность-атрибут-значение

Это часто предлагается в качестве решения этого класса задач. В этом случае вы имеете таблицы Product и ProductAttribute в отношениях родитель-потомок с некоторыми ссылочными данными, которые фильтруют типы атрибутов продукта в отношении типов продуктов.

Этот подход кажется концептуально элегантным и расширяемым, но неудобен и неэффективен для запроса и занимает значительно больше дискового пространства. Некоторые хаки для проектирования баз данных могут использоваться на разных платформах для смягчения проблем с производительностью. Вы не указали, какую платформу СУБД вы используете, поэтому вам трудно указать на это в правильном направлении. Основные преимущества и недостатки EAV структур:

• Бесконечно гибкий без необходимости вносить изменения в базу данных Schena (+)

• Неэффективное и неудобный для запроса, особенно, если вы хотите, чтобы фильтровать по нескольким атрибутам (-)

• Больше дискового пространства. (-)

Обычно структуры EAV не рекомендуются, если у вас нет убедительных требований.

Подход 3: поля XML

Перефразируя Фредрика Lundh: 'now you have two problems'. Поля XML бесконечно расширяемы - вы можете поместить в них все, что хотите, но они непрозрачны для всего, кроме вашего приложения, и они медленно и неудобно запрашивают. Получение данных из поля XML в SQL-запросе намного больше, чем с данными, хранящимися в столбцах.

Как правило, это плохая идея использовать XML-поля в базе данных для хранения чего-то, что по сути не является XML-документом. Многие люди писали о неразумности злоупотребления полями XML в базе данных. Мой личный опыт построения ETL-процессов для извлечения данных из полей XML приводит меня к согласию. Лучше всего избегать, если у вас нет веской причины.

Заключение

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

Answer 3

Существующие ответы правильные и очень хорошие. Вот новая мысль: Очевидно, что разделение дизайна на две таблицы (Products, ProductAttributeValues) является наиболее нормализованным и правильным способом для этого.

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

Denormalize, если он сэкономит вам работу даже в долгосрочной перспективе, или если он экономит на оборудовании.