Comments 50
Этот пост не шутка!? Постгрес масштабируется только вертикально? Вы серьёзно сейчас?
Как я понимаю, Вы имеете в виду различные расширения и продукты на основе postgres. Некоторые из них просто шардируют, другие же занимаются реализацией полноценной распределенной СУБД. Но это не ванильный Postgres. И все эти решения появились именно за счет того, что одного Postgres'a мало - о чём мы и написали пост. К сожалению, у нас не было возможности измерить все существующие СУБД, но мы стараемся :)
Шардирование работает и без расширений.
Всё равно есть какая-то сущность, которая знает о шардах. Конечно, можно сделать шардирование прозрачно для базы, утянув всю логику в приложение. И тогда вместо разработки прикладной логики заниматься реализацией распределенных транзакций, решать вопросы, связанные с консистентностью, распределенным снепшотом, перешардированием и т.п. Это крайне сложные вещи и очень легко посадить баги.
Шардирование работает и без расширений.
Вы путаете партиционирование и шардирование. Или шардирование и репликацию.
Если партиции FDW таблицы, то это и получается шардирование.
Если партиции FDW таблицы, то это и получается шардирование.
Было бы круто, но, к сожалению, в этом случае пожертвуете атомарностью и изоляцией (из ACID). Шардирование для ACID СУБД это немного больше, чем распределение записи и чтения. Как минимум распределённые транзакции еще нужны с соответствующим уровнем изоляции.
Так поддержка распределённых транзакций в PostgreSQL уже появилась.
PostgreSQL масштабируется только вертикально и её производительность ограничена возможностями одного сервера
PostgreSQL имеет все необходимые средства для горизонтального масштабирования. Другой вопрос, что в ванильном PostgreSQL предоставляется только низкоуровневая поддержка. Но на её базе вполне работает тот же Greenplum.
Как разработчик СУБД, я бы с удовольствием послушал более конкретно об этих средствах.
Мультимастер репликация и партиционирование, которое средствами FDW может быть шардировано.
P.S. Доказывание преимущества своего программного продукта методом минусования оппонентов говорит уже о многом. А ведь я ни слова не сказал о недостатках YDB.
Давайте попробуем разобраться, есть ли мультимастер в PostgreSQL. Вот статья в официальной вики postgresql: "As a result, current streaming replication in PostgreSQL provides only fault tolerance (HA), but not scaling performance". И это полностью совпадает с выводами нашего поста. Дальше в вики они предлагают Postgres-BDR (стороннее решение). Для полноты вот еще список альтернатив от Percona. И справедливости ради добавлю, что у postgres pro есть похожие решения. Все эти решения - самостоятельные сложные продукты. И причина их существования заключается именно в том, что PostgreSQL не масштабируется горизонтально. Очень странно, когда кто-то пытается доказать обратное.
Что касается минусов, то они не из-за YDB, а из-за того, что Ваши комментарии не совпадают с реальностью.
Я написал десять слов в первом предложении. Почему Вы заметили из них только первые два?
provides only fault tolerance
Распределенное хранение данных - это не только шардирование, но и их дуплицирование для отказоустойчивости. И если первая задача решается партиционированием через FDW таблицы, то вторая - именно репликацей.
Ваши комментарии не совпадают с реальностью.
Ваши, как видите, тоже
В этой презентации (PGCon 2020) очень хорошо рассказывают о том, почему в FDW нет ACID распределенных транзакций.
К сожалению, наш диалог так и остался неконструктивным.
К сожалению, наш диалог так и остался неконструктивным.
Само собой, если Вы ссылаетесь на презентацию четырехлетней давности, когда 2PC в PostgreSQL еще не было.
Само собой, если Вы ссылаетесь на презентацию четырехлетней давности, когда 2PC в PostgreSQL еще не было.
В презентации указано, что требуется не только 2PC. И за четыре года так все проблемы и не решили. Из описания atomic commit of distributed transactions на вики постгреса (в презентации это слайд "Atomic Visibility"):
Distributed transaction involves, atomic commit, atomic visibility, and global consistency. 2PC is the only practical solution for atomic commit.
...
Concurrent readers can see an inconsistent result, for example, when a reader starts a new foreign transactions on two foreign servers after the writer committed the prepared foreign transaction only on the one of the foreign server?
Yes. This feature ensures only atomic commit, but not atomic visibility. To support the globally consistent results, other mechanisms such as providing a globally consistent snapshot will be required.
А Вы не обратили внимание, что эта страница не правилась с ноября 2020 года?
Описанная ситуация возможна только в случае, когда "reader" использует 2PC, а "writer" - нет. Только в этом случае "writer" не будет использовать GID. Именно по этой причине в документации указано, что "PREPARE TRANSACTION is not intended for use in applications or interactive sessions"
Понятно, что руками с этим мало кто будет разбираться. Намного проще добавить расширение, которое это будет обеспечивать прозрачно. Или Вы считаете, что команда "CREATE EXTENSION citus;" превращает ванильный PostgreSQL сразу не в ванильный?
Авторы citus'a в статье, описывающей его архитектуру, очень чётко написали об ограничениях распределенных транзакций в citus (п. 3.7.4 Multi-node transaction trade-offs):
Multi-node transactions in Citus provide atomicity, consistency, and durability guarantees, but do not provide distributed snapshot isolation guarantees. A concurrent multi-node query could obtain a local MVCC snapshot before commit on one node, and after commit on another. Addressing this would require changes to PostgreSQL to make the snapshot manager extensible. In practice, we did not find a strong need for distributed snapshot isolation in the four workload patterns, and customers did not express a need for it yet. Most transactions in multi-tenant and CRUD applications are scoped to a single node, meaning they get isolation guarantees on that node. Analytical applications do not have strong dependencies between transactions and are hence more tolerant to relaxed guarantees.
Distributed snapshot isolation can be important in certain hybrid scenarios. However, existing distributed snapshot isolation techniques have a significant performance cost due to the need for additional network round trips or waiting for the clock, which increases response times and lowers achievable throughput. In the context of the synchronous PostgreSQL protocol, throughput is ultimately capped by #connections / response time. Since making a very large numberofdatabaseconnections is often impractical from the application perspective, low response time is the only way to achieve high throughput. Hence, we would likely make distributed snapshot isolation optional if we implement it in the future.
Фактически это eventual consistency. Вот отличный пример того, что это означает на практике. В конце поста приведены примеры задач, когда стоит использовать citus. И ещё один пост. Интересно, что в документации Citus это очень тяжело найти. Я нашёл только в одном месте про SELECT + COPY: "There is no notion of snapshot isolation across shards", только это касается и других случаев, а не только COPY.
Кроме того, шардирование не делает базу распределенной. Появляется координатор, который является единой точкой отказа. Кроме citus, надо ещё что-то типа Patroni (и etcd сбоку). И всё равно гарантии консистентности подойдут не всем приложениям.
Вам не кажется, что Вы "откапываете стюардессу"?
2PC появился только в PostgreSQL 16. То есть, в сентябре 2023 года. Отсюда любые ссылки на статьи, вышедшие до этого - заведомо содержат устаревшую информацию.
До версии 11.2 Citus вообще отправлял на рабочие ноды исключительно TRANSACTION ISOLATION READ COMMITTED, научившись TRANSACTION ISOLATION REPEATABLE READ только в прошлом году. А вот поддержку SERIALIZABLE обещают только в следующей версии, так как ради нее потребуется отказаться от поддержки PostgreSQL до 15-ой версии включительно.
Вам не кажется, что Вы "откапываете стюардессу"?
"There is no notion of snapshot isolation across shards" из документации к citus 12.1. Самая свежая версия. И пост югабайта, который я привел в качестве примера, от 16 августа 2023 года.
До версии 11.2 Citus вообще отправлял на рабочие ноды исключительно TRANSACTION ISOLATION READ COMMITTED, научившись TRANSACTION ISOLATION REPEATABLE READ только в прошлом году.
Внимательно читаем changelog к 11.2:
By propagating the level Citus' semantics will be mostly correct for workloads without multi-shard queries (e.g. multi-tenant).
И это полностью совпадает с тем, что они писали о своей архитектуре в цитате, что я привел выше. Они определили для каких сценариев их продукт и продолжают работать в том же направлении.
2PC появился только в PostgreSQL 16. То есть, в сентябре 2023 года. Отсюда любые ссылки на статьи, вышедшие до этого - заведомо содержат устаревшую информацию.
Повторю ещё раз: 2PC решает проблему атомарного коммита, он не решает другие проблемы распределенных транзакций, о чем и написано в документации постгреса, когда бы она ни была написана: "Distributed transaction involves, atomic commit, atomic visibility, and global consistency. 2PC is the only practical solution for atomic commit." В статье о дизайне Citus пишут прямым текстом, почему они не хотят нормальные многошардовые транзакции - это размен на performance.
Если честно, я не понимаю, о чём мы спорим. Citus не поддерживает распределенные снепшоты: это специально заложено в архитектуру этой СУБД, это есть в документации к последней версии. Югабайт показали красивый пример, что это означает на практике, при этом честно рассказав, в каких случаях Citus хорошо подходит для использования.
"There is no notion of snapshot isolation across shards"
which means that a multi-shard SELECT that runs concurrently with a COPY
Не профессионально обрубать предложения, существенно искажая их смысл.
И пост югабайта, который я привел в качестве примера, от 16 августа 2023 года.
И тем более не профессионально не знать, что август до сентября.
2PC решает проблему атомарного коммита
Но в сочетании с уникальным и последовательно возрастающим GID - решает.
Если честно, я не понимаю, о чём мы спорим.
О том, что если сравнивать распределенную шардированную СУБД, то тоже с распределенной шардированной конфигурацией.
Не профессионально обрубать предложения, существенно искажая их смысл.
Если внимательно перечитаете, то увидите, что я об этом написал:
Интересно, что в документации Citus это очень тяжело найти. Я нашёл только в одном месте про SELECT + COPY: "There is no notion of snapshot isolation across shards", только это касается и других случаев, а не только COPY.
Можете и дальше считать, что Citus полноценная распределенная СУБД без каких-либо скрытых нюансов. Начиная с сентября 2023-го года, конечно.
только это касается и других случаев, а не только COPY
На что никаких пруфов в случае Citus на PostgreSQL 16 предоставлено не было. То есть, это осталось лишь гипотезой.
Можете и дальше считать, что Citus полноценная распределенная СУБД без каких-либо скрытых нюансов. Начиная с сентября 2023-го года, конечно.
Я так не считаю, о чем писал выше: "А вот поддержку SERIALIZABLE обещают только в следующей версии, так как ради нее потребуется отказаться от поддержки PostgreSQL до 15-ой версии включительно."
Но это никак не влияет на то, что сравнение YDB с PostgreSQL производилось с шардированем в первой и без шардирования во второй, так как в сценарии TPC-C SERIALIZABLE совершенно не требуется.
Ссылка https://franckpachot.medium.com/monolithic-vs-distributed-sql-f07af959e1a4 не открывается. Есть где-то на других ресурсах эта статья?
Просьба дать полный конфиг ПГ. Или не полный конфиг, а выжимку что меняли от дефолтного.
Было в тексте статьи:
Здесь можно посмотреть на полный конфиг PostgreSQL. TPC-C запускается на 5 клиентах, каждый по 60 сессий.
Для TPC-C не только конфиг важен, но еще и fillfactor при создании справочников. Сами справочники там статичны, но содержат поля агрегатов, которые модифицируются при каждой операции. Если fillfactor оставить по умолчанию 100, то HOT updates смогут использоваться заметно реже. А значит получаем более частые обновления индексов справочников.
Статья на тему - сравнить ужа и ежа. Это конечно интересно, но бесполезно. Большая часть статьи - это как мы крутили настройки пг чтобы получить хоть что-то вразумительное.
Я с Вами не согласен. Да, это уж и еж, но задачу решают при этом одну: СУБД, которая переживает отказ одного из серверов. Мы рассмотрели трехсерверный сетап: пользователям как раз важно понимать, что делать для решения их задачи: использовать Postgres или распределенную СУБД. Когда мы сравнивали исключительно распределенные СУБД, то самый частый вопрос, который нам задавали был "А какие результаты у Postgres'a?". Либо вообще получали фидбек, что Postgres'a достаточно и на трех серверах он уверенно и значительно обойдет любую распределенную СУБД.
YDB просто по построению будет нормально работать только в том случае, если нет «узких мест», за которые конкурирует множество транзакций. Если вы попробуете, например, построить расчётную систему, где стопиццот транзакций в секунду идут через малое количество ЛОРО и НОСТРО счетов, никакого горизонтального масштабирования не будет. Кальвин — штука такая.
А если транзакции плюс-минус равномерно размазываются по данным, то гораздо лучше будет работать схема Facebook со множеством независимых шардов, каждый из которых обслуживается монолитной базой (MySQL или PostgreSQL). В этой схеме проще всё — и обновление прикладного софта, и локализация сбоев.
P. S. Да, и ещё добавлю. TPC-C — это именно такой тест, где конкуренция между транзакциями достаточно низкая. Сам консорциум TPC давно уже придумал новый тест TPC-E, но только на их сайте опубликовано не более сотни результатов. Так-то индустрия давно наигралась в синтетические тесты и перестала им верить.
Кальвин — штука такая
Calvin вдохновил YDB, но YDB достаточно далеко ушел в своем развитии. Мы планируем однажды наконец рассказать, почему YDB больше, чем просто Calvin. Хотя, конечно, у нас по-прежнему оптимистичные блокировки и где-то это большой плюс, но в некоторых сценариях, конечно, недостаток.
Если вы попробуете, например, построить расчётную систему, где стопиццот транзакций в секунду идут через малое количество ЛОРО и НОСТРО счетов, никакого горизонтального масштабирования не будет.
И если в один ключ писать, то тоже никакого горизонтального масштабирования не будет. Как и в значительной степени вертикального. Но мы ради интереса запускали YDB на различных бенчмарках, эмулирующих работу банка, и получили достаточно хорошие результаты.
А если транзакции плюс-минус равномерно размазываются по данным, то гораздо лучше будет работать схема Facebook со множеством независимых шардов, каждый из которых обслуживается монолитной базой (MySQL или PostgreSQL). В этой схеме проще всё — и обновление прикладного софта, и локализация сбоев.
Я с Вами абсолютно согласен, что идеальным вариантом является случай, когда данные не пересекаются между собой. В т.ч. для распределенных СУБД: одношардовые транзакции работают без участия координатора и быстрее, чем многошардовые. Но тут вся проблема в том, что шардированный не значит распределенный. Если требуются распределенные транзакции (и распределенный/глобальный снепшот), то особых альтернатив распределенным СУБД нет.
Так-то индустрия давно наигралась в синтетические тесты и перестала им верить.
Спорное утверждение, если посмотреть на цитаты, которые я специально привел в посте. Но я согласен, что синтетика синтетикой и у разных СУБД при разных нагрузках могут быть очень разные результаты.
Если требуются распределенные транзакции (и распределенный/глобальный снепшот), то особых альтернатив распределенным СУБД нет.
А много ли в жизни таких задач? Большинство реальных задач эффективно решаются сагами. Если какое-то непродолжительное время суммарный остаток на счетах будет меньше нужного (у дающего уже списали, а берущему ещё не зачислили), ничего страшного не случится. Возможно, при моделировании каких-то сложных систем в научных экспериментах этот самый «глобальный снапшот» и нужен, но для автоматизации бизнеса — в 99.99% случаев нет.
Спорное утверждение, если посмотреть на цитаты, которые я специально привел в посте.
Я не увидел ни одной цитаты типа «мы ориентируемся на результаты теста XXX при выборе YYY». А разработчики СУБД, конечно, любят щеголять высокими результатами в подобных тестах. Чем иногда создают серьёзные проблемы клиенту.
наконец рассказать, почему YDB больше, чем просто Calvin.
С удовольствием бы почитал. С точки зрения функциональности — очевидно, оригинальный Calvin оперирует моделью «ключ—значение», там нет реляционных механизмов. А вот с точки зрения производительности — пока понимаю только, почему она хуже оригинального кальвина :))
А много ли в жизни таких задач?
С этим я полностью согласен. В большинстве случаев людям достаточно одного не супер мощного сервера и монолитной СУБД. Если нужно переживать отказ сервера, то некоторым хватает и одной реплики. А если производительность становится проблемой, то можно использовать асинхронную репликацию, рискуя потерять часть данных. Но не для всех это критично.
Большинство реальных задач эффективно решаются сагами. Если какое-то непродолжительное время суммарный остаток на счетах будет меньше нужного (у дающего уже списали, а берущему ещё не зачислили), ничего страшного не случится.
Это крайне интересная тема для дискуссии :) Идеально за пивом/кофе/чаем на закрытии конференции :) Конечно, в приведенном примере это не страшно. Но пример достаточно ограниченный. Попробуем посмотреть немного шире.
Что если речь идёт не о транзакциях, а о бекапе? Является ли наш бекап консистентным, если во время его работы выполнялись транзакции? Сойдется ли у нас математика после восстановления из бекапа? Еще есть тренд на то, чтобы выгружать данные базы в другую систему, чтобы делать аналитику (как пример). Часто для этого используют change data capture (CDC). И опять хотелось бы иметь консистентность.
Вернемся к транзакциям. По сути, Вы предложили eventual consistency: какое-то время счет может быть отрицательным, но значение станет корректным достаточно быстро. А что если между списанием и зачислением сущность, выполняющая операцию, упадет? Изначально незначительное время может стать гораздо более ощутимым.
Конечно, логику СУБД можно вынести в пользовательское (с точки зрения базы) приложение. Но распределенные транзакции очень сложная тема, крайне легко пропустить какой-то момент и посадить баг, который будет потом тяжело найти (даже не сам баг, а его наличие). Да даже без распределенных транзакций можно использовать snapshot isolation и нарваться на write skew/phantom (да, на практике они встречаются крайне редко, но зато метко). Лично я за KISS. Приведу две любимых цитаты на эту тему:
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies"
C.A.R. Hoare, The 1980 ACM Turing Award Lecture
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
Brian W. Kernighan
На мой взгляд, разработчики приложений должны писать приложения, а разработчики СУБД - СУБД. И тогда багов будет меньше :)
А разработчики СУБД, конечно, любят щеголять высокими результатами в подобных тестах. Чем иногда создают серьёзные проблемы клиенту.
К сожалению, нам ничего другого не остаётся, как использовать бенчмарки. В т.ч. для работы над оптимизациями.
С удовольствием бы почитал.
Как говорится, "stay tuned" :)
Идеально за пивом/кофе/чаем на закрытии конференции
Ну приходите на PGConf через пару недель, например :)
На мой взгляд, разработчики приложений должны писать приложения
Видите ли, практика показывает, что если прикладной программист начинает использовать распределённую БД как «монолитную, только большую», это приводит к разного рода проблемам. Код операций, затрагивающих несколько узлов, должен принципиально отличаться от кода операций, выполняемых на одном узле — это залог успеха. Говорят, в Яндексе очень строгий отбор программистов, и те, кто прошёл этот отбор, такие вещи понимают. Но большинство программистов, особенно тех, которые автоматизируют бизнес, а не занимаются инфраструктурными проектами, — нет.
Является ли наш бекап консистентным
А тут философский вопрос — а что такое вообще «точка во времени» в распределённой системе? Если ответ на этот вопрос есть (как, например, в Foundation DB или в классическом Calvin), то сделать согласованную резервную копию — чисто техническая задача. А вот если нет...
А что если между списанием и зачислением сущность, выполняющая операцию, упадет?
Ну саги ведь тоже не вчера появились, они гораздо старше, чем Calvin. И бороться с такими инцидентами давно научились. Полагаю, вы тему знаете не хуже меня, а если чего-то не знаете, легко нагуглите :)
Я тоже за KISS, просто понятия о простоте у нас с вами разные. Как-то я столкнулся с неожиданным поведением распределённых систем, стал разбираться, почему они ведут себя так, и в итоге написал вузовский учебник по базам данных. А заодно стал идейным противником распределённых СУБД, если только это не аналитическая платформа типа Greenplum, Presto, Vertica и т. п. :))
Ну приходите на PGConf через пару недель, например :)
Я бы с радостью, но только если в следующий раз :)
Видите ли, практика показывает, что если прикладной программист начинает использовать распределённую БД как «монолитную, только большую», это приводит к разного рода проблемам.
Я бы сказал, что наша цель - сделать для разработчиков так, чтобы для них распределенная СУБД выглядела, как монолитная. И мы к ней идём :) В целом, конечно, распределенная СУБД нужна чаще тем, для кого важен и performance, а тогда лучше учитывать некоторые нюансы. Хотя по моим ощущениям у нас очень много тех, кто использует YDB, как монолитную базу, и у них все хорошо.
Код операций, затрагивающих несколько узлов, должен принципиально отличаться от кода операций, выполняемых на одном узле — это залог успеха.
Мне кажется, что это очень сильное преувеличение. Хотя бы потому, что пользователь ничего не знает о шардировании, т.е. сколько шардов и где какие ключи (может узнать, но смысла в этом нет). Было бы интересно услышать какие-то конкретные примеры.
Но большинство программистов, особенно тех, которые автоматизируют бизнес, а не занимаются инфраструктурными проектами, — нет.
Интересно, что мы с Вами видим это одинаково, но делаем разные выводы :) Мой довод заключается как раз именно в этом, что не надо разработчиков бизнес-логики заставлять писать части СУБД в своих приложениях, потому что они к этому не готовы.
Ну саги ведь тоже не вчера появились, они гораздо старше, чем Calvin. И бороться с такими инцидентами давно научились.
Это дополнительные код и тесты (часто нетривиальные). В итоге, на мой взгляд, получится по функциональности то, что предоставляют распределенные СУБД.
Как-то я столкнулся с неожиданным поведением распределённых систем, стал разбираться, почему они ведут себя так, и в итоге написал вузовский учебник по базам данных.
Учебник выглядит интересно. С удовольствием посмотрю :)
А заодно стал идейным противником распределённых СУБД
Очень любопытно, можно подробнее? :) Пока мне показалось, что Вы считаете, что "кастомизация" шардированных решений проще и обладает более высокой производительностью. Наверняка, немало случаев, где так и есть. Но и много, где стоило взять распределенную СУБД с самого начала. Кстати, мы и аналитику активно развиваем. Надеемся, что в обозримом будущем сможем показать результаты сравнения с другими аналитическими СУБД.
не надо разработчиков бизнес-логики заставлять писать части СУБД
Не надо. Но всю распределённую логику можно оформить в виде фреймворка. Тут же дело в том, что это всё потом сопровождать, и когда падает монолитная база, понятно, что делать. А с распределённой базой возможны варианты.
по моим ощущениям у нас очень много тех, кто использует YDB, как монолитную базу, и у них все хорошо.
Наши администраторы наотрез отказываются брать на сопровождение распределённую БД как единое целое. Где-то есть MongoDB, Cassandra и Hadoop, но всё это не поднимается выше класса вспомогательного программного обеспечения, данные которого можно и потерять, если рагнарёк.
пользователь ничего не знает о шардировании
Вот как раз когда пользователь знает, получается более эффективные приложения. Естественно, всё распределение автоматизировано. Но пишет, например, программист погашение долга по кредитке — это гарантированно локальная транзакция, и можно полагаться на гарантии СУБД. А вот пишет он p2p перевод — тут уже должна быть сага, потому что клиенты могут быть в разных шардах. И программист неизбежно задумается — а как бы сделать поменьше шагов?
Учебник выглядит интересно. С удовольствием посмотрю :)
Посмотрите.
Вот тут в электронном виде без регистрации и СМС: https://postgrespro.ru/education/books/dbguide
А вот тут на бумаге, но уже за деньги: https://dmkpress.com/catalog/computer/databases/978-5-93700-287-7/
Если понравится, буду благодарен за любой PR кроме некролога :)
Не надо. Но всю распределённую логику можно оформить в виде фреймворка. Тут же дело в том, что это всё потом сопровождать, и когда падает монолитная база, понятно, что делать. А с распределённой базой возможны варианты.
Извините, я не понял, какие возможны варианты. К сожалению, по-прежнему не понимаю, чем фреймворк, реализующий распределенные транзакции, лучше распределенной СУБД.
Наши администраторы наотрез отказываются брать на сопровождение распределённую БД как единое целое.
Я читаю это, как наши администраторы знают только монолитные базы X и Z, поэтому отказываются админить распределенную базу Y.
Вот как раз когда пользователь знает, получается более эффективные приложения. Естественно, всё распределение автоматизировано. Но пишет, например, программист погашение долга по кредитке — это гарантированно локальная транзакция, и можно полагаться на гарантии СУБД. А вот пишет он p2p перевод — тут уже должна быть сага, потому что клиенты могут быть в разных шардах. И программист неизбежно задумается — а как бы сделать поменьше шагов?
Для меня это звучит, как преждевременная оптимизация (без гарантий того, что получится лучше). У нас есть пользователи, которым для распределенных транзакций требуется не более 50 мс на 99.9%. Они сфокусированы на бизнес-логике и уверены в сохранности и консистентности данных в любой момент времени.
чем фреймворк, реализующий распределенные транзакции, лучше распределенной СУБД
Тем, что выход из строя какого-то одного компонента с состоянием (БД одного из шардов или экземпляра оркестратора) никак не влияет на другие компоненты с состоянием. Сбой всегда локализован.
как наши администраторы знают только монолитные базы X и Z
Примерно так и есть, да. И два десятка администраторов сопровождают несколько десятков тысяч экземпляров этих монолитных баз. С распределёнными базами не удаётся достичь такой эффективности работы администратора. Во многом, конечно, это заслуга эксплуатационной зрелости конкретных продуктов, а не распределённости как таковой, но тем не менее.
преждевременная оптимизация
Не преждевременная. Изначально большинство приложений пишется в расчёте на монолитную БД, и 95% за её пределы никогда и не вылезают. Работа с шардами начинается не раньше, чем будет очевидно, что в одну базу вся нагрузка не помещается.
Тем, что выход из строя какого-то одного компонента с состоянием (БД одного из шардов или экземпляра оркестратора) никак не влияет на другие компоненты с состоянием. Сбой всегда локализован.
В распределенной СУБД сбои в пределах модели отказов никогда не влияют на работу СУБД и клиентов. Отказал сервер (или целый ДЦ) - все продолжает работать абсолютно прозрачно для всех пользовательских приложений.
Примерно так и есть, да. И два десятка администраторов сопровождают несколько десятков тысяч экземпляров этих монолитных баз. С распределёнными базами не удаётся достичь такой эффективности работы администратора.
Достоинством распределенной СУБД является то, что не требуется десятков тысяч монолитных СУБД. Можно иметь одну большую СУБД и внутри нее тысячи изолированных друг от друга баз. Тогда потребуется один администратор вместо двух десятков. Кроме того, один администратор вполне справится с несколькими распределенными СУБД, а нескольких распределенных СУБД хватит 99.999% пользователей. Но я согласен, что администраторов распределенных СУБД на рынке мало и их тяжелее нанять.
Не преждевременная. Изначально большинство приложений пишется в расчёте на монолитную БД, и 95% за её пределы никогда и не вылезают. Работа с шардами начинается не раньше, чем будет очевидно, что в одну базу вся нагрузка не помещается.
Смотрите, мне кажется, что Вы относите шардированные и распределенные СУБД к одному классу систем, а это совсем не так. Шардированная СУБД не значит распределенная. Поэтому и складывается впечатление, что мы по-прежнему говорим каждый о своем: Вы о шардах, я о распределенных СУБД. С точки зрения пользователей распределенная СУБД представляет собой монолит, черный ящик. Шардирование - деталь реализации и пользователь никогда в своем приложении не работает с шардами. Другая проблема нашего обсуждения - слишком большая абстрактность. Вы пока не привели ни одного примера, когда пользователю распределенной СУБД надо работать с шардами.
Ну, саги появились давно, но нормальных реализаций, увы, нет. А реализация саги разработчиком, который использует YDB как монолит - еще хуже, нежели использование YDB как монолит )
Реализация корректных и надежных саг мало отличима от ручной реализации 2PC (
Если у вас остаток клиента на какое-то время ушел в минус, а вы не банк, а НКО - то ничего страшного не случится, просто лицензию отнимут и бизнес закроют.
Вообще, сценариев с жесткими требованиями к целостности - достаточно много.
Верно понимаю, что YDB, по сути, является реляционной базой данных "для чайников" и, в случае если, например, в одной таблице будет храниться больше миллиона записей - то пользователю не нужно будет задумываться о том, как оптимизировать базу данных (шардировать, cекционировать (partitioning) и пр.), а YDB сделает это "под капотом"?
Поэтому её часто используют как монолит?
Да, Вы абсолютно правильно поняли идею. YDB прозрачно для пользователя решает большое количество проблем. Гарантии консистентности позволяют использовать базу, как монолит, что в свою очередь упрощает логику пользовательских приложений и потенциально снижает вероятность сложных багов.
позволяют использовать базу, как монолит
Это верно лишь отчасти, без оглядки на производительность. Например, наличие любой оконной функции в запросе с ORDER BY, не имеющим никакого отношения к функции шардирования, эффективно выполнится не сможет.
Как в YDB решается эта проблема?
Как в YDB решается эта проблема?
Извините, я не понял, какую проблему Вы имеете в виду. И ещё раз повторю, что шардирование - деталь реализации СУБД, и это на 99.9% прозрачно для пользователей.
Пусть есть таблица из миллиарда строк.
CREATE TABLE _tmp (
id int PRIMARY KEY NOT NULL,
val_a int NOT NULL DEFAULT 1,
val_b int NOT NULL DEFAUTL -1
)И запрос
SELECT id, SUM(val_a) OVER (ORDER BY val_b DESC) AS running_total
FROM _tmp
ORDER BY id
LIMIT 1000;Какой план будет построен планировщиком в общем и по шардам, если этих шардов, например, 100?
99.9% прозрачно для пользователей
"Прозрачно" не бывает. При оптимизации запросов в любом случае приходится учитывать особенности СУБД.
В YDB требуется, чтобы PK был уникален, поэтому я немного изменил таблицу, но это никак не влияет на план запроса:
CREATE TABLE `/ru/home/eivanov89/mydb/window_fun_example` (
id Uint64 NOT NULL,
unique_nounce Uint64 NOT NULL,
val_a int NOT NULL,
val_b int NOT NULL,
PRIMARY KEY (id, unique_nounce)
);
SELECT id, SUM(val_a) OVER (ORDER BY val_b DESC) AS running_total
FROM `/ru/home/eivanov89/mydb/window_fun_example`
ORDER BY id
LIMIT 1000;Explain вполне ожидаемый:
Большие таблицы разбиты на шарды - full scan таких таблиц затрагивает все шарды. Извините, но я по-прежнему не понимаю, почему пользователь должен о них знать.
Когда одного Postgres'a мало: сравнение производительности PostgreSQL и распределенных СУБД