О каталоге Greenplum (1) В сообществах Greenplum обсуждают хабростатью. Я такой себе Greenplum DBA, но позволю себе небольшой коментарий. На самом деле, статью надо разбивать на 2 части. Первая про проблему мелких файлов в лейкхаусе, а точнее, мелких объектов в S3, которые генерит любой формат с дельтой. Вторая про проблему распухания каталога в Гринпламе. В чем суть. Колоночный формат в классической MPP СУБД (Greenplum, Clickhouse, Vertica etc) кладет в файловую систему 1 файлик на каждую колонку каждой таблицы. В случае партиционированной таблицы, это умножается еще и на количество партиций. В случае гринплама сюда же прибавим логические шарды-сегменты, и их зеркала, которые еще умножают число файлов на свой фактор параллелизма. Если таблицы широкие и партиций много, то файликов становится неприлично много. Когда-то кластер от такого начинает страдать. Конкретно в Гринпламе за этим огромным зоопарком следит такая штука, как системный каталог. Это, по сути, набор индексированных постгресовых таблиц на мастер-сегменте. С помощью этих таблиц сама СУБД узнает, где у нее чего и сколько лежит. И эта же структура используется при планировании пользовательских запросов. Коллеги описывают ситуацию, когда они делали множество 100-колоночных таблиц и много тысяч партиций к ним. Всего в БД оказывались десятки миллионов объектов и миллиарды строк в каталоге, которые их описывают. Объем служебной информации перевалил за 10 ТБ (!). И надо понимать, что при планировании каждого запроса кластер вынужден лопатить эти 10 ТБ просто для того чтобы понять, какие файлы ему читать для ответа на SQL. Ситуация слегка доведена до абсурда, но весьма поучительная. Если вы эксплуатируете большой Greenplum, то каталог, его объем и его здоровье становятся одной из ваших главных головных болей. Продолжение