powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / postgresql для частых инсертов
11 сообщений из 11, страница 1 из 1
postgresql для частых инсертов
    #38955230
Фотография Orin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Добрый день!

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

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

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

Спасибо :)
...
Рейтинг: 0 / 0
postgresql для частых инсертов
    #38955242
Фотография BusInt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В чем собственно проблема? Под такую задачу пойдет любая СУБД, даже текстовый файлик сгодится. Вопрос только в количестве этих вставок. Если в пике меньше сотни за секунду то и думать ни о чем не нужно.
...
Рейтинг: 0 / 0
postgresql для частых инсертов
    #38955302
Фотография Orin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BusIntВ чем собственно проблема? Под такую задачу пойдет любая СУБД, даже текстовый файлик сгодится. Вопрос только в количестве этих вставок. Если в пике меньше сотни за секунду то и думать ни о чем не нужно.

а если больше 100? Несколько тысяч пользователей на сайте, каждый генерирует события для записи в бд.
...
Рейтинг: 0 / 0
postgresql для частых инсертов
    #38955305
Фотография Orin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
думаю, может помочь:
- отключить wal синхронизацию,
- сделать одну плоскую unlogged таблицу, вставки делать только в нее
- из апликейшна(node) - для таких операций открыть отдельную сессию (отдельную от сессии, в которой происходит взаимодействие с базой инет-магаза).

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

Особенность - данные нужно записывать он-лайн, использоваться они будут позже, в качестве статистики, т.е. не онлайн.
...
Рейтинг: 0 / 0
postgresql для частых инсертов
    #38955311
Локшин Марк
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Orinа если больше 100? Несколько тысяч пользователей на сайте, каждый генерирует события для записи в бд.
Даже если они генерируют события раз в секунду, то на нормальной дисковой подсистеме все будет хорошо. Вопрос в том, будут ли они генерировать события раз в секунду...
...
Рейтинг: 0 / 0
postgresql для частых инсертов
    #38955312
Фотография BusInt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OrinBusIntВ чем собственно проблема? Под такую задачу пойдет любая СУБД, даже текстовый файлик сгодится. Вопрос только в количестве этих вставок. Если в пике меньше сотни за секунду то и думать ни о чем не нужно.

а если больше 100? Несколько тысяч пользователей на сайте, каждый генерирует события для записи в бд.
Как понимаю вам просто побеседоват захотелось? Что мешает создать табличку нужной структуры и набросать элементарный скрипт который будет в нее инсертить и посмотреть сколько записей постгри скушает на вашем железе? 100 записей я сказал просто для примера, т.к. с такой нагрузкой любая современная СУБД справляется влегкую. И 100 записей в секунду, это гораздо больше тысячи юзеров в онлайне, если это не игрушка.
...
Рейтинг: 0 / 0
postgresql для частых инсертов
    #38955584
Фотография Warstone
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Orin,

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

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

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

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

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

Нет, если он у вас уже есть, тогда другой вопрос...
...
Рейтинг: 0 / 0
postgresql для частых инсертов
    #38955585
Фотография Warstone
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BusIntИ 100 записей в секунду, это гораздо больше тысячи юзеров в онлайне, если это не игрушка.Кстати да... У нас в Онлайне около 20К пользователей постоянно(на инастанс). DAU около миллиона и сзади стоит одна Пг. И ей тепло и уютно. Большую нагрузку мы не генерим на нее.
...
Рейтинг: 0 / 0
postgresql для частых инсертов
    #38955603
Alexius
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
WarstoneНапример... В дефолтном режиме у Пг включен fsync. и у вас будет столько инсертов, сколько IOPS'ов у вас система хранения. Однако, если вы разоритесь на ИБП для сервера или, хотя-бы, на батарейку для Рейда, то можно fsync выключить и тогда скорость возрастет в разы.


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

где-то были тесты (не нашел ссылку) сравнения fsync=off и synchronous_commit = off и разницы в производительности особой не было. а выключение synchronous_commit и настройка wal_writer_delay куда более правильное решение при отсутствии нормальной дисковой системы.
...
Рейтинг: 0 / 0
postgresql для частых инсертов
    #38957042
Фотография Warstone
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexiusотключение fsync это имхо из разряда вредных советов. как ИБП и батарейка для рейда в этом случае спасут от последствий? да и в случае рейда с батарейкой и включенным кэшом на запись отключать fsync смысла как раз немного.

где-то были тесты (не нашел ссылку) сравнения fsync=off и synchronous_commit = off и разницы в производительности особой не было. а выключение synchronous_commit и настройка wal_writer_delay куда более правильное решение при отсутствии нормальной дисковой системы.Мне немного пофик на тесты. Я вижу что происходит на моем железе. На нем выключение этих 2х вещей дает ускорение где-то в 10 раз.

Там, на самом деле, вопрос в том, как fsync сделан в рейде. Большинство рейдов говорят что данные записаны, когда они в своем кеше сидят. И тогда - да. Меньшая-же часть более честна. Она говорит когда данные именно на шпинделях лежат. (А вообще это настраивается)
...
Рейтинг: 0 / 0
postgresql для частых инсертов
    #38957209
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
WarstoneAlexiusотключение fsync это имхо из разряда вредных советов. как ИБП и батарейка для рейда в этом случае спасут от последствий? да и в случае рейда с батарейкой и включенным кэшом на запись отключать fsync смысла как раз немного.

где-то были тесты (не нашел ссылку) сравнения fsync=off и synchronous_commit = off и разницы в производительности особой не было. а выключение synchronous_commit и настройка wal_writer_delay куда более правильное решение при отсутствии нормальной дисковой системы.Мне немного пофик на тесты. Я вижу что происходит на моем железе. На нем выключение этих 2х вещей дает ускорение где-то в 10 раз.

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

Не надо fsync Отключать... я пока не видел ситуации где бы отключение fsync при выключенном syncronous_commit бы давало заметный прирост. Если у вас есть тест который показывает разницу - покажите очень интересно посмотреть будет.

Про рейды - так они правильно себя ведут... задача рейда принять sync в свой кеш в памяти и максимально быстро ответить что да все готово... и батарейка на рейдах как раз чтобы этот кеш не потерять в случае сбоя питания. И как раз правильное поведение в 99% случаев чтобы это то которые вы называете "нечестным".

--
Maxim Boguk
www.postgresql-consulting.ru
...
Рейтинг: 0 / 0
11 сообщений из 11, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / postgresql для частых инсертов
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]