LINUX.ORG.RU

PostgreSQL 10 вышел

 , , ,


1

3

5 октября 2017 Всемирная группа разработки PostgreSQL объявила о выпуске PostgreSQL 10, новой версии реляционной системы управления базами данных с открытым исходным кодом.

Критически важная особенность современных высоконагруженных систем — способность распределять данные на несколько узлов для обеспечения более быстрого доступа, управления и анализа, что известно как стратегия «разделяй и властвуй». PostgreSQL 10 содержит ряд существенных улучшений, позволяющих эффективно применять данную стратегию: нативная логическая репликация, декларативное партиционирование таблиц и улучшенное параллельное исполнение запросов.

«Наше сообщество разработчиков сфокусировано на развитии таких свойств системы, которые позволяют наиболее полно использовать возможности современных инфраструктур с распределённым характером нагрузки», — говорит Магнус Хагандер (Magnus Hagander), член основной команды Всемирной группы разработки PostgreSQL. — «Такие функции как логическая репликация и улучшенный параллелизм исполнения запросов отражают годы работы и демонстрируют постоянный фокус сообщества на обеспечении лидирующей роли PostgreSQL в условиях растущих технологических требований».

С появлением данного релиза меняется схема версий PostgreSQL, новый формат — «x.y». Это означает, что следующее минорная версия будет 10.1, а следующий мажорный релиз — 11.

Логическая репликация — фреймворк для распространения данных по модели «публикация/подписка»

Логическая репликация расширяет дополняет существующий набор видов репликации в PostgreSQL за счёт возможности передавать данные о модификации данных на уровне конкретной базы данных или на уровне таблиц в другие базы данных PostgreSQL. Пользователи теперь могут определять, какие именно данные нужно реплицировать. Кроме этого, появляется возможность выполнять переход на новые мажорные версии PostgreSQL без простоя и за счёт встроенных в ядро СУБД средств.

«Мы активно используем PostgreSQL, начиная с версии 9.3, и очень рады появлению версии 10, так как она содержит долгожданные возможности партиционирования и встроенной логической репликации. Это позволит нам использовать PostgreSQL в ещё большем количестве сервисов», — заявил Владимир Бородин, компания «Яндекс».

Декларативное партиционирование таблиц

Возможность партиционирования таблиц долгие годы присутствовала в PostgreSQL, но при этом требовала от пользователя значительных усилий по поддержке нетривиального множества правил и триггеров. В PostgreSQL 10 представлен синтаксис для партиционирования, позволяющий пользователям с лёгкостью создавать и поддерживать таблицы с интервальной или списочной схемой партиционирования. Добавление синтаксиса партиционирования — первый шаг из запланированной серии изменений, ведущих к высокопроизводительному фреймворку партиционирования в PostgreSQL.

Улучшенный параллелизм выполнения запросов

PostgreSQL 10 содержит улучшенную поддержку параллелизации выполнения запросов — ещё больше частей плана выполнения запроса теперь могут исполняться параллельно. Улучшения заключаются в том, что ещё больше типов операций сканирования данных поддаются параллелизации, а также в том, что в некоторых случаях (например, когда данные уже отсортированы) проводится дополнительная оптимизация. В итоге, пользователь получает данные намного быстрее.

Кворум-коммит для синхронной репликации

В PostgreSQL 10 появился кворум-коммит для синхронной репликации, обеспечивающий гибкость процесса оповещения основной БД о том, что изменения успешно записаны на удалённые реплики. Администратор может теперь указывать, что если определённое число реплик получило информацию об изменении, данное изменение можно рассматривать как надёжно зафиксированное.

«Кворум-коммит для синхронной репликации в PostgreSQL 10 даёт нам больше вариантов расширять нашу инфраструктуру баз данных с временем простоя работы приложений, стремящимся к нулю. Это позволяет нам непрерывно выкатывать изменения и обновлять нашу инфраструктуру без необходимости объявления длительных периодов обслуживания», — сказал Курт Микол (Curt Micol), инженер инфраструктуры в компании Simple Finance.

Аутентификация SCRAM-SHA-256

SCRAM (The Salted Challenge Response Authentication Mechanism), описанный в RFC5802, определяет протокол безопасного хранения и передачи паролей за счёт использования специального фреймворка для более строгого сопоставления паролей. В PostgreSQL 10 представлена поддержка метода SCRAM-SHA-256, описанного в RFC7677. Данный подход является намного более безопасным, чем существующий метод аутентификации с использованием MD5.

>>> Подробности



Проверено: leave ()
Ответ на: комментарий от borisych

за бабки

