База данных с «открытой схемой» - хорошая или плохая идея? - PullRequest
19 голосов
/ 18 мая 2010

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

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

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

Мне кажется, это ужасная идея, но, похоже, она сработала для Reddit. Хотя это хорошая идея в целом? Или это особенность Reddit, которая сработала для них?

Ответы [ 3 ]

16 голосов
/ 18 мая 2010

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

8 голосов
/ 18 мая 2010

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

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

7 голосов
/ 18 мая 2010

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...