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 синоним каки. > >Ну а я больше люблю зеленый чай, чем черный. >Такая у нас примерно будет техническая беседа. Вы модуль читали? (Из-за чего >весь сыр-бор) Вы почитайте... А то вдруг я тут дурак полностью и он гениален. >> Исторически. Его можно >> использовать, но ты кровью расписываешься что ты понимаешь что делаешь. > >А 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