Вот ты к ценнику привязался. Перечитал весь тред и у меня сложилось стойкое впечатление что ты тут один оспариваешь что «бесплатное — это хорошо», ни кто больше про ценник не вспоминает. Вот только свободный софт не от «бесплатно», а от «свободно» (и свободное может не только стоить денег, оно может стоить значительно дороже «проприетарного» продукта). PostgreSQL пишут коммерческие конторы, как и любое серьезное ПО. А бсд-лайк лицензия позволяет им накладывать лапу на самые «вкусные» части своей работы — всего то.

mandala ★★★ ()
Ответ на: комментарий от borisych

Что значит неотносящаяся?

То и значит. Двухминутные (вообще, любые длинные) транзакции для OLTP --- ненормальны (это ошибка проектирования / реализации).

Robert Haas приводит в пример вполне адекватный сценарий

Адекватный чему, интересно?

(сценарий, естественно, плохой для PostgreSQL, но вполне нормальный для других СУБД)

Нет, не нормальный, от того, что ты это повторяешь, фактом это не становится. Robert Haas сетует на то, что если есть такая проблема в клиентских приложениях, решить её «со стороны PostgreSQL» очень сложно.

С разморозкой, snapshot isolation в MSSQL присутствует начиная с 2005 версии.

Ну прямо глаза мне открыл! Я, кстати, его использовал почти сразу после появления, и, чтобы ты знал, Snapshot isolation не помогает при конфликте пишущих транзакций, а совсем даже наоборот.

anonymous ()
Ответ на: комментарий от borisych

Довольно надуманно,

Абсолютно реально, и регулярно исполняется компаниями-монополистами, потому что... why not?

студенты они точно также могут больше денег запросить,

Но они совсем не точно так же пойдут нафиг.

да и не факт, что студентов получится заменить, там же априори не известно сколько будет стоить заменить одних на других.

Нда. Неудача в замене красноглазых студентов --- это просто epic win менеджмента. ;)

В случае облаков там договор заключается между компаниями, и в случае каких-то проблем можно судиться, в случае же карманного IT судиться уже не с кем.

Давай, посудись. Очень занимательное занятие, отсудишь долларов сто года через два, если повезёт. ;)

anonymous ()
Ответ на: комментарий от anonymous

это который даже план нормально показать неможет?

Задача оптимизатора --- не показывать планы, а генерировать оптимальные. Показ чего-либо в этом отношении --- отладочная возможность.

когда они работают через опу, конечно только для облегчения некоторого назначения(не кишечника часом?).

Так, интересно. А ну-ка, расскажи-ка нам, для чего же ещё нужны partition, и какими методами это ещё что-то достигается?

anonymous ()
Ответ на: комментарий от anonymous

и именно поэтому переезжают на all-flash, пилят всякие in-memory базы и героически решают проблемы консистенции, заняться видимо нечем больше.

В IT всегда чего-то «пилят» и «героически решают», а затем минимум 99% проектов исчезают на свалке истории (и большая часть из них вообще ничего не достигает). In-memory базы именно что «пилят» --- бабки очень хочется с лохов получить (это вообще систематическое явление в IT, вспомнить хоть историю того же NoSQL... и сотни аналогичных). И да, многим «заняться нечем больше». Тебя это возмущает? Хочешь им рассказать, как надо жить?

и как это исключает производительность?

Не исключает, просто её достижение не обязательно, и кроме того, для этого есть и другие пути, кроме оптимизации программ.

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

Не угадал. Так и только так работает успешный enterprise --- тот, который выживает и побеждает.

anonymous ()
Ответ на: комментарий от borisych

пара-тройка контор стригут деньги с нищебродов

рядом с

за бабки, причем ценник сравним с MSSQL

это превосходно, я считаю.

Я вот открываю EDB Postgres Subscription Plans

Мы всё ещё про PostgreSQL говорим, или уже про какой-то из десятков его fork-ов?

anonymous ()
Ответ на: комментарий от mandala

Вот ты к ценнику привязался. Перечитал весь тред и у меня сложилось стойкое впечатление что ты тут один оспариваешь что «бесплатное — это хорошо», ни кто больше про ценник не вспоминает.

Тут, действительно, несколько потерялась нить дискуссии, так что нужно напомнить. Поскольку адепты секты свидетелей автовакуума очень любят сравнивать свою СУБД с Oracle, я спросил с какой именно версией Oracle можно сравнивать PostgreSQL, а в результате получил ответ, что, якобы, Oracle создан для откатов, а наша СУБД, соответственно, самая свободная, самая бесплатная и самая лучшая в мире. Реальность же совсем другая: в то время, пока вы пишите что-то на этом форуме, представители компании Postgres профессиональный обивают пороги крупных клиентов Oracle/MSSQL в России и на волне импортозамещения пытаются этим клиентам впарить ту же самую дичь, что PostgreSQL - это самая свободная, самая бесплатная и самая лучшая СУБД в мире, однако, проблема в том, что если попытаться перейти с какой-то нормальной СУБД на PostgreSQL, то быстро вылезут подводные камни, о которых «пользователи» (на самом деле эксплуатанты) нормальных СУБД даже не задумываются, а когда адептам секты свидетелей автовакуума намекаешь, что не все так хорошо в их СУБД, как они описывают, оказывается, что некоторые вещи просто не нужны, и все отлично справляются без них (хотя в коммерческих реализациях эти вещи присутствуют), да и вообще эксплуатанты Oracle/MSSQL живут на откатах, ниже несколько (но не все) примеров.

