вопрос по MySQL кешированию

[radiante]

Узкое место - работа с БД, сервер держит 20 тыс однотипных запросов к разным строкам БД в секунду, если больше то сервер не справляется, и

обычно используют кеширование вместо наращивания железа. Я представляю себе 2 вида такого кеширования:
1. если строки в БД не менялись, то значения берутся из кеша (обычно оперативки)
2. если считать что первый вариант не прокатит, потому что поля меняются или еще почему-то, и нужно все запросы реально направлять на MySQL

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

Вопрос такой: где уже реализовано кешировать второго типа (может оно уже встроено в memcashed или что то другое надо юзать, подскажите) ?

 

[prolis]

сервер держит 20 тыс однотипных запросов к разным строкам БД в секунду, если больше то сервер не справляется

- для начала необходимо собрать факты, что именно сервер, именно БД и именно запросы приводят к отказу в обслуживании. Допустим анализ произведен и настройками уже все ресурсы выжаты. Тогда оптимизируем обращения к серверу, например кешированием, а это:
1. Взять значение из кеша
2. Если поле изменилось - обновить кеш.
3. см. п.1

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

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

 

[radiante]

я описывал кардинально другой вид оптимизации, приведу пример, чтобы было понятнее, опять же с учетом что узкое место БД (все цифры условные и показывают только суть): на сайте при пике одновременно сидит миллион человек на одной и той же php странице, каждая копия этого скрипа переодически по запросу пользователя делает выборку из БД, и скажем выходит 100 тыс уникальных незакешированных через memcached запросов в секунду, в итого сервер БД реально должен обрабатывать 100 тыс мелких запросов в сек, железо же тянет только 20 тыс таких запросов или 10 тыс более крупных подобных запросов где делается выборка сразу 10-и строк за один запрос (или тянет 5 тыс запросов по 100 строк). Решение: запросы к БД сначала обрабатывает промежуточный прокси сервер (да хоть самописный php скрипт куда передаются SQL запросы), собирая и склеивая запросы в один, и как только их число достигнет 10 (или 100) делается реальный SQL запрос в БД, а ответ снова разбивает на части и раздает нужные части ожидающим копиям той php страницы которая запросила данные. В итого при склеивании 10 запросов в один, страницы у пользователей будут открываться всего на 0,001 сек медленее, но зато теперь тоже железо потянет миллион юзеров онлайн, т.е. станет в 5 раз производительнее. При склейке 100 запросов, на 0,02 сек медленнее, но при том же пике сервер БД разгрузится в 5 раз, т.е. станет в 25 раз производительнее.

Чтобы не изобретать колесо, хотел узнать как называется уже готовая такая технология и как ее установить или на основе чего можно сделать свою разработку подобного прокси кеша?

 

[radioheaded]

Если я все правильно понял, вы предлагаете после условного первого запроса немного подождать, а вдруг есть еще запросы. Тогда-то мы их склеим и будет железу счастье. Даже если откинуть всю прочую фантастику, которую вы написали, то сколько нужно ждать, чтобы склеить? Не выполнится ли этот запрос быстрее, чем вы будете ждать других + потом выполнять эту пачку? Пока я вижу только ухудшение и никакой оптимизации. Могу ошибаться, конечно.

 

[MiksIr]

Если у вас выборки по ключу - уходите в noSQL.

 

[radiante]

Если я все правильно понял, вы предлагаете после условного первого запроса немного подождать, а вдруг есть еще запросы. Тогда-то мы их склеим и будет железу счастье. Даже если откинуть всю прочую фантастику, которую вы написали, то сколько нужно ждать, чтобы склеить? Не выполнится ли этот запрос быстрее, чем вы будете ждать других + потом выполнять эту пачку? Пока я вижу только ухудшение и никакой оптимизации. Могу ошибаться, конечно.

значит ты не понял о чем речь, не надо ждать пока накопятся 10/100 запросов! можно и один отослать, система ждет конкретное изначально настроенное время, некритичное для пользователя, причем ждет без локов таблиц! в итоге при мелкой нагрузке люди не заметят разницы, а при больших нагрузках можно разгрузить сервер БД во много раз.

 

[radiante]

Если у вас выборки по ключу - уходите в noSQL.

Согласен с тобой.

ладно. тема закрыта. всем спасибо)

 

[MiksIr]

Не осилил. В соседней вашей теме затронули noSQL плагин для MySQL, так вот он умеет накапливать запросы (судя по описанию). Если хочется распределенности, то попробуйте NDB кластер, для выборки по ключу он отлично подходит, хотя насчет накопления хз.

 

[radiante]

Не осилил. В соседней вашей теме затронули noSQL плагин для MySQL, так вот он умеет накапливать запросы (судя по описанию). Если хочется распределенности, то попробуйте NDB кластер, для выборки по ключу он отлично подходит, хотя насчет накопления хз.

вот, видите, стоит только поверить, покопать и оказывается что даже мои глупые фантазии уже кто то успешно реализовал))) MiksIr, спасибо за ссылка!

ради смеша просто покажу свое описание которое я давал тем кто мне искал решение (очень похоже на этот плагин)

Несколько серверов соединены в локальную сеть, на них раскидана БД случайным образом. Каждый запрос от пользователя проверяется, если ответ не в кеше, тогда большой склеенный запрос уже идет в БД. Делается это так: идет запрос php-страницы от пользователя, она запрашивает данные у особой прокси-функции, причем передаются только ключи с номерами процессов запущенных php-скриптов (просто пары чисел), прокси-функция собирает ключи в отдельные списки, исходя их таблицы ключей в оперативке. Собираются по два списка для каждого физ.сервера: список ключей, строки которого в кеше этого сервера и списки ключей по которым надо запрашивать БД. Таблица: ключ = адрес в памяти + смещение, по этому адресу записан номер физ. сервера где и находится нужная строка, а также кеш-бит определяющий в кеше данная строка по этому ключу или нет. Собираемые списки также хранятся в оперативке. По истечению заранее установленного некритичного для пользователя времени ожидания или при достижении заранее установленной макс.длинны списка, очередной собранный список (пары чисел ключ-процесс, а также один параметр кеш-бит для всего списка) асинхронно отсылается на нужный физ.сервер по сети, там и делается крупный запрос в БД и потом добавляются данные в кеш БД этого сервера, это конечно если запросили данные не из кеша, иначе сервер сразу отсылает нужные данные назад по сети (асинхронно, т.е. пока ждем ответ собираем новый список для этого физ.сервера), полученный второй прокси-функцией ответ из сети, парсится, помечается кеш-бит для каждого ключа в таблице (если на удаленном сервере данные были добавлены в кеш), и раздает ожидающим процессам по их номерам. Чем больше нагрузка тем эффективнее система. Также снижается нагрузка на сокеты и сетевой канал в распределенной системе.

я не разработчик, но в который раз убеждаюсь что возможно все, надо только дать волю фантазии)

 

[MiksIr]

вот, видите, стоит только поверить, покопать и оказывается что даже мои глупые фантазии уже кто то успешно реализовал))) MiksIr, спасибо за ссылка!

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

я не разработчик, но в который раз убеждаюсь что возможно все, надо только дать волю фантазии

Давать волю нужно рассудительности, математики, и опыту применимости тех или иных решений. Пока будут одни фантазии - будет одно недразумение. От того, что люди полетели в космос, по улицам города жители не стали передвигаться на ракетах. Мой вам совет - наймите человека, который не только фантазирует, но и умеет считать заранее получаемый выигрыш, стоимость внедрения, стоимость обслуживания. Хотя бы приблизительно. Думаю, тема закрыта, читать ваши фантазии не интересно.