|
|
Задавайте вопросы, мы ответим
Вы не зашли.
Есть ли возможность одновременно выслать запросы на разные MySQL, да так, что бы второй, не ждал пока придёт ответ от первого?
Неактивен
Такой возможности в php нет. Есть варианты обойти это, но они не идеальные
а) использовать fork http://php.net/manual/ru/function.pcntl-fork.php
b) использовать EVENTS для того, чтобы реальная работа выполнялась не запросом, а отложенно
Неактивен
А что думаете по поводу такого метода?
http://www.php.net/manual/en/mysqli.poll.php
Я немного запуталась во всех этих примерах, никак не могу разобраться (
Неактивен
Проблема тут не в MySQL, проблема тут в идеологии. Представьте, что Вы —
бригадир на стройке. У Вас есть рабочий, которого можно послать таскать
кирпичи, а можно послать таскать цемент. Вы хотите послать этого рабочего
таскать кирпичи, а пока он бегает за кирпичами послать независимо таскать
цемент. Один рабочий с такой задачей справиться не может — Вам нужно
два рабочих.
Теперь применим эту аналогию к базе. Кирпичи и цемент — это Ваши под-
ключения. Они оба доступны. Но рабочий у Вас один — это поток исполнения
в PHP. Решение rgbeast как раз клонирует поток исполнения. Судя по резуль-
татам выдачи поисковиков, это чуть ли не единственное решение (можно
еще выполнить независимый сценарий через CLI, но это тот же fork, только
еще менее контролируемый).
Неактивен
Чаще такое используют когда нужно осуществлять параллельные записи в DB.
С чтением это сложнее. И в практике такое очень редко надо ... Вы уверены что это то что вам нужно ?
Какие способы вообще есть ?
Конкретное решение на вашу задачу даёт Sphinx http://habrahabr.ru/blogs/sphinx/64318/
Открывать асинхронные процессы в php можно с помощью CURL
Возможно для асинхронной работы вам понадобится дополнительно объявлять в запускаемых скриптах
http://www.php.net/manual/en/function.i … -abort.php
Отредактированно evgeny (04.09.2011 11:44:15)
Неактивен
Уверена, нужно.
Спасибо за ссылку, сейчас буду изучать
Неактивен
Вот вам работающий пример с использованием CURL.
Неактивен
А разве он не ждёт каждого из них по отдельности?
Неактивен
Скажите честно, а что Вы такое пишете, что понадобились потоки PHP?
Неактивен
Ну вы же помните, вы мне помогали с базами, всё тоже самое пишу, горизонтальное масштабирование, разнести, разнесла, теперь нужен скрипт, что будет собирать нужные данные воедино )
Неактивен
Сейчас конечно всё на одной машине, но потом по проекту, сервера могут находится в разных уголках планеты, допустим случится так, что надо будет для выдачи результата опросить 5 серверов с разных концов, каждый запрос это одна только транспортировка в полсекунды + обработка, уже почти секунда. Если идти стандартно, то уйдёт 5 секунд, только на запрос информации, а надо будет её ещё переработать и дальше послать. А так если можно было бы отсылать запросы параллельно не дожидаясь ответа предыдущего, то затрата времени относительного первого варианта выигрывались в геометрической прогрессии 
Неактивен
animegirl написал:
А разве он не ждёт каждого из них по отдельности?
Нет.
Они работают асинхроно (параллельно)
Неактивен
animegirl написал:
Сейчас конечно всё на одной машине, но потом по проекту, сервера могут находится в разных уголках планеты, допустим случится так, что надо будет для выдачи результата опросить 5 серверов с разных концов, каждый запрос это одна только транспортировка в полсекунды + обработка, уже почти секунда. Если идти стандартно, то уйдёт 5 секунд, только на запрос информации, а надо будет её ещё переработать и дальше послать. А так если можно было бы отсылать запросы параллельно не дожидаясь ответа предыдущего, то затрата времени относительного первого варианта выигрывались в геометрической прогрессии
Опишите ваш проект. Скорее всего вы не туда роете.
Возможно правельней будет поменять структуру базы, или создать денормализацию асинхроно сливая в центральную базу или вообще использовать FEDERATED TABLES
Неактивен
В деталях не имею права, структурой тоже занималась не я, архитектура продумана так, что бы при увеличение количества записей, базы можно было дробить горизонтально по меткам.
Схема выглядит примерно так:
Первый домен
3* Апп сервера
Апп сервера принимают данные, и ответственные за их обработку, они видят базу данных как одно большое целое, отправляя запрос на второй домен
Второй домен
3* сервера, имеют на своих машинах каталог, где указано на каком сервере ДБ находится та или иная информация. Принимают запросы от Апп серверов, собирают информацию по базам, отрезают излишки, отдают готовое на Апп сервер.
ДБ* сервера
Разделены по направлениям под различные сервисы, если информация одной таблицы превышает допустимого значения (время затрачиваемое на поиск), база делится по меткам, и разносится на разные сервера
* - Все сервера запланированные таким образом, что увеличение их количества, должно прямо пропорционально увеличить мощность всей системы.
Неактивен
Забегу наперёд, пока не начали советовать
Идея репликации ДБ серверов отклонены, так как подключение новых серверов в группу не даёт 100% прирост мощностей, и чем больше будет в группе, тем меньше будет пользы от дальнейшего увеличения
Идея наращивания мощности отдельного сервера, отклонены по коммерческим соображениям.
Неактивен
Самым необоснованным, кажется, является написание приложения на PHP.
Это язык для написания страничек, а не полноценных приложений. Но если
этот язык тоже навязан снаружи, то годится обсуждение из параллельного
треда
Неактивен
В общем ваша структура довольно стандартная, полная расширяемость = шардинг + репликация.
сервера могут находится в разных уголках планеты
По описной выше структуре такое делать нет никакого смысла, то есть сервера нужно наоборот держать друг к другу максимально близко.
И от сюда следует что обращение сразу к нескольким базам должно работать быстро.
Но в общем это нужно крайне избегать, так как это ломает всю идеологию вашей структуры.
Обычно в таких случаях создаётся центральная база в которую асинхронно сливаются специально сформированные данные с ваших шардов (денормализация)
И в дальнейшем ваши запросы идут напрямую в центральную базу. Расширятся центральная база обычной репликацией.
Если обращения сразу к несколько шардам будет довольно редко, то можно не замарачиваться с денормализацией и действительно обращаться сразу ко всем, открывая несколько потоков.
Неактивен
paulus написал:
Самым необоснованным, кажется, является написание приложения на PHP.
Это язык для написания страничек, а не полноценных приложений. Но если
этот язык тоже навязан снаружи, то годится обсуждение из параллельного
треда
В этом я с вами абсолютно не согласен.
PHP это сильный, объектно ориентированный язык программирования, предназначенный для разработки полноценных web приложений.
Именно в web приложениях другие языки особо не обходят PHP, имея также свои сложности и косяки.
Неактивен
ПХП был выбран насколько я знаю теми же архитекторами, но по спецификации, программируем так, что бы можно было любой узел перенести на другую языковую платформу и пустить параллельно. Но на данный момент главное - скорость разработки, когда будет основное, то часть команды переключится на оптимизацию.
Географический разнос серверов запланирован на более позднию стадию, так как главный метки по разбивки данных будут географическое место расположение, и по моделе, выйдет так, что 80% запросов будет затрагивать ту область, где пользователь находится, тем самым разнос серверов, уменьшат время передачи данных.
Центральная база если и будет, то по некоторым определённым, не релевантным для общей работы, данным. Проект будет состоять из набора подключаемых модулей, запланировано так, что бы при вылете одного из модулей, остальные работали штатно, при вылете главного домена, модули можно было открывать с их личных доменов, и работать как не в чём не бывало
Запросы к нескольким серверам будут, причём чем больше будет информации, тем больше её будем делить, и тем больше будет шардов, так что это смоделировано заранее
Неактивен
Географический разнос серверов запланирован на более позднию стадию, так как главный метки по разбивки данных будут географическое место расположение, и по моделе, выйдет так, что 80% запросов будет затрагивать ту область, где пользователь находится, тем самым разнос серверов, уменьшат время передачи данных.
Лет 10 назад это могло бы быть эффективно, но с сегодняшней скоростью сети, месторасположение сервера практически не играет значение.
Географически распределяются только прокси сервера с кешем тяжелого трафика как фото или видео.
Ну в общем я так понял от вас мало что зависит, вас поставили перед действительностью с которой надо работать
Надеюсь вы получили ответы на ваши вопросы ...
Неактивен
Да почти, сейчас надо разобраться с federated и понять нужны ли вообще сервера Б, ведь основные действия на них происходить не будут, потому их задачу можно будет спокойно перенести на сервера А
Ну попробуйте взять прокси Бразилии и пропинговать японские сервера, потом умножаем количество соединений, и их частоту, так как аякс при малейшем изменение, будет запрашивать новые данные.
Неактивен
По поводу скорости разработки — возьмите какой-то высокоуровневый язык типа ruby,
(да, я имею в виду rails) — разработка станет быстрее, чем на php
Пинги обычно не так важны, как скорость передачи информации, которая у нас высокая
по всему миру. А скорость ответа Вам снизят обычные реплики на близкорасположенных
серверах.
Неактивен
Ну попробуйте взять прокси Бразилии и пропинговать японские сервера
А зачем ?
Международные проекты располагаются на американских или европейских дата центрах с хорошими выходами, с короткими трейсами, вот вам и быстрый доступ с любого конца света.
Попробуйте попингуйте google или facebook все сервера в Америке, и нигде проблем с гуглом нет, не в Японии не в Бразилии ...
Неактивен
paulus написал:
По поводу скорости разработки — возьмите какой-то высокоуровневый язык типа ruby,
(да, я имею в виду rails) — разработка станет быстрее, чем на php
Ну это бесконечная тема ... Так можно везде плюсы и минусы найти ...
Если на PHP писать используя фреймворки и готовые решения, и при этом очень хорошо это уметь делать, то разница в скорости уже будет зависеть не от языка.
Неактивен
Язык неизбежно накладывает свою идеологию на стиль программирования.
Можно писать на python так же, как на php, но это будет неэффективно (как
по времени программирования, так и по времени исполнения полученного
кода). Какой бы ни был фреймворк — он останется на PHP, и Вы будете вынуж-
дены думать в терминах PHP.
Я не призываю менять язык прямо здесь и сейчас. Просто существуют куда
более высокоуровневые языки, которые позволяют делать всё быстрее.
Тот же VisualBasic, например 
Неактивен
