<HTML><BODY>Fri, 16 Jan 2015 05:09:45 +0400 от Alex Chistyakov <alexclear@gmail.com>:<br>
<blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_14213706110000000402_BODY">2015-01-16 3:47 GMT+03:00 <a href="/compose?To=Warstone@list.ru">Warstone@list.ru</a> <<a href="/compose?To=warstone@list.ru">warstone@list.ru</a>>:<br>
><br>
> Огласите весь список тех реляционных СУБД, которые могут.<br>
><br>
> Здравствуй добрый тролль<br><br>
Вечер в хату!<br><br>
><br>
> MySQL Cluster - это средство горизонтального масштабирования? Ооооокей.<br>
><br>
> Могу ошибаться. Для меня MySQL синоним каки.<br><br>
Ну а я больше люблю зеленый чай, чем черный.<br>
Такая у нас примерно будет техническая беседа.</div></div></div></div></blockquote>Вы модуль читали? (Из-за чего весь сыр-бор) Вы почитайте... А то вдруг я тут дурак полностью и он гениален.<br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_14213706110000000402_BODY">> Исторически. Его можно<br>
> использовать, но ты кровью расписываешься что ты понимаешь что делаешь.<br><br>
А PostgreSQL, стало быть, можно использовать, не понимая? Ну да,<br>
многие так и поступают.<br><br>
><br>
>> Для PostgreSQL - это PostgreSQL-XC,<br>
>> который появился очень недавно и пока страшновато его использовать. Для<br>
>> платных СУБД - это "много денег за то что вы это будете использовать".<br>
>> Отсюда - перенос бизнес логики в приложение разгружает СУБД<br>
><br>
> То есть, если мы перенесем в приложение ВСЮ бизнес-логику, СУБД работы<br>
> не останется?<br>
> O_O<br>
><br>
> Как из моего текста можно было сделать этот вывод, я не знаю. Или разницы<br>
> между "разгружает" и "не останется" нету?<br><br>
Мне, собственно, интересно, как можно вынести CPU-bound задачи с СУБД<br>
(которая у всех нормальных людей обычно IO-bound) и что-то на ней<br>
разгрузить. Я, правда, достаточно повидал CPU-bound архитектурных<br>
решений на реляционных СУБД, но там вынос логики в приложение ничего<br>
не изменил бы - там надо линейкой по рукам фигачить.</div></div></div></div></blockquote>Есть еще вариант с wait-bound... Я такое тоже видал. Это когда в PL/Perlu удаленный хост через LWP дергают.<br>Оно еще бывает Lock-Bound. Когда вы вроде-бы считаете не много, но за счет того, что в это время транзакция открыта - локи на таблицы висят красиво... Похлеще чем IDLE IN TRANSACTION, если вы понимаете...<br>Причем зачастую, это рождается так: Была хранимка, а вот тут кровь из носу нужны вон те данные. А переделывает не автор. И все... Пипец.<br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_14213706110000000402_BODY">Хотел бы я это увидеть!<br>
Впрочем, в MySQL - запросто, но мы договорились уже, что он кака (в<br>
том числе - потому что у него репликация CPU-bound при определенных<br>
условиях).<br>
Вообще, конечно, не имея синхронной репликации в кластере СУБД<br>
разносить хранимки по разным нодам - это чисто теоретическая идея. Я<br>
бы так делать не стал. С другой стороны - что такое можно делать в<br>
хранимках, чтобы задолбать ими весь процессор, я тоже не очень знаю.<br>
Конвертировать видео? Биткойны майнить?</div></div></div></div></blockquote>Выше частичный ответ. И да, давайте не о MySQL.<br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_14213706110000000402_BODY">> У него<br>
> это написано вот тут:<br>
> <a href="https://github.com/pef-secure/dbix-struct/blob/master/lib/DBIx/Struct.pm#L207" target="_blank">https://github.com/pef-secure/dbix-struct/blob/master/lib/DBIx/Struct.pm#L207</a><br>
> хотя у MySQL известно). При всем при этом стоимость масштабирования<br>
> приложения - +1 сервер. Посчитать можно спокойно... У вас было 3 сервера (1<br>
> под Приложение, 2 под СУБД (реплика)), стало 5, а вообще-то 6. А так стало 4<br>
> (2 под приложение, 2 под СУБД).<br>
> 2) Из здравого смысла. Если мы сместили боттлнек на приложение, то можно<br>
> спокойно добавить +1 сервер, а не +2,5 из текста выше.<br><br>
Боюсь, в тексте выше не использовалась строгая типизация - это вы там<br>
яблоки с совами сравнили.</div></div></div></div></blockquote>Это больше манагерский подход использовался "Сколько мне это будет в баксах / количествах серверов". Естественно дьявол - в деталях.<br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_14213706110000000402_BODY">> Причем в случае с<br>
> СУБД масштабированием у вас время нулевой транзакции увеличивается, то есть<br>
> сервер начинает отвечать чуть медленнее.<br>
><br>
> Было бы неплохо, если бы кто-нибудь внятно объяснил, наконец, почему.<br>
> Два утверждения "ORM - зло" и "мы не умеем им пользоваться" имеют<br>
> совершенно разный смысл, но часто - одинаковые последствия. Есть<br>
> случаи, когда ORM - безусловное зло, но это граничные случаи.<br>
> И, конечно, ORM большое зло, когда разработчики из-за предоставляемых<br>
> абстракций утрачивают связь с реальностью - ну да мы ж ведь с вами<br>
> профессионалы.<br>
><br>
> Потому что из 2го часто следует 1е.<br><br>
Если люди не умеют использовать ORM, они себе чем угодно башку отстрелят.<br>
Что и происходит сплошь и рядом.<br>
Утверждение "мы откажемся от ORM прямо на этапе проектирования и<br>
поэтому заживем" - лютая чушь.<br>
Некоторые ORM отлично заменяют горе-рукоделов, для того и придуманы.<br>
Впрочем, некоторых авторов ORM я бы тоже в печи сжигал (оценочное суждение).<br></div></div></div></div></blockquote>Вот тут я не могу не согласиться. ORM - зло, отсутствие ORM - тоже. Жизнь - боль. Голактека жестока... Впрочем это уже из другой оперы.<br>
<br></BODY></HTML>