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 ()
Ответ на: комментарий от anonymous

Ну-ну. Откуда инфа?

Откуда инфа про миллионы?

Это нормально, по-твоему, это действительно их вклад?

Мне совершенно безразлично, нормально это или нет, суть концепции PostgreSQL от этого никак не меняется: пара-тройка контор стригут деньги с нищебродов (т.е. с тех, кому на свои данные вообще плевать, потому что даже на MSSQL, который в 7 раз дешевле оракла, они раскошелиться не смогли) и при этом пытаются прикрыться шильдиком «open source», а получается как-то не очень: у того же RedHat модель такая же, однако результат при этом куда более осязаем.

Хинтов, кстати, в PostgreSQL не так уж мало (просто они так не называются).

set var=val - это не хинт, а параметр сессии, нужно быть уже совсем в отчаянии, чтобы код обрамлять лапшой из set feature=on/set feature=off, ровно такая же ситуация и с диагностикой: то что кто-то пользуется explain analyze, совершенно не означает что explain analyze чудо инженерной мысли, PostgreSQL здесь от коммерческих конкурентов отстает на пару десятков лет, и скорее всего ситуация в ближайшее время никак не изменится.

история вопиющей некомпетентности разработчиков и попыток спереть это на СУБД (начиная с того, что они пытались использовать RDBMS не по назначению

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

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

СУБД --- это в основном не про производительность (surprise!).

Спасибо, you make my day! Вот из-за таких «разработчиков» IT и катится в УГ чем дальше, тем очевиднее. ЯП у вас не про производительность, СУБД - не про производительность, браузеры - не про производительность...

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

суть концепции PostgreSQL от этого никак не меняется: пара-тройка контор стригут деньги с нищебродов (т.е. с тех, кому на свои данные вообще плевать, потому что даже на MSSQL, который в 7 раз дешевле оракла, они раскошелиться не смогли) и при этом пытаются прикрыться шильдиком «open source»

Ути-пути, какой толстенький. А ничего так, что MSSQL для Linux вышел совсем недавно, и непонятно, будет ли развиваться дальше? А ничего так, что некоторым нужно именно open source, и без иронии? Компанию, осуществляющую техподдержку PostgreSQL можно поменять относительно малой кровью, если предыдущая лопнула или загнула конский ценник. Ты можешь называть это «стригут деньги». Только те, кто сел на Oracle, будут кормить Oracle всю оставшуюся жизнь. Один раз не продлил техподдержку - Oracle с тобой дел больше не имеет.

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

Откуда инфа про миллионы?

Хмм... действительно. Тоже не могу сходу найти.

Мне совершенно безразлично, нормально это или нет

То есть, сел в лужу и пытаешься съехать.

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

Обычный FUD.

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

Просто восхитиельно. Специально для настолько долбанутых где-то на сайте sqlite, например, можно купить «лицензию» за сколько-то там тысяч долларов. А иначе долбанутым за свои данные тревожно.

set var=val - это не хинт, а параметр сессии, нужно быть уже совсем в отчаянии, чтобы код обрамлять лапшой из set feature=on/set feature=off

И в чём же различие между хинтом и параметром сессии? Дай-ка определение hint-а, кстати.

Кстати, это не все hints, и не единственный способ применения вышеуказанных.

PostgreSQL здесь от коммерческих конкурентов отстает на пару десятков лет

Ерунда. Можно увидеть что-то, кроме понтов, от «конкурентов»?

ребята хотели в базе данных хранить и обрабатывать данные, а оказывается так делать нельзя, вот сюрприз-то.

Представь себе. RDBMS предназначена, внезапно, для relational data, а, как выясняется, uber-ям было нужно key/value store. Это называется «некомпетентость».

А для чего тогда PostgreSQL нужен?

Для всего того, для чего нужна каждая реляционка. Ты хоть знаешь, зачем они нужны?

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

ЯП у вас не про производительность, СУБД - не про производительность, браузеры - не про производительность...

Да, не про производительность. Grow up. Важны только общие затраты на достижение того же результата. Которые складываются, грубо говоря, из затрат труда разработчиков программ, стоимости hardware и поддержки. Всё это переводится в деньги, и выбирается наименьшая стоимость (и это ещё в идеале). Sad, but true.

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

Есть у меня два дата центра. Хочу писать изменения в риалтайме в обоих дата центрах. Где тут 99%? Если ущербная бд не умеет мастер-мастер, то место ей в «хайлоде» вордпреса

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

Я не сильно вникал в то, как galera себя ведет при различных сценариях, так как на это не выделялись человеко-часы работы. Просто придерживаюсь золотого правила, что должно быть в онлайне минимальное количество нод чтоб кластер не развалился.

Ну ок. Если что — galera-кластер ничерта не консистентный. и позволяет dirty reads ради скорости работы. Даже в монге (уже) лучше.

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

Хочу писать изменения в риалтайме в обоих дата центрах.

Ну так есть cockroachdb специально для этого юзкейса. Оно, может, и не sql (ну, не совсем традиционная sql), но с консистентностью лучше, чем во всяких галерах и mariadb.

x3al ★★★★★ ()
Последнее исправление: x3al (всего исправлений: 1)
Ответ на: комментарий от x3al

Любители пг какието странные люди. Вместо работающего решения вечно выбираете какую-то хрень. Есть перкона и она замечательно работает. Давно. И SQL.

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

ребята хотели в базе данных хранить и обрабатывать данные

Данные бывают разные, как и способы их хранения и обработки, сюрприз? Или ты считаешь что в любой базе данных можно хранить любые данные любым способом и любым образом их обрабатывать не столкнувшись с проблемами?

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

Любители пг какието странные люди. Вместо работающего решения вечно выбираете какую-то хрень. Есть перкона и она замечательно работает. Давно. И SQL.

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

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

:) очень авторитетный источник с флеймом 2015го года. У нас вроде как 2018 уже? А как говорят в народе, с дуру можно и ... сломать.

