LINUX.ORG.RU

PostgreSQL 18

 , ,


0

4

25 сентября, после более года разработки, состоялся выпуск стабильной версии 18 свободной объектно-реляционной системы управления базами данных PostgreSQL.

PostgreSQL 18 повышает производительность для рабочих нагрузок любого масштаба благодаря новой подсистеме ввода-вывода, которая показала до 3× ускорение чтения из хранилища, а также увеличивает число запросов, которые могут использовать индексы. Этот релиз делает обновления мажорной версии менее разрушительными, ускоряет сам процесс обновления и сокращает время, необходимое, чтобы после обновления выйти на ожидаемую производительность. Разработчики также выигрывают от функций PostgreSQL 18 — например, виртуальных вычисляемых столбцов, которые рассчитывают значения во время выполнения запроса, и дружественной к СУБД функции uuidv7(), обеспечивающей более быстрые индексацию и чтение UUID. Кроме того, PostgreSQL 18 упрощает интеграцию с системами единого входа (SSO) благодаря поддержке аутентификации OAuth 2.0.

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

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

Основные изменения:

  • Появление асинхронного ввода-вывода (AIO)
    • Ранее для ускорения доступа к данным PostgreSQL полагался на механизм опережающего чтения (readahead) операционной системы. Однако, поскольку операционные системы не понимают специфичных для баз данных паттернах доступа, они не всегда могут предсказать, какие данные потребуются, что приводит к неоптимальной производительности во многих рабочих нагрузках.
    • PostgreSQL 18 внедряет новую подсистему асинхронного ввода-вывода (AIO), разработанную для устранения этого ограничения. AIO позволяет PostgreSQL отправлять несколько запросов ввода-вывода (I/O) параллельно, не дожидаясь последовательного завершения каждого. Это дополняет существующий readahead и улучшает общую пропускную способность. В PostgreSQL 18 поддерживаются операции AIO для последовательных сканирований, сканирований по битовой карте (bitmap) страниц кучи (heap) и вакуума. Сравнительное тестирование продемонстрировало прирост производительности до 3 раз в некоторых сценариях.
    • Новый параметр io_method позволяет выбирать между реализациями AIO, включая worker и io_uring, либо сохранить текущее поведение PostgreSQL с настройкой sync. При включении AIO появляется больше параметров, доступных для тонкой настройки — подробнее в документации.
  • Более быстрые обновления и улучшенная производительность после обновления
    • Ключевая особенность PostgreSQL — сбор и хранение статистики, которая помогает планировщику выбирать наиболее эффективный план запроса. До PostgreSQL 18 эта статистика не переносилась между экземплярами при обновлении мажорной версии, что могло вызывать заметную деградацию производительности запросов на нагруженных системах до завершения выполнения операции ANALYZE. В PostgreSQL 18 появилась возможность сохранять статистику планировщика при обновлении мажорной версии, что позволяет обновлённому кластеру быстрее выйти на ожидаемую производительность.
    • Кроме того, утилита pg_upgrade, предназначенная для обновления между мажорными версиями, получила ряд улучшений в PostgreSQL 18, включая более быстрые обновления, когда в базе много объектов, таких как таблицы и последовательности. Этот выпуск также позволяет pg_upgrade обрабатывать свои проверки параллельно в зависимости от настроек флага --jobs и добавляет флаг --swap, позволяющий менять местами каталоги обновления вместо копирования, клонирования или связывания файлов.
  • Улучшения производительности запросов и общие оптимизации
    • PostgreSQL 18 дополнительно повышает производительность запросов благодаря функциям, которые автоматически ускоряют выполнение рабочих нагрузок. В этом выпуске представлены функции поиска «skip scan» по многоколоночным индексам B-дерево, улучшающие время выполнения запросов, в которых отсутствует условие = для одной или нескольких первых колонок индекса. Также оптимизируются запросы с условиями OR в WHERE, позволяя использовать индекс и существенно сокращая время выполнения. Также внесены многочисленные улучшения в планирование и выполнение соединений таблиц PostgreSQL: от ускорения хеш-соединений (hash join) до возможности использования инкрементальных сортировок в соединениях слиянием (merge join). PostgreSQL 18 также поддерживает параллельное создание GIN-индексов, дополнив этим B-деревья и BRIN-индексы, которые уже поддерживали такую возможность.
    • Релиз также развивает поддержку аппаратного ускорения: добавлены инструкции ARM NEON и SVE центрального процессора для встроенной функции popcount, которую использует bit_count и другие внутренние механизмы.
  • Улучшение опыта разработчика
    • PostgreSQL 18 вводит виртуальные вычисляемые столбцы, значения которых вычисляются во время выполнения запроса вместо хранения на диске (это теперь поведение по умолчанию для вычисляемых столбцов). Кроме того, «хранимые» вычисляемые столбцы теперь поддерживаются в логической репликации.
    • В этой версии появилась возможность получать как прежние (OLD), так и текущие (NEW) значения в предложении RETURNING для команд INSERT, UPDATE, DELETE и MERGE. PostgreSQL 18 также добавляет генерацию UUIDv7 с помощью функции uuidv7(), позволяя создавать случайные UUID, упорядоченные по временной метке, что улучшает стратегии кэширования. Кроме того, в PostgreSQL 18 функция uuidv4() добавлена как псевдоним gen_random_uuid().
    • PostgreSQL 18 добавляет временные ограничения — ограничения по диапазонам — для PRIMARY KEY и UNIQUE с использованием конструкции WITHOUT OVERLAPS, а также для FOREIGN KEY с использованием PERIOD.
    • Наконец, стало проще создавать схему внешней таблицы на основе локальной: добавлена команда CREATE FOREIGN TABLE … LIKE.
  • Улучшенная обработка текста
    • PostgreSQL 18 упрощает и ускоряет работу со строками благодаря нескольким улучшениям. В этом выпуске добавлена сортировка PG_UNICODE_FAST, которая обеспечивает полноценную семантику Unicode для преобразования регистра, помогая ускорить многие сравнения. Это касается функций upper и lower, а также новой функции casefold для регистронезависимых сравнений. Кроме того, PostgreSQL 18 теперь поддерживает выполнение сравнений LIKE над текстом с недетерминированной сортировкой, что упрощает сложный поиск по шаблону. В этом релизе также изменено поведение полнотекстового поиска: теперь он использует поставщика сортировки по умолчанию для кластера вместо принудительного использования libc. Это может потребовать пересоздания всех индексов полнотекстового поиска и pg_trgm после выполнения pg_upgrade.
  • Аутентификация и безопасность
    • PostgreSQL 18 добавляет аутентификацию oauth, позволяющую пользователям проходить проверку подлинности с использованием механизмов OAuth 2.0, поддерживаемых через расширения PostgreSQL. Кроме того, PostgreSQL 18 добавляет проверку режима FIPS и новый параметр ssl_tls13_ciphers для настройки наборов шифров TLS v1.3 на стороне сервера.
    • В этом выпуске прекращена поддержка аутентификации по паролю md5 (будет удалена в одном из будущих релизов). Если вам требуется парольная аутентификация в PostgreSQL, используйте SCRAM-аутентификацию. PostgreSQL 18 также поддерживает сквозную аутентификацию SCRAM с помощью postgres_fdw и dblink для аутентификации на удалённых экземплярах PostgreSQL. Кроме того, pgcrypto теперь поддерживает шифрование паролей с использованием SHA-2.
  • Репликация
    • PostgreSQL 18 поддерживает регистрацию конфликтов записи при логической репликации в журналах и в представлении pg_stat_subscription_stats. Кроме того, теперь команда CREATE SUBSCRIPTION по умолчанию применяет транзакции в несколько параллельных потоков, что может повысить производительность. Утилита pg_createsubscriber получила флаг --all, позволяющий создавать логические реплики для всех баз данных в экземпляре одной командой. Также PostgreSQL 18 позволяет автоматически удалять неактивные слоты репликации, чтобы избежать избыточного накопления файлов журнала предзаписи (WAL) на стороне публикующего сервера.
  • Обслуживание и наблюдаемость
    • PostgreSQL 18 улучшает стратегию очистки, путём упреждающей заморозки большего количества страниц во время регулярной очистки, что снижает накладные расходы и помогает в ситуациях, требующих агрессивной очистки.
    • PostgreSQL 18 добавляет больше информации в EXPLAIN, который предоставляет информацию о выполнении плана запроса, и, начиная с этого выпуска, теперь автоматически показывает, сколько буферов (основной единицы хранения данных) используется при выполнении EXPLAIN ANALYZE. Кроме того, EXPLAIN ANALYZE показывает количество обращений к индексу при его сканировании, а EXPLAIN ANALYZE VERBOSE включает статистику использования процессора, WAL и средним временам чтения. В представлении pg_stat_all_tables появилась дополнительная информация о времени, затраченном на очистку и связанные с ней операции, а также статистику ввода-вывода и использования WAL по каждому соединению.
  • Прочие заметные изменения
    • Базы данных, инициализированные с помощью initdb в PostgreSQL 18, теперь по умолчанию создаются с включёнными контрольными суммами страниц. Это может повлиять на обновления с кластеров, где контрольные суммы выключены: при использовании pg_upgrade для обновления таких кластеров потребуется создать новый кластер PostgreSQL 18 с опцией --no-data-checksums.
    • Кроме того, PostgreSQL 18 представляет новую версию (3.2) протокола взаимодействия (wire protocol) PostgreSQL — первое обновление протокола с момента выхода PostgreSQL 7.4 (2003 год). При этом libpq по умолчанию по-прежнему использует версию 3.0, пока клиенты (например, драйверы, пулеры, прокси) не добавят поддержку новой версии протокола.
  • Дополнительные возможности
    • Множество других новых функций и улучшений также вошли в PostgreSQL 18 и могут оказаться полезными для ваших сценариев. Полный список новых и изменённых возможностей приведён в примечаниях к релизу.

