postgresql для частых инсертов

Добрый день!

Порекомендуйте плз,

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

Необходимо эти данные записывать в базу.
Насколько целесообразно использовать для этих целей pg?
(есть специализированные бд - mongo, redis - но может можно обойтись одной бд - pg).

Спасибо :)

В чем собственно проблема? Под такую задачу пойдет любая СУБД, даже текстовый файлик сгодится. Вопрос только в количестве этих вставок. Если в пике меньше сотни за секунду то и думать ни о чем не нужно.

BusInt
В чем собственно проблема? Под такую задачу пойдет любая СУБД, даже текстовый файлик сгодится. Вопрос только в количестве этих вставок. Если в пике меньше сотни за секунду то и думать ни о чем не нужно.

а если больше 100? Несколько тысяч пользователей на сайте, каждый генерирует события для записи в бд.

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

может что-то еще?...

Особенность - данные нужно записывать он-лайн, использоваться они будут позже, в качестве статистики, т.е. не онлайн.

Orin
а если больше 100? Несколько тысяч пользователей на сайте, каждый генерирует события для записи в бд.

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

Orin
BusInt В чем собственно проблема? Под такую задачу пойдет любая СУБД, даже текстовый файлик сгодится. Вопрос только в количестве этих вставок. Если в пике меньше сотни за секунду то и думать ни о чем не нужно. а если больше 100? Несколько тысяч пользователей на сайте, каждый генерирует события для записи в бд.

Как понимаю вам просто побеседоват захотелось? Что мешает создать табличку нужной структуры и набросать элементарный скрипт который будет в нее инсертить и посмотреть сколько записей постгри скушает на вашем железе? 100 записей я сказал просто для примера, т.к. с такой нагрузкой любая современная СУБД справляется влегкую. И 100 записей в секунду, это гораздо больше тысячи юзеров в онлайне, если это не игрушка.

Orin,

Не занимайтесь преждевременной оптимизацией. Это бич вообще всех кодеров на пути их вырастания в программистов. ИМХО - это просто этап взросления )).

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

Например... В дефолтном режиме у Пг включен fsync. и у вас будет столько инсертов, сколько IOPS'ов у вас система хранения. Однако, если вы разоритесь на ИБП для сервера или, хотя-бы, на батарейку для Рейда, то можно fsync выключить и тогда скорость возрастет в разы.

То что вы говорили про WAL и UNLOGGED - вы это выкиньте из головы. unlogged при сбое вытирает все данные из таблицы. Это сделано специально, чтобы программисты понимали что unlogged нужен только для узкого класса задач.

Короче... Не выдумывайте себе проблем. Сначала сделайте и раскрутите сайт, чтобы у него было 100 инсертов в секунду.

Нет, если он у вас уже есть, тогда другой вопрос...

BusInt
И 100 записей в секунду, это гораздо больше тысячи юзеров в онлайне, если это не игрушка.

Кстати да... У нас в Онлайне около 20К пользователей постоянно(на инастанс). DAU около миллиона и сзади стоит одна Пг. И ей тепло и уютно. Большую нагрузку мы не генерим на нее.

Warstone
Например... В дефолтном режиме у Пг включен fsync. и у вас будет столько инсертов, сколько IOPS'ов у вас система хранения. Однако, если вы разоритесь на ИБП для сервера или, хотя-бы, на батарейку для Рейда, то можно fsync выключить и тогда скорость возрастет в разы.

отключение fsync это имхо из разряда вредных советов. как ИБП и батарейка для рейда в этом случае спасут от последствий? да и в случае рейда с батарейкой и включенным кэшом на запись отключать fsync смысла как раз немного.

где-то были тесты (не нашел ссылку) сравнения fsync=off и synchronous_commit = off и разницы в производительности особой не было. а выключение synchronous_commit и настройка wal_writer_delay куда более правильное решение при отсутствии нормальной дисковой системы.

Alexius

отключение fsync это имхо из разряда вредных советов. как ИБП и батарейка для рейда в этом случае спасут от последствий? да и в случае рейда с батарейкой и включенным кэшом на запись отключать fsync смысла как раз немного. где-то были тесты (не нашел ссылку) сравнения fsync=off и synchronous_commit = off и разницы в производительности особой не было. а выключение synchronous_commit и настройка wal_writer_delay куда более правильное решение при отсутствии нормальной дисковой системы.

Мне немного пофик на тесты. Я вижу что происходит на моем железе. На нем выключение этих 2х вещей дает ускорение где-то в 10 раз.

Там, на самом деле, вопрос в том, как fsync сделан в рейде. Большинство рейдов говорят что данные записаны, когда они в своем кеше сидят. И тогда - да. Меньшая-же часть более честна. Она говорит когда данные именно на шпинделях лежат. (А вообще это настраивается)