У меня перкона стоит с самого ее начала на достаточно многих установках. Проблем не было никогда. Лично для меня я думаю это победа.

Решение есть, оно работает и не требует вмешательства. То что особые умные консультанты втирают это сугубо их дело. Мне недавно консультант на полном серьезе втирал что лет 10 назад он писал модуль для линукса для обеспечения работы ядра в реальном времени. Когда я спросил про биглок, человек сказал что он решил это хаком. Человек работает в микрософт :)

mrdeath ★★★★★ ()
Последнее исправление: mrdeath (всего исправлений: 1)
Ответ на: комментарий от mrdeath

Расскажи, чем перкона отличается от MariaDB. Если она так хороша, как про нее болтают, почему не ее, а машку ставят по умолчанию RedHat и Debian? Я в курсе, что товарищ Зайцев и какая-то тетка из его конторы мотаются по свету и всем рассказывают, как правильно готовить перкону, даже инструмент для мониторинга запилили. Но почему же по умолчанию в линуксах ставится машка? Какие у них (Percona&MariaDB) тенденции развития?

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

Представь себе. RDBMS предназначена, внезапно, для relational data, а, как выясняется, uber-ям было нужно key/value store. Это называется «некомпетентость».

От чего такой вывод что «uber-ям было нужно key/value store» появился? Вот оригинальная статья: https://eng.uber.com/mysql-migration/, первые два кейса в ней следующие:

  • Inefficient architecture for writes, далее оно идет как Write Amplification - это то, что архитектура PostgreSQL не предназначена для работы с широкими таблицами: когда мы делаем update по широкой таблице PostgreSQL не обновляет строку, а делает ее копию, а старую строку помечает неактивной (чтобы потом ее подчистил vacuum), в результате чего еще приходится и все индексы обновлять. Если бы «uber-ям было нужно key/value store», то они с такой проблемой не столкнулись бы вообще.
  • Inefficient data replication - здесь две беды: огромный трафик между репликами из-за Write Amplification, что назвали как replication amplification problem, вторая - длинные транзакции приостанавливают репликацию, в результате чего реплики довольно сильно отстают от мастера, это они назвали Replica MVCC

И то и другое - это следствие реализации MVCC в PostgreSQL (здесь фанаты PostgreSQL любят говорить что-то в духе: а вот посмотрите, в Oracle-то MVCC не настоящий! там длинные транзакции держать нельзя - ORA-01555 вылетает, да и плевать, на самом-то деле, никому теоретические возможности СУБД не интересуют, результат нужен здесь и сейчас - точно также и с хинтами в запросах: какой смысл пытаться реализовать какой-то супер-оптимизатор, предусматривающий вообще все случаи, если нужно просто поправить план выполнения для 1% запросов?)

