Большое спасибо, что уделили внимание проекту OrioleDB!
На реплику приходят только логические изменения, и нужно найти способ их быстро применить. Единственный выход — распараллелить применение журнала, но сохранить при этом транзакционную целостность, — задача, может быть, и решаемая, но очень большой кровью.
При этом сами авторы Oriole не считают это проблемой. Параллельное применение у них используется только при восстановлении после сбоя. В этот момент база недоступна, транзакционная целостность никому не нужна. Важно лишь, чтобы система в итоге пришла в согласованное состояние. А вот при репликации критичны именно промежуточные состояния. Поэтому проект интересный, но, на мой взгляд, не очень жизнеспособный.
Вот тут вынужден не согласиться с такими сильными и такими печальными выводами. Репликация у нас работает! Просто видимость считается по минимуму между воркерами. То есть видимы те транзакции, по которым уже все воркеры отработали. Благодаря этому мы видим косистентное состояние.
Да, можно провести такую аналогию. На мой взгляд в большинстве типовых сценариев будет лучше подход на базе UNDO. Я просто хотел сказать, что в определённых ситуациях, преимущества у PostgreSQL MVCC тоже есть.
xmin/xmax необходимы для того, чтобы все обладатели всех различных снапшотов могли понять видят они данную версию или нет. Проход VACUUM в дальнейшем необходим для того чтобы найти таплы, которые уже никому не будут видны, удалить на них ссылки их индексов, а затем и сами таплы.
Я пока не ставил на эту тему экспериментов, на на мой взгляд у PostgreSQL MVCC преимущества всё же есть. Основное преимущество – обработка старых снапшотов с вменяемой производительностью, особенно в запросах, которые обрабатывают много данных. Например, у нас есть таблица, в которой за время существания снапшота каждая строка поменялась в среднем 3 раза, соответсвенно таблица распухла в 4 раза. Для того, чтобы прочитать её в соответствии со снапшотом, её нужно последовательно всю прочитать и выполнить для каждого тапла довольно простой MVCC-тест. И это одинаково и для старого стапшота и для свежего. В случае MVCC на базе undo, свежий снапшот просканирует только актуальные данные, а вот для старого снапшота мы начнём почти для каждой строки читать цепочку из в среднем 3-ёх undo-записей. И если эти undo-записи в силу своего объёма не будут закэшированы, то мы начнём на каждую undo-запись тратить реальные IOPS'ы, что выглядит катастрофой. То есть в случае существования старых снапшотов, PostgreSQL MVCC обрабатывает сканирование и по старому и по свежему снапшоту одинаково "посредственно". В случае же undo свежий снапшот будет работать хорошо, а со старым произойдёт катастрофа. Но суперпреимуществом именно для типовый сценариев я бы это не назвал. Цена (распухание + замедление свежих снапшотов) выглядит слишком высокой. Повторюсь ещё раз, что это теоретические соображения, которые я пока не проверял.
Могу сказать почему я, как первоначальный автор патча 64-битных идентификаторов транзакций, потерял к нему интерес. 1. Необходимость переодического freeze всё равно необходима исходя из структуры постгресового движка хранения. Как минимум, необходимо периодически "обрезать" SLRU, в особенности multixacts, который может неслабо распухать, в особенности после перевода на 64 бита. 2. Как было правильно написано в статье, xmin и xmax остались 32-битными, и из-за этого транзакции в рамказ страницы не могут отличаться больше чем 2^32, приходится иногда делать внутристраничный freeze и везде таскать с собой 64-битные базовые значения. Вроде бы всё это приемлемо, но создаёт некое ощущение костыльности от которого не получается избавиться. 3. Патч 64-битных идентификаторов транзакций задумывался до появления freeze map. После появления freeze map острота проблемы очень сильно спала.
В итоге патч вроде бы и полезен, но с одной стороны он не может решить проблему радикальным образом, а с другой – его очень сложно продвигать. В целом же, моё видение того как нужно радикально решать проблемы движка PostgreSQL реализовались в виде моего проекта OrioleDB.
Видно, что наибольшее количество времени процессор проводит внутри функции GetSnapshotData. Она вызывает GetTransactionSnapshot, а эта, в свою очередь, exec_eval_simple_expr.
Ну всё же наоборот. exec_eval_simple_expr вызывает GetTransactionSnapshot, а GetTransactionSnapshot вызывает GetSnapshotData. На картинке обратный стек вызовов, а не прямой.
В PostgreSQL есть подобное. Только записи WAL не объединяются, а просто процесс, который собирается сделать fsync на WAL, может подождать других. См. параметры commit_delay и commit_siblings. postgrespro.ru/docs/postgrespro/10/wal-configuration
Можно ссылку на источник по Маркусу Винанду? Просто на сайте у него тут и тут другое. Наверное, он просто на сайте ещё не обновил, нужно написать ему об этом.
Recheck в SP-GiST уже есть и кажется всегда был. См. структуру данных, которую возвращает leaf_consistent.
typedef struct spgLeafConsistentOut
{
Datum leafValue; /* reconstructed original data, if any */
bool recheck; /* set true if operator must be rechecked */
} spgLeafConsistentOut;
Патч о добавлении метода compress был на commitfest, но он как-то заглох. Будем его возобновлять. www.postgresql.org/message-id/flat/54907069.1030506@sigaev.ru#54907069.1030506@sigaev.ru
Насколько я понял отсюда, пока реализован opclass только для точек. Точки имеют ограниченный размер, поэтому для них compress не так чтобы прямо жизненно необходим. Но, конечно, с compress'ом намного лучше, мы будем им заниматься.
Извините, не удержусь от того, чтобы ответить вопросом на вопрос. Для вас Postgres-XL – это теоретическая возможность или вы его уже используете в продакшене? Если да, то какую версию?
Вот это уже слова «не мальчика, но мужа». Уважаю, без всякого сарказма!
Спасибо, я тебя тоже очень уважаю. Но ответить тем же на «не мальчика, но мужа», пока не могу (хотя надежды не оставляю). В твоих постах и комментариях на тему «PostgreSQL vs. MySQL» всё время сквозит какая-то обида. Если бы ты её преодолел, то дело продвижения MySQL только выиграло бы, ИМХО.
Интервью с Иваном Панченко я посмотрю, не думал, что вообще в нём что-то говорится о MySQL. Честно говоря, никогда не видел желания «спустить собак» на MySQL. Я бы сказал, что скорее MySQL вообще не брался в расчёт, а сравнение шло с коммерческими СУБД и NoSQL.
И Postgres Professional задаёт здесь локальный тренд как ни крути, в том числе и ты своими комментариями.
Да, задаёт. Но не вижу, где я своими комментариями задаю неправильный тренд, в том числе в тех комментариях, которые ты привёл в данной статье. Надо при этом учесть, что ты вырвал их из контекста. А эти комментарии делались под твоим провокационным постом в группе «PostgreSQL в России», что оправдывает их ироничный тон.
Ваша постгрес-профессиональная проблема заключается в абсолютно непрофессиональном подходе к дискусси с конкурентами.
Конкретно кто? Олег? Я мало вообще говорил про MySQL, дискуссии с тобой – редкое исключение. У нас в компании многим нравится MySQL. Во внутренних дискуссиях, сотрудники часто указывают на недостатки PostgreSQL и достоинства MySQL. Если во внешних дискуссиях кто-то кого-то обидел, то дай знать. Мы не можем это сами полностью контролировать, но и никому ничего не навязываем. По вопросам «проприетарности», «свободного ПО», «открытого ПО», и высказываниям на этот счёт Олега я буду разбираться. Не обещаю что это будет быстро. Но как только у меня будет законченное мнение, я его изложу.
Вообще, усиленная критика MySQL со стороны сообщества PostgreSQL – я думаю, вещь, естественная и закономерная. Дело в том, что MySQL – это действительно самая популярная в мире Open Source СУБД. И люди, которые пробовали работать с Open Source СУБД (использовать, разрабатывать и т.д.), начинали именно с MySQL. И только если их MySQL чем-то не устраивал, то они начинали знакомиться PostgreSQL (не скажу, что происходит всегда, но знаю лично много примеров). Поэтому сообщество PostgreSQL естественным образом (не потому что кто-то злые козьни строит), прошло селекцию нелюбви к MySQL, и потом активно критикует. Но в том есть своеобразная плата за популярность.
Но, по своему опыту, могу сказать, что поток критики не всегда направлен в сторону от PostgreSQL к MySQL. Довольно часто сталкивался с мнением, что PostgreSQL не нужен, потому что уже есть MySQL и он популярен; и на PostgreSQL не нужно тратить ни времени, ни сил. Аргументы при этом приводились разные, многие в духе тех, которые ты разоблачаешь. Но опыт, он у каждого свой. Бывает, что кто-то кого-то в детстве покусал. Но со временем это проходит.
P.S. Не в то место дискуссии отправил коммент. Цитата позволяет однозначно определить, что я отвечал вот на это.
Успех поста — вещь вообще никак не связанная с его качеством.
Ну, не знаю. На мой взгляд качество поста – один из факторов, влияющих на его успех. Не единственный, конечно.
Я написал хороший и качественный пост на сложную тему.
Это непреложная истина, а все кто думают по-другому – непременно врут и ведут пропаганду? :)
А сложная она исключительно потому что, что врать легко, а опровергать враньё сложно.
Вот этого я не понимаю. Почему те, кто думаю по-другому, непременно врут, а ты непременно говоришь одну лишь правду и только опровергаешь враньё?
У тебя в твоей серии постов «Памятка евангелиста» довольно много спорных и, я бы даже сказал, жульнических и манипуляторских аргументов. Зачастую приписываешь оппоненту (реальному или виртуальному) то, чего он не говорил, а потом выставляешь его дураком. Реально спорные и дискуссионные вопросы при этом обходятся стороной.
А сложная она исключительно потому что, что врать легко, а опровергать враньё сложно. На этом основана любая пропаганда.
Но ведь и ты написал свой пост в духе пропаганды. Он, как минимум, очень однобокий, избегает альтернативных мнений, и дискуссионных вопросов.
Если по сути поста сказать нечего, попробуй просто промолчать, например.
Честно скажу, что по итогам твоей серии статей «памятка евангелисту» стала вырисовываться идея статьи «разоблачаем разоблачителя». Смущает то, что это будет ещё большим разжиганием срача. И ещё какой-то подсознательный страх есть, когда видишь советские плакаты, безапелляционные суждения, а также посыпание альтернативных мнений словами «враньё» и «пропаганда» :)
В статье действительно много слов, и я своей целью ставил рассмотреть конкретные аргументы, которые набрасывает Postgres Professional. Иначе статья была бы настолько большой, что её бы вообще никто не прочитал, т.к. attention span у современного читателя довольно низкий.
Напротив, я думаю, если бы ты написал хороший пост, а не агитку, его успех был бы намного больше. Можно будет проверить. Боюсь, что не смотря на моё нежелание, в конце концов придётся мне самому придётся разобраться в теме и написать объективный и нейтральный пост на данную тему.
Я также старался сфокусироваться на сути высказываний, а не на личностях. Это не всегда просто, и если я где-то допустил ненамеренный переход на личности, пожалуйста, дай мне знать!
На мой взгляд, вырванные из контекста дискуссии скриншоты комментариев – это не самая лучшая идея (а в данном случае читатель не может увидеть контекст даже при желании). Попробуй отразить эту ситуацию зеркально на себя. Из твоих комментариев можно запросто надёргать подборку, которая дискредитирует и твою точку зрения, и тебя лично.
Я не хочу тебя обвинять в том, что ты эти комментарии злонамеренно выбирал против меня или Олега. Но хочу обратить внимание на сомнительность самой такой практики.
Мне действительно было трудно понять твою точку зрения, потому что в явном виде ты её нигде не высказывал.
Я не высказывал точку зрения, потому что её не было. Она и сейчас не сформирована полностью, потому что пока я не располагаю достаточной фактической информацией.
Если бы ты в комментариях на Facebook написал: «Я не считаю MySQL проприетарным ПО, но считаю *процесс разработки* PostgreSQL более открытым», у меня вообще бы никаких вопросов не возникало.
Так я бы не написал. Если нужна моя позиция *на текущий момент*, то её можно сформулировать следующим образом: «Я не называю никакое ПО, распространяемое под свободной лицензией проприетарным, потому что не считаю себя в этом вопросе достаточно компетентным. Но при этом считаю PostgreSQL *в целом как проект* более открытым, чем MySQL.»
Большое спасибо, что уделили внимание проекту OrioleDB!
Вот тут вынужден не согласиться с такими сильными и такими печальными выводами. Репликация у нас работает! Просто видимость считается по минимуму между воркерами. То есть видимы те транзакции, по которым уже все воркеры отработали. Благодаря этому мы видим косистентное состояние.
Да, можно провести такую аналогию.
На мой взгляд в большинстве типовых сценариев будет лучше подход на базе UNDO. Я просто хотел сказать, что в определённых ситуациях, преимущества у PostgreSQL MVCC тоже есть.
xmin/xmax необходимы для того, чтобы все обладатели всех различных снапшотов могли понять видят они данную версию или нет. Проход VACUUM в дальнейшем необходим для того чтобы найти таплы, которые уже никому не будут видны, удалить на них ссылки их индексов, а затем и сами таплы.
Я пока не ставил на эту тему экспериментов, на на мой взгляд у PostgreSQL MVCC преимущества всё же есть. Основное преимущество – обработка старых снапшотов с вменяемой производительностью, особенно в запросах, которые обрабатывают много данных.
Например, у нас есть таблица, в которой за время существания снапшота каждая строка поменялась в среднем 3 раза, соответсвенно таблица распухла в 4 раза. Для того, чтобы прочитать её в соответствии со снапшотом, её нужно последовательно всю прочитать и выполнить для каждого тапла довольно простой MVCC-тест. И это одинаково и для старого стапшота и для свежего. В случае MVCC на базе undo, свежий снапшот просканирует только актуальные данные, а вот для старого снапшота мы начнём почти для каждой строки читать цепочку из в среднем 3-ёх undo-записей. И если эти undo-записи в силу своего объёма не будут закэшированы, то мы начнём на каждую undo-запись тратить реальные IOPS'ы, что выглядит катастрофой.
То есть в случае существования старых снапшотов, PostgreSQL MVCC обрабатывает сканирование и по старому и по свежему снапшоту одинаково "посредственно". В случае же undo свежий снапшот будет работать хорошо, а со старым произойдёт катастрофа. Но суперпреимуществом именно для типовый сценариев я бы это не назвал. Цена (распухание + замедление свежих снапшотов) выглядит слишком высокой.
Повторюсь ещё раз, что это теоретические соображения, которые я пока не проверял.
Могу сказать почему я, как первоначальный автор патча 64-битных идентификаторов транзакций, потерял к нему интерес.
1. Необходимость переодического freeze всё равно необходима исходя из структуры постгресового движка хранения. Как минимум, необходимо периодически "обрезать" SLRU, в особенности multixacts, который может неслабо распухать, в особенности после перевода на 64 бита.
2. Как было правильно написано в статье, xmin и xmax остались 32-битными, и из-за этого транзакции в рамказ страницы не могут отличаться больше чем 2^32, приходится иногда делать внутристраничный freeze и везде таскать с собой 64-битные базовые значения. Вроде бы всё это приемлемо, но создаёт некое ощущение костыльности от которого не получается избавиться.
3. Патч 64-битных идентификаторов транзакций задумывался до появления freeze map. После появления freeze map острота проблемы очень сильно спала.
В итоге патч вроде бы и полезен, но с одной стороны он не может решить проблему радикальным образом, а с другой – его очень сложно продвигать.
В целом же, моё видение того как нужно радикально решать проблемы движка PostgreSQL реализовались в виде моего проекта OrioleDB.
Ну всё же наоборот. exec_eval_simple_expr вызывает GetTransactionSnapshot, а GetTransactionSnapshot вызывает GetSnapshotData. На картинке обратный стек вызовов, а не прямой.
Не совсем так. В данном патче я выступил в качестве коммиттера и соавтора, основной автор – Paul Jungwirth.
А если MPP форки на подобном железе запускать, то должно помочь и им.
postgrespro.ru/docs/postgrespro/10/wal-configuration
www.postgresql.org/message-id/CACowWR2LhVi4JHEVV=PYzLSyBfnpMd5+bhr2R8t5vzs0o79Ndw@mail.gmail.com
Скорее стоит смотеть в сторону отображения 2-мерное прямоугольника в 4-мерную точку, по аналогии с acdf2a8b372aec1da09370fca77ff7dccac7646d.
Патч о добавлении метода compress был на commitfest, но он как-то заглох. Будем его возобновлять.
www.postgresql.org/message-id/flat/54907069.1030506@sigaev.ru#54907069.1030506@sigaev.ru
Насколько я понял отсюда, пока реализован opclass только для точек. Точки имеют ограниченный размер, поэтому для них compress не так чтобы прямо жизненно необходим. Но, конечно, с compress'ом намного лучше, мы будем им заниматься.
Спасибо, я тебя тоже очень уважаю. Но ответить тем же на «не мальчика, но мужа», пока не могу (хотя надежды не оставляю). В твоих постах и комментариях на тему «PostgreSQL vs. MySQL» всё время сквозит какая-то обида. Если бы ты её преодолел, то дело продвижения MySQL только выиграло бы, ИМХО.
Интервью с Иваном Панченко я посмотрю, не думал, что вообще в нём что-то говорится о MySQL. Честно говоря, никогда не видел желания «спустить собак» на MySQL. Я бы сказал, что скорее MySQL вообще не брался в расчёт, а сравнение шло с коммерческими СУБД и NoSQL.
Да, задаёт. Но не вижу, где я своими комментариями задаю неправильный тренд, в том числе в тех комментариях, которые ты привёл в данной статье. Надо при этом учесть, что ты вырвал их из контекста. А эти комментарии делались под твоим провокационным постом в группе «PostgreSQL в России», что оправдывает их ироничный тон.
Конкретно кто? Олег? Я мало вообще говорил про MySQL, дискуссии с тобой – редкое исключение. У нас в компании многим нравится MySQL. Во внутренних дискуссиях, сотрудники часто указывают на недостатки PostgreSQL и достоинства MySQL. Если во внешних дискуссиях кто-то кого-то обидел, то дай знать. Мы не можем это сами полностью контролировать, но и никому ничего не навязываем. По вопросам «проприетарности», «свободного ПО», «открытого ПО», и высказываниям на этот счёт Олега я буду разбираться. Не обещаю что это будет быстро. Но как только у меня будет законченное мнение, я его изложу.
Вообще, усиленная критика MySQL со стороны сообщества PostgreSQL – я думаю, вещь, естественная и закономерная. Дело в том, что MySQL – это действительно самая популярная в мире Open Source СУБД. И люди, которые пробовали работать с Open Source СУБД (использовать, разрабатывать и т.д.), начинали именно с MySQL. И только если их MySQL чем-то не устраивал, то они начинали знакомиться PostgreSQL (не скажу, что происходит всегда, но знаю лично много примеров). Поэтому сообщество PostgreSQL естественным образом (не потому что кто-то злые козьни строит), прошло селекцию нелюбви к MySQL, и потом активно критикует. Но в том есть своеобразная плата за популярность.
Но, по своему опыту, могу сказать, что поток критики не всегда направлен в сторону от PostgreSQL к MySQL. Довольно часто сталкивался с мнением, что PostgreSQL не нужен, потому что уже есть MySQL и он популярен; и на PostgreSQL не нужно тратить ни времени, ни сил. Аргументы при этом приводились разные, многие в духе тех, которые ты разоблачаешь. Но опыт, он у каждого свой. Бывает, что кто-то кого-то в детстве покусал. Но со временем это проходит.
P.S. Не в то место дискуссии отправил коммент. Цитата позволяет однозначно определить, что я отвечал вот на это.
Ну, не знаю. На мой взгляд качество поста – один из факторов, влияющих на его успех. Не единственный, конечно.
Это непреложная истина, а все кто думают по-другому – непременно врут и ведут пропаганду? :)
Вот этого я не понимаю. Почему те, кто думаю по-другому, непременно врут, а ты непременно говоришь одну лишь правду и только опровергаешь враньё?
У тебя в твоей серии постов «Памятка евангелиста» довольно много спорных и, я бы даже сказал, жульнических и манипуляторских аргументов. Зачастую приписываешь оппоненту (реальному или виртуальному) то, чего он не говорил, а потом выставляешь его дураком. Реально спорные и дискуссионные вопросы при этом обходятся стороной.
Но ведь и ты написал свой пост в духе пропаганды. Он, как минимум, очень однобокий, избегает альтернативных мнений, и дискуссионных вопросов.
Честно скажу, что по итогам твоей серии статей «памятка евангелисту» стала вырисовываться идея статьи «разоблачаем разоблачителя». Смущает то, что это будет ещё большим разжиганием срача. И ещё какой-то подсознательный страх есть, когда видишь советские плакаты, безапелляционные суждения, а также посыпание альтернативных мнений словами «враньё» и «пропаганда» :)
Напротив, я думаю, если бы ты написал хороший пост, а не агитку, его успех был бы намного больше. Можно будет проверить. Боюсь, что не смотря на моё нежелание, в конце концов придётся мне самому придётся разобраться в теме и написать объективный и нейтральный пост на данную тему.
На мой взгляд, вырванные из контекста дискуссии скриншоты комментариев – это не самая лучшая идея (а в данном случае читатель не может увидеть контекст даже при желании). Попробуй отразить эту ситуацию зеркально на себя. Из твоих комментариев можно запросто надёргать подборку, которая дискредитирует и твою точку зрения, и тебя лично.
Я не хочу тебя обвинять в том, что ты эти комментарии злонамеренно выбирал против меня или Олега. Но хочу обратить внимание на сомнительность самой такой практики.
Я не высказывал точку зрения, потому что её не было. Она и сейчас не сформирована полностью, потому что пока я не располагаю достаточной фактической информацией.
Так я бы не написал. Если нужна моя позиция *на текущий момент*, то её можно сформулировать следующим образом: «Я не называю никакое ПО, распространяемое под свободной лицензией проприетарным, потому что не считаю себя в этом вопросе достаточно компетентным. Но при этом считаю PostgreSQL *в целом как проект* более открытым, чем MySQL.»