Без обид, но, имхо, это тупиковый путь сделать универсальный реплицированный мультимастер в(!) Постгресах. Полноценная поддержка транзакций в распред. режиме убьёт и объемом разработки и производительностью (write-lock, read-lock сюда же отношу).
А вот, как только спускаемся на прикладной слой и делаем реплицированный мультимастер у себя в прикладе из(!) Постгресов, всё гораздо проще, просто за счет того, что мы не все кейсы должны поддержать.
Я к тому, что это вечный трейдофф, между универсальностью и производительностью. Выжать второе можно только из первого. Но это так, по опыту )
+ для прикладных задач не всегда требуется С(CAP) в полном смысле линеаризуемости. Снизив уровень до Seqentual или Casual можно прямо много выжать в плане скорости. Если бы это был универсальный движок, то линеаризуемость запирает вас между выбором низкая производительность vs. A(CAP) - тот самый тупик.
Почему SAFe представлен как противоположность TOGAF по гибкости, хотя SAFe это фреймворк масштабирования Agile, а TOGAF - методология описания архитектуры предприятия? Они решают разные задачи. Тёплое vs. Мягкое?
Содержание статьи про инструменты, про планирование, про составление тз, про этап сбора требований и их анализ. Ну ок, а как сюда затесался Agile? Или, идея в том, чтобы рассказать про его менее важную "правую часть" ?
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
Декомпозиция и оценка в конце свелись к общим словам про "распределение времени в идеальном мире" и диаграмме Ганта. Как это с архитектурой вообще связано?
Большинство кластерных баз данных, которые имеют встроенное шардирование, не предоставляют строгой консистентности при записи и стерилизации транзакций, говоря техническим языком
ACID, она и в распределённом режиме исполнения кода обеспечивала строгую стерилизацию транзакций. Это значит: если мы что-то записываем в базу данных, оно либо точно записалось и тут же доступно для чтения, либо не записалось — и нигде не осталось мусора и несогласованных данных.
Сериализация, видимо, имелась в виду она, не относится к согласованности распред. систем. Это уровень изоляции ACID.
То, что далее описано, это смешение, атомарности (или записалось или нет, без мусора) с согласованностью (тут же доступно для чтения) и это не про сериализацию. Надо б разлепить, а то ничего тут непонятно.
Ну и уровень согласованности, которого добились интересно. Линеаризуемость, секвенчуал или лимитед эвенчуал, там, например?
Для простой статьи совсем непонятный переход от микросервисов и двухфазного комита к CAP теореме, которая относится к распределённым системам. Вы случайно не путаете микросервисную архитектуру и распределённые системы (https://microservices.io/articles/scalecube.html) ?
Consistency (Согласованность) — принцип, согласно которому база данных гарантирует, что после успешного завершения каждой транзакции, данные в ней остаются в согласованном состоянии. Другими словами, до и после выполнения транзакции данные остаются надёжными и достоверными. Например, в контексте банковского перевода это означает, что транзакция не приведёт к появлению отрицательного баланса на одном счете, и одновременно к положительному на другом. Таким образом, мы можем быть уверены в достоверности и корректности данных в базе.
А что мне мешает в одной (например pg) транзакции сделать две операции, которые загонят по одному счёту плюс, а по другому минус? Я нарушу принципы ACID?
Такой ответ часто приходится слышать, но это скорее демонстрация непонимания, что есть на самом деле неконсистентность ACID.
Если совсем простыми словами, то Consistency (ACID) обеспечивает гарантию, что в базе не будут нарушены ограничения (constraints). Например, не сможете затолкать в одну таблицу две записи с одним значением первичного ключа.
А что значит "вряд ли"? Банальный пример: таблицы клиентов, поставщиков, договоров. Договоры ссылаются на две другие таблицы. Запрос - получить всех контграгентов (клиентов и поставщиков) по диапазону договоров. Собственно, "правильный ключ" (чтобы без дублирования и в одном шарде всё) тут не подобрать, как ни хэшируй.
Описанное в статье - частное решение для древовидных структур (агрегатов), которые можно от корня делить по шардам. Общая задача же, как правило, шире.
На этом этапе работа корпоративного архитектора прерывается до момента, когда в работу её берёт солюшн архитектор. И далее корпоративный архитектор выступает в роли эксперта/консультанта, так как солюшн архитектору могут понадобиться разъяснения по утверждённой схеме. При глубокой проработке на данном этапе может выявиться необходимость её изменения. В этом случае солюшн архитектор создаёт задачу для корпоративного архитектора на согласование изменений концепт-дизайна.
команда реализации готовит детальную архитектуру, которую проверяет корпоративный архитектор. Вторая – когда инициатива реализована, её лидер передаёт корпоративному архитектору полную документацию того, что именно было передано в реализацию. Он сравнивает корпоративную архитектуру с тем, что было на концепт-дизайне. В случае расхождений корпоративный архитектор анализирует их причины.
Описанное деление ответственности между архитекторами "по слоям" приводит к тому, что ответственного за решение нет.
Если партиции FDW таблицы, то это и получается шардирование.
Было бы круто, но, к сожалению, в этом случае пожертвуете атомарностью и изоляцией (из ACID). Шардирование для ACID СУБД это немного больше, чем распределение записи и чтения. Как минимум распределённые транзакции еще нужны с соответствующим уровнем изоляции.
нету в коробке шардирования (не путать с партиционированием). Специально об этом написал. И опять же, в цитате речь о сильной согласованности, а не о какой-то.
Всё в кучу. Надо бы разлепить: распределенные системы и микросервисы, согласованность распределенных систем и acid.
Традиционные реляционные БД, такие как PostgreSQL или MySQL, часто обеспечивают сильную согласованность
Эти СУБД 'из коробки' распределённой системой не являются. И линеаризуемость (строгая консистентность), как уровень согласованности в распределённых системых к ним не применима вообще. Ни часто, ни редко :)
Lol
PS и, да, из посгресов, например, можно слепить распределённую систему, у которой можно сильными приседаниями добиться линеаризованности, но это же не тот кейс, про который написано..
Ну почему "никто", сразу-то... :-)
Без обид, но, имхо, это тупиковый путь сделать универсальный реплицированный мультимастер в(!) Постгресах.
Полноценная поддержка транзакций в распред. режиме убьёт и объемом разработки и производительностью (write-lock, read-lock сюда же отношу).
А вот, как только спускаемся на прикладной слой и делаем реплицированный мультимастер у себя в прикладе из(!) Постгресов, всё гораздо проще, просто за счет того, что мы не все кейсы должны поддержать.
Я к тому, что это вечный трейдофф, между универсальностью и производительностью. Выжать второе можно только из первого. Но это так, по опыту )
+ для прикладных задач не всегда требуется С(CAP) в полном смысле линеаризуемости. Снизив уровень до Seqentual или Casual можно прямо много выжать в плане скорости. Если бы это был универсальный движок, то линеаризуемость запирает вас между выбором низкая производительность vs. A(CAP) - тот самый тупик.
Обратная сторона: хочешь найти себе хорошего специалиста и во вменяемые сроки - ищешь сам.
Или выгрызть себе аккаунт компании в хх, ежедневно отбирать десяток резюме и отправлять HRам только обеспечить коммуникацию и базовый опрос.
Или через знакомых.
Простите, это салатник методологий получился.
Почему SAFe представлен как противоположность TOGAF по гибкости, хотя SAFe это фреймворк масштабирования Agile, а TOGAF - методология описания архитектуры предприятия? Они решают разные задачи. Тёплое vs. Мягкое?
Содержание статьи про инструменты, про планирование, про составление тз, про этап сбора требований и их анализ. Ну ок, а как сюда затесался Agile? Или, идея в том, чтобы рассказать про его менее важную "правую часть" ?
Декомпозиция и оценка в конце свелись к общим словам про "распределение времени в идеальном мире" и диаграмме Ганта. Как это с архитектурой вообще связано?
Автопроверка орфографии - зло. "Стерилизация" транзакций
Сериализация, видимо, имелась в виду она, не относится к согласованности распред. систем. Это уровень изоляции ACID.
То, что далее описано, это смешение, атомарности (или записалось или нет, без мусора) с согласованностью (тут же доступно для чтения) и это не про сериализацию. Надо б разлепить, а то ничего тут непонятно.
Ну и уровень согласованности, которого добились интересно. Линеаризуемость, секвенчуал или лимитед эвенчуал, там, например?
О каких объемах данных, всё-таки, идёт речь?
Судя по скрину метрик, там всё меньше 1 млрд записей. И тогда непонятно, откуда такие "скорости" измеряемые в часах?
Кажется, что это несуразно долго с такими объемами и задействованными ресурсами 33х нод.
Похоже на очередную попытку вырастить архитектора в неволе
Для простой статьи совсем непонятный переход от микросервисов и двухфазного комита к CAP теореме, которая относится к распределённым системам. Вы случайно не путаете микросервисную архитектуру и распределённые системы (https://microservices.io/articles/scalecube.html) ?
Баги gporca (например, из свеженького, видимость некоторых удалённых записей в запросах с сет операторами)
Производительность самого планировщика в некоторых кейсах дающая х100 к общей длительности запроса.
Предложил бы дополнить статью командами, которые выключают GPORCA (иногда и такое бывает нужно)
SET OPTIMIZER = OFF; --в рамках коннекта
ALTER DATABASE mydb1 SET OPTIMIZER = OFF; --на всю бд
А что мне мешает в одной (например pg) транзакции сделать две операции, которые загонят по одному счёту плюс, а по другому минус? Я нарушу принципы ACID?
Такой ответ часто приходится слышать, но это скорее демонстрация непонимания, что есть на самом деле неконсистентность ACID.
Если совсем простыми словами, то Consistency (ACID) обеспечивает гарантию, что в базе не будут нарушены ограничения (constraints). Например, не сможете затолкать в одну таблицу две записи с одним значением первичного ключа.
А что значит "вряд ли"?
Банальный пример: таблицы клиентов, поставщиков, договоров. Договоры ссылаются на две другие таблицы. Запрос - получить всех контграгентов (клиентов и поставщиков) по диапазону договоров. Собственно, "правильный ключ" (чтобы без дублирования и в одном шарде всё) тут не подобрать, как ни хэшируй.
Описанное в статье - частное решение для древовидных структур (агрегатов), которые можно от корня делить по шардам. Общая задача же, как правило, шире.
Описанное деление ответственности между архитекторами "по слоям" приводит к тому, что ответственного за решение нет.
Классика.
"К пуговицам претензии есть?" https://www.youtube.com/watch?v=w8NfqKlYKl0
Было бы круто, но, к сожалению, в этом случае пожертвуете атомарностью и изоляцией (из ACID). Шардирование для ACID СУБД это немного больше, чем распределение записи и чтения. Как минимум распределённые транзакции еще нужны с соответствующим уровнем изоляции.
Ссылка https://franckpachot.medium.com/monolithic-vs-distributed-sql-f07af959e1a4 не открывается. Есть где-то на других ресурсах эта статья?
Вы путаете партиционирование и шардирование. Или шардирование и репликацию.
нету в коробке шардирования (не путать с партиционированием). Специально об этом написал. И опять же, в цитате речь о сильной согласованности, а не о какой-то.
Всё в кучу. Надо бы разлепить: распределенные системы и микросервисы, согласованность распределенных систем и acid.
Эти СУБД 'из коробки' распределённой системой не являются. И линеаризуемость (строгая консистентность), как уровень согласованности в распределённых системых к ним не применима вообще. Ни часто, ни редко :)
Lol
PS и, да, из посгресов, например, можно слепить распределённую систему, у которой можно сильными приседаниями добиться линеаризованности, но это же не тот кейс, про который написано..
Любой статье, где задумываются о требованиях и их формализации сразу плюс.
А так да, есть же 34 ГОСТ, как тут уже написали, он подойдёт в большинстве случаев как основа, которую можно адаптировать.
Начинайте требки с 3х пунктов:
Цели
Назначение
Ограничения
и дальше само пойдет ))
Ну очень давно, один из моих учителей повторял "Сначала структуры, алгоритмы потом" :-P
Статье жирный плюс.
PS очепяточка в тексте: агилистов