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

[Alex Chistyakov]

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 архитектурных
решений на реляционных СУБД, но там вынос логики в приложение ничего
не изменил бы - там надо линейкой по рукам фигачить.

>
> Очень интересно.
> То есть: была у нас CPU-bound задача на СУБД (на СУБД!!!), мы
> перенесли ее на приложение, после чего уже на других нагрузках
> боттлнек у нас опять будет в СУБД. Вопрос номер один: а чего ж мы
> просто не взяли, я не знаю, master-slave репликацию? CPU-bound
> приложения легко масштабируются на любом конце многозвенной
> архитектуры. Вопрос номер два: а почему следующий боттлнек наступит на
> других нагрузках, а не на этих же? Нет никаких оснований так полагать.
>
> 1) И что вам даст эта репликация?.. Данные в одном месте, а CPU баунд может
> получиться при записи.

Хотел бы я это увидеть!
Впрочем, в MySQL - запросто, но мы договорились уже, что он кака (в
том числе - потому что у него репликация CPU-bound при определенных
условиях).
Вообще, конечно, не имея синхронной репликации в кластере СУБД
разносить хранимки по разным нодам - это чисто теоретическая идея. Я
бы так делать не стал. С другой стороны - что такое можно делать в
хранимках, чтобы задолбать ими весь процессор, я тоже не очень знаю.
Конвертировать видео? Биткойны майнить?

> Тогда уже PostgreSQL-XC, со всеми его приколами, типа
> 2х фазного коммита и умножения количества серверов на 2,5 при адекатном
> развертывании (Мы тут сейчас считаем что кроме PostgreSQL СУБД нету.

Приколы PostgreSQL-XC связаны с тем, что там синхронная репликация еще
и с масштабированием записи.
До масштабирования записи мы пока не добрались, у нас CPU-bound
задача, синхронностью репликации предлагаю тоже пренебречь.

> У него
> это написано вот тут:
> 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 я бы тоже в печи сжигал (оценочное суждение).

--
SY,
Alex


> Однако согласитесь, что 1го это не
> отменяет в ряде задач.
>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>