<HTML><BODY><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_14213644020000000345_BODY">
Огласите весь список тех реляционных СУБД, которые могут.</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_14213644020000000345_BODY">MySQL Cluster - это средство горизонтального масштабирования? Ооооокей.</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_14213644020000000345_BODY">> Для PostgreSQL - это PostgreSQL-XC,<br>
> который появился очень недавно и пока страшновато его использовать. Для<br>
> платных СУБД - это "много денег за то что вы это будете использовать".<br>
> Отсюда - перенос бизнес логики в приложение разгружает СУБД<br><br>
То есть, если мы перенесем в приложение ВСЮ бизнес-логику, СУБД работы<br>
не останется?<br>
O_O</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_14213644020000000345_BODY">Очень интересно.<br>
То есть: была у нас CPU-bound задача на СУБД (на СУБД!!!), мы<br>
перенесли ее на приложение, после чего уже на других нагрузках<br>
боттлнек у нас опять будет в СУБД. Вопрос номер один: а чего ж мы<br>
просто не взяли, я не знаю, master-slave репликацию? CPU-bound<br>
приложения легко масштабируются на любом конце многозвенной<br>
архитектуры. Вопрос номер два: а почему следующий боттлнек наступит на<br>
других нагрузках, а не на этих же? Нет никаких оснований так полагать.</div></div></div></div></blockquote>1) И что вам даст эта репликация?.. Данные в одном месте, а CPU баунд может получиться при записи. Тогда уже PostgreSQL-XC, со всеми его приколами, типа 2х фазного коммита и умножения количества серверов на 2,5 при адекатном развертывании (Мы тут сейчас считаем что кроме PostgreSQL СУБД нету. У него это написано вот тут: <a href="https://github.com/pef-secure/dbix-struct/blob/master/lib/DBIx/Struct.pm#L207" data-mce-href="https://github.com/pef-secure/dbix-struct/blob/master/lib/DBIx/Struct.pm#L207">https://github.com/pef-secure/dbix-struct/blob/master/lib/DBIx/Struct.pm#L207</a> хотя у MySQL известно). При всем при этом стоимость масштабирования приложения - +1 сервер. Посчитать можно спокойно... У вас было 3 сервера (1 под Приложение, 2 под СУБД (реплика)), стало 5, а вообще-то 6. А так стало 4 (2 под приложение, 2 под СУБД).<br>2) Из здравого смысла. Если мы сместили боттлнек на приложение, то можно спокойно добавить +1 сервер, а не +2,5 из текста выше. Причем в случае с СУБД масштабированием у вас время нулевой транзакции увеличивается, то есть сервер начинает отвечать чуть медленнее.<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_14213644020000000345_BODY"> Было бы неплохо, если бы кто-нибудь внятно объяснил, наконец, почему.<br> Два утверждения "ORM - зло" и "мы не умеем им пользоваться" имеют<br> совершенно разный смысл, но часто - одинаковые последствия. Есть<br> случаи, когда ORM - безусловное зло, но это граничные случаи.<br> И, конечно, ORM большое зло, когда разработчики из-за предоставляемых<br> абстракций утрачивают связь с реальностью - ну да мы ж ведь с вами профессионалы.<br></div></div></div></div></blockquote>Потому что из 2го часто следует 1е. Однако согласитесь, что 1го это не отменяет в ряде задач.<br><br></BODY></HTML>