← All posts tagged PostgreSQL

"Картина следующая: вот вы тащите миллион записей из таблицы своей mongodb, потом второй миллион из другой таблицы, а потом на клиенте этим вашим джаваскриптом пытаетесь сами, на коленке хоть как-то сделать JOIN.

Во-первых вы гоняете кучу траффика, во-вторых убиваете CPU на клиенте. И главное, в-третьих — вы решаете проблему, с которой в реляционных базах данных блестяще разделались еще в 1980-х годах".
(с)

```
for tbl in `psql -qAt -c "select tablename from pg_tables where schemaname = 'public';" YOUR_DB` ; do psql -c "alter table \"$tbl\" owner to NEW_OWNER" YOUR_DB ; done

for tbl in `psql -qAt -c "select sequence_name from information_schema.sequences where sequence_schema = 'public';" YOUR_DB` ; do psql -c "alter table \"$tbl\" owner to NEW_OWNER" YOUR_DB ; done

for tbl in `psql -qAt -c "select table_name from information_schema.views where table_schema = 'public';" YOUR_DB` ; do psql -c "alter table \"$tbl\" owner to NEW_OWNER" YOUR_DB ; done
```

Основное в конфиге:

shared_buffers — дать половину оперативки. Потюнить в системе файловый кэш, чтобы уменьшить шанс двойного кэширования.
work_mem = 64MB (поставить для начала) и смотреть за созданием temp-файлов. Если они есть — увеличивать
temp_buffers = 32MB
maintenance_work_mem = 2GB
max_stack_depth = 4MB

В системе (FreeBSD):
# /boot/loader.conf:
kern.ipc.semmns=1024
kern.ipc.semmni=256

# /etc/sysctl.conf:
kern.ipc.shm_use_phys=1
kern.ipc.shmall=8605532
kern.ipc.shmmax=35248259072 # если памяти 64 гига и мы хотим половину дать постгресу.

+ пускать всех только через pgbouncer.
— В общем-то, для начала этого хватит чтобы система уже быстро работала на больших объемах данных.
Если будет проседать дисковый i/o, нужно смотреть в сторону:

synchronous_commit = off
checkpoint_timeout
checkpoint_completion_target
(размазываем чекпоинты по времени)

Есть одна софтина, задача — агрегация разных данных из очереди (rabbitMQ) и складывание в хранилище (долгосрочное). Потом из сложенного в хранилище считаются всякие штуки, например, сколько конкретный клиент должен нам денег (и другое скучное). В силу исторических причин до сегодня все писалось в шардированный mongodb, развернутой на могучем стеке серверов (то ли 4, то ли 6) с SSD raid и прочими наворотами.

Но тут по производственной необходимости пришлось сохранять практически те же самые данные еще раз — для других скучных целей. А так как этот кусочек писал лично ваш покорный слуга (ололо ленивый быдлокодер), то складывать данные он решил в постгре. Развернутом на сервере чуть похуже, с рейдом, но без SSD.

Результат такой — чтобы в приемлемое время успевать сложить данные в монгу, в данный момент необходимо 40-60 параллельных потоков, пишущих в монгу. Для постгре хватает 1 (одного).

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