«Мы активно используем PostgreSQL, начиная с версии 9.3, и очень рады появлению версии 10, так как она содержит долгожданные возможности партиционирования и встроенной логической репликации. Это позволит нам использовать PostgreSQL в ещё большем количестве сервисов», — заявил Владимир Бородин, компания «Яндекс».

как ранее выяснилось, в 10 версии PostgreSQL партицирования (как у конкурентов) как не было так и нет, так что чего там так долго ждал представитель компания «Яндекс» так и останется секретом, тем не менее какую-то маркетинговую чепуху протолкнули. А теперь вопрос: какие данные можно/нужно хранить в «таблице», которая не поддерживает декларативные ограничения целостности и не позволяет (прозрачно) перемещать данные из одной секции в другую? Ответ: ненужные, т.е. всякие журналы аудита (условно логи от бложика, чего бы их тогда в каком-нибудь LogStash не хранить?), при этом если смотреть на партицирование как таковое, то даже в том же Oracle польза от него в большинстве случаев довольно сомнительна, однако существует довольно ограниченное количество случаев, когда оно действительно нужно: ну вот фулсканы по секциям идут очень шустро, особенно вкупе с параллельным выполнением, а что там у нас с фулсканами в PostgreSQL? все довольно ожидаемо: мультиблочное чтение не поддерживается, получается, что на самом деле у нас не быстрая и современная СУБД, а какая-то черепаха, или даже улитка.

Есть очень интересное мнение в документации относительно резервного копирования:

pg_dump is a utility for backing up a PostgreSQL database. It makes consistent backups even if the database is being used concurrently. pg_dump does not block other users accessing the database (readers or writers).

Прикол здесь в том, что у конкурентов подобные утилиты тоже есть, однако, конкуренты их не называют средством резервного копирования - все конкуренты рекомендуют использовать point in time recovery, просто потому что у PITR минимальные RTO и RPO, на что адепты секты свидетелей автоваккума говорят: вот, смотрите, у нас есть WAL - это тоже PITR. Однако здесь не все так просто. Вообще, ситуация, когда объем журналов повтора сравним (или даже больше) объема СУБД, вполне себе такая нормальная, однако из-за особенностей реализации MVCC в PostgreSQL объемы WAL просто огромные (мало того что на каждое обновление строки еще и все индексы обновляются, так там еще и автовакуум постоянно таблицы переколбашивает), и ладно бы WAL только требовал много места на диске (с этим можно жить, но плохо), так он еще и накатывается долго из-за своего объема, т.е. если случилась беда и пришлось восстанавливаться из бэкапов, то ждать пока PostgreSQL накатит WAL придется очень и очень долго. Каким образом вендоры нормальных СУБД борятся с подобной проблемой? Ответ прост: делаем инкрементальные бекапы, в случае восстановления сначала накатываем инкрементальные бекапы, потом журналы повтора. Что там с инкрементальными бекапами в PostgreSQL? Ну вы поняли... Решение для PostgreSQL: докупайте диски и делайте полные бекапы чаще (здесь не нужно рассказывать про standby, он помогает только в случае аппаратного сбоя)

borisych ★★★★★ ()
Ответ на: комментарий от anonymous

То и значит. Двухминутные (вообще, любые длинные) транзакции для OLTP --- ненормальны (это ошибка проектирования / реализации).

Ээээ, полегче на поворотах, у поклонников PostgreSQL же реализация MVCC это особый предмет гордости: все версионники ненастоящие, только на Ъ. А тут оказывается что длинные транзакции делать нельзя. Может это только в PostgreSQL длинные транзакции нельзя, а в остальных СУБД все с этим нормально, а?

Ну прямо глаза мне открыл! Я, кстати, его использовал почти сразу после появления, и, чтобы ты знал, Snapshot isolation не помогает при конфликте пишущих транзакций, а совсем даже наоборот.

Зачем тогда были утверждения про:

откаты (transaction aborts / implicit rollbacks) --- это основа модели реализации изоляции транзакций в PostgreSQL (Serializable Snapshot Isolation). Т.е. при высокой конкуренции откатов может стать много, и, если они будут тормозить так, как в этих ваших, о производительности можно забыть

