Мне в любом случае нужно будет пробежаться по всем партициям по определению особенностей моих данных :)

А это тогда что ?

я забыл пока спал ? честно

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

@pensnarik извиняюсь, вам известна постановка проблемы?

Из того, что я прочел, я понял, что надо вставлять много данных и искать по различным критериям, таким что партиционирование вам неподходит. Что я упустил?

а так называемый sharding key возможно извлечь из этих данных?

о

еще вопрос

а ElasticSearch не рассматривали?

А это тогда что ?

это причина по которой не подходит партицирование

ElasticSearch

а ElasticSearch не рассматривали?

у меня точный поиск, нет смысла

Наркомания какая то, извините

он точно ищет очень быстро

Из того, что я прочел, я понял, что надо вставлять много данных и искать по различным критериям, таким что партиционирование вам неподходит. Что я упустил?

все верно только с поправкой: вставлять надо редко и пачками

Я втавки данных вообще пока не касался. Я пока про поиск говорю.

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

Я втавки данных вообще пока не касался. Я пока про поиск говорю.

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

Я втавки данных вообще пока не касался. Я пока про поиск говорю.

ок напомню, что с поиском проблем нет

ок напомню, что с поиском проблем нет

Странно ).

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

могу, конечно если бы давали несколько машин :)

Странно ).

отчего странно то?

Наркомания какая то, извините

не понял вас

надо требовать

либо скорость вставки не столь критична

а так называемый sharding key возможно извлечь из этих данных?

не, это что-то типа внутреннего справочника

либо скорость вставки не столь критична

скорость вставки не критична

главное чтобы юзер её не заметил

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

???

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

Это троллинг такой ?

???

что именно вам не ясно?

Это троллинг такой ?

нет,это специфика данных они поступают не от пользователей

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

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

Неважно откуда они поступают

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

Не всегда, но я согласен с идеей партицирования

Неважно откуда они поступают

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

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

Партиции.

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

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

Партиции.

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

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

Значит вы неправильно что то делаете.

Значит вы неправильно что то делаете.

это по определению партиций, ведь у каждой свой индекс

это по определению партиций, ведь у каждой свой индекс

Это не по определению.

отчего же? 500 партиций — вот вам и 500 индексов

И что ?

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

при равномерном распределении это O(log(N)) против O(K*log(N/K)), где K есть кол-во партиций

теперь представьте во сколько раз (≈) это медленнее

при равномерном распределении это O(log(N)) против O(K*log(N/K)), где K есть кол-во партиций

Ну так себе утверждение

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

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

Ну так себе утверждение

оно достаточно примерное, да; но когда видно разницу на несколько порядков — становится очевидно, что это действительно гораздо (неприемлемо) медленнее

и это утверждение касательно select, кстати

оно достаточно примерное, да; но когда видно разницу на несколько порядков — становится очевидно, что это действительно гораздо (неприемлемо) медленнее

А вы сравнивали попадания в кеш в первом и во втором случае?

А вы сравнивали попадания в кеш в первом и во втором случае?

там абсолютно случайный доступ, к сожалению

Может пересмотреть схему данных ?

Ну и что. Возможно, перед первым тестом база была прогрета (нужные блоки были в shared buffers), а второй раз все данные читались с диска.

там абсолютно случайный доступ, к сожалению

Абсолютно случайного ничего не бывает.

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

И все-таки, сравнивали или нет?

Может пересмотреть схему данных ?

в силу заявленных требований по поиску это практически невозможно(

И все-таки, сравнивали или нет?

нет

в силу заявленных требований по поиску это практически невозможно(

Я думаю таки возможно

Если смотреть в сторону какого нить data vault или anchor model

нет

Тогда что вы сравнивали? Просто время выполнения? Планы запросов то хоть смотрели?

Если смотреть в сторону какого нить data vault или anchor model

спасибо, посмотрю

Тогда что вы сравнивали? Просто время выполнения? Планы запросов то хоть смотрели?

null; да; да

Андрей, немного не понимаю о чем вы намекаете в рамках сравнения скорости select между 500 партициями и одной — разница очевидна

Андрей, немного не понимаю о чем вы намекаете в рамках сравнения скорости select между 500 партициями и одной — разница очевидна

Все зависит от запроса. Если в его условии отсекаются лишние партиции, как я и писал выше, то это будет намного быстрее. Но это не ваш случай. Но даже в вашем случае не думаю, что разница может быть в два порядка, думаю, что жто ошибка измерения. Данных то надо прочитать столько же.

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

данных надо прочитать не столько же, все таки это бинарное дерево (деревья)

данных надо прочитать не столько же, все таки это бинарное дерево (деревья)

Во-первых, не бинарное.

когда это btree (именно его используют сейчас в основном) перестало быть бинарным?

Оно им и не было

Вроде

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

когда это btree (именно его используют сейчас в основном) перестало быть бинарным?

b от balanced, то есть сбалансированное.

Но суть не в этом. Я бы все равно сравнил чтения с диска.

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

Но суть не в этом. Я бы все равно сравнил чтения с диска.

и то верно, сути это не меняет. тесты я все-таки проведу, на будущее будет полезно. спасибо)

Хотя бы типы по которым индексы

И примерную селективность данных

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

10 text (A1,...,A10) и 3(B1,...,B3) smallint — развлекайтесь :) индексы сейчас тоже опишу для теста

Строки все без ограничения длины?

Строки все без ограничения длины?

верно

верно

А в реальности максимальные длины какие?

индексы: 1. A1+A2+A3 2. A1+B1+B2+B3 3. A4 4. A5 5. A6 6. A7 7. A8

Есть ли не ASCII символы?

А в реальности максимальные длины какие?

в тех полях которые участвуют в индексации — не более 20-40

Есть ли не ASCII символы?

в тех полях которые участвуют в индексации — только ASCII

Поскольку у вас очень много строк, есть места, где стоит сэкономить: 1) почитайте про выравнивание данных в tuple 2) varchar длиной до 126 включительно экономит место в заголовке 3) collate C для строк экономит место в данных и в индексах

да, еще в A5,...,A8 частенько бывают NULL это тоже надо учитывать

индексы: 1. A1+A2+A3 2. A1+B1+B2+B3 3. A4 4. A5 5. A6 6. A7 7. A8

+ означает (A1, A2)?

да, мультиколумн

Поскольку у вас очень много строк, есть места, где стоит сэкономить: 1) почитайте про выравнивание данных в tuple 2) varchar длиной до 126 включительно экономит место в заголовке 3) collate C для строк экономит место в данных и в индексах

спасибо, попробую применить

спасибо, попробую применить

А в чём у Вас _конкретно_ проблема? SELECT-ы проседают при заливке данных?

Столбцы через андер или кэмэл? Сорри за холиварный вопрос

Столбцы через андер или кэмэл? Сорри за холиварный вопрос

snake_case, IMHO. Потому что CamelCase всё равно downcase-ится до camelcase, если без кавычек. К тому же, говорят, его труднее читать. И вообще, см. http://www.sqlstyle.guide/

индексы: 1. A1+A2+A3 2. A1+B1+B2+B3 3. A4 4. A5 5. A6 6. A7 7. A8

Если у вас поиск по равенству, то посмотрите в сторону одного покрывающего bloom индекса.

Ну и ещё - вам может подойти brin индекс, раз у вас 1ккк записей. И обязательно учитывайте выравнивание и первыми пустите smallint, а потом уже varchar. Плюс вопрос - у вас когда проблемы возникают? При селектах? При вставке данных за месяц?