Все нравиться, просто интересно сколько она вывезет в плане размера

Если инстанс без реплик, каким размером таблица еще будет жить

Я понимаю, что там чанки, но если база дорастет до пары ТБ, она будет еще жива?)

а сколько сейчас?

Надо точно глянуть, но думаю гигов 200

а количество записей?

Боюсь соврать, завтра гляну и отпишусь по размеру и кол-во записей

спасибо

очень хочу попробовать, очень интересно, каких результатов можно добиться

Ну у нас все на нее поставлено

)

У нас система gps мониторинга, не сильно большая, чтобы не лезть в всякие nosq решения, была экспериза в postgres. Взяли связку postgres postgis timescale - зашло на ура

Теперь интересно сколько она будет жить)

Реплики, шардирование и прочее решат проблему, просто инженерный интерес, сколько она будет работать в "достаточном" для бизнеса режиме)

Кстати, у меня есть образ сборки готовой https://hub.docker.com/r/binakot/postgresql-postgis-timescaledb/ если хочется потыкать, у timescale тоже есть сборки с postgis

А что это? InfluxDB на основе пропатченого Postgre?

Типа того

Расширение для работы с метрическими даннами по времени

Создаем специальный тип таблицы, оптимизированной под поиск по времени

Всякие временные корзины, разбиение на чанки и т.д. и т.п. стоит почитать

https://www.timescale.com/

We modified the PostgreSQL insert path, execution engine, and query planner to intelligently process queries across chunks. Ммм, прикольно

Чуваки начинали по-тихоньку, а потом выстрелило. Получили кучу инвестиций, но продолжают в опенсорс, буквально недавно был релиз 1.0

Интересно, а gin индексы по чанкам разбивает? А-то у нас полнотекстовый поиск тормозит, партиционировать по времени создания записи хотим

When indexing JSONB data across all fields that may be contained inside, it is often best to use a GIN index. PostgreSQL documentation has a nice description of the different types of GIN indexes available on JSON data. If in doubt, it is best to use the default GIN operator since it allows for more powerful queries:

https://docs.timescale.com/v0.12/using-timescaledb/schema-management#indexing-all-json

Интересно, а gin индексы по чанкам разбивает? А-то у нас полнотекстовый поиск тормозит, партиционировать по времени создания записи хотим

по идее там просто таблицы партиционированные под капотом

Ухх, спасибо за наводку, нажо будет глянуть в эту сторону :)

Очень рекомендую, сам радовался, когда наресерчил это, ибо велосипедить собирались нехило))

Работает уже год под небольшой нагрузкой, но ни разу ничего не случилось (тьфу-тьфу)

Примерно 500 gps трекеров шлют примерно по 5-10 записей в минуту

Все пишется в гипертаблицу timescale

а там нет ttl? просто дропать старые данные?

Примерно 500 gps трекеров шлют примерно по 5-10 записей в минуту

С этим и postgres справится без экстеншна. Чем оно удобней? Намного быстрее?

мы должны хранить полтора года истории

С этим и postgres справится без экстеншна. Чем оно удобней? Намного быстрее?

значительно быстрее

когда у тебя база под 3 ТБ

и все в одной таблице без шардинга))

https://blog.timescale.com/time-series-data-why-and-how-to-use-a-relational-database-instead-of-nosql-d0cd6975e87c

Этого достаточно, чтобы вкатиться

значительно быстрее

А что именно в нём значительно быстрее? Кстати, Вы (а не timescale.com) проводили какие-нибудь сравнительные тесты?

Опубликованных нет, но делали выгрузку массива данных по старой схеме и с помощью timescale, скорость работы отличается на порядок

К тому же сама гипертаблица дает возможность работать с данными как time-series, а не просто кортежи

Быстрее, потому что внутри чанки из коробки и оптимизации для работы с данными с первичной характеристикой - время

Опубликованных нет, но делали выгрузку массива данных по старой схеме и с помощью timescale, скорость работы отличается на порядок

А что такое "делали выгрузку массива данных"? Мне это, например, ни о чём не говорит. :( Какие это запросы (какого типа), примерно?

Быстрее, потому что внутри чанки из коробки и оптимизации для работы с данными с первичной характеристикой - время

В статье пишут, про быстрые инсерты, а апдейты не очень у него?

В статье пишут, про быстрые инсерты, а апдейты не очень у него?

а какие могут быть апдейты в метрики? time-series базы для этого не используются.

а какие могут быть апдейты в метрики? time-series базы для этого не используются.

У меня немного другая задачп)

У нас история переписки, текстовые сообщения, с полнотекстрвым индексом

Но у каждого есть таймстамп