В MS SQL он бы за такое заплатил почти полной остановкой работы с этой таблицей из-за блокировок, не в курсе про Oracle

а? Т.е. какбы хотелось сказать, что вот в MSSQL все вообще плохо, потому что он блокировочник, а на самом деле с 2005 года все совсем не так.

borisych ★★★★★ ()
Ответ на: комментарий от anonymous

Задача оптимизатора --- не показывать планы, а генерировать оптимальные. Показ чего-либо в этом отношении --- отладочная возможность.

ну это же бред. Вот выдержка из документации:

It is possible to check the accuracy of the planner's estimates by using EXPLAIN's ANALYZE option. With this option, EXPLAIN actually executes the query, and then displays the true row counts and true run time accumulated within each plan node, along with the same estimates that a plain EXPLAIN shows.

А реальность такова, что explain analyze либо запускает не то, что его попросили, либо делает это не совсем так, как обычно делает клиентское приложение - забывает о существенном этапе выполнения запроса.

borisych ★★★★★ ()
Ответ на: комментарий от borisych

самая свободная, самая бесплатная и самая лучшая в мире.

Я вот, например, никогда этого не говорил. В чём-то, да, лучшая, в чём-то сильно уступает другим. И это нормально, у всех своя архитектура, плюсы и минусы. И да, миллионы долларов в разработку PostgreSQL не вливаются, и сотен full-time разработчиков там нет, поэтому «вылизанности» (вроде впиливания микрооптимизаций) ждать не стоит.

представители компании Postgres ... пытаются этим клиентам впарить ... что PostgreSQL - это самая свободная, самая бесплатная и самая лучшая СУБД в мире,

Если они действительно этим занимаются... им нужно кое-что продать, понимаешь? Поэтому они (как и Oracle, и Microsoft, и другие производители RDMBS и «консультанты»), беспардонно лгут используют маркетинговые приёмы. Такова жизнь.

однако, проблема в том, что если попытаться перейти с какой-то нормальной СУБД на PostgreSQL, то быстро вылезут подводные камни, о которых «пользователи» (на самом деле эксплуатанты) нормальных СУБД даже не задумываются,

Им очень мешает задумываться то, что они бьются головой о другие подводные камни, в своих СУБД. ;) И, кроме того, то, что в PostgreSQL что-то не так, как у них, не значит, что у них правильно.

а когда адептам секты свидетелей автовакуума намекаешь, что не все так хорошо в их СУБД, как они описывают, оказывается, что некоторые вещи просто не нужны, и все отлично справляются без них (хотя в коммерческих реализациях эти вещи присутствуют)

И да, и нет.

Некоторые вещи в коммерческие реализации добавлены для того, чтобы SQL (и методы «работы») разработчиков-идиотов худо-бедно работали (и им это выгодно, т.к. если хочешь продать, нужно ориентироваться на некомпетентное большинство). А вот проект PostgreSQL прямым текстом говорит идиотам, куда им идти, последним это не нравится, начинаются попытки поливания проекта дерьмом на форумах. Не встречался с таким? ;)

Других же вещей пока ещё нет, т.к. ресурсов (времени разработчиков, в первую очередь) у сообщества не так уж много, и их (в основном) тратят на первоочередные задачи.

как ранее выяснилось, в 10 версии PostgreSQL партицирования (как у конкурентов) как не было так и нет,

Сейчас ты нам, конечно не расскажешь, чем оно по сути отличается от такового у конкурентов (так же, как спускаешь на тормозах все опровержения своего бреда в этой ветке)?

так что чего там так долго ждал представитель компания «Яндекс» так и останется секретом, тем не менее какую-то маркетинговую чепуху протолкнули.

Чёрт его знает, чего он там ждал. По сути пока ничего не изменилось. Вообще, IMHO, PostgreSQL 10 --- это «фундаментальный» release, т.е. больших «прорывов» (user-facing features) в нём нет, зато заложен фундамент для таковых в последующих release-ах.

какие данные можно/нужно хранить в «таблице», которая не поддерживает декларативные ограничения целостности и не позволяет (прозрачно) перемещать данные из одной секции в другую?

Про DWH слышал, нет? Это «ненужные» данные, по-твоему?

ну вот фулсканы по секциям идут очень шустро, особенно вкупе с параллельным выполнением, а что там у нас с фулсканами в PostgreSQL? все довольно ожидаемо: мультиблочное чтение не поддерживается, получается, что на самом деле у нас не быстрая и современная СУБД, а какая-то черепаха, или даже улитка.

На самом деле ты не измерял разницу в производительности (а вот кто-то из разработчиков PostgreSQL измерял, AFAIR, и выяснил, что выигрыша/проигрыша от него где-то около 1%, т.е. это обычная «маркетинговая» feature), т.е. просто пытаешься вешать нам на уши улиточно-черепаховую лапшу. ;)

