NOSQL Design, без денормализации?

Question

Я только начал проектировать 'схему' базы данных распределенного хранилища.

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

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

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

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

Похоже, это может быть лучшим выбором среди:

• начать с СУБД, перейти к распределенному хранилищу, если необходимо
• начать с распределенного хранилища, с полностью денормализованным дизайном (готовым к масштабированию)
• начать с распределенного хранилища с реляционным дизайном, денормализовать + изолировать, если необходимо

Мысли?

Спасибо

Answer 1

Рассматривали ли вы масштабирование вашего должным образом нормализованного реляционного БД по старинке ?NoSQL получил известность, позволив масштабировать простые или плохо спроектированные php / lamp-приложения, заменив узкое место чем-то грубым, но эффективным.Если у вас элегантный дизайн, вам не нужно NoSQL для масштабирования.

Answer 2

Я бы выбрал вариант 2, предполагая, что у масштабируемой схемы нет действительно серьезных недостатков.

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

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

Answer 3

Я думаю, что последний подход звучит очень разумно, но у меня есть некоторые комментарии. Больше нет реляционных dbms, поэтому я бы предложил использовать OO design вместо реляционных. Например, если у нас есть отношение «один ко многим» с «владением» семантикой - мы можем поместить обе стороны в один объект и сохранить его как один объект. Я думаю, что этот подход можно считать совершенно «нормализованным» в слове NOSQL.