Будет ли нормализация моей базы данных уничтожить масштабируемость?

Question

У меня есть база данных, которая станет частью веб-приложения с высокой посещаемостью.

Мне интересно, следует ли нормализовать таблицы, чтобы такие вещи, как (например) 'question_type', были в отдельной таблице, а также вся основная информация о вопросе, такая как 'title' и 'question_body'?

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

Спасибо

Answer 1

Если на вашем столе есть question_body и question_type, то я не вижу, как перемещение его на другой стол приводит к нормализации.Например:

table question (
    question_body      text,
    question_user      text,
    question_user_rank integer,
    question_type      text
);

Разделение одного значения в таблице с одним столбцом не даст ничего, кроме бесполезных объединений.То есть:

select * from question q join question_type qt on (q.qt_id = qt.id)
  where qt.name = 'sql questions';

является эквивалентной, но расточительной формой

select * from question
  where question_type = 'sql questions';

С другой стороны (с использованием приведенного выше примера) имеет смысл разделитьинформация о пользователе вопроса в его собственную таблицу:

table question (
   question_body     text,
   question_type     text,
   question_user_id  integer references question_user(id) on delete cascade
);
table question_user (
   id                integer,
   name              text,
   rank              integer
);

Таким образом, если пользователь изменил свой ранг (так называемый SO), вам нужно изменить его только в одном месте, а не в каждой строке, где ему задают вопрос,Вы увеличили свою способность обрабатывать масштабирование, поскольку вы превратили сотни обновлений в одно обновление.

Answer 2

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

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

Answer 3

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

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

Answer 4

Будет ли добавление соли улучшить вкус моей еды?

Тот же вопрос. Никто не может ответить.

Основная проблема заключается в том, что это зависит от ваших шаблонов ИСПОЛЬЗОВАНИЯ и, в некоторой степени, от вашей компетенции программиста - использовать кеши поиска в приложении вместо соединений с базой данных. Довольно много программистов никогда не выходят за уровень SQL, «яичница, сожгли», чтобы сохранить аналогию с кулинарией.

Для масштабируемого дизайна приложений и технологий баз данных есть что сказать. Трудно превзойти установку Oracle RAC. В зависимости от того, что вам нужно на платформе Exadata. Стоимость, я думаю, около полумиллиона долларов за самый маленький блок. Все еще уверены, что вам нужно "максимально масштабируемый"? Не шучу - я сейчас работаю с хранилищем данных 6000 Гб, мы только что заказали 3 из этих монстров, а не самых маленьких.

Итак, что вы имеете в виду под "максимально масштабируемым"? Это похоже на то, что «моя машина должна ехать так же быстро, как машина когда-либо ездила, и даже больше», тогда вы получите автомобиль особого производства с реактивным двигателем в нем;)

Общее правило: * Разделите транзакции и отчетность на две базы данных. Второе - хранилище данных. * Нормализовать транзакционный дБ * Используйте звездообразную схему в хранилище данных.

БОЛЬШОЙ шанс: вы не знаете, о чем говорите, никогда не делали масштабируемость, поэтому есть 80% шанс, что ваше требование «высокой масштабируемости» - это шутка для достойного сервера баз данных. Теперь, это не означает оскорбление, но я видел, что так много людей говорят: «У меня тонна данных в таблице», а получается максимум 10.000 строк. Это не тонна - это шутка. Мы ежедневно загружаем 100 миллионов в основную таблицу нашего хранилища данных (и должны хранить их много лет). Большинство людей не понимают, какую скорость может обеспечить приличный сервер баз данных. Что означает много дисков.