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

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

В cassandra ваши данные не помещаются на одном компьютере, поэтому вы не можете выполнять соединения, единственный запрос, который вы можете выполнить эффективно, - это получить диапазон столбцов по ключу, а 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 возможных запросов.

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

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

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

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

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

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

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

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

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

С. Коронел, П. Роб (2009), «Системы баз данных: реализация проекта и управление», Курс «Технология», Бостон, Массачусетс (Глава 5)