LINUX.ORG.RU

UPSERT и не только. Что ждать от PostgreSQL 9.5?

 


6

6

2 июля вышла PostgreSQL 9.5 alpha. Среди основных улучшений можно отметить:

  • BRIN-индексы («индексы блоковых зон»), позволяющие сверхкомпактно индексировать очень большие таблицы.
  • Существенные оптимизации скорости сортировки и хэширования в памяти.
  • Автоматизированное управление размером лога транзакций.
  • INSERT ... ON CONFLICT UPDATE, также известный как «UPSERT».
  • Аналитические функции CUBE и ROLLUP.
  • Безопасность строкового уровня (Row-Level Security, RLS).
  • Новые манипуляционные возможности (функции и операторы) для типа данных JSONB.
  • Инструмент pg_rewind и другие улучшения репликации и средств повышения отказоустойчивости.
  • Множественные улучшения в механизм Foreign Data Wrappers, включая IMPORT FOREIGN SCHEMA.
  • Существенные улучшения масштабирования на системах с большим количеством процессорных ядер и оперативной памяти.

Статья «UPSERT и не только. Что ждать от PostgreSQL 9.5?» расскажет о некоторых новинках подробнее.

Скачиваем

What's New (англ.)

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

INSERT ... ON CONFLICT UPDATE

а что, раньше этого не было?

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

postgresql-docs весит 13.14 MiB. Клиента отдельно не нашел

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

Ну вот, стало быть не всё так однозначно.

Автор вот этой статьи сравнивая обе СУБД, у MySQL упирает на скорость и простоту, у постгре - надёжность и работу с большими объёмами данных.

Я подозреваю, что для начинающего MySQL должна быть проще. Самому мне эту простоту оценить сложно, поскольку я-то к PostgreSQL перешёл от Oracle, где всё запущено ещё намного сильнее...

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

Да нет, не нужно:

$ equery s postgresql
 * dev-db/postgresql-9.4.3
         Total files : 2671
         Total size  : 35.40 MiB

$ echo `which psql`
/usr/bin/psql

Installed versions:  9.4.3(9.4)(16:36:12 07.06.2015)(doc nls readline server ssl threads xml zlib -kerberos -ldap -pam -perl -pg_legacytimestamp -python -selinux -static-libs -tcl -uuid ELIBC="glibc -FreeBSD -NetBSD -OpenBSD -musl -uclibc" KERNEL="linux" LINGUAS="en ru -af -cs -de -es -fa -fr -hr -hu -it -ko -nb -pl -pt_BR -ro -sk -sl -sv -tr -zh_CN -zh_TW" PYTHON_SINGLE_TARGET="python3_3 -python2_7 -python3_4" PYTHON_TARGETS="python3_3 -python2_7 -python3_4")

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

данные в реляционную модель не вписываются

Например? IMO, данные без связей - сферический конь в вакууме.

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

Вообще, любители NoSQL упирают не на то, что там нет связей, а на то, что NoSQL заточен под гибкое распределение обработки данных между серверами и big data. Почему всё это нельзя сделать средствами реляционных СУБД, при этом никто внятно объяснить не пытается.

А гибкость и отсутствие строгой структуры БД - это далеко не всегда достоинство, IMHO. Ну да, при разработке выбрасывается проектирование БД, но ведь есть ещё отладка и сопровождение...

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

Правда, петабайт и даже терабайт данных у нас тогда не было. Возможно, это решающий аргумент.

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

Эксперт по шлаку это ты. Я еще использовал MySQL с тех времен, когда он молча заглатывал кривые запросы типа «FROM table SELECT table.column». С PostgreSQL такого никогда небыло. Какой дурак будет доверять свои данные дырявой базе, у которой даже SQL-парсер реализован с багами? PostgreSQL для небольших сайтов также прекрасно подходит. Даже я сам использую PostgreSQL на своем рабочем пека для хранения финансовых данных. Все работает замечательно.

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

У него (точнее, теперь уже у MariaDB) есть своя область применения - небольшие БД для сайтов

Из этой области его медленно, но верно вымещает SQLite.

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

У них данные key-value. Удивляет, что они оракал для этого использовали. Даже пугает.

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

Дурашка, это означает что ты не фига не кодил под SQLite, намекну небе IO.

anonymous ()

