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

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

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

то что знает клиент с базой никак не связано На этом этапе я нить потерял, пойду спать.

ну при чем тут база и клиент

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

Как причём?? А оттуда данные брать?

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

понял?

Нет, ну да ладно.

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

ты же не шлешь с фронтенда в базу запросы, все через бекенд, так и тут

короче чет я времени на разъяснения всякие много потратил, теперь точно пошел

сервер не умеет кластеризоваться?

сервер не умеет кластеризоваться?

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

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

все блин))) я пошел

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

Звучит как план

запускал через python wheel

решил проблему, если что)

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

фух чуть не умер

фух чуть не умер

не юзаешь наследование надеюсь?

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

Сергей Скрипник будет жить. Поприветствуем!

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

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

Привет всем. Столкнулся с проблемой что постгрес нагружает диск на 100%. Версия постгрес 9.4.2, которая для 1с. На ней собственно база 1ски. ОС Винда 2012. Диск ХДД. Подскажите пож. куда копать.

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

Привет всем. Столкнулся с проблемой что постгрес нагружает диск на 100%. Версия постгрес 9.4.2, которая для 1с. На ней собственно база 1ски. ОС Винда 2012. Диск ХДД. Подскажите пож. куда копать.

Эх, старая у Вас версия, во-первых. Начать смотреть можно с https://www.postgresql.org/docs/9.4/static/monitoring-stats.html А что такое "которая для 1с", какая-то их сборка? Они обновления выпускают вообще? Если да, стоит до 9.4.19 обновиться, хотя бы.

так у меня 9.4.2

да, с сайта 1ски скаченная

так у меня 9.4.2

Так у них новее нет, что ли?

эм, я не смотрел ещё

Парни, всем привет! Подскажите плиз как в PG можно сделать уникальность по столбцу в 3-х таблицах? То есть дано 3 таблицы и в каждой из них есть поле с неким числом (code), как сделать уникальность на это поле по трем таблицам сразу? думал на счет constraint но чето хз можно ли там в другие таблицы заглядывать. Т.е при вставке в любую нужно чекать другие две. P.S Понимаю, что костыльно и уместно было бы использовать uid, но надо вот так :/

вроде уже даже 10 для 1c есть....

вроде уже даже 10 для 1c есть....

У меня 10 стоит, 1С

У меня 10 стоит, 1С

Я его сам собирал, когда десятка вышла... Потестил, правда в бой так и не рискнул.

вроде уже даже 10 для 1c есть....

Я не про 10-ку, я про minor version.

Парни, всем привет! Подскажите плиз как в PG можно сделать уникальность по столбцу в 3-х таблицах? То есть дано 3 таблицы и в каждой из них есть поле с неким числом (code), как сделать уникальность на это поле по трем таблицам сразу? думал на счет constraint но чето хз можно ли там в другие таблицы заглядывать. Т.е при вставке в любую нужно чекать другие две. P.S Понимаю, что костыльно и уместно было бы использовать uid, но надо вот так :/

А зачем? И причём тут вообще UID?!

А зачем? И причём тут вообще UID?!

ну типа обеспечть уникальный код в пределах 3х таблиц

Я не про 10-ку, я про minor version.

Ааа, а я про мажерную. На официальном сайте 1с можно сборку десятки скачать для 1с.

ну типа обеспечть уникальный код в пределах 3х таблиц

Ещё раз: Зачем Вам "обеспечть уникальный код в пределах 3х таблиц"? И причём тут вообще UUID?

Вопрос: кто-нибудь знает какой-нибудь хороший способ ускорять COUNT? Пример запроса с планом (users ~1.5M строк): explain analyze SELECT COUNT(*) AS count FROM "public"."users" WHERE "public"."users"."group_id" = 3 AND "public"."users"."accreditation" = 2 AND "public"."users"."ban_flags" = 0; QUERY PLAN —--------------------------------------------------------------------------------------------------------------------------------------- Aggregate (cost=15050.91..15050.92 rows=1 width=8) (actual time=613.643..613.644 rows=1 loops=1) -> Index Scan using gid_accr_ban on users (cost=0.43..14983.84 rows=26829 width=0) (actual time=0.064..475.212 rows=166949 loops=1) Index Cond: ((group_id = 3) AND (accreditation = 2)) Filter: (ban_flags = 0) Rows Removed by Filter: 11982 Planning time: 0.392 ms Execution time: 613.727 ms (7 rows)

Вопрос: кто-нибудь знает какой-нибудь хороший способ ускорять COUNT? Пример запроса с планом (users ~1.5M строк): explain analyze SELECT COUNT(*) AS count FROM "public"."users" WHERE "public"."users"."group_id" = 3 AND "public"."users"."accreditation" = 2 AND "public"."users"."ban_flags" = 0; QUERY PLAN —--------------------------------------------------------------------------------------------------------------------------------------- Aggregate (cost=15050.91..15050.92 rows=1 width=8) (actual time=613.643..613.644 rows=1 loops=1) -> Index Scan using gid_accr_ban on users (cost=0.43..14983.84 rows=26829 width=0) (actual time=0.064..475.212 rows=166949 loops=1) Index Cond: ((group_id = 3) AND (accreditation = 2)) Filter: (ban_flags = 0) Rows Removed by Filter: 11982 Planning time: 0.392 ms Execution time: 613.727 ms (7 rows)

