The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Началось бета-тестирование СУБД PostgreSQL 10

19.05.2017 22:58

Доступна для тестирования бета-версия СУБД PostgreSQL 10. Релиз ожидается в начале осени. Выбор номера версии 10.0 вместо 9.7.0 связано с переходом проекта на новую нумерацию выпусков. Вместо трёхуровневневой нумерации (Major1.Major2.Minor) отныне будет применяться схема "Major.Minor", в которой "Major" указывает номер значительной ветки, а "Minor" - номер корректирующего обновления, не требующего перезаливки БД. Таким образом, первым корректирующим релизом PostgreSQL 10 станет 10.1, а следующей значительной версией PostgreSQL 11. Как и раньше значительные версии будут формироваться раз в год.

Основные улучшения:

  • Режим логической репликации, позволяющий выборочно реплицировать только заданные таблицы или использовать репликацию в процессе обновления. Данный вид репликации манипулирует логическими изменениями на уровне выполняемых операций, в то время как традиционная репликация работает на очень низком уровне, перенося байтовые изменения в WAL-журнале;
  • Добавлены встроенные возможности партицирования таблиц по диапазонам значений и спискам - разбивка теперь может задаваться через выражения "PARTITION BY" и "PARTITION OF" в директиве "CREATE TABLE". Например:
    
       CREATE TABLE padre (
         id             serial not null,
         nombre         text not null,
         fch_creado     timestamptz not null
        )
       PARTITION BY RANGE ( id );
    
       CREATE TABLE hijo_0
          partition of padre (id, primary key (id), unique (nombre))
          for values from (unbounded) to (9);
    
       CREATE TABLE hijo_1
          partition of padre (id, primary key (id), unique (nombre))
          for values from (10) to (unbounded);
    
  • Обеспечено распараллеливание с задействованием нескольких ядер CPU таких операций, как сканирование индексов и битовых карт, выполнение запросов со слиянием таблиц (JOIN);
  • Возможность подтверждения коммитов на основе кворума для предотвращения потери данных после выхода из строя сразу нескольких синхронно реплицируемых узлов. Например, теперь можно указать, что коммит должен быть подтверждён любыми К из N запасных синхронно реплицируемых серверов, без жестко заданной последовательности проверки;
  • Поддержка отслеживания незавершённых коммитов - позволяет выяснить статус недавно запущенной транзакции для организации восстановления после краха или обрыва соединения;
  • Поддержка аутентификации SCRAM для организации более безопасного доступа по паролю;
  • Многохостовый режим отказоустойчивости в libpq, при котором клиент соединяется с первым работающим хостом из заданного списка;
  • Добавлен параметр "target_session_attrs", позволяющий клиенту запросить хост, доступный на запись или чтение;
  • Для индексов типа Hash обеспечена поддержка репликации и повышена устойчивость к сбоям после крахов;
  • Добавлен новый тип полномочий, определяющий доступ к функциям мониторинга;
  • Добавлено выражение XMLTABLE, позволяющее представить XML-документ в табличном формате, что существенно упрощает разбор XML-данных, хранимых в БД;
  • Поддержка полнотекстового поиска для типов JSON и JSONB;
  • Поддержка сжатия данных в журналах pg_receivewal;
  • Добавлены средства для накопления статистики по корреляции данных в разных столбцах, которая может оказаться полезной для исключения выбора планировщиком некоторых ошибочных стратегий;
  • Добавлена независимая от операционной системы реализация свойства локали "Collation", позволяющего задавать правила сортировки и методы сопоставления с учётом смысла символов. Реализация основана на libicu и идентична для Linux и Windows;
  • Увеличена производительность функции SUM(), преобразования кодировок символов, выполнение выражений, группировки множеств и выполнения операций JOIN над уникальными столбцами. При выполнении аналитических запросов над большим числом строк наблюдается ускорение до 40%;
  • Из нарушающих совместимость изменений отмечается переименование "xlog" в "wal", прекращение поддержки устаревшего протокола FE/BE 1.0, изменение настроек по умолчанию для репликации и резервирования (pg_basebackup), прекращение поддержки значений времени (Timestamps) с плавающей запятой, удаление contrib/tsearch2 и прекращение поддержки в pg_dump баз данных от PostgreSQL 7.4 и более ранних выпусков.


  1. Главная ссылка к новости (https://www.postgresql.org/abo...)
  2. OpenNews: Релиз СУБД PostgreSQL 9.6
  3. OpenNews: Министерство обороны США выпустило STIG-рекомендации для решения на базе СУБД PostgreSQL
  4. OpenNews: Рассматривается переход СУБД PostgreSQL на новую нумерацию выпусков
  5. OpenNews: Релиз СУБД PostgreSQL 9.5
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/46572-postgresql
Ключевые слова: postgresql
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (31) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 23:36, 19/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +12 +/
    Один из немногих проектов, которые стоит уважать!
     
     
  • 2.2, key (??), 00:52, 20/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    А какие еще?
     
     
  • 3.3, Аноним (-), 01:33, 20/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Линукс.
     
  • 3.5, фыва (?), 03:00, 20/05/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    болгенос
     
  • 3.55, Kodir (ok), 17:46, 23/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я вот ARJ уважаю - взял и тихо помер! Не то, что всякие "bloated kernel" - тянут и тянут... видно же, что труп! Но некрофилы не сдаются и продолжают подбрасывать мощи.
     
  • 2.12, A.Stahl (ok), 09:25, 20/05/2017 [^] [^^] [^^^] [ответить]  
  • +25 +/
    Ну начались беспочвенные дифирамбы. Вот прямо таки "из немногих"? Что, в мире есть сотня хороших проектов, а остальные -- дрянь, да? И что же отличает проекты "которые стоит уважать" от остальных? Вот OpenSSL стоит уважать? А less? Или less таки дрянь?
    P.S. Зашёл в тред и сразу почувствовал какой-то странный неприятный запах. Слабый, но раздражающий. Чуть позже понял -- Хабрахабром воняет.
     
     
  • 3.14, jh (?), 10:41, 20/05/2017 [^] [^^] [^^^] [ответить]  
  • –4 +/
    он забыл сказать опенсорс. а реально опенсорс который можно уважать можно пересчитать по пальцам двухсотпалой ладони
     
     
  • 4.15, A.Stahl (ok), 10:52, 20/05/2017 [^] [^^] [^^^] [ответить]  
  • +16 +/
    Любой свободный или хотя бы открытый проект, выполняющий какую-то полезную функцию, достоин уважения. И таких проектов сотни тысяч.
     
  • 4.50, Клыкастый (ok), 10:58, 22/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    можно задрать критерии так, что уважать не нужно никого. можно опустить планку так, что любой код будет вызывать умиление. я это к тому, что гражданин вылез со своим "уважать", а критериев не указал. а стало быть будет сра4.
     

  • 1.4, лол (?), 02:22, 20/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Где найти Docker образ с наиболее полным набором PostgreSQL расширений из коробки? Например MySQL драйвер.
     
     
  • 2.7, Аноним (-), 05:33, 20/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    hub.docker.com и да мы оценили вашу тупую шутку.
     

  • 1.6, Аноним (-), 05:28, 20/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Как я понимаю то что говорил Олег Бартунов что хотели добавить
    ● BDR — двунаправленная репликация
    http://2ndquadrant.com/en/resources/bdr/
    ● Highly Available multi-master

    Не реализовали и не войдет в PostgreSQL «10.0»
    https://youtu.be/Zn5cVaTnJ4o?t=39m6s

     
     
  • 2.49, Аноним (-), 10:29, 22/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Двунаправленная репликация, это такая конфетка на верёвочке, вроде вот ещё немного и получится, но пока ни у кого не вышло, с разумными ограничениями.

    И чем больше работаешь с БД и отказоустойчивостью, тем проще понять что оно не реализуется в "общем виде".

     

  • 1.8, angra (ok), 05:50, 20/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > Основные  улучшения :
    > -  Режим логической репликации  позволяющий выборочно реплицировать только заданные таблицы или использовать репликацию
    > в процессе обновления до новой значительной ветки. Логическая репликация манипулирует
    > логическими изменениями на уровне выполняемых операций, в то время как традиционная
    > репликация работает на очень низком уровне, перенося байтовые изменения в WAL-журнале;

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

     
     
  • 2.9, Аноним (-), 05:53, 20/05/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Не боись, vacuum никуда не делся, и pg_bouncer всё так же приходится прикручивать костылями.
     
  • 2.10, моррут (?), 06:09, 20/05/2017 [^] [^^] [^^^] [ответить]  
  • +5 +/
    это же очевидно
    логическая репликация как в мускуле не нужна, нужна как в постгресе :)
     
  • 2.25, Аноним (-), 13:45, 20/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    При штатной работе не очень нужна, а для всяких бесшовных миграций на новые версии - очень даже.
     
  • 2.38, . (?), 18:56, 20/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Мся,с-ка,well :) Это такой эдакий продугд в себе.
    Но для склада\бухгалтерии - в принципе пойдёт (если бабло больше девать некуда).
     
  • 2.46, KonstantinB (ok), 16:01, 21/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Логическая репликация как в MySQL действительно не нужна.

    А хорошая - нужна :-)

     

  • 1.18, Аноним (-), 11:05, 20/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    memory не добавили, а обещали...
     
  • 1.24, Аноним (-), 13:44, 20/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Люди подскажите плиз следующее: как можно использовать асинхронную репликацию если в случае падения мастера мы имеем не синхронный слейв который нельзя использовать как новый мастер? что используете вы асинхронную репликацию или синхронную? как догоняете слейв до мастера в случае асинхронной репликации и мастер до слейва в случае синхронной (ведь возможен вариант когда на слейв запись произошла а ответ о записе мастеру не пришел, он не записал и упал) как отслеживаете событие падения мастера? как включаете слейв мастером? как удостоверяетесь что мастер и слейв синхронны до того как пускать на них запросы?


    заранее спасибо за ответы!

     
     
  • 2.32, ъ (?), 16:39, 20/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Первое: _это_ - "вопросы от Архитектора", а не от дба. Спросите Заказчика сколько девяток ему нужно (сколько он готов платить), это сразу сформирует горизонт планирования (и отклика системы).
    Второе: Падает не только БД. Составить нужно все точки отказа. А что вы будете делать если сломается диск у пользователя и он не сможет отправить запрос к БД? А что  вы будете делать если упадет канал, сетевая карта у клиентов или у сервера и т.д. (Подсказка - закрепите в ТЗ ваш вариант уровня ответственности и следуйте ему, если нужно синхронно то так и будет).
    Третье: у каждой системы есть срок разумного использования - за это время за железо отвечает гарантия, за сервис вендоры. Ну а ДБА отвечает за бэкапы. (храните wal на отдельном сервере)
    4: Систему мониторнига обычно используют совместно.. ну и совместно дорабатывают её под задачи.
    5: В классическом постгресе есть только один мастер и много слейвов. Для начала рекомендую почитать про repmgr (настройка, промоут, фолоу)
    6: Распределение запросов на мастер (чтение и запись) и слейвы (только чтение) зависит только от проекта (от нужд заказчика).

    По по характеру вопросов могу посоветовать почитать что такое ACID и самое главное что такое транзакция и как данные видны в паралельных транзакциях.

     
     
  • 3.39, anonymous (??), 19:05, 20/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    спасибо за repmgr, почитаем.
    что такое изоляция транзакция я понимаю, причем тут это?
     
     
  • 4.52, 1 (??), 11:49, 22/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Это как раз то, чем отличается недосинхронизированный слейв от мастера
     

  • 1.28, Ilya Indigo (ok), 15:44, 20/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Ссылка на локализованную документацию актуальной версии.
    https://postgrespro.ru/docs/postgresql/9.6
    На случай, если кто-то не в курсе.
     
     
  • 2.40, Аноним (-), 19:10, 20/05/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Требую в формате комикса с цветными картинками!
     
  • 2.53, 1 (??), 11:51, 22/05/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Выложите пожалуйста на ютуб
     

  • 1.29, Аноним (-), 16:18, 20/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    >  Добавлены встроенные возможности партицирования таблиц по диапазонам значений и спискам - разбивка теперь может задаваться через выражения "PARTITION BY" и "PARTITION OF" в директиве "CREATE TABLE"

    Ура! Наконец можно забыть про партиционирование костыльным триггером!

     
  • 1.45, fwerfgergeg (?), 14:03, 21/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Когда наконец-то прикрутят pg_repack из каробки, и чтобы автоматом можно было запускать.
    Задобалось бороться с распухающими базами на сотни гигов, несмотря на автовакуумы всякие.
     
  • 1.51, Клыкастый (ok), 11:03, 22/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > -  Обеспечено распараллеливание  с задействованием нескольких ядер CPU таких операций, как сканирование индексов и битовых карт, выполнение запросов со слиянием таблиц (JOIN);

    вот хорошо же.

    > -  Добавлен новый тип полномочий, определяющий доступ к функциям  мониторинга;

    ах, как хорошо.

    > -  Увеличена производительность функции SUM(), преобразования кодировок символов, выполнение выражений, группировки множеств и выполнение операций JOIN над уникальными столбцами. При выполнении аналитических запросов над большим числом строк наблюдается ускорение до 40%;

    годнота.

    спасибо, парни. ваша работа нужна и видна.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру