Comments 7
Вы совершенно забыли о такой вещи как РЕПЛИКАЦИЯ. Эта технология определенно поможет Вам решить часть перечисленных проблем: https://www.mydbops.com/blog/postgresql-replication. Технология (репликации) также поддерживается MySQL/MariaDB.
Существуют классы задач, где этого принципиально недостаточно — например, когда требуется трансформация схемы, агрегация, фильтрация или смена модели данных при передаче.
Стандартные механизмы репликации (и даже большинство доступных open-source-решений) не поддерживают репликацию с преобразованием структуры и типов данных, поскольку они ориентированы на побитовую или логическую идентичность.
Поэтому утверждение о «решении проблемы репликацией» справедливо только в теории, без учёта практических ограничений и сценариев, где между системами происходит не зеркалирование, а осмысленное преобразование данных.
Спасибо за статью, хорошо собрали все связанные проблемы вместе. Вступление возможно стоит поправить, из него вообще не понятно что речь идёт о разнесении таблиц по разным базам - после прочтения вступления и первой секции возникла мысль написать "автор, ты чо, реально про нормальные формы не слышал?"
Вертикальное шардирование
Автор сам термин придумал или тащит это из 1С?
Это все, в IT за пределами 1С, называется микросервисная архитектура - разбивание одной базы на несколько для шардирования систем, в отличие от шардирования таблички в одной базе.
Статья полезная, но выглядит, как тезисы доклада, а не статья. Собрано все в кучу, часто без примеров и анализа.
Вот например:
Минусы (ХА/2РС):
Очень медленно. Протокол очень болтливый и требует блокировок, что убивает производительность.
И примеры убитой производительности:
Amazon Redshift: Distributed commit (internal 2PC)
Teradata: 2PC across AMPs
TiDB: Percolator-style 2PC over Raft
CockroachDB: Raft + distributed 2PC
Greenplum: Custom gxid + 2PC across segments
Google Spanner: TrueTime + 2PC (Paxos + 2PC)
Изоляция нагрузки. Высокая нагрузка на профили не повлияет на производительность финансовых транзакций.
Это должно довольно сильно повезти. В худшем случае придётся держать несколько проекций одних и тех же данных и поддерживать их согласованность.
Потому что разбиение на группы колонок делает невозможным многоколоночные индексы, объединяющие данные из разных групп.
Выбор тут простой. Если вы столкнулись с очень широкими таблицами в БД - проверьте, не появился ли в OLTP-системе филиал OLAP-системы с необходимостью обрабатывать много данных за один запрос. Если да - пора переезжать в колоночную БД.
Если же имеет место осознанная денормализация без признаков OLAP - значит надо оставить как есть. Пример такой денормализации - пакетная обработка на основе конечных автоматов.
Отличный сборник для руководителя компании. Напоминает о том сколько денег он потратит в будущем, если будет экономить на архитектуре и дизайне системы в настоящем.
Круто! Четко и тезисно, правда я не понял, почему статья называется "вертикальное шардирование".
В принципе большая часть из упомянутого описывается в Микросервисах Ричардсона. Хотелось бы добавить, что задачи резервного копирования часто решает репликация, может решать чудесный event sourcing (хотя я про него только читал) и бэкапы бывают инкрементальными. Если мы говорим про реплики и про консистентность распределенной системы, то наверное стоит упомянуть CAP и консенсус. Ещё упоминается CQRS без упоминания названия паттерна (CQRS).
Ну и про appside join'ы я бы чуть поподробнее расписал, что когда у нас одна СУБД она может выполнить запрос по-разному в зависимости от многих факторов. Делать фильтрацию на разных уровнях, join'ить разными алгоритмами в зависимости от размера данных и существующих индексов. Сделать что-то такое гибко и быстро на стороне приложения достаточно тяжело (поэтому разрабы и используют базы данных). Писать свой планировщик звучит нереально, про универсальные существующие решения я не слышал. По сути часто просто хардкодят какой-нибудь Hash join и все. Мой самый большой страх здесь это ограниченность оперативки, ведь СУБД если что выгрузит часть на ФС и отработает медленно, но корректно. Как итог, мы теряем очень удобную штуку, и надеемся, что самописный join учитывает много всего и что со временем наши предположения останутся корректными
Вертикальное шардирование базы данных: проблемы, решения, практические рекомендации