anonymous ()
Ответ на: комментарий от borisych

все конкуренты рекомендуют использовать point in time recovery, просто потому что у PITR минимальные RTO и RPO, на что адепты секты свидетелей автоваккума говорят: вот, смотрите, у нас есть WAL - это тоже PITR.

А ты думаешь, что у конкурентов PITR основан на чём-то другом? Пруфлинком не поделишься?

однако из-за особенностей реализации MVCC в PostgreSQL объемы WAL просто огромные (мало того что на каждое обновление строки еще и все индексы обновляются, так там еще и автовакуум постоянно таблицы переколбашивает),

Ты тут два раза частично соврал, между прочим. Зачитай про HOT и https://www.postgresql.org/docs/current/static/routine-vacuuming.html#vacuum-... .

так он еще и накатывается долго из-за своего объема,

Да, бывает, что накатывается он долго, но часто не из-за «своего объёма», а из-за того, что выполняется только одним процессом (и важно это, в первую очередь, для standby).

ждать пока PostgreSQL накатит WAL придется очень и очень долго.

Надо же... а я вот просто переключусь на реплику и всё работает дальше. Не умеешь в стратегию восстановления и пытаешься давить своим невежеством?

Каким образом вендоры нормальных СУБД борятся с подобной проблемой? Ответ прост: делаем инкрементальные бекапы, в случае восстановления сначала накатываем инкрементальные бекапы, потом журналы повтора.

Ты, наверное, путаешь с дифференциальными (а может, это у Oracle путаница в терминологии? Не смотрел, впрочем.). Инкрементальные --- это, зачастую, тот же WAL (и много ими не выиграешь).

Что там с инкрементальными бекапами в PostgreSQL? Ну вы поняли... Решение для PostgreSQL: докупайте диски и делайте полные бекапы чаще

Да, докупайте и делайте, если нужно. Т.е. not implemented yet. За цену одной лицензии от конкурентов дисками можно завалиться. ;)

(здесь не нужно рассказывать про standby, он помогает только в случае аппаратного сбоя)

Потому что ты так сказал?

anonymous ()
Ответ на: комментарий от anonymous

Про DWH слышал, нет? Это «ненужные» данные, по-твоему?

Без мультиблочного чтения-то? ну-ну

На самом деле ты не измерял разницу в производительности (а вот кто-то из разработчиков PostgreSQL измерял, AFAIR, и выяснил, что выигрыша/проигрыша от него где-то около 1%, т.е. это обычная «маркетинговая» feature), т.е. просто пытаешься вешать нам на уши улиточно-черепаховую лапшу. ;)

Ну-ну, наверное даже ссылки на этих разработчиков есть, да?

Потому что ты так сказал?

ну вот красноглазый студент, свидетель автовакуума, сделал «случайно» truncate table, или просто delete, как здесь реплика вообще поможет-то? Да никак не поможет, потому что truncate/delete уже туда реплицировался :)))

Надо же... а я вот просто переключусь на реплику и всё работает дальше. Не умеешь в стратегию восстановления и пытаешься давить своим невежеством?

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

borisych ★★★★★ ()
Ответ на: комментарий от borisych

Ээээ, полегче на поворотах, у поклонников PostgreSQL же реализация MVCC это особый предмет гордости: все версионники ненастоящие, только на Ъ.

Да, так и есть --- PostgreSQL единственный «чистый» ACID-версионник.

А тут оказывается что длинные транзакции делать нельзя. Может это только в PostgreSQL длинные транзакции нельзя, а в остальных СУБД все с этим нормально, а?

Я говорю о пишущих транзакциях. Везде их делать нельзя (это же один из базовых принципов, ты не знал?).

Зачем тогда были утверждения про:
Т.е. какбы хотелось сказать, что вот в MSSQL все вообще плохо, потому что он блокировочник, а на самом деле с 2005 года все совсем не так.

А ты перечитывай их, пока не дойдёт.

Ещё раз, для read/write транзакций, TIL SNAPSHOT при высокой конкуренции хуже, чем (блокировочный) SERIALIZABLE в MS SQL (и даже не предоставляет тех же гарантий изоляции).

anonymous ()
Ответ на: комментарий от borisych

Задача оптимизатора --- не показывать планы, а генерировать оптимальные. Показ чего-либо в этом отношении --- отладочная возможность.

ну это же бред.

А вот и нет. Кто-то тут болтал, что без «показа планов» аж кушать невозможно.

Я утверждаю, что это не так, задача оптимизатора состоит вовсе не в демонстрации планов.

А реальность такова, что explain analyze либо запускает не то, что его попросили, либо делает это не совсем так, как обычно делает клиентское приложение - забывает о существенном этапе выполнения запроса.