Потабличной репликации, как понимаю, не будет?

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

Oracle, где всё запущено ещё намного сильнее...

Настолько всё ужасно? Или «запущено» в другом смысле?

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

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

erzent ☆☆ ()
Ответ на: комментарий от Deleted

оракл требует 4 сотрудника для обслуживания минимум, причём на нагрузке, на которой при постгре хватит и 1 сисадмина, недавно со смеху падал, в мае, контора 1С держит на oracle....

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

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

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

MySQL это тот самый случай, когда простота хуже воровства. Молча обрубать строки, проглатывать ошибки. Это какая-то PHP-шная философия. Зачем заставлять юзера нервничать из-за опечатки в названии переменной? Создадим новую.

Legioner ★★★★★ ()

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

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

хочу задачи :(

Лихко! Запили свою GPS, с картой и маршрутами. :) Как раз на досуге медленно собираюсь начать планирование старта по началу взятия за эту проблему через промежуточную стадию мотивации (мой Nuvi 42 - дерьмо полнейшее).

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

Не было. Merge вообще в стандарте SQL крайне туманно описан, но сообщество настояло, чтобы было.

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

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

The SQLite website (https://www.sqlite.org/) uses SQLite itself, of course, and as of this writing (2015) it handles about 400K to 500K HTTP requests per day, about 15-20% of which are dynamic pages touching the database. Each dynamic page does roughly 200 SQL statements. This setup runs on a single VM that shares a physical server with 23 others and yet still keeps the load average below 0.1 most of the time.

https://www.sqlite.org/whentouse.html

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

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

erzent ☆☆ ()
Ответ на: комментарий от Legioner

Мне знакомые похапешники говорили, кстати, что в следующей мажорной версии PHP грозятся ввести строгую типизацию, и народ привыкший говнокодить спустя рукава, уже в печали. Пруфов почему-то не найду...

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

Я про сложность освоения.

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

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

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

4.2 во все щели! Советская БД — это конечно же Interbase, ах пардон, Firebird. И свой «одобрямс» они какбэ уже получили.

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

MySQL и PostgreSQL - сервера БД, SQLite3 - библиотека доступа к данным, предоставляющая синтаксис SQL.

SQLite - это реляционная СУБД, а не «библиотека доступа к данным».

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

А гибкость и отсутствие строгой структуры БД - это далеко не всегда достоинство

Схема есть всегда. Даже в этой-самой монге. Это — аксиома.

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

Ну, например. Есть документ со 100500 полями и пара квитанций (уровня 1 и уровня 2) с отношением 1-1, стандартная в общем-то конфигурация.

Если подходить к моделированию по фен-шую, то такая штука моделируется строго одной таблицей. На практике — малореально.

Если отношения уже 1-n (а на практике, они *всегда* 1-n, даже когда по *модели* они 1-1), то начинают вылезать реляционные аномалии. Если бы мне платили по баксу за каждый эксцепшен «запрос возвратил слишком дофига» или дублирование строки из-за кривого составленного произведения, я бы вообще мог не работать.

Выход один. Забить на фен-шуй и денормализовывать. Я, например, знаю достаточно известную (в узких кругах) систему, в которой БД (хоть и SQL) совершенно денормализована, ещё задолго до появления NoSQL, что не мешает ей работать уже ~15 лет без глюков и сбоев и ЧСХ удивительно шустро. Что же сделаешь, если модель-то соответствует.

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

А уж в области денормализации PostgreSQL впереди планеты всей. Тут тебе и массивы, тут тебе и композитные типы, тут и XML/JSON/BSON/Блобы... А вот недавно пал последний бастион — UPSERT, который *очень* нужен для работы с денормализованными данными.

Останавливает только одно. Хреновое качество биндингов, именно в смысле работы с массивами/композитными типами/JSON. А еще большинство биндингов работает в текстовом режиме. А еще большинство биндингов чуть более чем никак работает с заранее подготовленными запросами.

А вот Монга, она в этом плане сцуко, простая как угол дома.

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

Ненужно.. MongoDB круче :)

А почему она тогда по скорости сливает Pg на том же наборн «NoSQLьных» данных?

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

Там же вроде только тайпхинтинг для скаляров добавят.

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

Например датчик-метка времени-значение. Вот уж где, если по дедушке Дейту все декомпозируешь, получишь тыкву.

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

Потому что если ты решишь это декомпозировать, то получишь лютую таблицу вида id_датчика, метка времени, значение (далее по вкусу качество сигнала и прочие параметры). И ещё десяток таблиц, в которых про датчик и сигнал все описано.

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

Вендоры, если не пилят своё key value, хранилище, имитируют его в реляционках: 1 таблица на каждый сигнал + dynamic sql. Такие дела.

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

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

mapReduce ведь тормозит куда больше?

Да и оверхед по каждому значению в виде ключа

id - это же самый мизернейший оверхед из возможных. ЕМНИП, размер БД монги в среднем в два раза больше похожей реляционной БД

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

а вот Крон, ЕМНИП, как-то тестировал производительность мускуля и пострге при дефолтных установках(без тюна), и мускуль выигрывал.

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

mapReduce ведь тормозит куда больше?

Ну тут специфика задачи - не надо ничего разбивать по нодам. Все крутится на одном арме. Нужна просто выборка. Никакого map-reduce. Просто много insert и select. Ещё иногда надо бы конечно бэкап слить куда-нибудь на живую.

ЕМНИП, размер БД монги в среднем в два раза больше похожей реляционной БД

Я и не говорю что надо использовать nosql субд или рсубд. Начинали разговор про реляционную модель, и вот она тут не очень применима.

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

база начинает быть очень неторопливой

Монга в этой ситуации вообще работать не будет, если конечно её в режиме key-value (чем она, собственно, и является) не пользовать... Пока не наткнётся на свои внутренние ограничения, т.к. индекс должен влазить в память.

Решается такая проблема элементарно. Данные по датчикам хранятся в т.к. bucket'ах — таблице (id датчика, дата с, дата по, блоб с массивом значений) плюс вспомогательные данные среднее, мнинмум/максимум и т.п. Данные накапливаются специальной таблице, после чего специальный процесс нормализует показания и раскладывает их по бакетам. Если события редки и нерегулярны то в блобах хранить пары дата-значение.

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

В зависимости от требований, буферная таблица может быть вообще временной. В зависимости от требований данные в таблицу могут не добавляться а обновляться (здесь как раз upsert рулит).

В зависимости от требований, буфером может быть вообще кардинально другая БД, а нормализованные данные хранить хоть в файловой системе, хоть в Монге...

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

Есть видео за апрель май на ютубе про onga VS postgres, monga при тестировании на загрузку данных сливает постгресу на порядок, а при выборках - в полтора раза, а в отдельных запросах просто космическая разница в пользу PG. Есть моменты, когда хинты приходится использовать, но и в этих моментах с хинтами всё равно быстрее монги получается. Необходимость использования хинтов по философии PG - косяк планироващика, Сигаев с Бартуловым обещают это пофиксить.

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

Легковесность?

Да, это несомненное преимущество PostgreSQL перед mysql и его форками.

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

Останавливает только одно. Хреновое качество биндингов, именно в смысле работы с массивами/композитными типами/JSON. А еще большинство биндингов работает в текстовом режиме. А еще большинство биндингов чуть более чем никак работает с заранее подготовленными запросами.

psycopg2 весьма хорош во всех указанных аспектах.

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

Есть видео за апрель май на ютубе про onga VS postgres

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

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

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

psycopg2 весьма хорош во всех указанных аспектах.

Да? Вообще-то, это питоновский враппер для libpq с блекджеком и шлюхами.

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

Кстати, судя по тому, что они там наворотили и каких изменений наделали, крайне не рекомендую применять в бою версию 9.5 и дождаться следующего мажора + с несколькими обновлениями. Один WAL чего стоит, не говоря про кучу других мест.

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

Вообще-то, это питоновский враппер для libpq

да и качество биндингов с точки зрения работы с

денормализованными данными оставляет желать лучшего.

В сабже есть поддержка нативных hstore/json/jsonb. Ты про какие вообще биндинги?

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

Один WAL чего стоит

А что не так с WAL? Как я понял, он существует достаточно давно, а в 9.5 появилась (весьма нужная) опция позволяющая его отключать для указанных таблиц.

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

при дефолтных установках(без тюна)

Дефолтные настройки postgresql нацелены на то, чтобы запустится практически на любом оборудовании.

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