А, вот это мне вспоминалось, наверное: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=719c84c1be51f3d3fe6049b77ddbaa0c4b58a9a9

@Illuminati_eye будет жить. Поприветствуем!

Хмм... а я ведь был практически уверен, что в этой области (относительно) недавно что-то чинили, что-то мне такое вспоминается...

был патч, который заменят relation extension lock на LWLock. Но его вроде ещё не закоммитили

@Zolegzz будет жить. Поприветствуем!

@dshubenok будет жить. Поприветствуем!

@ptiforka будет жить. Поприветствуем!

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

Ой ой ой...

как мне думалось в postgresql вставка блокирует таблицу на все транзакции кроме select, отсюда идея секционирования

А что, в MS SQLServer таблица блокируется при вставке? ?

@poctek будет жить. Поприветствуем!

Всем привет! Столкнулись с интересной проблемой с materialized view в PG. Используем их как кэш чтобы быстро отдавать ответ пользователям. Данные поступают в оперативную таблицу, оттуда делаем запрос, в котором group by и вставляем это дело в materialized view, который раз в 5 секунд обновляем concurrently. По такой схеме у нас строятся две вьюхи: в одной аггрегируем по сумме, во второй берем максимальное значение. До какого-то момента все работает нормально, но потом время обновления вьюхи резко вырастает в три раза. Причем по графику видно, что это происходит с обеими вьюхами в одно и то же время. Сталкивался ли кто-то с подобным поведением и вообще с частым обновлением вьюх? Какая статистика может помочь узнать где проблема? Выбрали такой способ чтобы удобно было делать селекты, но может быть лучше было использовать другую технологию?

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

Сделай партиционирование с равномерным распределением по хешу. Вот так может и помочь в увеличении производительности записи.

друзья, нужно секционировать таблицу добавив соответственно 500 секций писать 500 раз create table не хочется решение динамический sql ? p.s. есть вдруг пример может у кого ?)

Лес, предложи уже команде завести систему очередей))

Александр будет жить. Поприветствуем!

А что, в MS SQLServer таблица блокируется при вставке? ?

Только вчера читал. Вроде нет)

Только вчера читал. Вроде нет)

Так я знаю, что нет... ?

Только вчера читал. Вроде нет)

Там может накладывается блокировка, которая означает "таблица используется", чтобы DDL , нельзя было с ней делать...

Насчёт того, что в Посгресе инсёрты не конфликтуют... Почитайте статью на Хабре как мы боролись с этими не конфликтующими блокировками: https://habr.com/company/postgrespro/blog/423685/

Что-то очень плохо написано. Извините.

Хмм... а я ведь был практически уверен, что в этой области (относительно) недавно что-то чинили, что-то мне такое вспоминается...

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

Ой ой ой...

?

@VadymLypa будет жить. Поприветствуем!

В чем может быть проблема

Службы запущенные

А ведь то, про что я рассказывал, написано прямым тесктом в процитированном Вами отрывке... ;) Ситуация, опять-таки, малореальная для типичных INSERT, конечно...

Всем привет! Столкнулись с интересной проблемой с materialized view в PG. Используем их как кэш чтобы быстро отдавать ответ пользователям. Данные поступают в оперативную таблицу, оттуда делаем запрос, в котором group by и вставляем это дело в materialized view, который раз в 5 секунд обновляем concurrently. По такой схеме у нас строятся две вьюхи: в одной аггрегируем по сумме, во второй берем максимальное значение. До какого-то момента все работает нормально, но потом время обновления вьюхи резко вырастает в три раза. Причем по графику видно, что это происходит с обеими вьюхами в одно и то же время. Сталкивался ли кто-то с подобным поведением и вообще с частым обновлением вьюх? Какая статистика может помочь узнать где проблема? Выбрали такой способ чтобы удобно было делать селекты, но может быть лучше было использовать другую технологию?

