Объединения против нескольких копий данных: производительность

#mysql #performance #join

#mysql #Производительность #Присоединиться

Вопрос:

Я просто читал http://s.niallkennedy.com/blog/uploads/flickr_php.pdf об инфраструктуре Flickr, и вот что в нем говорилось.

 JOIN’s are slow
• Normalised data is for sissies
• Keep multiple copies of data around
• Makes searching faster
  

Это правда или это просто их способ управления своими базами данных? Если я просто ищу производительность, лучше ли не нормализовать?

Комментарии:

1. Идея нормализации заключается в уменьшении или устранении избыточности в модели данных. Часто производительность можно повысить путем денормализации модели — другими словами, путем введения избыточности, которая устраняет ограничения, вложенные запросы или объединения. Компромисс заключается в использовании хранилища и памяти.

2. @reve_etrange Я думаю, мне очень нравится часть признания того, что память будет использоваться так же, как и хранилище. Но если у вас есть денормализованные данные, у них будет меньше индексов и меньше использования памяти, верно?

3. Еще один компромисс: У вас есть несколько копий данных, потенциально все авторитетные. Если они не синхронизированы, вы не сможете определить, какой из них «правильный».

4. @user658911 Вы правы, общая память и хранилище будут зависеть от характера индексов.

Ответ №1:

Объединения становятся проблемой производительности на больших наборах данных. Об этом не стоит беспокоиться, если у вас нет проблем с медленностью. У нормализованных данных есть большие преимущества, но никто никогда не переходит к пятой нормальной форме. Типичной является вторая или третья нормальная форма.

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

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