Единственную ошибку, которую совершил Uber, - это то, что они перешли на MySQL, им нужно было пойти в Microsoft и сказать, что-то в духе: мы сейчас сделаем мега-крутую рекламу для MSSQL, я больше чем уверен что Microsoft бы еще и доплатили.

Еще более интересна реакция сообщества на эту тему - почему-то представители PostgreSQL более сдержаны в своих высказываниях, нежели фанатики, вот выдержки из https://www.postgresql.org/message-id/flat/579795DF.10502@commandprompt.com#5...

However, the issues they cite as limitations of our current replication system are real, or we wouldn't have so many people working on alternatives. We could really use pglogical in 10.0, as well as OLTP-friendly MM replication.

The write amplification issue, and its correllary in VACUUM, certainly continues to plague some users, and doesn't have any easy solutions.

The Uber guy is right that InnoDB handles this better as long as you don't touch the primary key (primary key updates in InnoDB are really bad). This is a common problem case we don't have an answer for yet.

I've seen multiple cases where this kind of thing causes a sufficiently large performance regression that the system just can't keep up. Things are OK when the table is freshly-loaded, but as soon as somebody runs a query on any table in the cluster that lasts for a minute or two, so much bloat accumulates that the performance drops to an unacceptable level. This kind of thing certainly doesn't happen to everybody, but equally certainly, this isn't the first time I've heard of it being a problem. Sometimes, with careful tending and a very aggressive autovacuum configuration, you can live with it, but it's never a lot of fun.

However, we did have issues for a couple of years where replication accuracy was poorly tested, and did have several bugs associated with that. It's not surprising that a few major users got hit hard by those bugs and decided to switch.

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

А ничего так, что MSSQL для Linux вышел совсем недавно, и непонятно, будет ли развиваться дальше?

Нет никаких сомнений, что выход MSSQL для Linux, положительная новость во всех отношениях, ценник у MSSQL весьма и весьма демократичный, так что, я надеюсь, это заставит Oracle снизить цены и собьет спесь с фанатиков PostgreSQL - я предпочту купить лицензии MSSQL вместо того, чтобы держать в штате специалистов по глубокой настройке autovacuum.

А ничего так, что некоторым нужно именно open source, и без иронии?

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

Только те, кто сел на Oracle, будут кормить Oracle всю оставшуюся жизнь. Один раз не продлил техподдержку - Oracle с тобой дел больше не имеет

Здесь неверная импликация. Можно точно также сказать, что те, кто устанавливают PostgreSQL будут кормить специалистов по глубокой настройке autovacuum всю оставшуюся жизнь - разница здесь лишь в том, что данные одних компаний стоят дешевле чем других, и логи от бложика в MSSQL или Oracle хранить не стоит. Вообще сама идея «бесплатной СУБД» несколько непонятна: вы же покупаете более-менее нормальное железо для своей СУБД, почему вы считаете что ПО при этом не должно стоить денег?

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

я еще раз повторяю. Ваш кейс с транзакцией с марсианскими опциями напоминает анекдот.

- доктор, когда я бью себе по голове, то мне больно

- а вы пробовали так не делать?

mrdeath ★★★★★ ()
Последнее исправление: mrdeath (всего исправлений: 1)
Ответ на: комментарий от borisych

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

Покупайте. Только вы через несколько лет можете обнаружить себя в глубокой зависимости от MS.

некоторым нужно именно open source

кому-то база нужна для хранения логов от бложика

:))) Вот прицепились вы с анонимусом к этому бложику.

Вы видимо не понимаете, что такое open source и для чего он нужен. Есть люди, которым критично отсутствие зависимости от одной компании. Есть разработчики, которым нужно иметь возможность накладывать патчи (так для 1С делали, например). Наконец, есть отрасли, где софт без исходников просто на порог не пустят, просто разговаривать с вами не будут (ибо сертификация на отсутствие НДВ).

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

P.S. Avito - это тоже «бложик»?

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

Разница в зависимости от одной компании (Oracle либо MS), характерная для проприетарщины. У PostgreSQL такого нет: там есть конкуренция на рынке обслуживания/поддержки, при том, что информационное ядро едино. Идеальная ситуация для грамотного потребителя.

и логи от бложика в MSSQL или Oracle хранить не стоит.

