2015-01-16 4:30 GMT+03:00 [email protected] <[email protected]>: > Fri, 16 Jan 2015 05:09:45 +0400 от Alex Chistyakov <[email protected]>: > > 2015-01-16 3:47 GMT+03:00 [email protected] <[email protected]>: >> >> Огласите весь список тех реляционных СУБД, которые могут. >> >> Здравствуй добрый тролль > > Вечер в хату! > >> >> MySQL Cluster - это средство горизонтального масштабирования? Ооооокей. >> >> Могу ошибаться. Для меня MySQL синоним каки. > > Ну а я больше люблю зеленый чай, чем черный. > Такая у нас примерно будет техническая беседа. > > Вы модуль читали? (Из-за чего весь сыр-бор) Вы почитайте... А то вдруг я тут > дурак полностью и он гениален.
Похоже на то, что он и правда гениален. Я почитал синопсис и тест и остался в тяжком недоумении. Как мне вытащить структуру объектов (то, что в старом добром SQL называется JOIN)? Где lazy loading? Где двухуровневый кэш? Где генерация структуры таблиц по метаописанию на XML? Нет, это не тот ORM, к которому я привык. Фиг бы с ним, с XML - но зачем нужен конструктор запросов к единственной таблице? Идти читать сам код я теперь немного боюсь - при таком радикальном подходе к постановке задачи, кто его знает, что ждет в реализации... -- SY, Alex > >> Исторически. Его можно >> использовать, но ты кровью расписываешься что ты понимаешь что делаешь. > > А 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 - тоже. Жизнь - > боль. Голактека жестока... Впрочем это уже из другой оперы. > > > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org > -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