добавить в индекс ban_flags? или индекс с where ban_flags=0

точно куда я только смотрел есть ban_flags и есть ban =\

спасибо!

Ещё раз: Зачем Вам "обеспечть уникальный код в пределах 3х таблиц"? И причём тут вообще UUID?

Ок, uuid не причем. Приходят данные от внешней системы из разных источников api, добавленные руками и т.д, в зависимости от типа пишутся в одну из 3х таблиц, все они приходят с определенным кодом, так вот нужно уметь понять что этого кода еще нет ни в одной из таблиц при вставке. Думаю подойдет просто view с кодами.

добавить в индекс ban_flags? или индекс с where ban_flags=0

взял по существующему индексу с примерно подходящей мощностью Всё равно 200-300мс на запрос: —------------------------------------------------------------------------------------------------------------------------------------------- Aggregate (cost=1640.94..1640.95 rows=1 width=8) (actual time=323.630..323.630 rows=1 loops=1) -> Index Only Scan using gid_accr_ban on users (cost=0.43..1573.85 rows=26833 width=0) (actual time=0.059..200.830 rows=166978 loops=1) Index Cond: ((group_id = 3) AND (accreditation = 2) AND (ban = 0)) Heap Fetches: 24855 Planning time: 0.318 ms Execution time: 323.698 ms

взял по существующему индексу с примерно подходящей мощностью Всё равно 200-300мс на запрос: —------------------------------------------------------------------------------------------------------------------------------------------- Aggregate (cost=1640.94..1640.95 rows=1 width=8) (actual time=323.630..323.630 rows=1 loops=1) -> Index Only Scan using gid_accr_ban on users (cost=0.43..1573.85 rows=26833 width=0) (actual time=0.059..200.830 rows=166978 loops=1) Index Cond: ((group_id = 3) AND (accreditation = 2) AND (ban = 0)) Heap Fetches: 24855 Planning time: 0.318 ms Execution time: 323.698 ms

vacuum сделай, у тебя 24855 heap fetches на index only scan

Ок, uuid не причем. Приходят данные от внешней системы из разных источников api, добавленные руками и т.д, в зависимости от типа пишутся в одну из 3х таблиц, все они приходят с определенным кодом, так вот нужно уметь понять что этого кода еще нет ни в одной из таблиц при вставке. Думаю подойдет просто view с кодами.

Понятно. Дело в том, что в такой модели типов лучше иметь общую родительскую таблицу (и Вы уже увидели, почему). Т.е. что-то вроде: CREATE TABLE common_type(id serial PRIMARY KEY, <common fields>); CREATE TABLE type_one(id int PRIMARY KEY REFERENCES common_type, <type one fields>); CREATE TABLE type_two(id int PRIMARY KEY REFERENCES common_type, <type two fields>); Вставка становится немного сложнее, естественно. Т.е. нужно вставлять сначала в common_type, потом в type_x.

Понятно. Дело в том, что в такой модели типов лучше иметь общую родительскую таблицу (и Вы уже увидели, почему). Т.е. что-то вроде: CREATE TABLE common_type(id serial PRIMARY KEY, <common fields>); CREATE TABLE type_one(id int PRIMARY KEY REFERENCES common_type, <type one fields>); CREATE TABLE type_two(id int PRIMARY KEY REFERENCES common_type, <type two fields>); Вставка становится немного сложнее, естественно. Т.е. нужно вставлять сначала в common_type, потом в type_x.

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

взял по существующему индексу с примерно подходящей мощностью Всё равно 200-300мс на запрос: —------------------------------------------------------------------------------------------------------------------------------------------- Aggregate (cost=1640.94..1640.95 rows=1 width=8) (actual time=323.630..323.630 rows=1 loops=1) -> Index Only Scan using gid_accr_ban on users (cost=0.43..1573.85 rows=26833 width=0) (actual time=0.059..200.830 rows=166978 loops=1) Index Cond: ((group_id = 3) AND (accreditation = 2) AND (ban = 0)) Heap Fetches: 24855 Planning time: 0.318 ms Execution time: 323.698 ms

у тебя append-only таблица?

у тебя append-only таблица?

удалений нет, всё верно поля могут меняться

Aggregate (cost=1076.96..1076.97 rows=1 width=8) (actual time=328.507..328.508 rows=1 loops=1) -> Index Only Scan using gid_accr_ban on users (cost=0.43..1002.87 rows=29636 width=0) (actual time=0.174..192.684 rows=166978 loops=1) Index Cond: ((group_id = 3) AND (accreditation = 2) AND (ban = 0)) Heap Fetches: 1554 Planning time: 0.615 ms Execution time: 328.588 ms лучше, да, но всё равно долго