Опять мантра про бложик. Ну вы поняли.

вы же покупаете более-менее нормальное железо для своей СУБД, почему вы считаете что ПО при этом не должно стоить денег?

Тред-то перечитайте. Здесь никто не говорил, что ПО не должно стоить денег. Слово «бесплатный» появилось в контексте обсуждения высказывания одного манагера, который поносил PostgreSQL, аргументируя тем, что «бесплатные СУБД это гэ на палочке». Он, видимо, как и некоторые местные, не понимает разницу между свободным и бесплатным.

hobbit ★★★★★ ()
Последнее исправление: hobbit (всего исправлений: 5)
Ответ на: комментарий от mrdeath

ты забыл еще настройку репликации на тригерах :)

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

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

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

ну очень спорное утверждение, я бы переформулировал так: есть люди, которые вместо того, чтобы признать свою узколобость, слабоумие, зашоренность и отсутствие компетенций, ноют про vendor lock-in. Вот бизнесу, который последние лет 20 зависит от IT, глубоко плевать какая там СУБД используется, потому что бизнес руководствуется довольно простыми метриками: RTO, RPO и TCO, если вы в состоянии обеспечить требуемые RTO и RPO строя инфраструктуру из говна и палок, то честь вам и хвала, однако не забывайте, что в случае грандиозного факапа бизнес к вам придет и будет выяснять как так оказалось, что его ценнейшие данные хранились непонятно где, а потом ваши эпигоны не упустят шанса обоссать вас и свалить уже свои факапы на вас.

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

а чегой-то 1C не делали патчей для MSSQL и Oracle, неужели из-за того что последние две базы просто работают?

Наконец, есть отрасли, где софт без исходников просто на порог не пустят, просто разговаривать с вами не будут (ибо сертификация на отсутствие НДВ)

Чего? Неужели вы думаете, что в каждой конторе людям делать больше нечего, кроме как вычитывать исходный код PostgreSQL до придания глазам требуемого оттенка красного? Есть конторы, которые специализируются на сертификации ПО, и будьте уверены, что и Microsoft и Oracle уже передали свой исходный код куда нужно и нужные бумажки получили.

P.S. Avito - это тоже «бложик»?

Мелковато берете, Avito - это же площадка для торговли проститутками и солями? нужно было что-то более существенное в пример приводить.

У PostgreSQL такого нет: там есть конкуренция на рынке обслуживания/поддержки, при том, что информационное ядро едино. Идеальная ситуация для грамотного потребителя.

что то херня, что это херня - идеальная ситуация для потребителя :)

borisych ★★★★★ ()
Последнее исправление: borisych (всего исправлений: 1)
Ответ на: комментарий от borisych

От чего такой вывод что «uber-ям было нужно key/value store» появился?

А это прямо вычитывается из их проблем (т.е. для корректной реляционной архитектуры то, что они делают, как минимум странно).

И, ты смотри: http://eng.uber.com/schemaless-part-one/

Inefficient architecture for writes, далее оно идет как Write Amplification - это то, что архитектура PostgreSQL не предназначена для работы с широкими таблицами: когда мы делаем update по широкой таблице PostgreSQL не обновляет строку, а делает ее копию, а старую строку помечает неактивной (чтобы потом ее подчистил vacuum), в результате чего еще приходится и все индексы обновлять.

Это т.н. tradeoff --- такая архитектура даёт возможность мгновенного отката транзакций, что очень подходит к реализации изоляции в PostgreSQL (SSI). А упомянутый MS SQL запросто может откатывать вдвое дольше, чем «накатывать».

Если бы «uber-ям было нужно key/value store», то они с такой проблемой не столкнулись бы вообще.

С какого потолка ты это взял? Они «бы» столкнулись именно с ней. Я вот по их проблемам угадал их архитектуру, а ты просто делаешь бездоказательные заявления.

какой смысл пытаться реализовать какой-то супер-оптимизатор, предусматривающий вообще все случаи, если нужно просто поправить план выполнения для 1% запросов?

А смысл такой, что после того, как какой-то «ковбой» поправляет «здесь и сейчас» (и исчезает вдали), а потом данные-то меняются, его hint становится большей проблемой, чем изначальная (и уже может быть «закопан» где-то в коде приложения).

