резнесение базы на несколько серверов

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

Ну конечно же не на php это пишут, это было бы так же смешно если бы oc на php бы кто писал))
Много на чем пишут и на с и на плюсах, бывает и на erlang.

Ну тут можно частично согласиться,
есть nosql которые тупо работают по key/value но есть и исключения,
такие как redis там 5 структур данных,
mongodb - там уже можно норм запросы делать, json документы вполне неплохая вещь...
А насчет сложных запросов, так вот если подумать то именно от них проблемы с производительностью и расширяемостью, да и в большинстве приложений сложные запросы и не нужны...

-----
Так было, так есть и так будет

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

преглашаю всех в раздача статики

и как тебе поможет репликация?
определись о чем твои фантазии - о разнесении нагрузки или чем то еще

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

да как обычно, запросы на чтение распределяем на несколько физических мест

Вопрос надуманный. Не представляю о системе каких масштабов и задач должна идти речь, чтобы начинать думать о нескольких серверах БД под одну систему. У нас крутится портал с десятком тематических поддоменов 50000-90000 хостов в сутки на одной железяке HP вместе с 10 базами.
А думать, в случае реальной необходимости, придется не о костылях и репликациях под мускул, а о серьёзных интегрированных в СУБД решениях. Мускул под эти задачи не подходит.

(Отредактировано автором: 25 Февраля, 2013 - 12:59:27)

если б это было первым ответом по теме, вопрос снялся бы гораздо раньше.

ну тогда уже причисли и MAX(), SUM(), и вообще все функции - ИМХО это уже паранойя, тригерры я тоже никогда не делаю, в остальном пользуюсь и мне это не мешает, и не думаю что это дает нагрузку чтобы бить в колокала - экономия на спичках. НЕправильно составленный запрос и отказ от выше перечисленного тебя не спасет.

-----
То что программа работает, не означает что она написана правильно!

Stierus привел это в качестве примера. Это вовсе не означает абсолютное отрицание встроенных функций СУБД.
А вот думать или не думать о том, стоит-ли "бить в колокола" не нужно. Для этого есть тестирование, которое покажет все узкие места.
Хороший стиль, когда СУБД отдается статикой, то что ей можно отдать статикой не перенося на СУБД логику приложения (по понятным причинам. И дело не только в нагрузке). Очень часто сначала пишется запрос, к примеру с NOW().
Потом принимается решение выполнять в цикле, забыв об оптимизации (как обычно и происходит), и вот, - вы уже 50 раз заставляете СУБД "считать" время.

(Отредактировано автором: 25 Февраля, 2013 - 13:26:18)

еще раз - каким боком тут репликация?

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

caballero, если есть что конкретно возразить, то не надо пытаться из меня непонятно что вытянуть
я с этим делом знаком очень поверхностно

возразить на что?


тогда с чего ты решил что то "дело" тебе необходимо если не имеешь понятия о чем говоришь?

если у тебя будет настолько масштабный проект что понадобится кластер серверов БД то у тебя будет более чем достаточно денег нанять профи-админов которые решат эти проблеммы и купить Oracle Real Application Clusters или типа того .

Никто в здравом уме не берет PHP/Mysql и не пытается это масштабировать и строить распределенные приложения.

(Отредактировано автором: 25 Февраля, 2013 - 14:38:39)

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

KingStar, отказ от now(), MAX(), SUM() и тд В АПДЕЙТАХ не из-за нагрузки на сервера, а из-за неконсистентности данных на разных нодах, к которым они могут привести, нагрузки они не дают Триггеры - та же песня, у вас будет огромный геморой при необходимости шардировать данные, если будут триггеры. Шардировать данные можно по-разному, у нас система решает, к какой ноде направить зпрос, решается исходя из праймари ключа (имя ноды находится по функции от праймари ключа), который мы ищем, для этого не требуется делать доп. запросы к внешней системе за инфой, на какой ноде лежат данные.

Все комментарии типа "какой идиот пишет высокопроизводительные системы на php" и "кому это надо, если есть оракл и ibm" говорят лишь о абсолютной некомпетенции высказывающегося в теме.

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

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

caballero, я не хочу разводить демагогию на эту тему, но незнание, неумение и нежелание - три разные вещи

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