@darthunix спасибо, гляну

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

Что значит "не заметил"? Запись новых данных будет занимать ресурсы в любой системе / архитектуре, чудес не бывает. У Вас есть какая-то проблема (время выполнения запросов при заливке данных слишком велико) или нет? ;)

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

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

я пока еще провожу тесты, если пачка 100кк вставится за сутки в таблицу с индексами — то задача "решена"

я пока еще провожу тесты, если пачка 100кк вставится за сутки в таблицу с индексами — то задача "решена"

По-моему, тут одно из трёх: . Железо в принципе не позволяет решить Вашу задачу. . Железо в принципе позволяет решить Вашу задачу, но что-то неправильно настроено. . Железо при текущих настройках позволяет решить Вашу задачу (т.е. проблемы вообще нет). Разве не так?

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

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

По-моему, тут одно из трёх: . Железо в принципе не позволяет решить Вашу задачу. . Железо в принципе позволяет решить Вашу задачу, но что-то неправильно настроено. . Железо при текущих настройках позволяет решить Вашу задачу (т.е. проблемы вообще нет). Разве не так?

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

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

Без определения того, что такое "незаметным", это беспредметное обсуждение, IMHO. Дело в том, что время выполнения одного и того же запроса, на тех же данных существенно "плавает" в многопользовательской системе даже при "нормальной" нагрузке.

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

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

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

И какое решение Вы выбрали (просто любопытно)? Какое у Вас железо, кстати?

И какое решение Вы выбрали (просто любопытно)? Какое у Вас железо, кстати?

сейчас я выбрал не использовать MyRocks, а просто в течении месяца аккумулировать новые данные в отдельную табличку без индексов (вставка будет за O(1)) А раз в месяц пушить ее в основную за O(log(N)) в санитарный день

Данные у юзера будут месячной актуальности (это норма в моей задаче) Аккумулированная таблица ему на чтение доступна не будет

сейчас я выбрал не использовать MyRocks, а просто в течении месяца аккумулировать новые данные в отдельную табличку без индексов (вставка будет за O(1)) А раз в месяц пушить ее в основную за O(log(N)) в санитарный день

O(N log N), вообще-то. ;) Понятно, спасибо!

И вставал вопрос: полностью пересчитать индексы (удалить индексы, вставить данные, построить индексы), или же сразу вставлять

решил пока что второе

O(N log N), вообще-то. ;) Понятно, спасибо!

если у вас N ≈ кол-во строк в таблице, то вы похоже что-то напутали :) Так как вставка за O(N log(N)) при 1ккк это как-то долговато

btree insert же O(log(N))

если у вас N ≈ кол-во строк в таблице, то вы похоже что-то напутали :) Так как вставка за O(N log(N)) при 1ккк это как-то долговато

N —- кол-во вставляемых строк. Если чуть точнее, то, если K —- кол-во строк в таблице-приёмнике, а N —- кол-во вставляемых строк, то это где-то O(N log K). ;)

а, ну тогда разумеется :) напугали вы

кстати, кто-то занимался расчетом time complexity для билда индекса btree с нуля, когда данные уже вставлены?

кстати, кто-то занимался расчетом time complexity для билда индекса btree с нуля, когда данные уже вставлены?

O(N log N) если данные не сортированы, что тут заниматься-то? ;) "The devil is in the detail", т.е. вся разница в константах при O(N log N).

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

точнее хочу прикинуть отношение time complexity между (удалить индексы, вставить данные, построить индексы) и (вставить данные в таблицу с индексом) при условии, что в таблице изначально имеется 1ккк записей

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

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

А его нет, асимптоты у них одинаковые. Суть, опять-таки, в константах при O.

и каково между ними различие?

и верно ли утверждение, что во втором случае износ ресурсов серверных (жесткий диск и тд) будет ≈ меньше?

точнее хочу прикинуть отношение time complexity между (удалить индексы, вставить данные, построить индексы) и (вставить данные в таблицу с индексом) при условии, что в таблице изначально имеется 1ккк записей

Тестируйте, что тут скажешь... кроме того, в Вашей ситуации можно менять настройки PostgreSQL на время заливки данных, что может дать существенный выигрыш.

ну да, я ставлю меинтененс ворк мем в 4ГБ

спасибо :)

Тестируйте, что тут скажешь... кроме того, в Вашей ситуации можно менять настройки PostgreSQL на время заливки данных, что может дать существенный выигрыш.

Просто дело в том, что полный ребилд это 1ккк+ записей, а вставить надо только ≈30кк (к слову, вчера поставил билдиться в 20:16 индексы, так до сих пор считаются, что-то уже думаю что второй вариант быстрее выйдет)

ну да, я ставлю меинтененс ворк мем в 4ГБ

Это далеко не единственная настройка. https://www.postgresql.org/docs/current/static/populate.html читали? Кроме того, вполне возможно, что у Вас PostgreSQL вообще настроен не оптимальных образом. ;)

Просто дело в том, что полный ребилд это 1ккк+ записей, а вставить надо только ≈30кк (к слову, вчера поставил билдиться в 20:16 индексы, так до сих пор считаются, что-то уже думаю что второй вариант быстрее выйдет)

Вот от соотношения кол-ва записей в таблице, кол-ва добавляемых записей; и определений самих индексов это и зависит. Т.е., опять-таки, тестируйте. ;)

Это далеко не единственная настройка. https://www.postgresql.org/docs/current/static/populate.html читали? Кроме того, вполне возможно, что у Вас PostgreSQL вообще настроен не оптимальных образом. ;)

