Само собой, если Вы ссылаетесь на презентацию четырехлетней давности, когда 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.
Давайте попробуем разобраться, есть ли мультимастер в 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, а из-за того, что Ваши комментарии не совпадают с реальностью.
Всё равно есть какая-то сущность, которая знает о шардах. Конечно, можно сделать шардирование прозрачно для базы, утянув всю логику в приложение. И тогда вместо разработки прикладной логики заниматься реализацией распределенных транзакций, решать вопросы, связанные с консистентностью, распределенным снепшотом, перешардированием и т.п. Это крайне сложные вещи и очень легко посадить баги.
Как я понимаю, Вы имеете в виду различные расширения и продукты на основе postgres. Некоторые из них просто шардируют, другие же занимаются реализацией полноценной распределенной СУБД. Но это не ванильный Postgres. И все эти решения появились именно за счет того, что одного Postgres'a мало - о чём мы и написали пост. К сожалению, у нас не было возможности измерить все существующие СУБД, но мы стараемся :)
Мне очень жаль, что Вы остались при своём мнении и, судя по всему, не ознакомились ни с пул реквестом, ссылку на который я дал и где есть комментарии авторов Benchbase, ни со стандартом TPC-C и сутью того, чем мы вообще занимаемся.
Мы будем рады, если Вы укажете нам на конкретные проблемы бенчмаркинга, потому что мы стараемся сделать наши результаты максимально прозрачными и верными.
Вы задались важным вопросом, как могут повлиять наши изменения на результаты бенчмарка. Наверное, стоило проговорить это более явно в самом начале поста. Наши изменения абсолютно никак не влияют на результаты. Времена всех задержек прописаны в стандарте TPC-C, они используются в оригинальном benchbase и сохранены в нашем форке. Более того, мы в процессе доработки pull request в benchbase и уже прошли ревью изменений. Что же тогда делают наши изменения? Они позволяют запустить бенчмарк на меньшем количестве железа, что позволяет снизить расходы на исследование производительности СУБД.
Повторюсь, что нам следовало разобрать более подробно некоторые базовые моменты, чтобы у Вас не возникло ощущение того, что Вам что-то впаривают. Мне кажется, что неплохим доказательством нашей добропорядочности является то, что английская версия поста сейчас на главной странице hacker news, а запостили её туда наши прямые конкуренты YugabyteDB, которые тоже используют Benchbase. Мы очень активно сотрудничаем как с ними, так и с другими конкурентами, чтобы получить честное сравнение наших баз. И именно поэтому активно вкладываемся в бенчмарки.
Да, нам нужно нагрузить БД. Для этого мы используем бенчмарк TPC-C, который написан на Java. Большое число потоков обусловлено тем, как реализован бенчмарк и совсем не связано с БД.
Сильное исправление, которое ломает весь остальной код кроме конкретного бенчмарка
Benchbase - фреймворк для написание бенчмарков и добавления СУБД. Мы оттуда используем только TPC-C. Но несложно добавить returnConnection() в другие бенчмарки, если потребуется.
У вас 700 ядер и 2,5 терабайта ram держат этакий аналог nginx.
Про nginx не понял, что имеете в виду. У нас есть СУБД (YDB и PostgreSQL). Нам нужен бенчмарк, чтобы оценить производительность. TPC-C как раз очень популярный бенчмарк для OLTP систем. Проблема оказалось в том, что общедоступная реализация TPC-C потребляет слишком много ресурсов и нам пришлось решать эту проблему, т.к. в нашем случае (YDB) речь идёт о сотнях серверов под СУБД и не вариант заводить дополнительно сотни серверов под запуск бенчмарка. Самый свежий пример: вчера один из клиентов попросил результаты TPC-C для YDB, работающей на 18 серверах (каждый 128 ядер, 1 TB RAM и 6 NVMe дисков). Без улучшений TPC-C нам бы потребовалось как минимум ещё 18 таких серверов, а с улучшениями должно хватить двух.
100 конекшенов к базе, но почему бы не юзать их в 100000 потоков.
Проблема, которую мы решали, как раз обусловлена тем, что в отличие от виртуальных крайне проблематично запустить 100K физических потоков.
Если узкое место БД, то извращения в жаве тебя не спасут.
Речь в первую очередь о клиенте (бенчмарке), а не какой-либо БД.
Ладно тупой вопрос: работать быстрее стало?))
Да, благодаря переходу на виртуальные потоки мы теперь можем запускать на одном сервере десятки и даже сотни тысяч терминалов TPC-C. А до этого приходилось запускать на нескольких серверах. Изначально мы стали оптимизировать бенчмарк по очень простой причине: чтобы нагрузить кластер YDB из 3 серверов (по 128 ядер и 512 GB RAM), требовалось 3-5 таких же серверов для запуска TPC-C. А что если мы хотим нагрузить кластер из 100 серверов? :) В этой презентации я подробно рассказал об этой и некоторых других проблемах производительности бенчмарков, которые нам пришлось решить.
Сергей, возможно, что я что-то упускаю, но мне кажется, что для полноты в обзоре явно не хватает распределенных СУБД. Например, YDB. Я привожу в пример именно YDB, потому что пост начинается с того, что речь о СУБД для российских компаний и госорганов, а YDB в отличие от её распределенных конкурентов входит в реестр отечественного ПО.
У CockroachDB во время выполнения TPC-C такое случается всего раз за запуск, после чего бенчмарк завершается ошибкой. Я предполагаю, что если бы бенчмарк не завершился, то получилась бы полочка с задержкой в 10 секунд.
Стенд у вас конечно мощный! А можно посчитать среднюю tpmС на teraflop кластера?
У нас процессор Ice lake. Согласно википедии он делает 32 FP64/cycle. Частота, когда включается turbo boost, равна 3.2 GHz. В сервере 2 чипа с 32 физическим ядрами, что дает 192 ядра на кластер. Перемножив, получаем 614.4 GFlops или 0.6144 TFlop.
Я веду практику по распределенным вычислениям у третьего и шестого курсов кафедры ВТ ИТМО. При подготовке к занятиям я пользовался этим пособием, когда оно еще не было опубликовано, и поэтому очень хорошо знаком с текстом. Очень рекомендую к прочтению всем, кто увлекается компьютерными науками: интересный и полезный материал изложен очень живо и просто, одно удовольствие читать.
В презентации указано, что требуется не только 2PC. И за четыре года так все проблемы и не решили. Из описания atomic commit of distributed transactions на вики постгреса (в презентации это слайд "Atomic Visibility"):
В этой презентации (PGCon 2020) очень хорошо рассказывают о том, почему в FDW нет ACID распределенных транзакций.
К сожалению, наш диалог так и остался неконструктивным.
https://dev.to/yugabyte/monolithic-vs-distributed-sql-5702
Давайте попробуем разобраться, есть ли мультимастер в 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, а из-за того, что Ваши комментарии не совпадают с реальностью.
Как разработчик СУБД, я бы с удовольствием послушал более конкретно об этих средствах.
Всё равно есть какая-то сущность, которая знает о шардах. Конечно, можно сделать шардирование прозрачно для базы, утянув всю логику в приложение. И тогда вместо разработки прикладной логики заниматься реализацией распределенных транзакций, решать вопросы, связанные с консистентностью, распределенным снепшотом, перешардированием и т.п. Это крайне сложные вещи и очень легко посадить баги.
Как я понимаю, Вы имеете в виду различные расширения и продукты на основе postgres. Некоторые из них просто шардируют, другие же занимаются реализацией полноценной распределенной СУБД. Но это не ванильный Postgres. И все эти решения появились именно за счет того, что одного Postgres'a мало - о чём мы и написали пост. К сожалению, у нас не было возможности измерить все существующие СУБД, но мы стараемся :)
Это текущая особенность реализации. Как я понимаю, они хотят это исправить, но в чём заключается сложность я, к сожалению, не знаю.
Мне очень жаль, что Вы остались при своём мнении и, судя по всему, не ознакомились ни с пул реквестом, ссылку на который я дал и где есть комментарии авторов Benchbase, ни со стандартом TPC-C и сутью того, чем мы вообще занимаемся.
Мы будем рады, если Вы укажете нам на конкретные проблемы бенчмаркинга, потому что мы стараемся сделать наши результаты максимально прозрачными и верными.
Нет, maxzh83 Вам выше очень верно описал суть. TPC-C это бенчмарк, дедлоки возникли именно в нём. СУБД здесь не при чём.
Вы задались важным вопросом, как могут повлиять наши изменения на результаты бенчмарка. Наверное, стоило проговорить это более явно в самом начале поста. Наши изменения абсолютно никак не влияют на результаты. Времена всех задержек прописаны в стандарте TPC-C, они используются в оригинальном benchbase и сохранены в нашем форке. Более того, мы в процессе доработки pull request в benchbase и уже прошли ревью изменений. Что же тогда делают наши изменения? Они позволяют запустить бенчмарк на меньшем количестве железа, что позволяет снизить расходы на исследование производительности СУБД.
Повторюсь, что нам следовало разобрать более подробно некоторые базовые моменты, чтобы у Вас не возникло ощущение того, что Вам что-то впаривают. Мне кажется, что неплохим доказательством нашей добропорядочности является то, что английская версия поста сейчас на главной странице hacker news, а запостили её туда наши прямые конкуренты YugabyteDB, которые тоже используют Benchbase. Мы очень активно сотрудничаем как с ними, так и с другими конкурентами, чтобы получить честное сравнение наших баз. И именно поэтому активно вкладываемся в бенчмарки.
Да, нам нужно нагрузить БД. Для этого мы используем бенчмарк TPC-C, который написан на Java. Большое число потоков обусловлено тем, как реализован бенчмарк и совсем не связано с БД.
Benchbase - фреймворк для написание бенчмарков и добавления СУБД. Мы оттуда используем только TPC-C. Но несложно добавить
returnConnection()в другие бенчмарки, если потребуется.В этом суть горутин: сделать возможным делать это максимально дёшево. И virtual threads идет к той же цели.
Про nginx не понял, что имеете в виду. У нас есть СУБД (YDB и PostgreSQL). Нам нужен бенчмарк, чтобы оценить производительность. TPC-C как раз очень популярный бенчмарк для OLTP систем. Проблема оказалось в том, что общедоступная реализация TPC-C потребляет слишком много ресурсов и нам пришлось решать эту проблему, т.к. в нашем случае (YDB) речь идёт о сотнях серверов под СУБД и не вариант заводить дополнительно сотни серверов под запуск бенчмарка. Самый свежий пример: вчера один из клиентов попросил результаты TPC-C для YDB, работающей на 18 серверах (каждый 128 ядер, 1 TB RAM и 6 NVMe дисков). Без улучшений TPC-C нам бы потребовалось как минимум ещё 18 таких серверов, а с улучшениями должно хватить двух.
В самом начале есть ссылка на наш предыдущий пост о TPC-C, где все результаты: https://habr.com/ru/companies/ydb/articles/763938/
В тексте есть ссылка на коммит с этим исправлением: https://github.com/ydb-platform/tpcc/commit/175f0c03d9c16652c85a6103331fec473017797e
Проблема, которую мы решали, как раз обусловлена тем, что в отличие от виртуальных крайне проблематично запустить 100K физических потоков.
Речь в первую очередь о клиенте (бенчмарке), а не какой-либо БД.
Да, благодаря переходу на виртуальные потоки мы теперь можем запускать на одном сервере десятки и даже сотни тысяч терминалов TPC-C. А до этого приходилось запускать на нескольких серверах. Изначально мы стали оптимизировать бенчмарк по очень простой причине: чтобы нагрузить кластер YDB из 3 серверов (по 128 ядер и 512 GB RAM), требовалось 3-5 таких же серверов для запуска TPC-C. А что если мы хотим нагрузить кластер из 100 серверов? :) В этой презентации я подробно рассказал об этой и некоторых других проблемах производительности бенчмарков, которые нам пришлось решить.
Сергей, возможно, что я что-то упускаю, но мне кажется, что для полноты в обзоре явно не хватает распределенных СУБД. Например, YDB. Я привожу в пример именно YDB, потому что пост начинается с того, что речь о СУБД для российских компаний и госорганов, а YDB в отличие от её распределенных конкурентов входит в реестр отечественного ПО.
У CockroachDB во время выполнения TPC-C такое случается всего раз за запуск, после чего бенчмарк завершается ошибкой. Я предполагаю, что если бы бенчмарк не завершился, то получилась бы полочка с задержкой в 10 секунд.
У нас процессор Ice lake. Согласно википедии он делает 32 FP64/cycle. Частота, когда включается turbo boost, равна 3.2 GHz. В сервере 2 чипа с 32 физическим ядрами, что дает 192 ядра на кластер. Перемножив, получаем 614.4 GFlops или 0.6144 TFlop.