|
Цитата:
|
|
Индекс по полю ника будет по твоей же схеме полностью дублировать поле ника. Если я понимаю как это работает, то это минимум увеличит место на диске. Хотя возможно это спички.
|
Конечно, каждый индекс - это дополнительное место на жестком диске и в оперативной памяти (ведь для нормальной работы БД она должна полностью влезать в оперативу). Если памяти не хватает, а возможности сегментировать БД нет, то некоторые СУБД могут загружать в оперативу только индексы, а за данными ходить на хард (или как вариант загружать в оперативу только часть данных, но индексы обязательно или будут неменуемые тормоза).
Также каждый индекс увеличивает время обновления / создания данных в коллекции, т.к. помимо самой модификации данных, нужно также дополнить индекс. Поэтому перед тем как создать индекс, нужно по профилировать запросы пользователей и найти те, который тормозят.
Но так или иначе, если база перестаёт влезать в оперативу, то самое лучшее решение - это сегментация, т.е. разнесение данных на разные машины. Некоторые СУБД могут делать это сами, в некоторых придётся писать руками (и это реальный геморой).
Я был на мастер классе от TopFace (они юзают MySQL + Redis) и они не используют встроенные индексы, а на каждый популярный запрос сохраняют результат в отдельную таблицу, т.е. делают индексы руками, а сами таблицы размазывают по кластеру по географической позиции, т.е. пользователи из Москвы на одних серверах, из Питера на других и т.д. Причём само размазывание у них тоже написано самостоятельно и там жесть логики.
Но если база данных становится очччень большой (свыше терабайта), то тут вступает в игру техника работы с BigData, а именное map-reduce, например, есть мега фреймворк Hadoop для таких задач.
В общем проектирование БД это реально очень сложная задача.