Да, и это недостаток. Не единственный подобного рода, кстати, и что? Почему наличие нескольких дефектов тут нам впаривают как конец света?

anonymous ()
Ответ на: комментарий от anonymous

Да, так и есть --- PostgreSQL единственный «чистый» ACID-версионник.

Doug the Head: We got sandy beaches. Avi: So who the fuck wants to see them?

Ещё раз, для read/write транзакций, TIL SNAPSHOT при высокой конкуренции хуже, чем (блокировочный) SERIALIZABLE в MS SQL (и даже не предоставляет тех же гарантий изоляции).

нужно еще какую-нибудь ссылочку дать, лучше всего чтобы там еще и про PostgreSQL было

borisych ★★★★★ ()
Ответ на: комментарий от borisych

Без мультиблочного чтения-то? ну-ну

Ну да.

Ну-ну, наверное даже ссылки на этих разработчиков есть, да?

А то. Читай до просветления: https://www.postgresql.org/message-id/flat/a86bd200-ebbe-d829-e3ca-0c4474b2fc...

ну вот красноглазый студент, свидетель автовакуума, сделал «случайно» truncate table, или просто delete, как здесь реплика вообще поможет-то?

«Красноглазым студентам» вообще мало что помогает, кроме взросления.

Да никак не поможет, потому что truncate/delete уже туда реплицировался :)))

Да ты что? Расскажи как мне, как это решается (если решается) в этом вашем? А я тебе потом расскажу как это решается в PostgreSQL.

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

Сказки здесь рассказываешь только ты, систематически.

А потом расскажи зачем при вполне разумных RTO городить стенбаи кроме как для утехи своего собственного ЧСВ.

Не знаешь / не умеешь --- почитай, зачем.

Подсказка --- вот сгорел у тебя master. Синим пламенем, да (может, и вместе с datacenter-ом). Расскажи-ка мне методы достижения наилучших RTO и RPO в этой ситуации.

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

Если ты и далее собираешься продолжать в том же духе, лучше GFTO из этого обсуждения, я тебя очень прошу.

anonymous ()
Ответ на: комментарий от anonymous

А то. Читай до просветления

Мде, доказывать на ЛОРе что-либо анонимусам занятие весьма неблагодарное, ну да ладно....

The Uber blog post, among other things, pointed out that PG uses lseek + read instead of pread. I didn't see any discussion around that and my Google searches didn't find any posts about pread / pwrite for the past 10 years.

The attached patch replaces FileWrite and FileRead with FileWriteAt and FileReadAt and removes most FileSeek calls. FileSeek is still around so we can find the end of a file, but it's not used for anything else.

On my laptop a simple pgbench run (scale 100, 15 minutes) shows a 1.5% performance improvement.

Краткое содержания написанного, для тех, кто не владеет английским:

кто-то где-то запостил, что PostgreSQL, когда читает данные, зачем-то делает seek, а потом read, вместо того чтобы делать сразу pread. Чувак сделал соответствующий патч, посмотрел улучшается производительность или нет и сказал, что изменения какбы есть, но не особо-то и значительные - всего 1.5%.

Ну хорошо, только никакого отношения к мультиблочному чтению оно не имеет. Поясню, так сказать, на пальцах. Что происходит, когда мы выбираем данные из базы используя индекс? Мы читаем индекс, получаем из него идентификаторы строк, эти идентификаторы мапим на файлы и блоки данных, потом читаем сами данные. Если в результате такого доступа по индексу мы вычитываем довольно большое количество данных из таблицы, то возможна ситуация, что индекс нам не нужен вообще, потому что, во-первых, мы тратим время на чтение самого индекса, а во-вторых, может получиться так, что один и тот же блок данных мы может прочесть несколько раз, что с точки зрения производительности оказывает негативное влияние, соответственно, располагая информацией о распределении данных в таблице оптимизатор может принять решение не использовать индекс, а читать всю таблицу целиком - на этом сходство PostgreSQL и нормальных СУБД заканчивается, потому что когда PostgreSQL принимает решение читать таблицу целиком он ее читает кусками по 8K (ага, давайте закупим сторажи, SSD, а база все равно будет читать кусками по 8K). А вот что происходит в нормальных СУБД:

  • чтение происходит кусками такого объема, который позволяет контроллер, ну скажем так, что 1MB - это такой минимум на текущий момент (в перерасчете на 8K это получается 128 блоков за раз, т.е. в 128 раз эффективнее, чем это делает PostgreSQL)
  • чтение осуществляется мимо кеша ОС и мимо кеша СУБД - нам же хочется в кеше хранить полезные данные, а не всякий мусор, PostgreSQL же при подобном чтении забивает кеш ОС мусором (там же в файлах мертвые записи лежат)

