Эволюция отказоустойчивости в PostgreSQL

[kaamos]

PostgreSQL является SQL-совместимым (SQL: 2011) и полностью соответствует требованиям ACID

Меня тут сейчас заминусуют как обычно, но это всё неправда, конечно:

• С примерами несоответствия PostgreSQL SQL стандарту можно ознакомиться здесь
• пример несоответствия D в ACID — печально известные bitmap индексы
• с примерами несоответствия I в ACID можно ознакомиться здесь

И это навскидку, наверняка можно накопать ещё примеров. Просто никто этим никогда не занимался. Все больше любят громкие красивые утверждения.

[kshvakov]

Аргументированная критика это хорошо и, возможно, это все действительно неправда, но вы действительно считаете что данные ссылки все разъясняют:

START TRANSACTION;
CREATE TABLE t (s1 SMALLINT);
INSERT INTO t VALUES (1);
INSERT INTO t VALUES (32768); /* This causes an error. */
COMMIT;
SELECT * FROM t;

Result:
MySQL finds a row containing 1. PostgreSQL finds nothing.
Reason:
PostgreSQL rolls back the entire transaction when it encounters a syntax error. MySQL only cancels the statement.

CREATE TABLE t (s1 INT);
INSERT INTO t VALUES (1);
COMMIT;
START TRANSACTION;
SELECT CURRENT_TIMESTAMP FROM t;
/* Pause 1 second. */
SELECT CURRENT_TIMESTAMP FROM t;

Result: PostgreSQL shows the same timestamp twice. MySQL shows two different timestamps.
Reason:
PostgreSQL keeps the same time throughout a transaction; MySQL keeps the same time throughout a statement.
The key sentences in the standard say that the result of a datetime value function should be the time when the function is evaluated, and «The time of evaluation of a datetime value function during the execution of S and its activated triggers is implementation-dependent.»

* при этом замечу что как раз функции (пример: clock_timestamp()) ведут себя ожидаемым образом

и т.д.

ps: я бы еще не отказался почитать о печальной известности bitmap-индексов постгреса

[kaamos]

Я перечитал это сообщение несколько раз, но так и не понял, что вы хотели сказать. Что я не прав, то есть по ссылке есть примеры несоответсвия PostgreSQL стандарту SQL? Или что я не прав, то есть по ссылке нет примеров несоответствия PostgreSQL стандарту SQL? Или смешная третья опция?

Про bitmap индексы всё просто: они не журналируются в WAL. Поэтому для них durability не существует. И репликации тоже.

[kshvakov]

1. у постгреса транзакционный DDL, он откатывает транзакцию полностью
2. функции для получения timestamp в транзакции есть и работают корректно
3. у постгреса нет bitmap индексов
4. и т.д.

очень, мягко скажем, противоричивый источник правды

[kaamos]

Источник правды там нормальный. Я знаком с человеком лично — это ходячая энциклопедия по SQL стандарту. Это человек, которого можно разбудить ночью, и спросить про любой произвольный аспект SQL стандарта. И он подробно расскажет, с примерами и аспектами реализации в разных СУБД. А ещё этот человек автор книг по SQL стандарту. Просто вы в статье пытаетесь прочитать то, чего там нет. Статья утверждает, что MySQL в некоторых вещах лучше соответствует SQL стандарту. А я статью привёл потому, что там действительно есть примеры несовместимости SQL стандарта и PostgreSQL.

Да, я говорил про hash индексы, естественно, просто закоротило провода. Но на Хабре нельзя редактировать комментарии. И т. д.

[Bozaro]

Статья все равно жёлтая: обсуждение соответствия стандарту без ссылок не то что, на сам стандарт, а даже на его название.

[kaamos]

Ну не учёл человек, что к нему строгие эксперты с Хабра придут. Иначе бы он конечно по всей форме доложился. С ссылками, цитатами и названиями стандарта.

[zubrabubra]

А можно немного подробнее почему в первом примере вообще должно произойти сохранение записей в таблицу? Даже если DDL транзакционный у Postgresql, а Mysql нет, ожидаемое поведение вероятно откатывание всех операций DML.

[kaamos]

А я здесь никаким сравнением MySQL и PostgreSQL не занимаюсь. Это у вас какой-то каскадный триггер на ключевые слова сработал. Я говорю, что два утверждения из статьи не соответствуют действительности и привожу примеры. PostgreSQL сообщество любит тиражировать такие байки.

По поводу оффтопа — я могу вам рассказать о гораздо более серьёзных проблемах в MySQL, чем каскадные триггеры. Собственно, я это уже делал на Хабре и в докладах. Но действительно оффтоп же.

[printercu]

Пришлось тут связаться с mysql, после уже долгой работы с postgresql. Как же я рад, что постгре "не саблюдает" стандарт, и DDL тоже транзакционно выполняет. Очень не удобно откатывать половину миграции, если 2я половина дала сбой.

И case-sensitivity тоже радует.

[Bozaro]

У меня, кстати, сложилось впечатление, что ни одна СУБД полностью не соответствует SQL стандарту.

Касательно статьи, можно упомянуть более простой случай, где MySQL не соответствует SQL92.
Речь идет про абзац:

13.9 <update statement: positioned>

6) The <value expression>s are effectively evaluated before updat-
   ing the object row. If a <value expression> contains a reference
   to a column of T, then the reference is to the value of that
   column in the object row before any value of the object row is
   updated.

И иллюстрируется запросом:

UPDATE foo SET a = b, b = a WHERE id = 42;

Беда в том, этот запрос в MySQL эквивалентен:

UPDATE foo SET a = b, b = b WHERE id = 42;

[kaamos]

