Данная тема не совсем к Yii, но очень интересная.
Есть проект на c++, бд состоит примерно из 150 таблиц, примерный размер базы от 500мб(чистый вариант) до 600-700гб, а это и больше. Постоянно от 20 запросов в секунду.
Какую лучше субд выбрать? Остановился на PostgreSQL или Firebird. Самым важным фактором является скорость получения данных (Insert и тд не так важно)
Рекомендую посмотреть в сторону PostgreSql + hstore plugin, который позволит в некоторых ситуациях отказаться от промежуточных таблиц.
Также рекомендую посмотреть в сторону noSql решения Cassandra. Эта БД крайне интерсно устроена, и маштабировавние в ней очень прозрачное.
Решение на MongoDb плохо себя ведут, отжирая колоссальное кол-во ресурсов при увеличении кол-ва данных на ноду. А при большом кол-ве нод получается большой оверхед на коммуникации в сети.
Если у Вас необходимость огромного чтения - можно использовать sphinx, который даст бонусы в виде возможности реализации сложных фильтров. В тоже время под Lucene on Java дотаточно сложно добиться гладкой работы highload, нужно уметь готовить.
Одним из бонусов Sphinx - его можно нещадно пилить из сорцов как вам нравится. Не очень удобно, но результат себя оправдывает.
Если используется шардинг, то рекомендую начать использовать RabbitMq для фонового сбора данных по системе, например для аналитики, мониторинга, бекапов.
mitallast
Мне главное что бы выдерживала и успела обрабатывать ~500запросов в сек.
Это немного неверный подход, чтобы БД выдерживала энное кол-во запросов. Это просто не работает.
Хорошее решение - то, которое маштабируется простым добавлением нод под БД. Есть один проект, в котором на странице листинга до 400 запросов на страницу с одной БД - используется Percona Server, по сути допиленный mysql. Вещь хорошая, шустрая - но она уже некисло так загружена по банальному IO жестких дисков. Не спасет от нагрузки увеличение мощности одной железки - нужна архитектура, при которой можно просто добавить еще один сервер под БД, чтобы снизить нагрузку на остальные. Есть разные подходы к маштабированию - основные репликация и шардинг.
При репликации делают несколько нод БД, в которой один-два мастера и куча слейвов. Чтение маштабируется, запись нет. Есть оверхед на синхронизацию между нодами, которая ведется и помощи бинарного лога - в средм отставание десятки секунд. Имеет ограниченную возможность расширяться - рано или поздно оверхед на репликацию станет слишком большим.
При шардинге данные равномерно распределяются на существующие ноды. В качестве примера, есть 10 нод - тогда пользователей например можно распределять по нодам по остатку деления на количество машин например, типа 114%10 = 4 нода.