Comments 4
Поясните, пожалуйста, зачем держать базу данных через LoadBalancer? Драйвера многих баз данных сами знают на какие шарды идти, а здесь получается распределение нагрузки через одну точку, где на самом деле приложения должны идти напрямую и дергать нужные данные.
Речь в приведенной архитектуре идет о группе виртуалок с некоторым количеством баз данных, в том числе распределенных по различным локациям. Internal Load Balancer позволяет удобным способом оптимизировать процесс обращения к backend-у и обеспечить отказоустойчивость системы очевидным и человеколюбивым образом.
Я впервые услышал о способностях серверов БД распределять запросы между различными базами данных. Но, по слухам, балансировка запросов в подобных инфраструктурах — задача нетривиальная, не имеющая единого решения и требующая серьезных кастомизаций. Load Balancer — серьезное обезболивающее.
Я впервые услышал о способностях серверов БД распределять запросы между различными базами данных. Но, по слухам, балансировка запросов в подобных инфраструктурах — задача нетривиальная, не имеющая единого решения и требующая серьезных кастомизаций. Load Balancer — серьезное обезболивающее.
Ниже hodzanassredin привел пример, это то о чем я говорил. Тоже самое и в MongoDB. Да и в целом логично, что для разных шардов нужно сразу идти на шард, а не гулять по всяким промежуточным нодам. Никакой кастомизаций серъезных не требуется, и решение одно — на уровне драйвера базы данных. Иначе вообще, тогда теряется смысл ключей шардирования.
Да это частая ошибка. Например в туториалах по кассандре предлагают ставить лоад балансер blog.z-proj.com/setting-up-a-cassandra-cluster-on-azure. Хотя в манах четко указано что не надо blog.tomas.cat/en/2013/05/13/cassandra-frequent-mistakes.
Sign up to leave a comment.
Различия Azure Resource Manager и Azure Service Manager — взгляд разработчика, часть вторая, про Networking