>>> Подробности на postgresql.org

★★★★★

Проверено: Dimez ()

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

Причины можно назвать, например, такие:

  • СУБД — это лишняя внешняя зависимость, при том что вообще любые внешние зависимости суть хамство в отношении пользователей и мейнтейнеров;
  • СУБД требует трудозатрат на установку, настройку и дальнейшее администрирование;
  • СУБД способна упасть (и да, падает намного чаще, чем, скажем, тот же апач — вообще пока мои сайты жили на «традиционной» CMSке, именно СУБД была причиной всех случаев downtime моих сайтов, за исключением одного, когда на сервере физически осыпался жёсткий диск);
  • СУБД требует от пользователя постоянно обновлять навыки, которые, возможно, больше ни для чего не нужны;
  • СУБД хранит информацию пользователя в неочевидном для него виде; этим грешат не только СУБД, конечно, но СУБД мало того что хранят всё в бинарных файлах, которые без самой СУБД даже думать нечего разобрать, они ещё и вводят дополнительный слой хаотизации в виде схемы БД, провоцируя разработчиков софта на внедрение «решений», единственное «описание» которых остаётся в голове у автора;
  • СУБД требует изрядных вычислительных мощностей и крадёт (а вовсе не повышает, как почему-то многие уверены) производительность.
