Концептуально, delayed replication это фича MySQL[1], и если ее настроить - должно работать без участия wal-g. Могу предположить единственную пользу которую может принести wal-g - не хранить бинлоги за сутки на реплике... но текущая версия wal-g так не умеет - она отдает бинлоги как можно быстрее, и только в самом конце ждет когда все транзакции применятся.
Надо в табличку с выводами добавить стоимость серверов: 8, 2 и 1шт. И тогда +50% ко времени запросов за 4х кратную экономию может выглядит отличным компромиссом. Интересно посмотреть на упаковку по 3 сегмента на dom0 - должна быть 100% утилизация физическими ядрами и при умеренном ценнике.
И.. еще не очень понятно, почему есть просадка в производительности на низких (меньшее чем 12) CONCURRENCY. Я правильно понимаю, что при CONCURRENCY=4 на каждом сегменте работает 4 процесса PostgreSQL, и суммарно должно быть 16 активно перемалывающих байтики потоков на 48 физический ядер? Или PostgreSQL 9.x достаточно умный чтобы использовать все доступные ему потоки?
Интересно, что для объяснения event propagation в DOM используется React, который не обязан действовать как браузерный DOM. Но, что интересно, React так же предоставляет capturing фазу обработки событий ) <div onClickCapture={() => { /* this runs first */ }}> </div>
Да, ты прав. Пару раз видел как mysqlbinlog зависает на больших бинлогах. Но при подготовке статьи мне больше интересовала скорость наката бинлогов. На самом деле это интересный вопрос, как MySQL работает с большими бинлогами, т.к. когда в самом бинлоге event_size и next event position это int32. Но в самом MySQL position уже int64, а с недавних пор (8.0.33) и mysqlbinlog умеет int64 position. В общем, надо будет посмотреть как они запихивают int64 в int32 =)
Вот тут чуваки в соавторстве с Andy Pablo говорят что MMAP для баз данных - плохая идея: Are You Sure You Want to Use MMAP in Your Database Management System? https://www.cidrdb.org/cidr2022/papers/p13-crotty.pdf
Удивился, увидев riak : последнее, что про нее слышал это то, что компания-разработчик Basho Technologies закрылась. Пришлось погуглить - оказывается база еще живет. Ее подхватило коммьюнити и другие компании. Даже версию 3.0 выпустили.
PS: Но, в этой статье все-таки про старую (2.x) версию riak-а написано: оригинальная статья 2017го года, когда у riak-а еще была материнская компания :)
При любом отказе flush-а база остановится. Если бы flush был один - то страница с данными могла побиться. Если два - то у нас есть как минимум одна целая копия страницы.
Когда данные пишутся два раза в разные места, и между записью(write) делается flush - у нас всегда есть цельная копия странички. Страничка может быть оказаться неактуальной версии, но к странице можно применить изменения из redo log-а (во второй части статьи), и получить нужную версию.
с двойной записью все ещё непонятно: в 2 разных файла данные записываются, или как-то переносятся из одного файла в другой?
Страницы с данными пишутся дважды. Сначала пачкой в double write buffer, потом уже в положенное место (каждая страничка в своё место - здесь получается рандомная запись). Переноса данных между файлами нет - это привело бы к лишним операциям чтения.
"сам doublewrite buffer не удваивает количество IO операций - страницы в doublewrite buffer пишутся большими блоками"
Это почти прямая цитата из документации :) Теоретически - запись данных два раза должна приводить к двукратному замедлению работы базы. Но на моих замерах производительность с double write и без него - отличалась в пределах погрешности. Справедливости ради, авторы MySQL ожидают 5% замедления от double write, а разработчики из Facebook добавили innodb_doublewrite=DETECT_ONLY - который пишет только метаданные о страницах (Восстановить страницу из такого doublewrite невозможно, но понять что данные могли быть побиты - можно).
UDF-функции синхронные. Я не видел ограничений на время выполнения функции - можно попробовать заблокироваться внутри функции надолго. Фоновые вычисления порождают больше вопросов, чем ответов: например, что произойдет если пользователь вызовет DROP FUNCTION my_function; или как в итоге получить результаты вычисления =)
Пересборка UDF под linux/windows не выглядит сложной задачей. А в остальном - соглашусь: поддерживать UDF-ы на боевом проде - это не самая лучшая идея.
Концептуально, delayed replication это фича MySQL[1], и если ее настроить - должно работать без участия wal-g. Могу предположить единственную пользу которую может принести wal-g - не хранить бинлоги за сутки на реплике... но текущая версия wal-g так не умеет - она отдает бинлоги как можно быстрее, и только в самом конце ждет когда все транзакции применятся.
[1] https://dev.mysql.com/doc/refman/5.7/en/replication-delayed.html
Надо в табличку с выводами добавить стоимость серверов: 8, 2 и 1шт. И тогда +50% ко времени запросов за 4х кратную экономию может выглядит отличным компромиссом. Интересно посмотреть на упаковку по 3 сегмента на dom0 - должна быть 100% утилизация физическими ядрами и при умеренном ценнике.
И.. еще не очень понятно, почему есть просадка в производительности на низких (меньшее чем 12) CONCURRENCY. Я правильно понимаю, что при CONCURRENCY=4 на каждом сегменте работает 4 процесса PostgreSQL, и суммарно должно быть 16 активно перемалывающих байтики потоков на 48 физический ядер? Или PostgreSQL 9.x достаточно умный чтобы использовать все доступные ему потоки?
Проверил на википедии - Peter Norvig еще жив. Первое фото можно было и цветным оставить =/
Интересно, что для объяснения event propagation в DOM используется React, который не обязан действовать как браузерный DOM.
Но, что интересно, React так же предоставляет capturing фазу обработки событий )
<div onClickCapture={() => { /* this runs first */ }}> </div>Да, ты прав. Пару раз видел как
mysqlbinlogзависает на больших бинлогах. Но при подготовке статьи мне больше интересовала скорость наката бинлогов.На самом деле это интересный вопрос, как MySQL работает с большими бинлогами, т.к. когда в самом бинлоге event_size и next event position это int32. Но в самом MySQL position уже int64, а с недавних пор (8.0.33) и mysqlbinlog умеет int64 position. В общем, надо будет посмотреть как они запихивают int64 в int32 =)
Вот тут чуваки в соавторстве с Andy Pablo говорят что MMAP для баз данных - плохая идея:
Are You Sure You Want to Use MMAP in Your Database Management System? https://www.cidrdb.org/cidr2022/papers/p13-crotty.pdf
Поэтому, только если IO_DIRECT
В оригинале статья называется "How Postgres Stores Rows" - т.е. речь идет про записи, а не про varchar/text.
Выглядит как
ts-pattern. Надо будет попробовать эту библиотечку.Удивился, увидев riak : последнее, что про нее слышал это то, что компания-разработчик Basho Technologies закрылась.
Пришлось погуглить - оказывается база еще живет. Ее подхватило коммьюнити и другие компании. Даже версию 3.0 выпустили.
PS: Но, в этой статье все-таки про старую (2.x) версию riak-а написано: оригинальная статья 2017го года, когда у riak-а еще была материнская компания :)
Привет! Пара вопросов по этом "форку" PostgreSQL-я:
поддерживает ли он расширения обычного PostgreSQL?
поддерживает ли MTS Cloud эту базу данных? (На сайте вообще не нашел managed баз данных)
При любом отказе flush-а база остановится. Если бы flush был один - то страница с данными могла побиться. Если два - то у нас есть как минимум одна целая копия страницы.
Когда данные пишутся два раза в разные места, и между записью(write) делается flush - у нас всегда есть цельная копия странички. Страничка может быть оказаться неактуальной версии, но к странице можно применить изменения из redo log-а (во второй части статьи), и получить нужную версию.
Страницы с данными пишутся дважды. Сначала пачкой в double write buffer, потом уже в положенное место (каждая страничка в своё место - здесь получается рандомная запись). Переноса данных между файлами нет - это привело бы к лишним операциям чтения.
Это почти прямая цитата из документации :)
Теоретически - запись данных два раза должна приводить к двукратному замедлению работы базы. Но на моих замерах производительность с double write и без него - отличалась в пределах погрешности. Справедливости ради, авторы MySQL ожидают 5% замедления от double write, а разработчики из Facebook добавили
innodb_doublewrite=DETECT_ONLY- который пишет только метаданные о страницах (Восстановить страницу из такого doublewrite невозможно, но понять что данные могли быть побиты - можно).UDF-функции синхронные. Я не видел ограничений на время выполнения функции - можно попробовать заблокироваться внутри функции надолго.
Фоновые вычисления порождают больше вопросов, чем ответов: например, что произойдет если пользователь вызовет
DROP FUNCTION my_function;или как в итоге получить результаты вычисления =)Пересборка UDF под linux/windows не выглядит сложной задачей. А в остальном - соглашусь: поддерживать UDF-ы на боевом проде - это не самая лучшая идея.