Доброго времени суток!

Суть проблемы: столкнулся с проблемой проектирование БД(в личных целях) - но являюсь полным профаном в этой теме! Знания ограничиваются недельным "гуглированием". Посему прощу сообщество о помощи!

Что есть:
Таблица users:
поля:
user_id - primery_key
city_id
login
pass

Выборка из таблицы осуществляться по user_id или по login+pass

Таблица rating(связанна с users. 1 юзер может иметь несколько рейтингов (один-ко-многим)):
id (не знаю зачем он нужен, но вроде как обязательно уникальное поле(повторюсь я полный профан)));
type_id
rating
city_id
user_id

Выборка из таблицы осуществляться по city_id+type_id + rating (по 15 записей с самыми большими значениями, потом другие 15 и тд).
+Выборка по user_id.

Таблица stars:(связанна c users многие-к-одному)
поля:
id
one_star
two_star
....
....
five_star
user_id
Выборка из таблицы по user_id.
Примечание: поле rating таблицы rating - рассчитывается исходя из значений полей таблицы stars(но скорость обновления не критична). - + Я же правильно понял что это возможно?

Есть еще пару таблиц но они мелкие и статичные(вроде таблицы city - они как я понимаю тупо кэшируються?).
Суть вопроса:
В ситуации когда в таблицах особо никого нет, все будет работать отлично!
Но если представить что в таблицах очень много записей , users от миллиона, и высокая нагрузка на чтение? (пусть даже с редкой записью,но тем не менее с записью)
То как оптимизировать выборки:?

Понимаю тема объемная, но тем не менее:

Если rating зависит от stars и изменяется с изменением полей в stars + я так понимаю для более быстрой выборки из rating она будет проиндексирована(по rating и по city_id?), то есть любое изменение это часовые перестановки? или там оптимизация на это дело? или с большой БД уже никакая оптимизация не помощник?

И еще вопрос, будет ли поле rating сразу обновляться, или в sql как-то синхронизация настраиваться?


Если на все это дело сделать репликацию: то можно ли будет сделать так что бы мастер обновлял инфу по rating раз в день? (то есть целый день, меняются значения полей в stars - он ждет, в какой-то момент берет их(те которые изменились), и пересчитывает рейты, и потом обновляет на слайвах?)

А что будет, если сделать партиционирование(секционирование)? по городам предположим! Поиск будет быстрее? А индексирование после перестройки(это из прошлых вопросов)? Оно будет в своей партиции или будет затрагивать все партиции? (просто не понимаю, это будут "как бы" разные таблицы , или все таки одна но в которую как и при индексировании добавят что-то вроде индекса?)

Прошу прощения, за некий сумбур, особенно когда затрагиваются такие глобальные моменты, и опускаются фундаментальные, но очень интересно!

SERG1257, Спасибо, за ответы!
Если вы не против чуть-чуть еще поспрашиваю.

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

Насчет задачи(которую поставил сам перед собой и как я это вижу):
Таблица users это общие данные - я не описал(что безусловно мой просчет) что в ней хранятся так же поля name/surname/phone и тд, в общем вся общая информация - поэтому выборка по id! по login+pass понятно для авторизации.

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

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

Репликацию я хочу использовать ,так как на чтение запросов будет в разы больше по моим прикидкам 20/80 , но эти 20% - как я писал выше влияют на rating , которая в свою очередь тоже является часто читаемой таблицей(но не критичной к скорости обновления)! Поэтому мной был придуман этот метод, когда за определенный промежуток времени собираться даные - после чего происходит пересчет и видимо переиндексация(так как в тонкостях работы БД я не разбираюсь - я думаю что переиндексация, НО какая она? полная? тогда надо 4-5 часов ,как я понимаю! или просто элементы изменившие свое положение в дереве ,каким-либо образом мирно переедут на другие ветки? Я решил рассматривать худший случай - что надо несколько часов пока таблица переиндексируеться, поэтому мастер в виду не критичности скорости обновления инфы реально настроить так , что бы эта постоянно переиндексируемая таблица синхронизировалась раз в день, а все остальное как в обычной репликации по мере обновления инфы?

Насчет партитиционирования: так как базы большие и критична скорость ,подумал что этот механизм будет уместен, особенно он интересен применительно к таблице rating - в которой происходят простоянные перерасчеты, пусть и простые. Поможет ли он увеличить скорость ,в том числе переиндексации? Конечно, хотелось бы рассматривать этот этап , как подготовительный к шардированию, но настолько оптимистичным быть я уже не могу(да и честно говоря не того масштаба проект)).

Кэширование всей горячей информации, конечно предусмотрено, не могу сказать сколько займет времени все это сделать, но статичные таблицы, топы в рейтингах и тд, в любом случае надо будет кэшировать(memcache - плацдарм изучаемого материала огромен))

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