MaZy ★★★★★
()
Ответ на: комментарий от MaZy

Андрей Викторович, перелогиньтесь.

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

чтобы не тащить отдельным расширением.

а если между тобой и БД ещё и девопсы стоят - ещё и девопсов не уговаривать это расширение собирать/ставить.

хочется же

CREATE TABLE table_name (
	id_name uuid DEFAULT uuid_generate_v7() NOT NULL,
        ...
)
без мороки.

Toxo2 ★★★★★
()
Последнее исправление: Toxo2 (всего исправлений: 1)

Хм, прикольно. 2 дня назад крячил ПГ в контейнер, была проблема с volume, долго не мог понять в чем дело. Поглядел а ПГ18, ну взял поменьше и все сразу заработало.

Я тогда даже не подумал что она только что вышла ;)

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

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

Извините а вы понимаете что такое СУБД и зачем оно нужно?

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

только зачем БД его генерировать…

Например если вставляешь запись руками или через текстовый скрипт - будет удобно. Ну и в целом в БД хватает функций генерации идентификаторов - sequence, uuidv4, теперь этот будет. В конце концов, почему бы и не генерировать id в БД. Кому-то так может быть удобней. В Java, например, UUIDv7 насколько я помню нет. Тянуть какие-то васянские либы или генерировать в БД - я бы выбрал второе.

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

Это очень плохая идея - не указывать версию образа, для postgres. У него нет автоматических миграций, поэтому когда твой контейнер с postgres:latest внезапно пересоздастся через год с тем же каталогом data, но с версией n+1, может случится что-то непонятное. А оно по закону подлости так и случится, когда этого меньше всего ожидаешь.

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 2)

А почему UUID вообще не забыто как чисто мастдайно-майкрософтная сущность и давно не похоронено в веках? Это же просто 128-битное число. Генерируй и записывай его как хочешь, если тебе зачем-то нужны 128-бит. Зачем привязываться к этому странному формату его записи? Какая-то там временная метка, версия, id узла и прочая фигня.

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

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

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

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

А почему UUID вообще не забыто как чисто мастдайно-майкрософтная сущность и давно не похоронено в веках?

