Комментарии 24
Мда, 3 и 6 сервера отожгли)
причём чтение ещё можно объяснить например настройками/таймингами памяти (её ж меняли), но запись-то чисто в диски упирается...
Навскидку не только в диски упирается-) В случае софтрейда контроллер шины PCI-е+контроллер дисков+ контроллер самого диска, а также их взаимодействие друг с другом, в случае хард рейда еще добавляется контроллер хардрейда. Это если рассматривать цепочку с середины цикла записи/чтения в рамках одного сервера. SMART для анализа не сильно поможет, он покажет только битый/не битый диск, если грубо, поведение контроллера конкретного диска при больших нагрузках он не покажет. Что происходит на уровне шины PCI-e тоже науке не известно. Это очень грубо на уровне железа, считаем что софт идеальный и багов в нем нет. Как показывает практика с серверами Supermicro 10 одинаковых серверов, вот реально все потроха одной ревизии, отличаются только неделями выпуска, ведут себя по разному при больших нагрузках.
Большое спасибо за статью,с интересом прочитали с коллегами.
Не могли бы прокомментировать этот момент:
>> и вот такая матрица, содержащая достигнутый TPS при одинаковом количестве воркеров (20):
Производительность кросс-серверных обращений очевидным образом на полтора порядка ниже, но не является ли это следствием малого количества воркеров?
Если у вас латенси одной операции увеличивается грубо на порядок из-за раундтрипа и т.д., то простое расширение количества воркеров до 500-1000 должно линейно увеличить производительность межсерверных обращений, и показать намного менее драматичную разницу.
Шардман теоретически рассматривали как "поставить и не думать о масштабировании / реализации своего шардирования", эта табличка намекает, что "не думать" не получится...
Вот это ещё одна загадка, до которой мы не успели докапаться на том оборудовании. В целом на других тестах мы не наблюдали такой большой разницы.
Более того, в случаи с межсерверным обращением, утилизация процессора увеличивается на промежуточном сервере на 50%, что тоже неожиданно. По диску разницы не вижу, там одинаковый набор читался. И явно по сети не вижу проблем.
Мы повторим тесты на своём оборудовании и разберемся. Не могу сказать что это ошиюка архитектуры, вполне возможно что это ошибка установки, настроек, релиза или в другом любом рандомном месте. Задача заведена и попробуем её сделать в ближайшее время.
Я почему-то oracle supercluster и exadata вспомнил, аж вспотел. Они, конечно работали, особенно если zdlra поставить. Цена сопоставима с годовым бюджетом некрупной страны.
Очень интересно, какой у этого кошмара промышленный юзкейс? Наверное, какая-то аналитика, ни для чего другого в здравом уме петабайт в одну базу лить никто не будет. А логически разбить на базы никак нельзя? Ведь в проде это не будет работать все равно - это невозможно забекапить, здесь никогда не будут работать стандартные процедуры работы. Это уникальное решение не вполне понятно для чего.
Ну классический пример -- CERN. Не знмю, индустрия это или нет, но оно даже вроде бы и не самы масштабный ай-ти в науке давно со своим петабайтом в день и 100 петабайтами хранения и бэкапов, причем это сисема восьмилетней давности.
Ну или любой современный радиотелескоп 0.5-1 TB/s генерит, тупо мультиспектральные картинки 2^15 на 2^16 размером, но очень , очень много штук. Проект Aeneas по созданию общей базы данных звездного неба в радио диапазоне был рассчитан на 8.5 экзабайт на 15 лет в постоянном хранении, уж не знаю, сколько они там собрали в итоге, но это вполне рутинная задача.
Я понимаю, откуда эти данные могут взяться. Сам бекапил по 4-6 петабайт каждый день, когда в сбере работал. Но это же не все в одной базе лежит, нет никакого смысла это класть в одну базу, даже если данные однородные.
Я уверен, что тот же церн не в базу сырые данные пишет по петабайту в день.
В несколько баз поменьше. И часть сращу в Будапешт, что ли стримит, там у них второй кластер для обработки (вроде на общей T1 магистрали сидят). А в радиотелескопах в том и соль, что иногда надо интегральную картинку собрать со в всех источников. но не сразу за полгода, конечно, и не регулярно. Но вроде проект на 3 миллиона был как раз про seamless on-demand access. Ну чтоб любой тупой студент мог вбить временное окошко, частотный диапазон, и через 10 секунд на рабочем столе картинка.
Такие OLTP базы есть, в основном это высоконагруженные системы, где данные прилетают массово. К примеру платежи, посылки, realtime rating и charging и прочие. Во многих таких системах важно хранить данные за долгие годы.
По некоторой инфе есть в РФ инстансы на GreenPlum-е с 6 петабайтами данных (не знаю что за природа базы, но это даже не self-hosted, а на арендованных серверах).
Можно конечно пилить на несколько баз, но зачем - это только усложняет доступы. Надо менеджить уже не одну единицу, а несколько.
Бекапы делаются инкрементальные, конечно не надо каждый час и день делать полную копию. Раз в месяц сделать полный бекап за сутки возможно, а дальше только собирать инкременты. Это рабочая стратегия.
Суть простая - такие базы существуют, их мало, но они есть.
Любой опсос это десятки терабайт в день новых данных, и петабайтные объемы. Звонки, смс, мобильный трафик, немерянное количество интеграций (тот же ОФД, реклама, банки). Всё это создает терабайты только текстовых данных. Hadoop в целом тянет все это, плюс пачка вспомогательных баз под различные прикладные задачи.
Судя по флеймграфу, 15% занимает GetCachedPlan. Что-то многовато: может таки generic-планы стоило использовать?
Тогда fine tuning нам даже и не пришло в голову делать - задача не стояла так. Надо бы конечно покрутить планами, со стороны утилиты мы точно используем расширенный протокол. Скорее всего generic слишком дорогой, вот он и постоянно кастомы строит. Можно попробовать конечно force_generic. Думаешь стоит?
Полагаю, что можно смотреть в pg_stat_statement - там где generic дает сравнимый execution time и видно, что кастомные планы не имеют больших разбросов по времени выполнения - то я бы фиксил дженерик.
О, а pg_hint_plan так умеет делать? Было бы прикольно
Он умеет хинты проставлять - в том числе настройки гуков. Но, полагаю, тебе нужно написать plpgsql-рутину, которая будет ходить в статистику, prepared statements, и решать, что форсить.
https://postgrespro.ru/docs/postgresql/17/runtime-config-query#GUC-PLAN-CACHE-MODE
это базовый функционал
Пробовали оптимизировать работу PostgreSQL (ванильного или Shardman) при помощи пересборки с Profile-Guided Optimization (PGO)? Если да, то интересно было бы посмотреть на ваши результаты. По имеющимся бенчмаркам выглядит достаточно интересно: тык
Хотели поисследовать это как и LTO, и знаем что на простых тестах это даёт некоторый процент выйгрыша. Но вот в базах данных зачастую производительность задаётся не только оптимильным набором инструкций, но ещё сложность алгоритмов обработки информации и пределами масштабирования на горячих данных (блокировках). Поэтому PGO/LTO - вещи хорошие, со своими минусами и багами (PGO насколько помню вносит требование что расширения тоже должны быть собраны таким же или особым способом), но лучше boost производительности дают именно улучшения кода с точки зрения алгоритмов и lock-free вещей.
Хотели поисследовать это как и LTO, и знаем что на простых тестах это даёт некоторый процент выйгрыша.
По моим ссылкам выше я вроде старался использовать достаточно уважаемые в среде БД бенчмарки, которые приближены к реальным кейсам, а не синтетике (тот же ClickBench). По всем этим бенчам, оптимизация инструкций через LTO/PGO очень даже работает даже без оптимизации блокировок и прочего.
PGO насколько помню вносит требование что расширения тоже должны быть собраны таким же или особым способом
Не слышал про такое требование ни в одном компиляторе и ни разу не сталкивался с таким на практике. Вы можете собрать PostgreSQL с PGO, но при этом модули могут отлично работать без PGO.
но лучше boost производительности дают именно улучшения кода с точки зрения алгоритмов и lock-free вещей.
Одно другому не мешает. Даже более эффективные алгоритмы улучшаются за счёт LTO/PGO, так как у компилятора больше информации для проведения оптимизаций. Например, в случае PGO, для вашего более эффективного алгоритма может лучше расставить инлайны и сделать намного более качественный branch prediction.
Верно, был не прав. Сам компилятор никак не влияет и все моменты которые обсудили в https://postgrespro.com/list/thread-id/2634776 надо детальнее изучать и исправлять. И про memory barrier и про фряху и прочее.
Тогда может и приземлится PGO/LTO в PG. :) Спасибо большое за комментарий!
Правильно-ли предположить, что вы измеряли производительность базы не 1ПБ, а 1/7?
Ведь задача делилась между 7 серверами.
Если горизонтально масштабировать до 15 серверов, то на 2ПБ производительность должна быть похожей.
Или я что-то упускаю?
Для конечного пользователя это всё таки одна база данных, даже одна таблица, размером в петабайт. Но и верно что ресурсно это разбросано на 7 серверов, как с точки зрения дисков, так и с точки зрения процессоров.
14 серверов и 2ПБ vs 7 серверов и 1ПБ мы конечно не сравнивали, в теории конечно можно конечно оптимистично говорить что будет похожее, но уверен что там тоже будут интересные погружения в rabbit holes. Как минимум чем больше нод, тем больше интерконнектов на каждой ноде и т.п.
Как мы под Новый Год загрузили в PostgreSQL петабайт данных и что из этого вышло