Aggregate (cost=1076.96..1076.97 rows=1 width=8) (actual time=328.507..328.508 rows=1 loops=1) -> Index Only Scan using gid_accr_ban on users (cost=0.43..1002.87 rows=29636 width=0) (actual time=0.174..192.684 rows=166978 loops=1) Index Cond: ((group_id = 3) AND (accreditation = 2) AND (ban = 0)) Heap Fetches: 1554 Planning time: 0.615 ms Execution time: 328.588 ms лучше, да, но всё равно долго

а почему heap fetches всё ещё 1554?

надо 0

уже 2028

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

А почему бы и не переделать? Т.е. добавить общую таблицу, в которой одно это поле + PRIMARY KEY + триггеры на вставку в прочие три? Другой вариант — повесить AFTER TRIGGERS, которые будут проверять. Но, если Вы используете default isolation level, Вам придётся (наверное) немало подолбаться, чтобы они работали надёжно.

уже 2028

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

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

десятки

десятки

а shared_buffers таблицу в себя вмещает?

А почему бы и не переделать? Т.е. добавить общую таблицу, в которой одно это поле + PRIMARY KEY + триггеры на вставку в прочие три? Другой вариант — повесить AFTER TRIGGERS, которые будут проверять. Но, если Вы используете default isolation level, Вам придётся (наверное) немало подолбаться, чтобы они работали надёжно.

Да, вариант с дополнтельной таблицей вполне подходящий, дело в том, что было ок до недавних пор, пока данные из внешних источников не начали задваиваться, сейчас помимо огрничений на уровне бизнес-логики хотелось бы добавить ограничения на бд. А вариант с view примерно же тоже самое? т.е данных не так чтобы много и запрос к view наверно не сильно будет критичен в плане скорости.

Да, вариант с дополнтельной таблицей вполне подходящий, дело в том, что было ок до недавних пор, пока данные из внешних источников не начали задваиваться, сейчас помимо огрничений на уровне бизнес-логики хотелось бы добавить ограничения на бд. А вариант с view примерно же тоже самое? т.е данных не так чтобы много и запрос к view наверно не сильно будет критичен в плане скорости.

Эээ... а чем Вам поможет VIEW? Какой именно VIEW?

а shared_buffers таблицу в себя вмещает?

табличка чуть меньше 2гб, buffers - 8 да, вмещает

Эээ... а чем Вам поможет VIEW? Какой именно VIEW?

Ну типа строить view по трем таблицам и смотреть туда

Ну типа строить view по трем таблицам и смотреть туда

Имеется в виду не mat. view

Ну типа строить view по трем таблицам и смотреть туда

Так это тот же второй вариант, просто "сахара" больше. ;) Хотя, опять-таки, в плане реализации надёжности на RC это может быть ещё и похуже (сильно не думал, просто ощущение).

Так это тот же второй вариант, просто "сахара" больше. ;) Хотя, опять-таки, в плане реализации надёжности на RC это может быть ещё и похуже (сильно не думал, просто ощущение).

Спасибо за совет)

табличка чуть меньше 2гб, buffers - 8 да, вмещает

А покажите EXPLAIN (ANALYZE, BUFFERS). Впрочем, судя по тому, что нужно посчитать actual rows=166978, время выполнения ещё и ничего...

А покажите EXPLAIN (ANALYZE, BUFFERS). Впрочем, судя по тому, что нужно посчитать actual rows=166978, время выполнения ещё и ничего...

Aggregate (cost=1013.93..1013.94 rows=1 width=8) (actual time=316.484..316.485 rows=1 loops=1) Buffers: shared hit=9407 -> Index Only Scan using gid_accr_ban on users (cost=0.43..942.11 rows=28726 width=0) (actual time=0.308..204.208 rows=166981 loops=1) Index Cond: ((group_id = 3) AND (accreditation = 2) AND (ban = 0)) Heap Fetches: 4663 Buffers: shared hit=9407 Planning time: 2.614 ms Execution time: 316.596 ms

Aggregate (cost=1013.93..1013.94 rows=1 width=8) (actual time=316.484..316.485 rows=1 loops=1) Buffers: shared hit=9407 -> Index Only Scan using gid_accr_ban on users (cost=0.43..942.11 rows=28726 width=0) (actual time=0.308..204.208 rows=166981 loops=1) Index Cond: ((group_id = 3) AND (accreditation = 2) AND (ban = 0)) Heap Fetches: 4663 Buffers: shared hit=9407 Planning time: 2.614 ms Execution time: 316.596 ms

Ну так: actual rows=166981, Buffers: shared hit=9407 Т.е. просто считать нужно много, так что... чего Вы ещё хотите? ;(

Ну то есть понятно, что данных много и в-целом оно считать будет долго

Вопрос о существующих практиках оптимизации COUNT в-целом

Первый - очевидно, не использовать COUNT Второй - предварительный подсчет через триггеры или на уровне приложения

но может есть ещё что-то хорошее? )

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

здрасьте,подскажите как переименовать БД если к ней есть коннект

но может есть ещё что-то хорошее? )

А вот чисто ради интереса, можете попробовать: CREATE INDEX /* CONCURRENTLY */ ON "users"(id) WHERE group_id = 3 AND accreditation = 2 AND ban_flags = 0; Потому что лучше уже вряд ли будет...