Потому, что крайне полезная сущность оказалась, по совокупности свойств.

Это же просто 128-битное число.

Всё твоё сообщение это просто 2500-битное число :)

Генерируй и записывай его как хочешь, если тебе зачем-то нужны 128-бит.

Если генерировать «как хочешь», то полезные свойства теряются. Надо генерировать как положено.

Зачем привязываться к этому странному формату его записи?

Что значит «привязываться»? В базе UUID хранится, как 16 байтов. При трансформации в строку - да, используется стандартный формат представления UUID. Почему бы и не использовать его, что в нём такого уж странного? Понятный всем формат.

Какая-то там временная метка, версия, id узла и прочая фигня.

Это как раз редко используется. По моему опыту в 99% случаев используется UUIDv4. Это просто 124 случайных бита и 4 фиксированных. Но UUIDv7, скорей всего, тоже будет набирать популярность, т.к. у UUIDv4 есть некоторые проблемы и неудобства, которые решены в UUIDv7, а серьёзных недостатков у UUIDv7 нет.

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 1)

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

Единственное я не понял нафиг нужно OAuth 2.0

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

Бесплатный совет. Заменить в этом сообщении «СУБД» на «архитектура Фон Неймана» и перечитать.

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

В Java, например, UUIDv7 насколько я помню нет. Тянуть какие-то васянские либы

реализация RFC 9562 в жаве - строк 8 от силы (ну вот она), на SQL оно даже еще меньше выходит:

create or replace function uuid_generate_v7()
returns uuid
as $$
  -- use random v4 uuid as starting point (which has the same variant we need)
  -- then overlay timestamp
  -- then set version 7 by flipping the 2 and 1 bit in the version 4 string
select encode(
    set_bit(
      set_bit(
        overlay(uuid_send(gen_random_uuid())
                placing substring(int8send(floor(extract(epoch from clock_timestamp()) * 1000)::bigint) from 3)
                from 1 for 6
        ),
        52, 1
      ),
      53, 1
    ),
    'hex')::uuid;
$$
language SQL
volatile;

при этом потерь в производительности как бы и нет:

pgbench --client=8 --jobs=8 --transactions=200000 --file=${TEST}.sql

-- SELECT gen_random_uuid();
latency average = 0.073 ms
initial connection time = 4.815 ms
tps = 110325.912399 (without initial connection time)

-- pg_uuidv7 C extension
latency average = 0.073 ms
initial connection time = 5.422 ms
tps = 109623.347197 (without initial connection time)

-- sql function r27
latency average = 0.088 ms
initial connection time = 5.146 ms
tps = 90448.451336 (without initial connection time)

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

borisych ★★★★★
()

при использовании pg_upgrade для обновления таких кластеров потребуется создать новый кластер PostgreSQL 18 с опцией --no-data-checksums.

Не понял какие из этого вытекают проблемы. У нас есть базы, мигрирующие аж с 9.x (возможно есть и более ранние, о которых я просто не в курсе). Нам надо баяцца, или?

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

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

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

Всё твоё сообщение это просто 2500-битное число

Так оно и нехранится в базе как нечто особенное типа MessageV7.

Просто треш. Ни одного аргумента ты ни привел. Ещё раз: зачем тебе именно этот формат, зачем эти минусы между группами чисел, когда достаточно uint128_t value = rand128_norm_distribution()? Выдеди ты там какие хочешь себе биты под что надо, хоть сколько сделай постояннымми. Зачем завязываться на UUID? Господи, эти клоуны там даже ВЕРСИИ напридумывали.

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

Это некорректная реализация. UUID должны быть упорядочены в порядке генерации

Судя по

CREATE TABLE test_v7_ext (
	id uuid DEFAULT uuid_generate_v7() NOT NULL PRIMARY KEY,
	ballast text NOT NULL
);
CREATE TABLE test_v7_sql (
	id uuid DEFAULT uuid_generate_v7_sql() NOT NULL PRIMARY KEY,
	ballast text NOT NULL
);
CREATE TABLE test_v7_native (
	id uuid DEFAULT uuidv7() NOT NULL PRIMARY KEY,
	ballast text NOT NULL
);

INSERT INTO test_v7_ext (ballast) SELECT 'row_' || i FROM generate_series(1, 2000000) i;
INSERT INTO test_v7_sql (ballast) SELECT 'row_' || i FROM generate_series(1, 2000000) i;
INSERT INTO test_v7_native (ballast) SELECT 'row_' || i FROM generate_series(1, 2000000) i;
расширение тоже некорректная реализация. Нативная красиво положила. По времени sql-версия секунды на 2-3 медленнее на моем локалхосте.

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

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

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

Не кипятись. Тебе не надо — не используй. Я тоже для первичных ключей не использую. Там обычные числа 4 или 8 байтовые работают. UUID в основном полезен как публичный ключ, который может увидеть внешний пользователь. Его нельзя перебирать, он скрывает число записей и его можно генерировать на клиенте. Все эти свойства на практике востребованы.

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

UUID в основном полезен

UUID только и нужен, как для распределенных БД с мультимастерами. А кайф от v7 в основном (для меня) в том, что не нужно создавать отдельное поле а-ля «create_at». А вот в качестве «публичного ключа» v7 как раз именно этим и плох, что раскрывает эту информацию посторонним людям.

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

UUID только и нужен, как для распределенных БД с мультимастерами.

Далеко не только. У него есть масса других применений. А распределенные бд это штука крайне редкая.

А кайф от v7 в основном (для меня) в том, что не нужно создавать отдельное поле а-ля «create_at».

Конечно же надо. Это логически не связанные понятия.

А вот в качестве «публичного ключа» v7 как раз именно этим и плох, что раскрывает эту информацию посторонним людям.

Это верно. Чаще всего ничего страшного в раскрытии этой информации нет, но про это стоит помнить, да.

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

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

Заменяем «СУБД» на «ОС» («Операционная Система»), и получаем совершенно такую же чушь... ;P ;))

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

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

осталось только понять зачем это действительно нужно и нужно ли вообще.

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

Во-первых при таком подходе индекс не раздувается.

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

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

А что есть хорошего на английском?

Title: Mastering PostgreSQL: A Comprehensive Guide for Developers
Author(s): Kameron Hussain; Frahaan Hussain
Publisher: Sonar Publishing
Year: 2024
dataman ★★★★★
() автор топика
Ответ на: комментарий от vbr

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

Во-первых при таком подходе индекс не раздувается.

«не раздувается» - это сколько в процентах? хотя бы 20% наберется? там же аж 48 бит на таймстемп и 62 бита под рандомные данные - тут получится скроить разве что на одном уровне индекса - спускаемся ниже на уровень и там ровно все что было и раньше, т.е. ваше «не раздувается» правильно писать как «индексы имеют тенденцию иметь высоту на 1 меньше, и то не всегда»

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

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

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

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

Нафига-нахрена? Чем не угодило hUbnhVag-7aNba как у ютуба с любой разрядностью? Нафига нужен именно этот престарелый стандарт UUID? Зачем числа записывать именно так через это тире?

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

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

Нафига-нахрена? Чем не угодило число вида 1U4nWVag-7aNba8N_baMMa как у ютуба с любой разрядностью? Нафига нужен именно этот престарелый стандарт UUID? Зачем числа записывать именно так через это тире в таком виде? Свойства у ютубного выражения 64-битного числа те же, что ты назвал. Ты можешь даже сделать 256-битное ютубное число если надо.

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

Это не заблуждения, это простая истина, которая очевидна исходя из устройства B-деревья.

Вот за меня потестировали, разница во времени вставки в полтора раза, разница в размере индекса 22%, разница в скорости запроса 200-500% (хотя тут, конечно, запросы специально подобрали, чтобы это продемонстрировать).

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

Чем не угодило hUbnhVag-7aNba как у ютуба с любой разрядностью?

Почему оно должно угодить? Выглядит уродливо. Тогда уж какой-нибудь RB5S1HXWIWZ7V6VHGM61HV86M, выглядит куда красивей и в QR кодируется оптимально.

Нафига нужен именно этот престарелый стандарт UUID?

Потому, что это стандарт. Он реализован везде. У него 100% интероперабельность. Ты можешь одной строчкой преобразовать UUID в эту строку, а другой строчкой распарсить и это в любом языке, включая пресловутый PostgreSQL. А ютубовская белиберда это не стандарт. Тебе её надо реализовывать каждый раз заново. А по факту никто не будет ничего реализовывать, а просто будет хранить её в виде строки, что явно менее оптимально, чем компактная форма для UUID.

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

Тут как с ZFS: или ты боишься silent bit rot и используешь ФС (в этом случае — СУБД) с чексуммами данных, либо не боишься.

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

«в теории» это уникальный id

поэтому можно буквально для всех «обьектов» иметь поле id в каждом кортеже T ( хотя imho лучшее val(T)id тогда естественный джойн первичных со вторичными) и id джойн никогда не будет паразитным

обьективно это как python-id али какой иной механизм быстрого удостоверения без структурного анализа

на текущих скоростях-памятях 16 байт дешево и надёжно

ибо если пипхолит память uuid явно не первое под оптимизацию попадёт если иметь полный профиль по памяти-скорости

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

Как говорил один осуждённый убийца: «Если вы используете дополнительный слой для хранения данных – у вас просто плохая файловая система.»

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

Не получится запустить pg_upgrade для миграции со старой базы без контрольных сумм в новую базу с контрольными суммами.

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

В общем никаких проблем это не вызовет. В худшем случае pg_upgrade при запуске сразу выдаст ошибку, что мол отличаются настройки баз и придётся пересоздать новую базу.

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

Почему оно должно угодить? Выглядит уродливо.

Вам зачем выглядеть, вам надо компактнее и чтобы было копируемо в буфер обмена. Что 1U4nWVag-7aNba8N_baMMa, что 87A94AB0-E370-4cde-98D3-ACC110C5967D, что RB5S1HXWIWZ7V6VHGM61HV86M - один хрен, в первом хоть больше возможностей - максимальная плотность бит за счёт обоих регистров символов.

Потому, что это стандарт. Он реализован везде.

Мало ли чё там стандарт, мало ли что пошло там то мастдая когда-то? Не везде он реализован.

У него 100% интероперабельность.

Чиво. Что-то понимает этот UUID, что-то не понимает. Нафиг его всем поддерживать, чтобы что?

А ютубовская белиберда это не стандарт.

Ютубовская билеберда настолько приметивна, что является просто вариантом base64 и там даже стандарт не нужен. Мне дико смешно, когда на какую-то запись 128 бит завели целый стандарт, напихали туда каких-то тире чтобы разделить какие-то… что разделить? Поля там какие-то? Нафиг они там? Для чего? Да ещё какие-то биты в этом UUID константны. Да ещё там какие-то ВЕРСИИ у этой хрени! Это уже похоже тупо не религию виндузятничества или кружок си-шарпистов престарелых.

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

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

Почему не будет реализовывать? Люди, которые используют base64, как в ютубе, просто отдали 64 бита наружу, а в базе у них лежит uint64 конечно же, зачем им строку хранить, какую ещё строку, чтобы что, парсить её постоянно? Зачем?

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

Вам зачем выглядеть, вам надо компактнее и чтобы было копируемо в буфер обмена

Как надо - это в каждом случае отдельно надо разбираться.

К примеру, если в URL надо показывать, то там одни дозволенные символы. Если в QR-код надо кодировать максимально компактно, там другие дозволенные символы. Если надо двойным кликом выделять, там тире не подходит. А чаще всего никаких требований нет и обычная форма UUID вполне подходит.

Что 1U4nWVag-7aNba8N_baMMa, что 87A94AB0-E370-4cde-98D3-ACC110C5967D, что RB5S1HXWIWZ7V6VHGM61HV86M - один хрен, в первом хоть больше возможностей - максимальная плотность бит за счёт обоих регистров символов.

Так а что ты так мало символов добавил? Можно же туда куда больше символов засунуть. Вот все эти символы, например, помимо букв и цифр: ^,.-!/()=?*;:_{}[]\|~

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

разница в размере индекса 22%

ну все! победа! разница не 20% а аж 22%! я-то грешным делом думал, что «пухнут» означает ни как не меньше чем «разы»… Сорян, делал прикидки по «экономии» исключительно в уме и не проверял гипотезы.

разница во времени вставки в полтора раза

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

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

а в базе у них лежит uint64 конечно же, зачем им строку хранить, какую ещё строку, чтобы что, парсить её постоянно? Зачем?

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

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

Вам зачем выглядеть, вам надо компактнее и чтобы было копируемо в буфер обмена. Что 1U4nWVag-7aNba8N_baMMa, что 87A94AB0-E370-4cde-98D3-ACC110C5967D, что RB5S1HXWIWZ7V6VHGM61HV86M - один хрен, в первом хоть больше возможностей - максимальная плотность бит за счёт обоих регистров символов.

в твиторе используется некий Snowflake Id, всего-то 64 бита - им хватает вполне, но для лоровских экспертов 64 бита на индентификатор - это крайне мало, нужно больше (угу, у каждого второго под кроватью не пыль, а 10 твиторов)

borisych ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.
Тема будет перемещена в архив .