Как стать автором
Обновить

В PostgreSQL необходим официальный бенчмарк для функции uuidv7()

Уровень сложностиСредний
Время на прочтение4 мин
Количество просмотров3.8K
Всего голосов 8: ↑6 и ↓2+5
Комментарии16

Комментарии 16

Честно говоря ничего не понял. Во-первых, бенчмарк у pg есть. Не помню, как он называется, но он есть. Во-вторых, если вам надо проверить производительность вашего конкретного сценария, то почему бы вам его и не проверить? В конце концов не будут же разработчики pg делать отдельный бенчмарк на каждый тип данных в PG!?

Бенчмарка для функции uuidv7() в PostgreSQL нет, поэтому невозможно вспомнить его название.

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

UUIDv7 - это не "каждый тип данных". Функцию uuidv7() или аналогичную в PostgreSQL ждали уже не меньше восьми лет. Она революционным образом меняет проектирование и сопровождение баз данных и систем логирования. Так что, она достойна отдельного бенчмарка.

Разработчики PostgreSQL считают, что такой бенчмарк нужен. Но как всегда в open source, все ждут, что за них это сделает кто-то другой, а время уходит. Может быть Вы возьметесь?

Спасибо за предложение, но я занят развитием pgTap. Да еще и работу работаю. И все же pgbanch не подходит? Там они пишут много-много потоков можно сделать. Или я не понимаю цель нового бенчмарка?

Ваша идея использовать pgbench действительно прекрасная, особенно с собственным файлом со скриптом. В этот скрипт вполне можно было бы вставить те SQL-запросы, которые я предложил в статье. Стандартный скрипт не очень подходит для сравнения производительности разных первичных ключей для разных типов запросов, так как сделан для другой цели - тестирования производительности PostgreSQL на определенном "железе".

Но я ни разу не встречал предложение использовать pgbench для тестирования разных функций генерации первичного ключа. Видимо, этот инструмент недостаточно хорошо известен. К тому же, судя по пухлой документации, правильная настройка pgbench - нетривиальная вещь, и требует слишком высокой квалификации разработчика. Я думаю, что готовый шаблон теста на основе pgbench действительно был бы очень полезен. Было бы замечательно, если бы кто-нибудь опубликовал такой шаблон на Хабре.

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

Да, мне нравится Ваше предложение. Оставлю в личке мой Телеграм

И ещё. Объясните мне, ещё не читавшему официальную документацию, каким образом функция генерирующая чего-то там не как старая последовательно поможет временным рядам и особо хронологическому чтению, плиз.

Перевод цитаты из статьи "Why UUIDv7 is Revolutionizing Time-Ordered Identifiers for Modern Systems":

  1. Улучшенная совместимость с временными метками (Timestamps)

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

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

Еще одна переведенная цитата оттуда же (в оригинале на английском, правда, понятнее):

  1. Простота временного разбиения (Partitioning)

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

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

Если нету бенча и он вам нужен может вам его и написать?

Это не тот случай, когда спасение утопающих - дело рук самих утопающих. Бенчмарк нужен не мне лично, а очень многим компаниям самых разных отраслей. Эти компании скорее всего сляпают на коленке какой-нибудь примитивный и неправильный бенчмарк для внутренего употребления, будут ему слепо доверять, но не будут отдавать его в open source. А я не разработчик на языке C, а системный аналитик DWH. К тому же, далеко не всякий разработчик на языке C сможет написать такой бенчмарк - нужно глубокое понимание PostgreSQL. Качество бенчмарка должно быть таким высоким, чтобы кто-нибудь из коммитеров PostgreSQL согласился рискнуть своей репутацией и его закоммитить.

Ну C тут явно не нужен. Подойдёт буквально любой язык. Даже интерпретатор Python. Тут скорее дело в том, что общую оценку производительности разработчики PG уже провели. Наверняка выявили сильные и слабые стороны, описали их. Теперь дело за разработчиками прикладных систем. Именно они должны тестировать свои решения с применением нового типа данных на их железе и в их среде выполнения. Тут серебряной пули быть не может. К примеру, и с последовательными типами данных можно так все устроить, что работать будет ужасно медленно.

Функции в ядре PostgreSQL пишутся на C.

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

Кстати, а почему в 17 не завезли? Я на проектах использую такую реализацию (но хотелось бы что-то из коробки):

CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
create or replace function uuid_generate_v7()
returns uuid
as $$
declare
  unix_ts_ms bytea;
  uuid_bytes bytea;
begin
  unix_ts_ms = substring(int8send(floor(extract(epoch from clock_timestamp()) * 1000)::bigint) from 3);

  -- use random v4 uuid as starting point (which has the same variant we need)
  uuid_bytes = uuid_send(gen_random_uuid());

  -- overlay timestamp
  uuid_bytes = overlay(uuid_bytes placing unix_ts_ms from 1 for 6);

  -- set version 7
  uuid_bytes = set_byte(uuid_bytes, 6, (b'0111' || get_byte(uuid_bytes, 6)::bit(4))::bit(8)::int);

  return encode(uuid_bytes, 'hex')::uuid;
end
$$
language plpgsql
volatile;


Стандарт RFC 9562 еще не был утвержден к моменту "заморозки" функциональности 17 версии PostgreSQL. Поэтому никто не согласился закоммитить функцию по еще не утвержденному стандарту, хотя он был высокой степени готовности и после этого не изменялся. Если бы RFC 9562 утвердили на пару недель раньше, то функция попала бы в 17 версию PostgreSQL. Правда, после этого функция претерпела изменение: вместо прежнего метода 1 (используется счетчик) в ней теперь используется метод 3 (используется субмиллисекундный сегмент таймстемпа, но при этом весь таймстемп работает как счетчик в критических ситуациях), что почти всегда позволяет обеспечить монотонность даже при многопоточной генерации идентификаторов. То есть, мы получили более полезную функцию, но с задержкой еще на год.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации