Зачем тогда свое делать ?

Есть у меня один знакомый, кодер от б-га, но вот архитектор БД... Убить порой хочется.

Приветствую товарищи, вопрос банальный, делаю простой интернет магазин плюс еще склад, таблицы нечто подобное: Users(roles), Customers, Items (Item by categories), Orders, Остатки, вопрос такой, может уже есть готовое спроектированная база? Или все делать самому?

Переделывать часто сложнее чем сделать с нуля как надо

Есть. http://bfy.tw/8sFr

database design for stock, database design for store, for book store, online store, database design for stock managment system —> пока вот так ищу, годное не нашел

У Вас принципиально неверный подход. При наличии теоретических знаний о принципах построения реляционных БД практическая задача разработки архитектуры под конкретное приложение становится тривиальной.

У Вас принципиально неверный подход. При наличии теоретических знаний о принципах построения реляционных БД практическая задача разработки архитектуры под конкретное приложение становится тривиальной.

Тогда придется делать самому, как умею. Обычно при кодинге, смотришь на чужой код, так быстрее учишься у бывалых, а для БД такое не прокатит?

Тогда придется делать самому, как умею. Обычно при кодинге, смотришь на чужой код, так быстрее учишься у бывалых, а для БД такое не прокатит?

Нарисуйте схему данных на стене и сразу понятно будет какие таблицы нужны

Не очень понятно чему можно научиться с чужой БД, у всех свои представления о структуре, сущностях, отношениях. И одну и ту же задачу можно реализовать пачкой способов. Тут скорее вопрос, что конкретно вам будет удобнее.

мастер холодный при этом

лаг есть?

что в топе?

ядер достаточно?

уж не в D ли состоянии большинство процессов ?

может рейд рассыпался

или свопчик

рейд в порядке

лага вроде не наблюдается

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

SELECT

ну там всегда так

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

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

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

<зануда> Drastically переводится как кардинально, а не драматически. </зануда> А так - +1, slow query log зубы и вперёд

ггг

Там вон в топе селекты простые по кучу времени висят

pgbouncer не используете, кстати?

используем

и перед мастером и перед слейвом баунсер стоит

блокировки посмотрите

привет что за софт?

pgsql-9.6.1, pgbouncer-1.7.2, рельсобэкенд

или о чем вопрос?

блокировки посмотрите

там 760 accesssharelock, если верить прометею

select * from pg_locks where granted = false таких много?

посмотрите на самые старые сессии на примари и стендбае

возможно среди них есть подозрительные

реально долгих запросов нет

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

визуализация

или о чем вопрос?

и слейв начинал сходить с ума

но сейчас дело не в этом

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

а селекты долгие одни и теже?

визуализация

Prometheus + Grafana

спс

проблем на схд нет?

нет

BLOAT какой на объектах БД?

select * from pg_locks where granted = false таких много?

postgres=# select * from pg_locks where granted = false; (0 rows)

посмотрите планы и наличие статистик

посмотрите pg_stat_user_tables, может analyze давно не было?

а что там конкретно посмотреть?

.

.

https://gist.github.com/anonymous/82037d2f17450b41173f8c57580c07ce

https://gist.github.com/anonymous/82037d2f17450b41173f8c57580c07ce

gist.github.com

gist.github.com

спасибо

так

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

и даже вроде не открыл ворота в ад

каков результат?

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

-[ RECORD 1 ]-+----------------------------------------------------------- database_name | darberry schema_name | public table_name | offer_financials index_name | offer_financials_uniqueness bloat_pct | 77.1 bloat_bytes | 16962265088 bloat_size | 16 GB index_bytes | 21987745792 index_size | 20 GB table_bytes | 41457065984 table_size | 39 GB index_scans | 0

ну вот вам и ответ на ваши вопросы)

ERROR: S client not available

блоат в половину размера таблицы

а запросы на этой таблицы тормозят?

pg_repack или FULL VACUUM

а запросы на этой таблицы тормозят?

если говорить культурно, то ДА

а когда на ней последний last_autovacuum был?

и попробуйте запустить на ней VACUUM VERBOSE

и попробуйте запустить на ней VACUUM VERBOSE

скорее всего не поможет. Он обрежет только то, что сможет обрезать в конце таблицы. Нужен полный вакуум таблицы

блоат в половину размера таблицы

https://github.com/reorg/pg_repack

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

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

А давайте сделаем сначала полный вакуум и проверим) у меня другие предположения на этот счет)

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

понятно, что сделав vacuum full у вас все будет чики-пуки

по, не факт, что он пройдет

потому что могут быть старые снапшоты активны, которые на дадут почистить dead tuples, для этого я и советую сначала запустить VACUUM VERBOSE, чтобы понять, сможет он почистить или нет

но если он отработает, то по идее и его должно хватить

А давайте сделаем сначала полный вакуум и проверим) у меня другие предположения на этот счет)

ну это пара часов простоя полного же, не?

Сделайте только над теми таблицами которые у вас наиболее распухшие сейчас. Чтобы не было простоя, воспользуйтесь https://github.com/reorg/pg_repack

Остальное сделайте ночью, когда у вас база наименее нагружена

https://gist.github.com/anonymous/82037d2f17450b41173f8c57580c07ce

по этой ссылке есть запрос dead_tuples. Там есть время последнего вакуума и анализа таблиц. если оно совсем старое то запустите обычный вакуум пока что.

а когда на ней последний last_autovacuum был?

# select relname,last_vacuum, last_autovacuum, last_analyze, last_autoanalyze from pg_stat_user_tables where relname = 'offer_financials'; -[ RECORD 1 ]----+------------------------------ relname | offer_financials last_vacuum | last_autovacuum | 2016-11-17 09:34:58.496268+00 last_analyze | 2016-10-04 06:25:12.992705+00 last_autoanalyze | 2016-11-17 11:42:04.574505+00

ну в общем только полный вакуум как я и говорил

Почему?

используйте пгрепак

Потому что нужно неистово писать 4 дня (2 из которых выходные), чтобы получить 16 Гб BLOAT

fuck yeah

ERROR: could not access status of transaction 1321660374 DETAIL: Could not open file "pg_clog/04EC": No such file or directory.

ооо..вот это уже интересно)

потому и не кусают

слейв ждет транзакций из этого лога

а его нет

коммит синхронный?

Это в ответ на что такое прилетело?