Для простой статьи совсем непонятный переход от микросервисов и двухфазного комита к CAP теореме, которая относится к распределённым системам. Вы случайно не путаете микросервисную архитектуру и распределённые системы (https://microservices.io/articles/scalecube.html) ?
Consistency (Согласованность) — принцип, согласно которому база данных гарантирует, что после успешного завершения каждой транзакции, данные в ней остаются в согласованном состоянии. Другими словами, до и после выполнения транзакции данные остаются надёжными и достоверными. Например, в контексте банковского перевода это означает, что транзакция не приведёт к появлению отрицательного баланса на одном счете, и одновременно к положительному на другом. Таким образом, мы можем быть уверены в достоверности и корректности данных в базе.
А что мне мешает в одной (например pg) транзакции сделать две операции, которые загонят по одному счёту плюс, а по другому минус? Я нарушу принципы ACID?
Такой ответ часто приходится слышать, но это скорее демонстрация непонимания, что есть на самом деле неконсистентность ACID.
Если совсем простыми словами, то Consistency (ACID) обеспечивает гарантию, что в базе не будут нарушены ограничения (constraints). Например, не сможете затолкать в одну таблицу две записи с одним значением первичного ключа.
А что значит "вряд ли"? Банальный пример: таблицы клиентов, поставщиков, договоров. Договоры ссылаются на две другие таблицы. Запрос - получить всех контграгентов (клиентов и поставщиков) по диапазону договоров. Собственно, "правильный ключ" (чтобы без дублирования и в одном шарде всё) тут не подобрать, как ни хэшируй.
Описанное в статье - частное решение для древовидных структур (агрегатов), которые можно от корня делить по шардам. Общая задача же, как правило, шире.
На этом этапе работа корпоративного архитектора прерывается до момента, когда в работу её берёт солюшн архитектор. И далее корпоративный архитектор выступает в роли эксперта/консультанта, так как солюшн архитектору могут понадобиться разъяснения по утверждённой схеме. При глубокой проработке на данном этапе может выявиться необходимость её изменения. В этом случае солюшн архитектор создаёт задачу для корпоративного архитектора на согласование изменений концепт-дизайна.
команда реализации готовит детальную архитектуру, которую проверяет корпоративный архитектор. Вторая – когда инициатива реализована, её лидер передаёт корпоративному архитектору полную документацию того, что именно было передано в реализацию. Он сравнивает корпоративную архитектуру с тем, что было на концепт-дизайне. В случае расхождений корпоративный архитектор анализирует их причины.
Описанное деление ответственности между архитекторами "по слоям" приводит к тому, что ответственного за решение нет.
Если партиции FDW таблицы, то это и получается шардирование.
Было бы круто, но, к сожалению, в этом случае пожертвуете атомарностью и изоляцией (из ACID). Шардирование для ACID СУБД это немного больше, чем распределение записи и чтения. Как минимум распределённые транзакции еще нужны с соответствующим уровнем изоляции.
нету в коробке шардирования (не путать с партиционированием). Специально об этом написал. И опять же, в цитате речь о сильной согласованности, а не о какой-то.
Всё в кучу. Надо бы разлепить: распределенные системы и микросервисы, согласованность распределенных систем и acid.
Традиционные реляционные БД, такие как PostgreSQL или MySQL, часто обеспечивают сильную согласованность
Эти СУБД 'из коробки' распределённой системой не являются. И линеаризуемость (строгая консистентность), как уровень согласованности в распределённых системых к ним не применима вообще. Ни часто, ни редко :)
Lol
PS и, да, из посгресов, например, можно слепить распределённую систему, у которой можно сильными приседаниями добиться линеаризованности, но это же не тот кейс, про который написано..
Первое, что должно насторожить (ну, по опыту, конечно), что лидить нужно 10 (десять!) специалистов. Имхо, для прямого "лидства" это уже овер или на грани эффективности даже для отлаженной и сработанной команды.
Ну, и рассматривая оффер тимлида, сразу стоит обозначить нанимающей стороне, что всё будет, но не сразу, и не так как было раньше. Может потребоваться и реорганизация команды (разделение на группы или отдельные команды), и снижение эффективности на какое-то время и тп.
А если будущий работодатель загоняет в строгие рамки: "оставьте всё как было, просто вольётесь/вникните за месяц" - не стоит вестись, должность тимлида без полномочий, без запаса времени, с навязанными, по сути, процессами и ответственностью, ну такое...
Жаль, что по первому опыту автор отказался от этого направления. Возможно, отрасль потеряла хорошего лида :(
Со стороны нанимателя дополню: наличие пет-проектов или решенные учебные задачи в открытых репах могут сыграть в плюс. На интервью, о них можно поговорить детально и лучше понять сильные стороны соискателя.
Похоже на очередную попытку вырастить архитектора в неволе
Для простой статьи совсем непонятный переход от микросервисов и двухфазного комита к 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 очепяточка в тексте: агилистов
В статье-то, как раз, про это ничего и не написано
Можно поменять слово Kanban в статье быстрой заменой на Jira и ничего не изменится.
А на прктике ПМ просто прибегает с круглыми глазами в конце спринта, требуя срочно зарелизить второй хобот для слона, потому что ОН уже обещал..
Первое, что должно насторожить (ну, по опыту, конечно), что лидить нужно 10 (десять!) специалистов. Имхо, для прямого "лидства" это уже овер или на грани эффективности даже для отлаженной и сработанной команды.
Ну, и рассматривая оффер тимлида, сразу стоит обозначить нанимающей стороне, что всё будет, но не сразу, и не так как было раньше. Может потребоваться и реорганизация команды (разделение на группы или отдельные команды), и снижение эффективности на какое-то время и тп.
А если будущий работодатель загоняет в строгие рамки: "оставьте всё как было, просто вольётесь/вникните за месяц" - не стоит вестись, должность тимлида без полномочий, без запаса времени, с навязанными, по сути, процессами и ответственностью, ну такое...
Жаль, что по первому опыту автор отказался от этого направления. Возможно, отрасль потеряла хорошего лида :(
А почему нет в списке отечественного qboard? https://qml.rqc.ru/products/qboard
Вроде пользуются уже желающие..
Со стороны нанимателя дополню: наличие пет-проектов или решенные учебные задачи в открытых репах могут сыграть в плюс. На интервью, о них можно поговорить детально и лучше понять сильные стороны соискателя.