[Moscow.pm] v2 просьба о ревью модуля DBIx::Struct

[Warstone@list.ru]

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

----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150116/d2358aea/attachment.html>