>Огласите весь список тех реляционных СУБД, которые могут. Здравствуй добрый >тролль >MySQL Cluster - это средство горизонтального масштабирования? Ооооокей. Могу >ошибаться. Для меня MySQL синоним каки. Исторически. Его можно использовать, >но ты кровью расписываешься что ты понимаешь что делаешь. >> Для PostgreSQL - это PostgreSQL-XC, >> который появился очень недавно и пока страшновато его использовать. Для >> платных СУБД - это "много денег за то что вы это будете использовать". >> Отсюда - перенос бизнес логики в приложение разгружает СУБД > >То есть, если мы перенесем в приложение ВСЮ бизнес-логику, СУБД работы >не останется? >O_O Как из моего текста можно было сделать этот вывод, я не знаю. Или разницы >между "разгружает" и "не останется" нету? >Очень интересно. >То есть: была у нас CPU-bound задача на СУБД (на СУБД!!!), мы >перенесли ее на приложение, после чего уже на других нагрузках >боттлнек у нас опять будет в СУБД. Вопрос номер один: а чего ж мы >просто не взяли, я не знаю, master-slave репликацию? CPU-bound >приложения легко масштабируются на любом конце многозвенной >архитектуры. Вопрос номер два: а почему следующий боттлнек наступит на >других нагрузках, а не на этих же? Нет никаких оснований так полагать. 1) И >что вам даст эта репликация?.. Данные в одном месте, а CPU баунд может >получиться при записи. Тогда уже PostgreSQL-XC, со всеми его приколами, типа >2х фазного коммита и умножения количества серверов на 2,5 при адекатном >развертывании (Мы тут сейчас считаем что кроме PostgreSQL СУБД нету. У него >это написано вот тут: >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е. Однако согласитесь, что 1го это не отменяет в ряде задач.
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
