MongoDB

[Krusty]

Сообщение от AlexCooper

Прокомментируйте пожалуйста это
Sphinx это следующий этап оптимизации, плюс я думаю будет реализована еще связка Node.js с long-poll, memcache и железом SSD-диски которые помогут дышать серверу но начало идет от архитектуры и самой БД.

Правда сие есть, разумеется. Да ну в общем-то отпинать можно любую БД, mysql свои плюсы имеет, как и минусы. Важны ли они для вас или нет - вопрос другой. Рекомендации в том топике тоже приведены.
Зы. партиции и R-index - два основных проблемных места mysql. ну по моим ощущениям, с чем сталкивался.

[AlexCooper]

Кто-то использовал MySQL в hi-load проектах? И на сколько оправданны оптимизации MySQL?

Добавлено через 11 часов 33 минуты
Решил использовать комбинированный метод. К примеру ленту для пользователя хранить в mongoDB, а вот текста для поиска MySQL+Sphinx.
Кому интересно туториал партицирование MySQL.

[terbooter]

Да каждый четвертый хайлоад на мускуле. Например, badoo
Кстати, слушал несколько докладов на конференции от ребят из Badoo, они окончательно убедили меня отложить NO SQL на какое-то время

[Андрей911]

Я слышал что Mongo существенно быстрее MYSQL, только при записи данных в базу, так как они записываются в оперативку и только периодически идет синхронизация с диском, а MYSQL пишет сразу на диск. А при чтении из базы если в MYSQL используется кеширование, то разница в скорости особо нет.

[Psycho Tiger]

Сообщение от kackbip

Еще можно использовать нормальную БД Проиндексированную

В монгоДБ есть индекс. Почему она не нормальная?

[AlexCooper]

В целом мой совет для строений хайлоад-проектов.
максимально перенести нагрузку с Апача на Nginx
передача данных AMFPHP с использованием Long-pool
хранения информации участвующей в выборке MYSQL
поиск по базе Sphinx
ленты обновлений, чаты и т.д. MONDODB/XtraBD
асинхронные задачи Gearman
кеширование выборки из мускл Memcached
плюс незабываем об изменениях всех стандартных конфигов.

[Krusty]

Зачем кэшировать выборку из mysql в Memcached? Им обычно кэшируют результаты более высокого уровня, нежели выборка. Он рульный, не спорю, но в мускуле есть встроенные средства для кэширования запросов, если запрос не кэшируется - на это есть причины ( NOW(), RAND(), обновление таблицы etc) . Ну кроме некоторых ограничений архитектуры запросов, где они поленились писать.

[AlexCooper]

Кешировать нужно не обычные запросы по типу выборки по ключам, а сложные запросы с объединением таблиц и тому подобное. В своих проектах я кеширую именно такие запросы. Или к примеру список рейтинга пользователей с сроком хранения час.

Добавлено через 1 минуту
кеширование произвожу отличным предложенным методом ключ к мемкэшу = md5(sql_query)

[Krusty]

А, ограничения архитектуры.

[terbooter]

AlexCooper, расскажите вот тут по-подробнее

передача данных AMFPHP с использованием Long-pool

Остальное мы так или иначе уже используем.