База данных с "открытой схемой" - хорошая или плохая идея?

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

Что меня удивило, так это пункт 3:

Вместо этого они сохраняют таблицу Thing и таблицу данных. Все в Reddit - это Thing: пользователи, ссылки, комментарии, субредады, награды и т.д. Вещи сохраняют общий атрибут, например, вверх/вниз, тип и дату создания. Таблица данных имеет три столбца: id, ключ, значение. Theres строка для каждого атрибута. Theres строка для заголовка, url, автора, спама голосов и т.д. Когда они добавляют новые функции, им больше не нужно беспокоиться о базе данных. Им не нужно было добавлять новые таблицы для новых вещей или беспокоиться об обновлениях.

Мне кажется, это ужасная идея, но, похоже, она была разработана для Reddit. Это вообще хорошая идея? Или это особенность Reddit, которая оказалась для них?

Ответ 1

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

Ответ 2

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

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

Ответ 3

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