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 архитектурных решений на реляционных СУБД, но там вынос логики в приложение ничего не изменил бы - там надо линейкой по рукам фигачить. > > Очень интересно. > То есть: была у нас 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 > [email protected] | http://moscow.pm.org > -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