И после этого, я с удивлением читаю, что находятся индивидуумы, которые делают хранилища на PostgreSQL :)

Подсказка --- вот сгорел у тебя master. Синим пламенем, да (может, и вместе с datacenter-ом). Расскажи-ка мне методы достижения наилучших RTO и RPO в этой ситуации.

ну сгорел, дальше что? Бизнесу была предоставлена информация о возможных сбоях, он решил что такое редко происходит и доп. сервер под standby не нужен, т.е. принял риски на себя - приедет новый сервер, там будет развернут бекап.

Если ты и далее собираешься продолжать в том же духе, лучше GFTO из этого обсуждения, я тебя очень прошу.

Давай еще какие-нибудь ссылки на перлы, типа многоблочного чтения.

borisych ★★★★★ ()
Ответ на: комментарий от borisych

Ещё раз, для read/write транзакций, TIL SNAPSHOT при высокой конкуренции хуже, чем (блокировочный) SERIALIZABLE в MS SQL (и даже не предоставляет тех же гарантий изоляции).

нужно еще какую-нибудь ссылочку дать, лучше всего чтобы там еще и про PostgreSQL было

не нужно ссылок, я эту ржаку про PostgreSQL уже прочел:

Within predicate.c there are five static functions to provide an API to manage information about read-write dependencies (also referred to as rw-conflicts). This uses a double-linked list in shared memory, as it was assumed the lists would be short. Some benchmarks at high concurrency levels have seen the code in these functions take up to half the CPU time on the test machine, highlighting the O(N^2) nature of the current implementation. Rewrite these five functions to use a technique that scales better. It is likely that the function signatures will not need to change.

borisych ★★★★★ ()
Ответ на: комментарий от borisych

приедет новый сервер, там будет развернут бекап.

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

anonymous ()
Ответ на: комментарий от borisych

Мде, доказывать на ЛОРе что-либо анонимусам занятие весьма неблагодарное, ну да ладно....

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

чтение происходит кусками такого объема, который позволяет контроллер, ну скажем так, что 1MB - это такой минимум на текущий момент (в перерасчете на 8K это получается 128 блоков за раз, т.е. в 128 раз эффективнее, чем это делает PostgreSQL)

Боже мой, да ты же упоротый, как же я раньше-то не догадался. :)

Это прямо образец «компетентности» оракалоедов, и яркий пример «rocket science»-технологий, за счёт которых Oracle якобы что-то выигрывает.

Давай еще какие-нибудь ссылки на перлы, типа многоблочного чтения.

Нет уж, я, пожалуй, прекращу кормить тролля.

anonymous ()
Ответ на: комментарий от anonymous

Это прямо образец «компетентности» оракалоедов, и яркий пример «rocket science»-технологий, за счёт которых Oracle якобы что-то выигрывает.

это как-раз брильянтый пример твоей «компетентности» в вопросах физического расположения и пути данных. ты бы вместо того, чтобы расписываться в своей некомпетентности, прогнал бы dd с bs 8k и 1m, и сравнил результат.

anonymous ()
Ответ на: комментарий от anonymous

ты бы вместо того, чтобы расписываться в своей некомпетентности, прогнал бы dd с bs 8k и 1m, и сравнил результат.

Прогони, сравни, выложи, «компетентный» ты наш. Особенно хочется увидеть ускорение в 128 раз.

anonymous ()
Ответ на: комментарий от anonymous

это как-раз брильянтый пример твоей «компетентности» в вопросах физического расположения и пути данных. ты бы вместо того, чтобы расписываться в своей некомпетентности, прогнал бы dd с bs 8k и 1m, и сравнил результат.

ничего не выйдет. если забыть тот факт, что он прочел слово «эффективнее» как «быстрее», то вполне можно ожидать, что он и dd запустит на каком-нить дохлом домашнем SSD вместо полки :)

borisych ★★★★★ ()
Ответ на: комментарий от borisych

когда PostgreSQL принимает решение читать таблицу целиком он ее читает кусками по 8K (ага, давайте закупим сторажи, SSD, а база все равно будет читать кусками по 8K)

А на чём основано это утверждение? Я тут включил blktrace и вижу запросы по 240 блоков:

  8,17   3        6     0.459248777  8153  Q   R 536624 + 240 [postgres]
  8,17   3        7     0.459249332  8153  G   R 536624 + 240 [postgres]
  8,17   3        9     0.459261464  8153  Q   R 536864 + 240 [postgres]
  8,17   3       10     0.459261919  8153  G   R 536864 + 240 [postgres]
  8,17   3       12     0.459274216  8153  Q   R 537104 + 240 [postgres]
  8,17   3       13     0.459274661  8153  G   R 537104 + 240 [postgres]
  8,17   3       15     0.459287723  8153  Q   R 537344 + 240 [postgres]
  8,17   3       16     0.459288413  8153  G   R 537344 + 240 [postgres]
  8,17   3       18     0.459300639  8153  Q   R 537584 + 240 [postgres]
  8,17   3       19     0.459300991  8153  G   R 537584 + 240 [postgres]
  8,17   3       21     0.459313015  8153  Q   R 537824 + 240 [postgres]
  8,17   3       22     0.459313402  8153  G   R 537824 + 240 [postgres]
  8,17   3       24     0.459325847  8153  Q   R 538064 + 240 [postgres]
  8,17   3       25     0.459326577  8153  G   R 538064 + 240 [postgres]