А, и вот ещё что: если есть возможность хинтовать, эти ковбои любят расставлять их заранее, ещё до начала эксплуатации системы (они «так видят», что будет лучше). Результат, опять же, предсказуем.

я больше чем уверен что Microsoft бы еще и доплатили

А я больше чем уверен, что людей, которые не умеют выбирать адекватные инструменты, не обращаются в техподдержку, да ещё могут потом писать статьи, представляющие «репутационные риски» для SQL Server, в Microsoft с радостью спустили бы с лестницы.

Еще более интересна реакция сообщества на эту тему - почему-то представители PostgreSQL более сдержаны в своих высказываниях, нежели фанатики,

Да, безусловно. Объективных недостатков-то хватает (а если бы их не было, можно было бы завершить разработку и разойтись ;) ). Но то, что пишет Uber, это «слышал звон», вот в чём дело.

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

ну очень спорное утверждение, я бы переформулировал так: есть люди, которые вместо того, чтобы признать свою узколобость, слабоумие, зашоренность и отсутствие компетенций, ноют про vendor lock-in.

Да нет, они руководствуются простой логикой (слышал про такое, или ты можешь только провозглашать лозунги?): vendor lock-in --- это риск. Потому что, если твой бизнес абсолютно зависит от кого-то, почему бы этому кому-то не «приставить тебе нож к горлу» и не взять с тебя столько, сколько захочет он («indeed», подумали в Oracle ;) )? А если он завтра разорится, ты готов «утонуть с этим кораблём»?

Вот бизнесу, который последние лет 20 зависит от IT, глубоко плевать какая там СУБД используется, потому что бизнес руководствуется довольно простыми метриками: RTO, RPO и TCO,

Нет такой неделимой вещи, как «бизнес». Есть организация, а в ней есть люди с разными задачами, и некоторым приходится решать, как именно достигать RTO, RPO и TCO.

если вы в состоянии обеспечить требуемые RTO и RPO строя инфраструктуру из говна и палок, то честь вам и хвала,

Опять-таки, sad but true.

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

IRL виновный давно уже там не работает, и покажет средний палец пришедшим к нему жалким банкротам. ;)

а чегой-то 1C не делали патчей для MSSQL и Oracle,

Может, из-за того, что не могут? Тебе надо объяснять очевидные вещи?

неужели из-за того что последние две базы просто работают?

Списки исправлений критических ошибок в update-ах и service pack-ах этих продуктов как бы намекают нам... ;)

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

Это т.н. tradeoff --- такая архитектура даёт возможность мгновенного отката транзакций, что очень подходит к реализации изоляции в PostgreSQL (SSI). А упомянутый MS SQL запросто может откатывать вдвое дольше, чем «накатывать».

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

А смысл такой, что после того, как какой-то «ковбой» поправляет «здесь и сейчас» (и исчезает вдали), а потом данные-то меняются, его hint становится большей проблемой, чем изначальная (и уже может быть «закопан» где-то в коде приложения).

Не становится, и причины следующие:

  • у взрослых СУБД есть средства мониторинга производительности, поэтому косяки обнаруживаются практически сразу
  • у взрослых СУБД есть возможность «хранить хинты» отдельно от запросов (в том же Oracle сущетвует чуть ли не 4 механизма: начиная от stored outlines и заканчивая sql patch)

А, и вот ещё что: если есть возможность хинтовать, эти ковбои любят расставлять их заранее, ещё до начала эксплуатации системы (они «так видят», что будет лучше). Результат, опять же, предсказуем.

это уже сугубо личные фантазии.

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

Ты же понимаешь, что master-master в SQL с ACID очень не бесплатен даже в одной стойке, а между датацентрами - это будет большая просадка производительности? Если в твоём применении это нормально, то вопросов нет. Но не всегда это допустимо.

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

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

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

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

Отчасти верно, но приемлемого мониторинга можно достичь и в PostgeSQL. Но выявление --- это только начало.

у взрослых СУБД есть возможность «хранить хинты» отдельно от запросов (в том же Oracle сущетвует чуть ли не 4 механизма: начиная от stored outlines и заканчивая sql patch)

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

это уже сугубо личные фантазии.

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

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

vendor lock-in --- это риск. Потому что, если твой бизнес абсолютно зависит от кого-то, почему бы этому кому-то не «приставить тебе нож к горлу» и не взять с тебя столько, сколько захочет он («indeed», подумали в Oracle ;) )? А если он завтра разорится, ты готов «утонуть с этим кораблём»?

