База данных с “открытой схемой” - хорошая или плохая идея?
Соучредитель Reddit дал презентацию проблем, которые они имели при масштабировании миллионам пользователей. Сводка доступна здесь.
То, что удивило меня, является точкой 3:
Вместо этого они сохраняют Вещь Таблицей и Таблицей данных. Все в Reddit - Вещь: пользователи, ссылки, комментарии, subreddits, премии, и т.д. Вещи сохраняют общий атрибут как/вниз голоса, тип и дата создания. Таблица данных имеет три столбца: вещь идентификатор, ключ, значение. Существует строка для каждого атрибута. Существует строка для заголовка, URL, автора, голосов спама, и т.д. Когда они добавляют новые опции, они не должны были больше волноваться о базе данных. Они не должны были добавлять новые таблицы для новых вещей или беспокойства об обновлениях.
Это походит на ужасную идею мне, но это, кажется, удалось для Reddit. Действительно ли это - хорошая идея в целом, хотя? Или действительно ли это - особенность Reddit, которая, оказалось, удалась для них?
3 ответа
Это модель данных, известная как EAV для значения атрибута объекта . У него есть свои применения. Ярким примером являются данные тестов пациента, которые, естественно, немногочисленны, так как существуют сотни тысяч тестов, которые можно запустить, но, как правило, для пациента присутствует лишь горстка. Таблица с сотнями тысяч столбцов - это глупо, но таблица с EAV имеет смысл.
Большинство действительно крупных веб-сайтов в конечном итоге используют что-то вроде невероятно простой базы данных. Преимущество этого способа в том, что он быстрый и масштабируемый. Недостатком является то, что все отношения, которые база данных обеспечивает автоматически (с помощью триггеров и т.п.), вам нужно обеспечивать самостоятельно в клиентском коде. Поддерживать непротиворечивость - та еще морока, и почти всегда есть хоть какой-то шанс, что ваши данные будут непоследовательными, по крайней мере, в течение коротких периодов времени.
Для сайта социальной сети это достойный компромисс. Данные, которые в основном верны большую часть времени, являются адекватными (например, кого действительно волнует, что количество голосов "вверх", полученных вами за элемент, действительно устарело на 20 миллисекунд в момент отправки), а сохранение разумных затрат при масштабировании для поддержки гигантского количества пользователей имеет большое значение.
Я заметил, что они ничего не упоминали о простоте или сложности создания отчетов на основе этих данных. При использовании в узком наборе обстоятельств EAV могут быть полезными. Как центральная часть большинства систем, когда вы нажимаете на репортаж, он превращается в кошмар. Проблема с EAV заключается в том, что большая часть преимуществ возникает на начальном этапе проекта, а большая часть боли возникает позже при анализе и отчетности, особенно из-за серьезного отсутствия целостности данных. «Не беспокоиться о внешних ключах» для меня звучит как кошмар с потерянными строками. Добавьте сюда использование суррогатных ключей для всего, и вы получите запутанное болото, которое обычно заканчивается полным переписыванием