читал конечно, именно оттуда я взял вот​ это: >If you are adding large amounts of data to an existing table, it might be a win to drop the indexes, load the table, and then recreate the indexes. Of course, the database performance for other users might suffer during the time the indexes are missing. One should also think twice before dropping a unique index, since the error checking afforded by the unique constraint will be lost while the index is missing.

Вот от соотношения кол-ва записей в таблице, кол-ва добавляемых записей; и определений самих индексов это и зависит. Т.е., опять-таки, тестируйте. ;)

ага, спасибо)

читал конечно, именно оттуда я взял вот​ это: >If you are adding large amounts of data to an existing table, it might be a win to drop the indexes, load the table, and then recreate the indexes. Of course, the database performance for other users might suffer during the time the indexes are missing. One should also think twice before dropping a unique index, since the error checking afforded by the unique constraint will be lost while the index is missing.

Да, кстати, можно посмотреть и на https://www.postgresql.org/docs/current/static/non-durability.html (только не fsync, конечно). ;)

сейчас гляну

точнее хочу прикинуть отношение time complexity между (удалить индексы, вставить данные, построить индексы) и (вставить данные в таблицу с индексом) при условии, что в таблице изначально имеется 1ккк записей

Петр, а вы не рассматривали brin индекс? Он конечно не совсем индекс, но для ваших объёмов небольшой seq scan может и не во вред. И обновляется он "руками" - как раз то, чего вы хотели

Не будет ли дешевле - на чтении - лёгкий index scan, а затем небольшой seq scan?

Господа, как мне получить количество дней, начиная с первой записи в таблице по сегодняший день 1 запросом? Могу получить дату первой записи и постчитать от неё на ЯП основной логики программы, но может есть способ получить это одним запросом?

Sysdate-min

Привет всем ,возникла такая пробелма в боте тедеграм. Бот стоит на впс и в нем есть функция "Сделать рассылку на всех пользователей" С сегодняшнего утра выдает такую ошибку в консоли "sqlite3.OperationalError: Could not decode to UTF-8 column 'channels' with text '?�'"

Кто поможет решить ,деньгой не обижу

мигрируй с скулайт на постгре

а так кто то записал в колонку не UTF8 символ

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

типа такого делай last_id = 0 while True: row = 'select * from blabla where id > last_id order by id limit 1' last_id = row['id'] log.info(last_id)

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

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

Кто поможет решить ,деньгой не обижу

bitcoin кошелек 1JmaXFNBfwnjuVDpekn8D79wNdrAepEPeA

а можно ли для каждого пользователя генерировать свою таблицу?

например сделать у пользователей инвентарь и это будет отдельная таблица для пользователя

или так не эффективно?

а можно ли для каждого пользователя генерировать свою таблицу?

Можно даже целую схему

а как это потом связать?

у пользователя хранить название таблицы?

или так не эффективно?

Да, это будет неэффективно

а как лучше сделать?

не делал серверных БД

у пользователя хранить название таблицы?

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

ээто внешний ключ называется

Две таблицы: user (Id serial, name text) и inventory (Id serial, userid int, name text, amount int)

И ты всегда сможешь посмотреть инвентарь игрока запросом select * from inventory where userid=123

не делал серверных БД

Нет различий между серверных или пользовательских бд. Есть нормализованные и не нормализованные.

я в том смысле что не приходилось делать БД для многих пользователей, делал такие, где всего 1 пользователь

я в том смысле что не приходилось делать БД для многих пользователей, делал такие, где всего 1 пользователь

И это тоже неважно. Всегда есть объекты и связи между ними. Это не зависит от количества пользователей бд. Это зависит от предметной области

Петр, а вы не рассматривали brin индекс? Он конечно не совсем индекс, но для ваших объёмов небольшой seq scan может и не во вред. И обновляется он "руками" - как раз то, чего вы хотели

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

@netneladno если интересно, индексирование закончилось и заняло 20 часов 2 минуты :) теперь попробую вставить пачку 40млн и сделать замер

что значит таблица в центре?

я ее уже удалил, она без надобности

Товарищи, поделитесь лучшими практиками по партицированию (мне предстоит импортировать два вида данных в количестве 125 млн и 4 млн строк). Вообще сабж потянет столько?

я ее уже удалил, она без надобности

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

Товарищи, поделитесь лучшими практиками по партицированию (мне предстоит импортировать два вида данных в количестве 125 млн и 4 млн строк). Вообще сабж потянет столько?

конечно, потянет: это копейки

а зачем там собственно партицирование? как делятся эти 125 млн?

а зачем там собственно партицирование? как делятся эти 125 млн?

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

схему уже сильно переделал)

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

например +100к записей в день

100k записей в день - это немного

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

паттерн чтения важнее

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

их необходимо читать

как именно читать? по ключу, по интервалу, top-n, knn, ещё как-то? :)

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

id юзера - 30 символьный токен

если индекс по этому id есть, все будет нормально

если индекс по этому id есть, все будет нормально

токен это же как ююид твой?.. нормально с ним, напомни? ?

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

Зачем вам postgres?

Зачем вам postgres?

А есть что-то получше?

Ну логи хранить можно много где... можно больше подробностей о логах... о их структурированности?

Просто хранение логов в pg - если это логи, а не аудит - у меня особый пунктик - много геммороя - большие объемы. При том, что 99% логов не будут прочитаны никогда