А ещё какая-нибудь информация есть? Определение view и таблиц, подробны логи при обновлении? Если выполнить на копии кластера, ситуация воспроизводится?

А это ошибка где / что её выдаёт? А ставили из какого дистрибутива?

@semenova_n будет жить. Поприветствуем!

А это ошибка где / что её выдаёт? А ставили из какого дистрибутива?

Ставил отсюда https://www.enterprisedb.com/downloads/postgres-postgresql-downloads После того как все установил, хочу открыть pgAdmin 4

Аналогичным образом (если Вы имели в виду Sch-) таблица будет "блокирована" и в PostgreSQL, конечно.

> После того как все установил, хочу открыть pgAdmin 4 Да это его проблема, похоже... Проверьте psql, для начала.

> После того как все установил, хочу открыть pgAdmin 4 Да это его проблема, похоже... Проверьте psql, для начала.

Как проверить ? Просто первый раз с ним

Как проверить ? Просто первый раз с ним

В командной строке: psql -U postgres

понял

Значит, psql в PATH (ещё?) не добавился. А как там в Windows... может, нужно re-login или перезагрузиться, чтобы изменения в PATH применились? Я не помню... Тем не менее, psql должен быть в том каталоге, куда Вы ставили PostgreSQL, найдите его / перейдите туда и повторите попытку.

Аналогичным образом (если Вы имели в виду Sch-) таблица будет "блокирована" и в PostgreSQL, конечно.

заблокирована на вставку будет ?? в общем в 500 потоков в 1-у не секционированную таблицу без блокировок можно писать ?

заблокирована на вставку будет ?? в общем в 500 потоков в 1-у не секционированную таблицу без блокировок можно писать ?

Так её и в MS SQL не будет, в типичных ситуациях. ;) > в общем в 500 потоков в 1-у не секционированную таблицу без блокировок можно писать ? Можно. Чтобы проверить, какое железо для этого потребуется, нужно рассказать поподробнее (С какой интенсивностью? Какой объём записи / ожидаемый размер таблицы? Какие индексы на ней будут? Какие другие запросы?), а лучше всего, протестировать.

Да, значит сервер PostgreSQL работает и проблема вообще не в нём. :) Так что разбираться Вам точно нужно с PgAdmin4 (я им вообще не пользовался, извините).

Да, значит сервер PostgreSQL работает и проблема вообще не в нём. :) Так что разбираться Вам точно нужно с PgAdmin4 (я им вообще не пользовался, извините).

Хорошо, спасибо за правильное направление

Так её и в MS SQL не будет, в типичных ситуациях. ;) > в общем в 500 потоков в 1-у не секционированную таблицу без блокировок можно писать ? Можно. Чтобы проверить, какое железо для этого потребуется, нужно рассказать поподробнее (С какой интенсивностью? Какой объём записи / ожидаемый размер таблицы? Какие индексы на ней будут? Какие другие запросы?), а лучше всего, протестировать.

по mssql прикладывал таблицу совместимости блокировок 1. интенсивность варируется от того сколько людей проходит перед камерой (думатся каждый поток пишет по 10 строк в секунду) 2. по железке Intel(R) Xeon(R) CPU X5670 @ 2.93GHz 6Gb Ram, 90Gb HDD 3. Размер до 100 мб растет и сбрасывается в dwh 4. без индексов 5. Запросов не будет, это "stage слой"

по mssql прикладывал таблицу совместимости блокировок 1. интенсивность варируется от того сколько людей проходит перед камерой (думатся каждый поток пишет по 10 строк в секунду) 2. по железке Intel(R) Xeon(R) CPU X5670 @ 2.93GHz 6Gb Ram, 90Gb HDD 3. Размер до 100 мб растет и сбрасывается в dwh 4. без индексов 5. Запросов не будет, это "stage слой"

> по mssql прикладывал таблицу совместимости блокировок Вот здорово... только Вы делаете из неё совершенно неправильный вывод. :) > 1. интенсивность варируется от того сколько людей проходит перед камерой (думатся каждый поток пишет по 10 строк в секунду) Как пишет, подробнее? По одной строке, по много? Какой ширины? Кстати, в связи с нижеуказанным (это "stage слой"), какой у Вас вообще подход к потере данных / насколько она критична? > 3. Размер до 100 мб растет и сбрасывается в dwh А потом, когда вырастет до 100 Мб, всё удаляется?

народ, кто подскажет по патрони

решил затюнить, но те параментры которые прописываю в конфиге патрони не применяются, в файле postgresql.conf , остаются дефолтные значения

то есть, меняю макс коннектион, на 200, а показывает 100

в файле postgresql.base.conf, макс коннектон раскоментировано

> по mssql прикладывал таблицу совместимости блокировок Вот здорово... только Вы делаете из неё совершенно неправильный вывод. :) > 1. интенсивность варируется от того сколько людей проходит перед камерой (думатся каждый поток пишет по 10 строк в секунду) Как пишет, подробнее? По одной строке, по много? Какой ширины? Кстати, в связи с нижеуказанным (это "stage слой"), какой у Вас вообще подход к потере данных / насколько она критична? > 3. Размер до 100 мб растет и сбрасывается в dwh А потом, когда вырастет до 100 Мб, всё удаляется?

таблица в моём понимании - файл. Запись в файл есть физическая линейная опеация. Соответственно потоки конкурируют за файл. Пишут в таблицу ручки (RESTful) по 10 строк 10 колонок, одна из колонок одномерный вектор 128-и значенй float(32)[] Подход такой: ручки пишут в схему stg, условно каждый час переливается в схему dwh. перелитые строки удаляются из stg, а затем из dwh строится отчет в схему dm

> таблица в моём понимании - файл. А в понимании тех, кто разрабатывает СУБД — нет (концептуально). > Запись в файл есть физическая линейная опеация. Соответственно потоки конкурируют за файл. И, соответственно, это работает совсем не так. > по 10 строк 10 колонок, одна из колонок одномерный вектор 128-и значенй float(32)[] Так у Вас эта таблица уже есть? Тогда можно прямо посмотреть ширину... Вообще, Вы бы лучше на каждый мой вопрос ответили...

есть ли способ узнать через консоль, закончилась ли первоначальная синхронизация таблиц при логической репликации? в логи постгрес пишет по каждой таблице: LOG: logical replication table synchronization worker for subscription "demo", table "users" has started LOG: logical replication table synchronization worker for subscription "demo", table "users" has finished вот бы скриптами тоже узнать можно было (без парсинга логов)

> таблица в моём понимании - файл. А в понимании тех, кто разрабатывает СУБД — нет (концептуально). > Запись в файл есть физическая линейная опеация. Соответственно потоки конкурируют за файл. И, соответственно, это работает совсем не так. > по 10 строк 10 колонок, одна из колонок одномерный вектор 128-и значенй float(32)[] Так у Вас эта таблица уже есть? Тогда можно прямо посмотреть ширину... Вообще, Вы бы лучше на каждый мой вопрос ответили...

не совсем понятен вопрос "какой у Вас вообще подход к потере данных / насколько она критична?"

не совсем понятен вопрос "какой у Вас вообще подход к потере данных / насколько она критична?"

У Вас будут возникать ситуации (по разным причинам), когда данные с камер могут теряться. Что Вы с этим вообще собираетесь делать? И что делать в том случае, если они всё же потеряны?

У Вас будут возникать ситуации (по разным причинам), когда данные с камер могут теряться. Что Вы с этим вообще собираетесь делать? И что делать в том случае, если они всё же потеряны?

по какой причине данные будут потеряны?

по какой причине данные будут потеряны?

Вам должно быть виднее. Вы же уже должны были об этом думать, нет? ;)

Вам должно быть виднее. Вы же уже должны были об этом думать, нет? ;)

реализована автономность и очередь на nuk'e к которому подцеплена камера, в случае даже если бд будет недоступна и/или нюк выдернут из розетки, как только его включат и/или вновь поднимется база - данные из очереди попадут в бд данные не потеряются только если кто-то с3,14159здит наш нюк с камерой))))

небольшая ретроспектива, в чем сабж ?

небольшая ретроспектива, в чем сабж ?

А в том, что с этим со стороны БД? Когда она потеряет данные, Вы что собирались делать?

А в том, что с этим со стороны БД? Когда она потеряет данные, Вы что собирались делать?

по какой из причин данные должны быть утеряны? как дополнил в сообщении выше, пропадут они если только кто-то с3,14159здит наш нюк с камерой =) или нашу серверную затопит ты намекаешь на бэкапы в облако? или я что-то пропустил))

> по какой из причин данные должны быть утеряны? Потому что "железо" сервера рано или поздно накроется (ну или исчезнет, как в Вашем примере ;) )?

т.е. всё-таки облако?)

т.е. всё-таки облако?)

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

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

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

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

Не паясничайте. ;) Причём тут ACID? Вы что, хотите мне сказать, что об аварийных ситуациях со стороны СУБД Вы вообще не думали?

Не паясничайте. ;) Причём тут ACID? Вы что, хотите мне сказать, что об аварийных ситуациях со стороны СУБД Вы вообще не думали?

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

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

У вас всё будет хорошо до определённого момента. После этого момента будет всё не просто плохо, а совсем плохо. С базами всегда так, либо думаешь, либо страдаешь безмерно.

намёкам вашим стараюсь внять я, но сказать прямо время пришло. С чем столкнуться придется юному джедаю ? запугать запугали, а теперь жгите панчлайн ? чую тайные эмпирические знания ☝?

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

Ага, то есть на потерю данных Вам, грубо говоря, наплевать. > а по правде, в голову пока не приходят аварийные ситуации Вы серьёзно? У Вас никогда ничего в Ваших компьютерах не ломалось?! И OS никогда так не падала, чтобы FS "превращалась в тыкву"? И ни одного bug-а в системах хранения Вы не видели? Ладно, идём дальше... Раз Вы "уповаете", рассмотрите возможность "synchronous_commit = off". Но! Это может приводить к потере committed транзакций даже при исправном железе. Но вообще-то я спрашивал не только поэтому... Как Вы собирались предотвращать возможные потери на участке клиент -> сервер? Откуда клиент знает, какие данные ему передавать снова, если сервер упал в неподходящий момент?

Ага, то есть на потерю данных Вам, грубо говоря, наплевать. > а по правде, в голову пока не приходят аварийные ситуации Вы серьёзно? У Вас никогда ничего в Ваших компьютерах не ломалось?! И OS никогда так не падала, чтобы FS "превращалась в тыкву"? И ни одного bug-а в системах хранения Вы не видели? Ладно, идём дальше... Раз Вы "уповаете", рассмотрите возможность "synchronous_commit = off". Но! Это может приводить к потере committed транзакций даже при исправном железе. Но вообще-то я спрашивал не только поэтому... Как Вы собирались предотвращать возможные потери на участке клиент -> сервер? Откуда клиент знает, какие данные ему передавать снова, если сервер упал в неподходящий момент?

.у меня ничего не падало))) 2 недели отроду девопсю и админю, до этого жил простым дивилопиром на osx ;) .такая себе реклама synchronous_commit'a :D .нет потерь на данном участке, у нас нюк всё пишет в очередь если базы нет, а когда появляется - пишет всё из очереди в базу

@lestvt raid контроллер может сгореть, вместе с дисками

и вообще весь Питер разбомбят нахер и моей базе кабзец :DD

ощущение что мне хотят облако продать ))))

а может mirroring ?

угадал? писать в два сервера ?

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