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

[Warstone@list.ru]

 Fri, 16 Jan 2015 05:09:45 +0400 от Alex Chistyakov <alexclear на gmail.com>:
>2015-01-16 3:47 GMT+03:00  Warstone на list.ru < warstone на list.ru >:
>>
>> Огласите весь список тех реляционных СУБД, которые могут.
>>
>> Здравствуй добрый тролль
>
>Вечер в хату!
>
>>
>> MySQL Cluster - это средство горизонтального масштабирования? Ооооокей.
>>
>> Могу ошибаться. Для меня MySQL синоним каки.
>
>Ну а я больше люблю зеленый чай, чем черный.
>Такая у нас примерно будет техническая беседа. Вы модуль читали? (Из-за чего весь сыр-бор) Вы почитайте... А то вдруг я тут дурак полностью и он гениален.
>> Исторически. Его можно
>> использовать, но ты кровью расписываешься что ты понимаешь что делаешь.
>
>А PostgreSQL, стало быть, можно использовать, не понимая? Ну да,
>многие так и поступают.
>
>>
>>> Для PostgreSQL - это PostgreSQL-XC,
>>> который появился очень недавно и пока страшновато его использовать. Для
>>> платных СУБД - это "много денег за то что вы это будете использовать".
>>> Отсюда - перенос бизнес логики в приложение разгружает СУБД
>>
>> То есть, если мы перенесем в приложение ВСЮ бизнес-логику, СУБД работы
>> не останется?
>> O_O
>>
>> Как из моего текста можно было сделать этот вывод, я не знаю. Или разницы
>> между "разгружает" и "не останется" нету?
>
>Мне, собственно, интересно, как можно вынести CPU-bound задачи с СУБД
>(которая у всех нормальных людей обычно IO-bound) и что-то на ней
>разгрузить. Я, правда, достаточно повидал CPU-bound архитектурных
>решений на реляционных СУБД, но там вынос логики в приложение ничего
>не изменил бы - там надо линейкой по рукам фигачить. Есть еще вариант с wait-bound... Я такое тоже видал. Это когда в PL/Perlu удаленный хост через LWP дергают.
Оно еще бывает Lock-Bound. Когда вы вроде-бы считаете не много, но за счет того, что в это время транзакция открыта - локи на таблицы висят красиво... Похлеще чем IDLE IN TRANSACTION, если вы понимаете...
Причем зачастую, это рождается так: Была хранимка, а вот тут кровь из носу нужны вон те данные. А переделывает не автор. И все... Пипец.
>Хотел бы я это увидеть!
>Впрочем, в MySQL - запросто, но мы договорились уже, что он кака (в
>том числе - потому что у него репликация CPU-bound при определенных
>условиях).
>Вообще, конечно, не имея синхронной репликации в кластере СУБД
>разносить хранимки по разным нодам - это чисто теоретическая идея. Я
>бы так делать не стал. С другой стороны - что такое можно делать в
>хранимках, чтобы задолбать ими весь процессор, я тоже не очень знаю.
>Конвертировать видео? Биткойны майнить? Выше частичный ответ. И да, давайте не о MySQL.
>> У него
>> это написано вот тут:
>>  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е.
>
>Если люди не умеют использовать ORM, они себе чем угодно башку отстрелят.
>Что и происходит сплошь и рядом.
>Утверждение "мы откажемся от ORM прямо на этапе проектирования и
>поэтому заживем" - лютая чушь.
>Некоторые ORM отлично заменяют горе-рукоделов, для того и придуманы.
>Впрочем, некоторых авторов ORM я бы тоже в печи сжигал (оценочное суждение).
Вот тут я не могу не согласиться. ORM - зло, отсутствие ORM - тоже. Жизнь - боль. Голактека жестока... Впрочем это уже из другой оперы.

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