РП
Size: a a a
2020 June 07
РП
At TimescaleDB we also work on scaling PostgreSQL, but primarily for one specific type of big data workload: time-series data. We do this by building on-top of the partitioning functionality already in PostgreSQL.
РП
вот, собственно, и все 🙂
MG
Статьям в обед сто лет, 2017 и 2018 год. На дворе 2020
RM
At TimescaleDB we also work on scaling PostgreSQL, but primarily for one specific type of big data workload: time-series data. We do this by building on-top of the partitioning functionality already in PostgreSQL.
Underneath the hood, hypertables rely on the older table inheritance mechanism of PostgreSQL that declarative partitioning is also built on.
Таким образом, и таймскейл, и нативное партиционирование основны на механизме наследования таблиц, т.е. таймскейл не использует нативное партиционирование. Там дальше пример с вложенным партиционирование поясняет различия в подходе. Совсем не очевидно, что улучшения в PG12 сильно повлияют на таймскейл, разве что изменения в подходе к блокировкам, хотя из-за скудности документации по таймскейлу, не понятно актуальны ли вообще для него проблемы которые решаются в PG12.
Таким образом, и таймскейл, и нативное партиционирование основны на механизме наследования таблиц, т.е. таймскейл не использует нативное партиционирование. Там дальше пример с вложенным партиционирование поясняет различия в подходе. Совсем не очевидно, что улучшения в PG12 сильно повлияют на таймскейл, разве что изменения в подходе к блокировкам, хотя из-за скудности документации по таймскейлу, не понятно актуальны ли вообще для него проблемы которые решаются в PG12.
РП
Underneath the hood, hypertables rely on the older table inheritance mechanism of PostgreSQL that declarative partitioning is also built on.
Таким образом, и таймскейл, и нативное партиционирование основны на механизме наследования таблиц, т.е. таймскейл не использует нативное партиционирование. Там дальше пример с вложенным партиционирование поясняет различия в подходе. Совсем не очевидно, что улучшения в PG12 сильно повлияют на таймскейл, разве что изменения в подходе к блокировкам, хотя из-за скудности документации по таймскейлу, не понятно актуальны ли вообще для него проблемы которые решаются в PG12.
Таким образом, и таймскейл, и нативное партиционирование основны на механизме наследования таблиц, т.е. таймскейл не использует нативное партиционирование. Там дальше пример с вложенным партиционирование поясняет различия в подходе. Совсем не очевидно, что улучшения в PG12 сильно повлияют на таймскейл, разве что изменения в подходе к блокировкам, хотя из-за скудности документации по таймскейлу, не понятно актуальны ли вообще для него проблемы которые решаются в PG12.
Ром, ты так пытаешься оправдать свое заблуждение, чтоли? В начале стати прямым текстом написано. Если считаешь, что знаешь лучше - проследуй в исходники, посмотри, как это сделано точно
РП
вопрос с замедлением точно улучшится на пг12 в связи с внесенными патчами
RM
Ром, ты так пытаешься оправдать свое заблуждение, чтоли? В начале стати прямым текстом написано. Если считаешь, что знаешь лучше - проследуй в исходники, посмотри, как это сделано точно
Какое заблуждение? Я пока тебе только вопросы задавал, так как не являюсь DBA, но партиционирование и в MySQL и в pg9, pg10, pg11 пробовал.
РП
Какое заблуждение? Я пока тебе только вопросы задавал, так как не являюсь DBA, но партиционирование и в MySQL и в pg9, pg10, pg11 пробовал.
РП
tsdb дополняет (на то оно и расширение) функционал партиций, чтобы можно было так, как на картинке. тем не менее, это те же партиции, планировщика нового не появилось, стало быть стандартный планировщик планирует запрос по партициям.
РП
но у стандартного планировщика есть проблемы при работе с большим количеством партиций, отсюда имеем лаги, покушанную память и тот тикет, что выше показывали
РП
в пг12 ситуацию с планировщиком улучшили, соответственно, справедливо ожидать улучшение и в работе таймскейл с ихними тучами партиций, которые создаёт заббикс. просто потому, что планировщик стал намного лучше работать с большим количеством партиций
РП
собственно, заббикс так и улучшил ситуацию: уменьшил количество партиций
A
но у стандартного планировщика есть проблемы при работе с большим количеством партиций, отсюда имеем лаги, покушанную память и тот тикет, что выше показывали
О каком количестве партиций идёт речь?
A
И какой chunk_time_interval выставлен? Сутки?
РП
И какой chunk_time_interval выставлен? Сутки?
в тикете, что выше показывали, есть информация
A
в тикете, что выше показывали, есть информация
А можно ссылку?
РП
А можно ссылку?
предлагаешь мне его поискать в хистори за тебя? 🙂
A
предлагаешь мне его поискать в хистори за тебя? 🙂
Я не могу найти то, на что ты ссылаешься