LINUX.ORG.RU

PostgreSQL 9.3

 


0

2

Вышла новая версия СУБД PostgreSQL — 9.3.

В этой версии:

  • Запись в внешние таблицы. Предыдущие версии PostgreSQL позволяли подключать к базе различные внешние источники данных, в том числе Oracle, MySQL, Redis, LDAP и многие другие. В этой версии добавилась возможность записи в такие «внешние» таблицы. Модуль postgres-fdw, предназначенный для подключения других баз PostgreSQL (базовые функции доступны с 8.1, а полная поддержка всех функций требует 8.3), также поддерживает расчет плана выполения запроса и ограниченную поддержку транзакций.
  • Улучшения надежности и доступности:
    • Опциональная проверка контрольных сумм на читаемых страничках для определения аппаратных сбоев.
    • Быстрое переключение с master на slave при сбое master'а, возможность переключения slave в master в режиме streaming-репликации.
  • Расширения PostgreSQL теперь могут запускать собственные процессы внутри сервера. Предполагается, что эта возможность будет использоваться для создания обработчиков очередей запросов, поддержки выполнения параллельных запросов, планировщиков, альтернативных протоколов и др.
  • Расширены функции для работы с JSON.
  • Материализованные и обновляемые VIEW, упрощенный синтаксис для создания рекурсивных VIEW.
  • Параллельный pg_dump.
  • Отказ от использования разделяемой памяти SysV в пользу posix версии и mmap.
  • В расширении pg_trgm добавлена возможность использования индекса при поиске по регулярным выражениям (в случаях когда из регулярного выражения удается извлечь необходимые для его срабатывания триграммы).
  • Раздельные блокировки для изменения ключевых и неключевых полей таблиц. Благодаря этому повышена производительность и заметно снизилась вероятность возникновения deadlock'ов при параллельном выполнении комплексных транзакций с использованием внешних ключей.

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

★★★★★

Последнее исправление: maxcom (всего исправлений: 15)

Ответ на: комментарий от Virus

Почему LAMP больше распространён, чем LAPP? Вот, что я имел в виду.

А вы попробуйте произнести вслух аббревиатуры ;)

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

Иногда перестроением (физического) порядка можно увеличить производительность.

Это данные по постгресу или костыли исключительно для дурного планировщика мускля?

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

Это данные по постгресу или костыли исключительно для дурного планировщика мускля?

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

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

Что там такого непосильного? SQL нестандартный?

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

Предупреждая следующий вопрос. Документация отличная. Просто она написана для тех, кто понимает, что такое RDBMS. Т.е. читал, например, Дейта.

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

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

что делает mysql - меняет только порядок отображения

this. Иначе бы ALTER TABLE занимал месяцы на таблицах в пару сотен миллионов строк

GateKeeper ★★
()
Ответ на: комментарий от no-dashi

...оне вот настоясчий ынтырЪпрайзЪ!»
no-dashi ★★★★★ (11.09.2013 7:37:40)

Офигеть.

ВПЕРВЫЕ полностью, на 100% согласен с нодашей ... 8-о

Где меня кидают? :)

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

Востребована. В т.ч. мастер-мастер :) Что с этим под Postrge? Как реализовать репликацию по кольцу, чтобы внесённые на любой ноде изменения оказывались на всех других нодах?

Штатными средствами, без костылей. То, что в MySQL симулирует работу, в PostgreSQL спокойно пишут чтобы работало как надо. Оттюнить PostgreSQL он не осилил, DBA такая, посмотрите вы на неё!

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

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

SQLite.

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

я не копался в этом настолько, но думаю что решение можно найти в любом случае

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

все равно это непорядок и потенциальный крах

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

Чем уж так сильно различаются сабж и MySQL, что последний распространённее?

IMHO, причина исключительно в известности самого названия: хомячки выбирают мускуль потому, что про существование не стоящих сотни нефти альтернатив ничего не знают, хостеры этим пользуются и завлекают клиентов ценами на шареды с искоробочным MySQL, разработчики CMS и т.п. тоже не отстают ради увеличения пользовательской базы, ынтырпрайзы предпочитают ораклы всякие, остальные (не [совсем] хомячки, но и не ынтырпрайз) тоже не всегда могут выбирать из-за тех же фреймворков.

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

СУБД тебе для этого не нужна.

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

Типичный ответ быдлокодера. Аватарка доставила.

anonymous
()

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

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

мастер-мастер - Postgre-XC. Это почти 1 в 1 то что у Мускуля.

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

научите (ссылкой, например) делать репликацию MySQL вида мастер-мастер.

С конкретными конфигами не помогу, только пальцем ткну. При чём я работал только с тремя серверами в кольце, но, по идее, два сервера — будет то же самое.

— Настраиваем репликацию master-slave с сервера S1 на S2.
— На сервере S2 пишем бинлоги реплики
— У сервера S1 указываем мастером S2 с его, в свою очередь бинлогами

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

На обоих серверах нужно указать шаг автоинкремента в 2 (т.е. новое значение на 2 больше предыдущего), но для каждого сервера — разное смещение инкремента. Для одного 0, для другого — 1. Тогда один будет генерировать только чётные записи, другой — нечётные.

Ну и потенциально могут быть проблемы с уникальными ключами, если они заполняются не автоинкрементно. Тут уже надо разбираться в частных случаях. Скажем, если у нас уникальная запись — это IP посетителя в статистике, то или вводить дополнительное поле «№ сервера» и делать уникальным не IP, а составной ключ, IP,№, или выводить такую статистику в отдельную нереплицируемую базу.

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

… необходимо озаботиться об отсутствии конфликтов …

То есть репликация убивает ACID. Налицо подмена понятий, когда за «мастер-мастер репликацию RDBMS» выдают нечто другое.

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

Налицо подмена понятий, когда за «мастер-мастер репликацию RDBMS» выдают нечто другое.

Мне важно, чтобы ехало, а не чтобы с шашечками :) Отсутствие конфликтов с автоинкрементом ты иначе ни в какой системе не получишь.

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

Мне важно, чтобы ехало, а не чтобы с шашечками :)

Так спору нет, но «едет» уже не RDBMS.

Отсутствие конфликтов с автоинкрементом ты иначе ни в какой системе не получишь.

Есть кластер Postgres-XC. Там пока, ИМХО, триггеры ещё не до конца прикрутили и лоск не навели, но пользоваться уже вполне возможно.

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

baka-kun ★★★★★
()
Ответ на: комментарий от KRoN73

и тем не менее

Мне важно, чтобы ехало, а не чтобы с шашечками :) Отсутствие конфликтов с автоинкрементом ты иначе ни в какой системе не получишь.

Важно, что бы и терминология была правильна, иначе люди не понимают.

в PsotgreSQL прекрасно работает stream replication собственно она может работать каскадной

переползание на другую ноду проходит вполне спокойно

и при этом легко превратить бывший мастер в slave

у меня работают 4-ре ноды

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

PavelAnd
()

вкусный...

молодцы...

надо обновляться...

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

Кстати, поддержка собственных процессов переводит этот сервер баз данных в разряд серверов приложений. Или я не прав?

Да вроде не с чего. Откуда такой смелый вывод?

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

Ну, сервер приложений — это, по сути, ОС над ОС. Фреймворк над API базовой операционной системы, предоставляющий те же основные сервисы, но в структурированном виде. А именно: процессы, память и коммуникацию.

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

Сервера же приложений обычно активны. Они содержат постоянно запущенные процессы, выполняющие активную логику приложений.

Если PostgreSQL теперь может запускать долгоживущие процессы, я больше не вижу функциональной разницы между ним и, скажем, JBoss AS. Понятно, что последний куда более структурирован именно как сервер приложений. Но PostgreSQL теперь может выполнять всю ту же работу, только с более эффективным доступом к локальным данным :)

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

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

Если PostgreSQL теперь может запускать долгоживущие процессы, я больше не вижу функциональной разницы между ним и, скажем, JBoss AS.

У вас в голове каша.

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

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

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

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

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

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

У вас в голове каша.

Это не каша, а творческий процесс.

Например, тот же вакум, бэкапы, перестройка индексов в фоне, сбор статистики, мониторинг и многое другое.

...и многое другое.

Ну так что мне мешает «задеплоить» в СУБД веб-сервер и пользоваться преимуществом низкой латентности обращения к локальным данным?

Ладно, я понял. ОС из СУБД делать никто не собирается :)

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

