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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

Это хорошая презентация на how to do indexing in cassandra.

Answer 2

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

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

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

Answer 3

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

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

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

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

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

С. Коронель, П. Rob (2009), "система база данных: Внедрение и администрирование", курс технология, Бостон, MA (Ch. 5)