А что такое "делали выгрузку массива данных"? Мне это, например, ни о чём не говорит. :( Какие это запросы (какого типа), примерно?

300 ГБ данных, это порядка истории за полгода для 500 объектов. Делали запросы на расчет суммарного пробега за это время, среднюю скорость движения, доля времени проведенная в движении или на стоянке и подобные бизнес-задачи. Еще раз повторюсь, делалось это без документаци и на коленке. Нам было достаточно того, что мы увидели.

Но у каждого есть таймстамп

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

300 ГБ данных, это порядка истории за полгода для 500 объектов. Делали запросы на расчет суммарного пробега за это время, среднюю скорость движения, доля времени проведенная в движении или на стоянке и подобные бизнес-задачи. Еще раз повторюсь, делалось это без документаци и на коленке. Нам было достаточно того, что мы увидели.

То есть, грубо говоря, большинство запросов идёт ко всем данным?

То есть, грубо говоря, большинство запросов идёт ко всем данным?

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

Проста эта штука позволяет делать твои таблицы time-series, не знаю как еще это объяснить)

Короче, вот что можно делать https://docs.timescale.com/v0.12/api#time_bucket

И прочие вытекающие из time-series подхода

Кто работал со всякими метрика типа prometheus - поймет суть

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

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

А какая (примерно) производительность в том и другом случае, на каком "железе"?

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

это вот как раз наша старая схема, 2 месяца на ssd, остальное на hdd

А какая (примерно) производительность в том и другом случае, на каком "железе"?

Intel Xeon E3-1271V3 HDD2x HDD SATA 4,0 TB Enterprise RAM4x RAM 8192 MB DDR3 ECC честная железка

А какая (примерно) производительность в том и другом случае, на каком "железе"?

Получить список точек с пост-обработкой (фильтрация кое-какая и прочие бизнес-дорасчеты) за месяц на старой системе - 1 минута, на новой 10 секунд

Причем для новой схему удаленность данных от настоящего времени не важна, для старой схемы, чем старее данные, тем дольше они достаются

Получить список точек с пост-обработкой (фильтрация кое-какая и прочие бизнес-дорасчеты) за месяц на старой системе - 1 минута, на новой 10 секунд

Понятно, спасибо! > для старой схемы, чем старее данные, тем дольше они достаются Хмм... это как-то странно, вообще-то.

слушайте, вы какие-то непонятные страсти рассказываете

вот реально

вопрос: есть 3 поля с датами date_a, date_b, date_c нужно вывести отсортированные записи по дате, по алгоритму date_a is not null`- для сортировки используется `date_a, date_b is not null`- для сортировки используется `date_b, и т.д как это сделать? и не будут ли проблемы с производительностью?

Понятно, спасибо! > для старой схемы, чем старее данные, тем дольше они достаются Хмм... это как-то странно, вообще-то.

да там много странного)

вопрос: есть 3 поля с датами date_a, date_b, date_c нужно вывести отсортированные записи по дате, по алгоритму date_a is not null`- для сортировки используется `date_a, date_b is not null`- для сортировки используется `date_b, и т.д как это сделать? и не будут ли проблемы с производительностью?

В смысле "ORDER BY COALESCE(date_a, date_b, date_c)"? Или я не так понял?

В смысле "ORDER BY COALESCE(date_a, date_b, date_c)"? Или я не так понял?

похоже на то, проверю, спасибо

Я понимаю, что там чанки, но если база дорастет до пары ТБ, она будет еще жива?)

что я делаю не так?

вы рассказываете про какой-то волшебный тайм-сериес, но ванильный PG + pg_pathman без проблем решают кучу этих надуманных проблем

у нас есть две основные таблицы, они 95% обьема типовой базы из примера выше

это, если что, не прод)

Стоп, pg_pathman решает проблему партицирования, но он делает данные time-series

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

14 ТБ

Это на одном сервере? Что там за конфигурация?

я же три картинки бросил)

я про диски

12Гб мем + 6виртуальных ядер с HT

2Тб SSD

остальное - обычные

последние два месяца лежат на ссд

2Тб SSD

Вот это Вы явно делаете не так, как они. ;) И про производительность ничего не рассказали...

по мере старения переезжают на медленные диски

по мере старения переезжают на медленные диски

Похоже на нашу прошлую схему, только база до таких размеров не дорастала. 14 тб это конечно сильно лул

сильно что?)

А HDD диски как связаны, в плане там же одна гиганская таблица, как она на разных физических дисках живет?

сильно что?)

я не сталкивался с таким объемом сингл-базы постгри

мы же секционировали данные, партиции лежат в разных тейбспейсах)