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

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

и всё это на одном сервере живет?

на текущий момент — да

и что ты делаешь со старыми данными

они тоже необходимы постоянно

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

рандом

это некий "справочник"

а в семь раз больше серверов не хочешь?

хочу, но возможности на текущий момент для этого нет

да и поиск "норм" проходит, где-то за 400-800мс посадка допустима до десятка секунд

В общем то мне не шибко охота вставлять данные по несколько суток, логически напрашивается именно какая-то работа с индексами, не знаю :(

а там есть какой-то автоинкремент у нового батча? или оно перемешивается всё?

Делай пулл реквест)

боюсь

а там есть какой-то автоинкремент у нового батча? или оно перемешивается всё?

нету, у каждой пачки только есть колонка с ID, и он одинаков на всю пачку

но в поиске он потом не учавствует да?

не участвует, нет

как вариант, попроси постгреспро сделать тебе билд с параллел аппенд патчем и сделать партишонинг

если бы еще хуйнуть блумфильтр сверху для секондари индексов, вообще пушка бы была

как вариант, попроси постгреспро сделать тебе билд с параллел аппенд патчем и сделать партишонинг

чтобы не ждать 11 постгрес еще год

если бы еще хуйнуть блумфильтр сверху для секондари индексов, вообще пушка бы была

честно говоря ничего не понял :) как это?

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

я не могу сказать что их нет в остальных 1000

а блумфильтр может

даже наоборот, скорее всего они там есть

а блумфильтр может

каким образом?

к тому же, это все равно в 100 раз медленнее в моем случае относительно глобального индекса:(

параллел аппенд поможет

как? ?

пойдет в партиции параллельно за твоими данными

раз они везде разбросаны

чувствую себя глупцом, однако, пока еще не понял как это позволит затем делать поиск за логарифм

у тебя и так поиск за логарифм, просто N таблиц проверить

раньше была одна таблица, теперь будет на каждый батч

чтобы сканить быстрее - параллел аппенд чтобы сканить меньше таблиц - блум фильтр (такого патча нет)

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

у тебя и так поиск за логарифм, просто N таблиц проверить

это тогда не логарифм, а O(K*log(N/K)), что в моем случае на два порядка медленнее

или я опять что-то не так понял?)

не, вроде все так понял

ну это будет 100 секунд и больше на запрос — не приемлемо (

я просто еще говорю что ты сможешь их параллельно просканить

вчера уже тут обсуждали прелести партицирования как раз

я просто еще говорю что ты сможешь их параллельно просканить

и это даст прирост в пару раз только

еп, трейдоф между записью и чтением

просто не вижу смысла это делать когда сейчас поиск работает за чистый логарифм

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

понятно, что придется идти на компромисс

это тогда не логарифм, а O(K*log(N/K)), что в моем случае на два порядка медленнее

но вот это слишком большая цена(

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

если у тебя вставка 30 часов (а не пиздишь?) то как все данные перестроятся за 8

если у тебя вставка 30 часов (а не пиздишь?) то как все данные перестроятся за 8

30 часов это если вставлять 40млн пачку туда где уже есть 1млрд В таблицу без индексов это делается​ за 1 час

Вот и выходит, что удалить индексы, вставить пачку, и построить индексы — выходит более интересный результ

ты не посчитал сколько они перестраиваться будут на 1ккк

1 индекс у меня строился за 2 часа

7 будут за ≈14 надеюсь

Копирование таблицы где-то за 1 час

тогда не понимаю как так медленно вставляется

Итого 1+1+17≈19-20 часов

честно говоря надо сделать более точные замеры

Иными словами весь вопрос в том, действительно ли в моем общем случае копирование+вставка+построение индексов быстрее чем просто вставка в таблицу с индексами

Известно, что вставка + построение точно быстрее

но и у тебя батч вставляющийся не маленький

ты ж не по одной строке вставляешь надеюсь

а оперируя тем фактом что копирование — операция достаточно дешевая, то даже в случае просадки в другую сторону это не критично плюс в том что это "логически кажется более логичным"

ты ж не по одной строке вставляешь надеюсь

нет, конечно к слову, для заливки данных используется pgloader

и время мерил ты конечно же с его стороны

конечно же :)

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

там самый смак в том,что данные льются из csv и это аксиома

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

кстати, интересно

пустая без индексов, рабочая — с индексами, это же имеется в виду?

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

да

единственная проблемка — я сейчас дропнул все индексы в рабочей, придется построить :) по той причине что на текущий момент льется миллиард (кусками, еще около недели будут приходить пачки) новых строк "первоначальных", пока юзерам это недоступно

я её скопирую сейчас и построю все индексы на тест, сейчас там что-то около 750 000 000 строк

поставил на копирование :) заодно посмотрим за сколько скопируется

после построения индексов попробую вставить пачку 40 млн по указанной выше схеме в голую таблицу -> в рабочую(экспериментальную)

год назад Костя Книжников еще предлагал подходик [HACKERS] Batch update of indexes там патчик который никто не возьмет в ядро, но ты можешь ему написать

он в принципе как раз твою проблему решал

судя по тому треду, у тебя вставка будет раз в 8 медленнее с индексами

то есть за 8 часов обернёшься, а не 30

но скоро узнаем

сможешь меня нотифайнуть?

@netneladno копирование завершилось за 56 минут

кстати а какой у тебя меинтененс ворк мем?

то есть за 8 часов обернёшься, а не 30

ого, вот это уже​ вполне приемлемо

кстати а какой у тебя меинтененс ворк мем?

4ГБ

ну это только в pgloader сессиях

оно там бесполезно же

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

так сколько ты им памяти даешь пока они билдятся?

дай тоже 4

оно там бесполезно же

я его эмпирически выставил)

дай тоже 4

ок

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

не понял на счет "через год"

ну выйдет постгрес 11

а, ну то через год...

create index будет параллелиться

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