Коллеги, положим есть приложение. Веб сервис с базой. Задача такая, что нужно смасштабировать его на два ЦОД. Как такое делается? Ведь латенси между ЦОД большой и по тупому сделать репликацию между базами не выйдет. Тогда как?

Здравствуйте, Gattaka, Вы писали:

G>Коллеги, положим есть приложение. Веб сервис с базой. Задача такая, что нужно смасштабировать его на два ЦОД. Как такое делается? Ведь латенси между ЦОД большой и по тупому сделать репликацию между базами не выйдет. Тогда как?
Шардинг? Горизонтальный Вертикальный

Здравствуйте, Gattaka, Вы писали:

G>Коллеги, положим есть приложение. Веб сервис с базой. Задача такая, что нужно смасштабировать его на два ЦОД. Как такое делается? Ведь латенси между ЦОД большой и по тупому сделать репликацию между базами не выйдет. Тогда как?

делайте асинхронную двухстороннюю репликацию.

Здравствуйте, Gattaka, Вы писали:

G>Коллеги, положим есть приложение. Веб сервис с базой. Задача такая, что нужно смасштабировать его на два ЦОД. Как такое делается? Ведь латенси между ЦОД большой и по тупому сделать репликацию между базами не выйдет. Тогда как?
Это зависит от того, какие цели стоят для распределенного деплоймента. Ну и хорошо бы сначала померять, насколько большая лейтенси, может она и не такая и большая.

Здравствуйте, Gattaka, Вы писали:

G>Коллеги, положим есть приложение. Веб сервис с базой. Задача такая, что нужно смасштабировать его на два ЦОД. Как такое делается? Ведь латенси между ЦОД большой и по тупому сделать репликацию между базами не выйдет. Тогда как?

Можно взять БД которая умеет географическое распределение изначально: Cassandra, Google Spanner etc.

Здравствуйте, Gattaka, Вы писали:

G>Коллеги, положим есть приложение. Веб сервис с базой. Задача такая, что нужно смасштабировать его на два ЦОД. Как такое делается? Ведь латенси между ЦОД большой и по тупому сделать репликацию между базами не выйдет. Тогда как?

Прежде чем, что-то масштабировать, нужно понять, что же тормозит: сам сервис или бд?
Если тормоза в бд, то профильнуть запросы. Шардирование бд — это когда у вас объем данных как у ФБ. Но я видел когда в таблице порядка 100К записей и в запросах были тормоза, в этом случае ни какое шардирование не поможет.
В бд провести денормализацию данных, заюзать Materialized Views, если не поможет, то кешировать результаты выполнения тяжеловесных запросов. В общем, шардирование бд — это реально последнее, что нужно делать.

Если торомза в сервисе, то посмотреть какая часть сервиса тормозит. Если сервис монолитный, то превратить его в набор микросервисов и тормозящие микросервисы горизонтально масштабировать.
Если же и так микросервисная архитектура, то все проще

А что за СУБД и на чем написан сервис?

Здравствуйте, white_znake, Вы писали:

_>Если тормоза в бд, то профильнуть запросы. Шардирование бд — это когда у вас объем данных как у ФБ. Но я видел когда в таблице порядка 100К записей и в запросах были тормоза, в этом случае ни какое шардирование не поможет.
_>В бд провести денормализацию данных, заюзать Materialized Views, если не поможет, то кешировать результаты выполнения тяжеловесных запросов. В общем, шардирование бд — это реально последнее, что нужно делать.

Это сильно зависит от нагрузки. Если данных относительно немного, но постоянная нагрузка и на чтение и на запись — то ни денормализация, ни кеширование не помогут.

Здравствуйте, itslave, Вы писали:

I>Это сильно зависит от нагрузки. Если данных относительно немного, но постоянная нагрузка и на чтение и на запись — то ни денормализация, ни кеширование не помогут.

Денормализация не зависит от объема данных вообще. Как пример: у тебя есть чаты, и тебе нужно для каждого пользователя хранить кол-во непрочитанных сообщений, вместо нормализации и подсчета кол-ва непрочитанных сообщений, можешь хранить кол-во непрочитанных сообщений.

Обычно больше read запросов (80%), чем write (20%), поэтому кеширование может зайти хорошо (но как всегда, есть проблема с инвалидацией кэша, поэтому его использовать, когда оптимизация запросов не помогла). Но тут опять же, не зная предметной области ни чем не поможешь. Может у него реально модель где 80% write операций, а 20% read.

Тут просто ТС хочет шардирование для бд, мне кажется, что у него нет столько данных, что бы нормальная бд: Postgre, Oracle или даже MS SQL — не справелись бы. Скорее всего проблема с оптимизацией.

Здравствуйте, white_znake, Вы писали:

_>Денормализация не зависит от объема данных вообще. Как пример: у тебя есть чаты, и тебе нужно для каждого пользователя хранить кол-во непрочитанных сообщений, вместо нормализации и подсчета кол-ва непрочитанных сообщений, можешь хранить кол-во непрочитанных сообщений.
Я в курсе, просто это не всегда помогает.

_>Обычно больше read запросов (80%), чем write (20%), поэтому кеширование может зайти хорошо (но как всегда, есть проблема с инвалидацией кэша, поэтому его использовать, когда оптимизация запросов не помогла). Но тут опять же, не зная предметной области ни чем не поможешь. Может у него реально модель где 80% write операций, а 20% read.
Отош
_>Тут просто ТС хочет шардирование для бд, мне кажется, что у него нет столько данных, что бы нормальная бд: Postgre, Oracle или даже MS SQL — не справелись бы. Скорее всего проблема с оптимизацией.
У меня украли миелофон и телепаты ушли в отпуск.

Здравствуйте, Gattaka, Вы писали:

G>Коллеги, положим есть приложение. Веб сервис с базой. Задача такая, что нужно смасштабировать его на два ЦОД. Как такое делается? Ведь латенси между ЦОД большой и по тупому сделать репликацию между базами не выйдет. Тогда как?

С чего это не выйдет? Репликация асинхронная конечно нужна, ну и приложения надо писать так чтобы особенности этого учитывались.
Почитай вообще книжку Designing Data-Intensive Applications, ну или русский перевод тут (хотя в отзывах пишут что фигово перевели — "Высоконагруженные приложения. Программирование, масштабирование, поддержка" Мартина Клепмана) — там обсуждается вопрос репликации между дата центрами довольно подробно.

Здравствуйте, itslave, Вы писали:

I>Здравствуйте, white_znake, Вы писали:

_>>Если тормоза в бд, то профильнуть запросы. Шардирование бд — это когда у вас объем данных как у ФБ. Но я видел когда в таблице порядка 100К записей и в запросах были тормоза, в этом случае ни какое шардирование не поможет.
_>>В бд провести денормализацию данных, заюзать Materialized Views, если не поможет, то кешировать результаты выполнения тяжеловесных запросов. В общем, шардирование бд — это реально последнее, что нужно делать.

I>Это сильно зависит от нагрузки. Если данных относительно немного, но постоянная нагрузка и на чтение и на запись — то ни денормализация, ни кеширование не помогут.

Репликация спасет, но пострадает доступность (availability). По условиям CAP теоремы что-то должно пострадать в любом случае, или consistency или availability.