А я кстати совершенно не спорю с утверждением «PostgreSQL лучше соответствует SQL стандарту, чем MySQL». Я кстати уже об этом писал.

Но это же совсем не то, что PostgreSQL сообщество любит говорить. PostgreSQL сообщество любит говорить «PostgreSQL является SQL-совместимым» («PostgreSQL is SQL-compliant» в оригинале). Это враньё. И rdruzyagin это знает, но старательно это враньё переводит.

[rdruzyagin]

Как главный провокатор и распространитель вранья, прокомментирую)

Алексей, рад вас видеть, мы тут как раз планировали вас пригласить к нам в гости предстоящим летом :) Надеюсь, что вы согласитесь.

По существу теперь. Соглашусь, что утверждение про полноценный ACID является преувеличенным, и, вероятно, мне стоило добавить примечание переводчика на этом месте. Посыпаю голову пеплом)

Насчет стандарта, в тексте написано, что «PG является SQL-совместимым», а не «PG строго соответствует стандарту SQL». Или я не прав, и эти два выражения надо отождествлять? Какова позиция строгих экспертов Хабра по данному вопросу (by the way, наименование стандарта, SQL:2011, он же ISO/IEC 9075:2011, все-таки упоминается в тексте, пускай и без прямой ссылки)?

Насколько я могу судить, примерно то же самое пытаются изложить разработчики СУБД в этом разделе документации: https://www.postgresql.org/docs/current/static/features.html

Я безмерно благодарен за вашу критику, Алексей, в будущем наша команда будет более внимательна в подборе материалов)

[Bozaro]

наименование стандарта, SQL:2011, он же ISO/IEC 9075:2011, все-таки упоминается в тексте, пускай и без прямой ссылки

Извиняюсь, если я был не правильно понят.
Когда я говорил про отсутствие наименования стандарта, речь шла про статью: http://ocelot.ca/blog/blog/2013/09/30/sometimes-mysql-is-more-standards-compliant-than-postgresql/

[rdruzyagin]

Понял, значит это я некорректно истолковал ваши комментарии. Внезапно развернувшаяся баталия на тему MySQL vs. PostgreSQL сбила меня с толку.

[kaamos]

Роман, спасибо за развёрнутый ответ!

На мой взгляд, нельзя соответствовать стандарту «нестрого». Стандарту можно либо соответствовать, либо нет. Поэтому утверждение «PostgreSQL is SQL-compliant (SQL:2011)» из оригинальной статьи ложно. А утвеждение из официальной документации «PostgreSQL supports most of the major features of SQL:2011» истинно. С другой стороны, утверждения «It is fully ACID compliant» и «Its SQL implementation strongly conforms to the ANSI-SQL:2008 standard» отсюда снова ложные.

Про упоминания названия стандарта — это претензия относилась не к данной статье, а моей ссылке. Если я правильно понял.

[rdruzyagin]

ОК, позиция ясна и аргумент принимается. По вопросу ACID я полностью согласен, по вопросу конформирования стандарту — не совсем, но смысла спорить не вижу :)

В дальнейшем мы постараемся обращать внимание читателя на подобные огрехи, чтобы провоцировать более вдумчивое осмысление материала и стремление к более обстоятельному изучению рассматриваемых вопросов.

[kaamos]

Хотел бы пояснить своё мнение по соответствию стандарту. Если принять, что фраза «PostgreSQL является SQL-совместимым (SQL:2011)» на самом деле означает «PostgreSQL соответствует SQL:2011 нестрого, в некоторой степени», то в этом же самом смысле можно сказать и «MySQL является SQL-совместимым (SQL:2011)». Ведь соответствует же. Нестрого, в некоторой степени, хоть и в меньшей, чем PostgreSQL. Поэтому я считаю, что с терминами нужно аккуратнее, это важный вопрос.

[merlin-vrn]

Поясните, в каком месте в статье описана именно эволюция отказоустойчивости? Эта статья — описание конкретной технологии, основанной на широко распространённой идее бинарных логов транзакций, вовсе не уникальной для PostgreSQL — та же MySQL, с которой его постоянно зачем-то сравнивают, умеет Point-In-Time Recovery с помощью своих Binary Log.

Под эволюцией я бы понял, например, такое: была тупая база, крошилась при неожиданном убивании процесса. Потом это она научилась переживать, стала крошиться только при переполнении диска. Потом с этим научились бороться, но при внезапном отключении питания всё-таки данные портились. Потом и с этим научились бороться. А потом появился мульти-мастер кластер, можно писать на любую ноду, читать с любой ноды, если одна из них выйдет из строя — никто не заметит, т.к. остальные ноды подхватят всю нагрузку. Но в статье же ничего похожего нет.

[rdruzyagin]

Эта статья — первая из цикла статей, посвященных вопросу. В ней рассматриваются более фундаментальные аспекты архитектуры СУБД. Следующие выпуски будут освещать развитие иных средств из числа доступных пользователям PostgreSQL, не охваченных в текущем выпуске. Всего будет 4 публикации. Но того уровня детализации, который вы ожидаете, точно не предвидится, вынужден разочаровать.

[merlin-vrn]

Я заметил, что предполагается цикл статей. Я протестую против слова "эволюция" в заголовке. Эволюция — это то, как что-то там изменялось со временем. Вы про это, как менялось, собираетесь рассказывать? Если нет, то это не эволюция.

Ну и, какой бы там ни предполагался цикл статей, вот этот заголовок относится к этой конкретной статье. И ей не соответствует.

[rdruzyagin]

Собираемся, конечно. Например, в следующей статье будет короткий экскурс в историю становления возможностей репликации в PostgreSQL.

Заголовок меняться не будет, из песни слов не выкинешь. Это перевод существующей публикации.