Риск - это студенты с красными глазами, а компании с тысячами клиентов - это не риск, а партнеры. Да и вероятность того, что сегодня какая-нибудь компания сможет (даже если захочет) кинуть своих клиентов через бедро довольно мала - напомнить чем закончилась тяжба Oracle с HP относительно поддержки итаников?

Нет такой неделимой вещи, как «бизнес». Есть организация, а в ней есть люди с разными задачами, и некоторым приходится решать, как именно достигать RTO, RPO и TCO.

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

Может, из-за того, что не могут? Тебе надо объяснять очевидные вещи?

Все может быть, однако тем временем 1C прекрасно работает на MSSQL.

Списки исправлений критических ошибок в update-ах и service pack-ах этих продуктов как бы намекают нам... ;)

А uber врет чтоли, что у них при репликации данные бились?

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

Вообще сама идея «бесплатной СУБД» несколько непонятна: вы же покупаете более-менее нормальное железо для своей СУБД, почему вы считаете что ПО при этом не должно стоить денег?

Далеко не все IT-компании имеют возможность потратить 100500 денег на СУБД. Особенно если речь идёт о стартапе, где правильный выбор применения каждого доллара важен для выживания/развития компании.

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

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

Бгг, при высокой конкуренции PostgreSQL только и будет что чистить мусор и базы, вместо того чтобы работать. Еще раз цитату разработчика PostgreSQL приведу:

I've seen multiple cases where this kind of thing causes a sufficiently large performance regression that the system just can't keep up. Things are OK when the table is freshly-loaded, but as soon as somebody runs a query on any table in the cluster that lasts for a minute or two, so much bloat accumulates that the performance drops to an unacceptable level. This kind of thing certainly doesn't happen to everybody, but equally certainly, this isn't the first time I've heard of it being a problem. Sometimes, with careful tending and a very aggressive autovacuum configuration, you can live with it, but it's never a lot of fun.

И это, в Oracle есть микрооткаты (statement restarts) если что.

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

транзакцией с марсианскими опциями

OMFG. Уже ISOLATION LEVEL SERIALIZABLE марсианский (в проекте. над которым работаю, он кое-где требуется).

Если тебе это не надо — возьми какую-нибудь leveldb, там нет таких сложностей. Или sqlite, в конце концов. Даже монга (!) умеет в линеаризуемость в 2к17 году, а эти ваши перконы — нет.

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

Почему?

Хм... Поправлюсь:

1. Быстрый мастер-мастер между двумя датацентрами в разных странах — когда каждая транзакция не подтверждается обоими — будет откатывать транзакции если найдёт конфликты. Без вариантов. Такое делает redis и для него это замечательно (если его не пытаются пользовать как базу данных: для кэша потерять половину контента — ок, для базы данных — обычно не очень).

2. Правильный мастер-мастер может быть медленным на определённых транзакциях. Хотя он даст повышение availability (в случае если один из мастеров умрёт). Но всё же READ UNCOMMITED — не предел: на практике вполне можно сделать READ COMMITED в кластере, не дожидающемся подтверждения от каждой ноды (т.е. достаточно high available). Но из SQL-баз это реализовано не в galera и xtradb cluster (они молча дают READ UNCOMMITED даже если их попросить о гарантиях получше), а в более экзотичных базах вроде той же cockroachdb.

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

Риск - это студенты с красными глазами, а компании с тысячами клиентов - это не риск, а партнеры.

И те, и другие --- это риск. Но студентов легко заменить, в отличе от.

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

Она есть, понимаешь? И не «кинуть», а просто:

- Мы решили, что цена нужной Вам услуги/продукта с завтрашнего дня увеличивается в 10 раз.

- Но как же так, с чего это?! Мы не хотим!

- А что, у Вас есть альтернатива? Платите и заткнитесь. Второе, кстати, тоже обязательно.

напомнить чем закончилась тяжба Oracle с HP относительно поддержки итаников?

Мне это не интересно, если честно. Если имеет какое-то отношение к теме, можешь рассказать. А я вот слышал, чем заканчиваются попытки слезть с поддержки Oracle, и что?

