Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / postgresql для частых инсертов / 11 сообщений из 11, страница 1 из 1
09.05.2015, 19:28
    #38955230
Orin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
postgresql для частых инсертов
Добрый день!

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

Там, на самом деле, вопрос в том, как fsync сделан в рейде. Большинство рейдов говорят что данные записаны, когда они в своем кеше сидят. И тогда - да. Меньшая-же часть более честна. Она говорит когда данные именно на шпинделях лежат. (А вообще это настраивается)
...
Рейтинг: 0 / 0
13.05.2015, 11:49
    #38957209
Maxim Boguk
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
postgresql для частых инсертов
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
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / postgresql для частых инсертов / 11 сообщений из 11, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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