Проблемные шаблоны данных с точки зрения производительности

Question

Утверждение: производительность баз данных SQL ухудшается, когда объем данных становится очень большим (скажем, десятки или сотни терабайт). Это означает, что определенные шаблоны в дизайне базы данных, которые являются разумными для большинства малых и средних баз данных, ломаются, когда база данных растет. Для (довольно общего) примера, существует тенденция, которая отходит от разработки моделей данных, которые полностью (или, скажем, BCNF) нормализованы, поскольку необходимые объединения слишком сильно влияют на производительность. Смотри также этот вопрос

У меня такой вопрос: Вам известны какие-либо шаблоны баз данных, которые, хотя и приемлемы для типовой базы данных, ломаются (с точки зрения производительности) для огромных баз данных , особенно SELECT-запросы? Существуют ли альтернативные стратегии, которые достигают того же (с точки зрения данных) без этих проблем производительности?

Answer 1

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

Answer 2

Идентификационные столбцы?!

Это может произойти с ОГРОМНОЙ таблицей, содержащей много данных и объемные транзакции вставки / удаления.

РЕДАКТИРОВАТЬ: ОК. Перечитай свой вопрос. Индексы могут быть огромными производительность узкие места для вставок в таблицы, содержащие много строк.