Денормализация: сколько стоит слишком много?

Question

Я разработал базу данных для веб-приложения, которое я создаю "по книге". То есть я:

• Создана ER-диаграмма, содержащая сущности, атрибуты и отношения приложения
• Переведите диаграмму ER в схему
• Переводил схему в форму "без схемы" для моделирования базы данных (база данных - это база данных Cassandra (NoSQL)).

Все идет хорошо (пока). Раньше я денормализовал с отличными результатами и сейчас внедряю часть приложения, которая будет использовать данные, которые еще не были денормализованы. Я предполагаю, что выполнение этой конкретной части несколько увеличит производительность (чтение из 1 Column_Family ("таблица" в реляционном мире) вместо 7).

Однако я боюсь, что я могу слишком много денормализовать. Если бы я сделал это для рассматриваемой части, это значительно уменьшило бы количество столбцов Column_Family/ таблицы в моем приложении примерно на 20%, и из-за того, что большая часть моей базы данных была денормализована, я почему-то нервничаю.

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

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

Answer 1

Разработка схемы для Cassandra очень отличается от разработки схемы для базы данных SQL. С базой данных sql ваши данные помещаются на одном компьютере, база данных будет поддерживать индексы для вас, вы можете выполнять объединения и выполнять сложные запросы с помощью sql. Все это делает нормализацию данных практической.

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

В Кассандре вы обычно разрабатываете свою схему для обслуживания запросов, которые собираетесь делать, и денормализуете для этого. Мой любимый пример этого - то, что твиттер делает для своей статистики для rainbird, как объяснено в этом посте,

For example, say someone clicks on a t.co link to blog.example.com/foo at 11:41am on 1st Feb. 
Rainbird would increment counters for:

 t.co click: com (all time)
 t.co click: com.example (all time)
 t.co click: com.example.blog (all time)
 t.co click: com.example.blog /foo (all time)
 t.co click: com (1st Feb 2011)
 t.co click: com.example (1st Feb 2011)
 t.co click: com.example.blog (1st Feb 2011)
 t.co click: com.example.blog /foo (1st Feb 2011)
 t.co click: com (11am-12 on 1st Feb)
 t.co click: com.example (11am-12 on 1st Feb)
 t.co click: com.example.blog (11am-12 on 1st Feb)
 t.co click: com.example.blog /foo (11am-12 on 1st Feb)
 t.co click: com (11:41-42 on 1st Feb)
 t.co click: com.example (11:41-42 on 1st Feb)
 t.co click: com.example.blog (11:41-42 on 1st Feb)
 t.co click: com.example.blog /foo (11:41-42 on 1st Feb)

Этот 1 клик копируется 16 раз, чтобы удовлетворить 16 запросов, которые могут быть выполнены.

Это хорошая презентация о том, как сделать индексацию в Кассандре.

Answer 2

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

Прежде всего, помещение таблицы в 1NF предполагает устранение избыточных данных или (Coronel, Rob 2009) "повторяющихся групп". Удаление данных в нескольких местах (будь то в других таблицах или строках) - это хорошая вещь, которая помогает в обслуживании, сохранности данных и производительности.

Переход на 2NF предполагает устранение частичных зависимостей. Частичные зависимости существуют, когда у вас есть составной ключ (первичный ключ, состоящий из нескольких полей ключа) и полей, значение которых определяется только одним или частью ключа. Как правило, устранение частичных зависимостей - это то место, где вы начинаете видеть таблицы мостов, созданные для обработки отношений "многие ко многим".

3NF - это шаг вперед, поскольку он устраняет все транзитивные зависимости или поля, которые зависят от значения неключевых полей. Этот шаг часто обсуждается во имя исполнения. В зависимости от размера или дисперсии значений переходных полей вам нужно будет взвесить трудности, связанные с сохранением этих значений в таблице, а не с тем, как часто вам понадобится ПРИСОЕДИНЯТЬСЯ, чтобы получить их.

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

C. Coronel, P. Rob (2009), "Системы баз данных: реализация проекта и управление", курс технологии, Бостон, Массачусетс (гл. 5)

Answer 3

Как правило, вы хотите максимально нормализоваться, особенно в отношении таблиц, которые, по вашему мнению, могут стать большими. Я пропустил нормализацию очень маленьких наборов данных или непосредственно связанных данных, но никогда не улучшал соображения производительности (для этого нужны серверы отчетов и ETL); Я считаю, что дополнительные усилия в разработке и объединение очень маленьких, непосредственно связанных, редко меняющихся таблиц - пустая трата времени с точки зрения разработки.

Мои самые большие проблемы с денормализацией - это целостность данных и нехватка места (на диске и в памяти) в этом порядке.

Моя единственная проблема с нормализацией - ремонтопригодность; Создание чего-то очень простого, намного более сложного, чем это действительно необходимо, обычно бесполезно. Нормализация ради нормализации фанатична, насколько я понимаю, и только ситхи имеют дело с абсолютами.