ага, только проблема в том, что IT - это какая-то черная дыра в бюджете организации, потому что люди из IT вместо того чтобы заниматься нужными вещами сидят и денно и нощно настраивают autovacuum и репликацию на тригерах,

Или хинтуют Oracle, или shrink-ают базы MS SQL... идиотов 95%. Но всё это решается наймом адекватного руководителя IT и предоставлением ему соответствующих полномочий и ресурсов (проверено --- работает отлично). А если этого найма не происходит, может, проблема этой организации где-то в другом месте? ;)

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

Спорно. Эти менеджеры, наверное, ещё не распробовали этих самых облаков, поэтому несколько эйфоричны. А в них, как выясняется, зачастую витают не ангелы, а те же самые красноглазые угадайте кто. ;)

Все может быть, однако тем временем 1C прекрасно работает на MSSQL.

Вряд ли прекрасно. У 1С (но это когда я в последний раз интересовался, годы назад), была отвратительная архитектура, тупо перенесённая с файлового хранилища. На RDBMS нормально такое не работает.

А uber врет чтоли, что у них при репликации данные бились?

О, докатились до «А у вас негров линчуют!». ;)

Нет, не врёт, конечно. Ошибки бывают везде, и к ним надо быть готовым (не то что Uber), такие дела.

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

Далеко не все IT-компании имеют возможность потратить 100500 денег на СУБД.

Если они действительно не имеют возможности при наличии необходимости, это случай «не по Сеньке шапка», т.е. их мечты не соотвествуют их ресурсам.

Особенно если речь идёт о стартапе, где правильный выбор применения каждого доллара важен для выживания/развития компании.

Кроме бесплатных СУБД, есть и бесплатные версии коммерческих; поддержка на форумах и stackoverflow; crowdfunding, кредиты, наконец... ;)

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

Бгг, при высокой конкуренции PostgreSQL только и будет что чистить мусор и базы, вместо того чтобы работать. Еще раз цитату разработчика PostgreSQL приведу:

И приводится не относящаяся к делу цитата, прекрасно. Ты что, надеешься, что никто кроме тебя по-анлийски читать не умеет? ;)

as soon as somebody runs a query on any table in the cluster that lasts for a minute or two,

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

so much bloat accumulates that the performance drops to an unacceptable level

Enlarge your pencil, т.е. добавь hardware. ;)

И это, в Oracle есть микрооткаты (statement restarts) если что.

По сколько $ за «откат»? ;)

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

Но студентов легко заменить, в отличе от.

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

Платите и заткнитесь. Второе, кстати, тоже обязательно.

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

Вряд ли прекрасно. У 1С (но это когда я в последний раз интересовался, годы назад), была отвратительная архитектура, тупо перенесённая с файлового хранилища. На RDBMS нормально такое не работает.

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

Спорно. Эти менеджеры, наверное, ещё не распробовали этих самых облаков, поэтому несколько эйфоричны. А в них, как выясняется, зачастую витают не ангелы, а те же самые красноглазые угадайте кто. ;)

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

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

И приводится не относящаяся к делу цитата, прекрасно. Ты что, надеешься, что никто кроме тебя по-анлийски читать не умеет? ;)

Что значит неотносящаяся? Robert Haas приводит в пример вполне адекватный сценарий (сценарий, естественно, плохой для PostgreSQL, но вполне нормальный для других СУБД)

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

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

По сколько $ за «откат»? ;)

Халява, сэр.

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

Ничего так себе в PostgreSQL оптимизатор,

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

Партишены-то тут причём? Они вообще нужны для облегчения обслуживания таблиц некоторого назначения.

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

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

Да, не про производительность.

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

Важны только общие затраты на достижение того же результата.

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

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

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

зато везде пихают своё поделие. и чем это отличается?

Любители pg как правило грамотные специалисты

весьма спорное утверждение.

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

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

Обычный FUD.

Почему FUD-то? Я вот открываю EDB Postgres Subscription Plans и, о боже, оказывается, что все «ненужные» фичи есть: и анализ производительности, и хинты, и multi-master репликация, но за бабки, причем ценник сравним с MSSQL

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

причем тут вообще мария? тут разговор о постгри - перкона :)

Мода не отвечать на вопрос (или отвечать вопросом на вопрос) - 100%-й признак балабола. Или ты тут строишь из себя знатока перконы, а про Марию вообще не в курсе? Такого быть не может.

anonymous ()