Именно так и поступает сам MySQL.

Обычно используется то, что дешевле во внедрении и обслуживании. И чаще всего это железо

Какой движок БД используете?

Нету такого memcashed есть memcached и memcache Ставиться на сервер выделяеться оперативная память и в него ложаться sql запросы которые уже выполнялись по хеш ключу.
Снижает нагрузку таки раз в 15 если правильно использовать.

ну опечатался просто)

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

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

гы Ага, а наш мега-пхп-скрипт конечно с удовольствием будет щёлкать миллионы запросов в секунду

Кто вам вообще сказал что "склеенные" запросы будут выполняться быстрее?

Тут скорее нужно стремиться к тому, чтобы открывать небольшое количество постоянных подключений к СУБД и гонять запросы через них. С помощью php это сделать не выйдет (не говорите ничего про mysql_pconnect)..

Вообще чего вы к этому мемкэшу и mysql'ю привязались. Есть ведь redis, memcacheDB - их вполне можно юзать как быстрые постоянные хранилища.

во первых, что мне надо знать а чего не надо я решу сам.

во вторых, у павла дурова не сидит миллион человек, ибо он не владелец контакта.

в третьих facebook и многие другие крупные сайты написаны на php

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

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

а вообще решение найдено, даже несколько. всем спасибо за участие!

Поделиться не хотите?

Даже мои глупые фантазии уже реализовали, и склейку запросов тоже)

ГОТОВОЕ РЕШЕНИЕ - http://lib.custis.ru/%D0%A3%D0%B2%D0%B5%D0...B2,_ADD-2011%29

Фантазия всегда приводит к лучшим решениям! Даже если все вокруг считают ее бредом)))

Упрощенное теоретическое описание подобного решения NoSQL:

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

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