при помощи рукописного скрипта с rsync?:)

ну мы все взрослые и читали как готовится slave :)

для stream replication без rsync никуда

он как бы изначально там деется через синхронизацию и только потом начинает wal ловить

но по сути если переход происходит недалече (просто сервак отрестартили или нечто подобное) то разница в данных там копееечная и приходит в норму шустро

если у кого-то будет желание, то я опишу как настраивали OpenAIS и положу скрипты для мастера и ведомого

PavelAnd
()

Кстати, давеча предметно обсуждали косяки в монге и посгресе (когда я впервые узнал, что посгрес без останова не проапгрейдить). Хочу к монге плюху добавить. Оказывается она на range+sort запросах не умеет нормально индексы использовать. Поэтому на многоколоночных условиях возникают вот такие compound-индексы:

[directs, sorted, ranged] вместо [directs, ranged, sorted]

Причем условие { a: { $in: [1,2,3] }} считается ranged. Я почему-то думал, что уж простые индексы, которые в сиквеле давно пашут, в монге тоже пашут всегда. А оказывается у них там конь не валялся. Вроде собираются частично пофиксить в 2.6.0.

http://blog.mongolab.com/2012/06/cardinal-ins/
https://jira.mongodb.org/browse/SERVER-3310

Шел 2013 год...

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

ну а вот мне все это жонглирование со скриптами не говорит о взрослости. сложно представить инструкцию по базе Oracle, где написано «напишите следующий скрипт с rsync», да? поэтому я высказывание о легкости поставил под сомнение.

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

ну а вот мне все это жонглирование со скриптами не говорит о взрослости. сложно представить инструкцию по базе Oracle, где написано «напишите следующий скрипт с rsync», да? поэтому я высказывание о легкости поставил под сомнение.

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

открывая параграф stream replication в доке PostgreSQL мы читаем четкую последовательность действий, как готовить мастер, как готовить slave и если считать перенесение этой информации в скрипт, не побоюсь этого слово «карающим богохульством» то не в полне понимаю зачем нам *nix давай все под винду, там все просто, но нихрена нельзя.

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

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

Я почему-то думал, что уж простые индексы, которые в сиквеле давно пашут, в монге тоже пашут всегда

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

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

подрастут и доработают индексы

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

Доработают конечно, в тикетах же забито. Просто как-то уж слишком неожиданно вышло. Вплоть до такого:

https://github.com/nodeca/nodeca.forum/blob/master/server/forum/section/list/...
https://github.com/nodeca/nodeca.forum/blob/master/models/forum/Topic.js#L69

Если делать выборку одним запросом (сразу выбирать документы, а не сначала _id, и потом документы по ним), то будет сортировка датасета в памяти, и на большом skip станет грустно. Почему планировщик сам такое не разруливает на covered index - так и не понял, хотя перерыл пол гугля (ссылки в комментах).

IMHO, о таких edge cases надо заранее предупреждать.

Vit ★★★★★
()

Ну так, вопрошающим по LAMP историческая справка. Буквально каких-то 13-14 лет назад было очень четкое разделение - для тех, кому нужна была тупая хранилка данных с псевдо-SQL языком, был MySQL 3.х. Для 98% тогдашних веб приложений этого хватало. Худо-бедно конкурентный доступ к данным был, и ладно. Для хлопцев с запросами повыше, типа хранимок, триггеров, плюс-минус вменяемой версией SQL (близкой к стандарту) - из открытых был только PostgreSQL 6.5 (кстати, даже foreign keys не поддерживал напрямую, только писаниной триггеров руками). Interbase 6 так и не смог отвоевать места под солнцем.

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

Если сейчас - самый близкий аналог MySQL 3.x это SQLite, современный мускул по функциональности догоняет постгрес 7 наверное (местами лучше, местами хуже).

Еще про позиционирование - так уж с тех же 2000х повелось, что MySQL позиционировал себя как простую и быструю СУБД, PG всегда претендовал на замену толстых энтерпрайзов. Вот отсюда и LAMP (а еще любовь янки к «красивым» аббревиатурам), а не LAPP.

Для меня решающим моментом при выборе в 2000 стала консоль - у PG она уже тогда была приятная, на MySQL как была говном, так и осталась.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.