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

Question

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

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

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

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

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

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

Answer 1

Разработка схемы для 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 запросов, которые могут бытьготово.

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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