Как это понимать, не подскажите?

Eshkin_kot ★★ ()
Ответ на: комментарий от Eshkin_kot

Как это понимать, не подскажите?

да никак не понимать, нужно для начала выхлоп btrace сопоставить с тем что делает в этот момент PostgreSQL - может у вас там в это время какие-то неинкрементальные бекапы идут. С помощью strace это сделать гораздо проще.

Seq Scan в PostgreSQL

brk(0x2a33000)                          = 0x2a33000
lseek(34, 0, SEEK_END)                  = 14131200
lseek(34, 0, SEEK_SET)                  = 0
read(34, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0010\1\0 \4 \0\0\0\0x\237\20\1\360\236\20\1"..., 8192) = 8192
read(34, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0010\1\0 \4 \0\0\0\0x\237\20\1\360\236\20\1"..., 8192) = 8192
read(34, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0010\1\0 \4 \0\0\0\0x\237\20\1\360\236\20\1"..., 8192) = 8192
read(34, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0010\1\0 \4 \0\0\0\0x\237\20\1\360\236\20\1"..., 8192) = 8192
read(34, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0010\1\0 \4 \0\0\0\0x\237\20\1\360\236\20\1"..., 8192) = 8192
read(34, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0010\1\0 \4 \0\0\0\0x\237\20\1\360\236\20\1"..., 8192) = 8192
read(34, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0010\1\0 \4 \0\0\0\0x\237\20\1\360\236\20\1"..., 8192) = 8192

Full scan в Oracle:

pread(256, "\6\242\0\0\341\206A\0C\222\33\1\0\0\1\4*T\0\0\1\0\0\0Cx\1\0009\222\33\1"..., 253952, 819732480) = 253952
pread(256, "\6\242\0\0\0\221A\0[\222\33\1\0\0\1\4\203E\0\0\1\0\0\0Cx\1\0009\222\33\1"..., 262144, 840957952) = 262144
pread(256, "\6\242\0\0 \221A\0[\222\33\1\0\0\2\4\26\336\0\0\1\0\0\0Cx\1\0009\222\33\1"..., 262144, 841220096) = 262144
pread(256, "\6\242\0\0@\221A\0[\222\33\1\0\0\2\4\267\r\0\0\1\0\0\0Cx\1\0009\222\33\1"..., 262144, 841482240) = 262144
pread(256, "\6\242\0\0\200\221A\0]\222\33\1\0\0\1\4\344\1\0\0\1\0\0\0Cx\1\0009\222\33\1"..., 262144, 842006528) = 262144
pread(256, "\6\242\0\0\240\221A\0]\222\33\1\0\0\2\4\34\253\0\0\1\0\0\0Cx\1\0009\222\33\1"..., 262144, 842268672) = 262144
borisych ★★★★★ ()
Ответ на: комментарий от Eshkin_kot

Как это понимать, не подскажите?

Это понимать так, что этот тупой тролль попросту врёт, и кроме того, осилил, видимо, только первое сообщение из того thread-а, ссылку на который я ему давал. ;)

anonymous ()
Ответ на: комментарий от borisych

когда PostgreSQL принимает решение читать таблицу целиком он ее читает кусками по 8K (ага, давайте закупим сторажи, SSD, а база все равно будет читать кусками по 8K)

Немного вас поправлю, как человек который эту тему достаточно долго копал: При фулскане постгрес упирается не в скорость чтения по 8к, а в скорость разбора туплов из страниц памяти. Это вообще оказывается очень дорого и ПГ умирает задолго до того как SSD начнёт тормозить. Вы тут сказали про «мапинг», которого в постгресе нету вообще. Ну т.е. там получается двойная адресация внутри страницы, а если есть большие строки то вообще тройная... Я провёл много дней с флеймграфом и всё упирается именно в это. (это если нету конкуретности) Там ещё могут быть такие ситуации если вы недавно делали альтер тейбл то надо ещё проверять версию схемы «тюпла» прежде чем его разбирать. Это всё конечно сильно оптимизированно но всё же колличество действий получается слишком много и постоянные кеш миссы.

stalkerg ★★★★★ ()