В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

pgsql – PostgreSQL

4818 membersпожаловаться на группу
2020 July 14

V

Valery in pgsql – PostgreSQL
Plus
C:\Windows\system32>E:\pgsql\bin\pg_ctl.exe start -w -N "pgsql-10.9-5.1C-x64" -D
"E:\pgsql\data\"
waiting for server to start....< 2020-07-14 17:38:06.875 GMT >LOG:  could not bi
nd IPv6 address "::": Only one usage of each socket address (protocol/network ad
dress/port) is normally permitted.

< 2020-07-14 17:38:06.875 GMT >HINT:  Is another postmaster already running on p
ort 5432? If not, wait a few seconds and retry.
< 2020-07-14 17:38:06.894 GMT >LOG:  could not bind IPv4 address "0.0.0.0": Only
one usage of each socket address (protocol/network address/port) is normally pe
rmitted.

< 2020-07-14 17:38:06.894 GMT >HINT:  Is another postmaster already running on p
ort 5432? If not, wait a few seconds and retry.
< 2020-07-14 17:38:06.909 GMT >WARNING:  could not create listen socket for "*"
< 2020-07-14 17:38:06.913 GMT >FATAL:  could not create any TCP/IP sockets
< 2020-07-14 17:38:06.917 GMT >LOG:  database system is shut down
stopped waiting
pg_ctl: could not start server
Examine the log output.

C:\Windows\system32>
Netstat -nb
источник
21:28пожаловаться#1

P

Plus in pgsql – PostgreSQL
Valery
Netstat -nb
+1
источник
21:29пожаловаться#2

B

Bulat in pgsql – PostgreSQL
Добрый вечер, хочу как-то хранить статистику всяких событий на фронте в БД (клики, переходы и т.п.).
Думаю сделать столбцы event_type и event_date, адекватный ли это способ для хранения статистики, учитывая, что в день может быть порядка миллиона событий?
источник
21:38пожаловаться#3

D

Denisio in pgsql – PostgreSQL
може лучше в clickhouse?
источник
21:40пожаловаться#4

B

Bulat in pgsql – PostgreSQL
Может и лучше, но надо в постгресе
источник
21:40пожаловаться#5

D

Denisio in pgsql – PostgreSQL
ок
источник
21:41пожаловаться#6

ДЛ

Дмитрий Лукьянов... in pgsql – PostgreSQL
Bulat
Может и лучше, но надо в постгресе
Плохое решение. Бери тогда хотя бы timescaledb
источник
21:49пожаловаться#7

DP

Darafei Praliaskousk... in pgsql – PostgreSQL
11 в секунду постгрес потянет легко
источник
21:50пожаловаться#8

ВК

Виталий Кухарик... in pgsql – PostgreSQL
Bulat
Добрый вечер, хочу как-то хранить статистику всяких событий на фронте в БД (клики, переходы и т.п.).
Думаю сделать столбцы event_type и event_date, адекватный ли это способ для хранения статистики, учитывая, что в день может быть порядка миллиона событий?
У меня примерно такой же сценарий. Таблица events :)
На сегодня пишем 9 млн событий в час. В скором будущем будет больше.
Под копотом PostgreSQL с расширением timescaledb.
источник
21:50пожаловаться#9

B

Bulat in pgsql – PostgreSQL
Окей, тут вопрос не в перформансе, а скорее в том, как правильнее хранить эти данные в таблице, в каких полях. Миллиона в день у меня пока нет, да и вряд ли будет :)
источник
21:51пожаловаться#10

B

Bulat in pgsql – PostgreSQL
Я хотел узнать некие best practices для хранения подобного
источник
21:52пожаловаться#11

ДЛ

Дмитрий Лукьянов... in pgsql – PostgreSQL
Bulat
Я хотел узнать некие best practices для хранения подобного
Выше же написали. Для хранения time series данных лучше подходят колоночные БД. Кликхаус, расширение timescaledb для PG и прочие. Со строчными с определённого момента будет сложно производить хоть какие-то действия. А вам же аналитика нужна раз в бд пишете
источник
21:54пожаловаться#12

D

Denisio in pgsql – PostgreSQL
яндекс не просто так написал кликхаус, как раз для этих целей. И он очень хорошо справляется, 500к в секунду вставить - пыщ и оно там.
источник
21:57пожаловаться#13

ДЛ

Дмитрий Лукьянов... in pgsql – PostgreSQL
Виталий Кухарик
У меня примерно такой же сценарий. Таблица events :)
На сегодня пишем 9 млн событий в час. В скором будущем будет больше.
Под копотом PostgreSQL с расширением timescaledb.
А с историческими данными что-то делаете при этом или за все время храните?
источник
22:04пожаловаться#14

ДЛ

Дмитрий Лукьянов... in pgsql – PostgreSQL
Какой уже размер бд набежал?
источник
22:04пожаловаться#15

ВК

Виталий Кухарик... in pgsql – PostgreSQL
Denisio
яндекс не просто так написал кликхаус, как раз для этих целей. И он очень хорошо справляется, 500к в секунду вставить - пыщ и оно там.
Скорее для целей Онлайн аналитики.
Выше я прочёл только о требовании писать N событий. И никаких подробностей о аналитики.

Clickhouse нужен для других объёмов данных.
Также в компании может не быть специалиста по CH.

Десяток другой млн строк в час прекрасно справляется и pg.
В пром примерно пол года, реальный отзыв эксплуатации ещё впереди.
источник
22:05пожаловаться#16

ВК

Виталий Кухарик... in pgsql – PostgreSQL
Дмитрий Лукьянов
А с историческими данными что-то делаете при этом или за все время храните?
Сейчас retantion короткий 15 дней, только из за того что железо только на подходе и пока на ВМ.
источник
22:07пожаловаться#17

ВК

Виталий Кухарик... in pgsql – PostgreSQL
Дмитрий Лукьянов
Какой уже размер бд набежал?
Пока почти 2TB.
В тестах при включении сжатия получили в 22х раз уменьшение объёма.
В скором времени включу сжатие на боевых данных, там уже и посмотрим какой будет коэффициент сжатия.
источник
22:09пожаловаться#18

ВК

Виталий Кухарик... in pgsql – PostgreSQL
Дмитрий Лукьянов
Выше же написали. Для хранения time series данных лучше подходят колоночные БД. Кликхаус, расширение timescaledb для PG и прочие. Со строчными с определённого момента будет сложно производить хоть какие-то действия. А вам же аналитика нужна раз в бд пишете
Кстати и с timescaledb данные изначально в строковом виде. И только после включения компрессии, данные "перепаковываются" в колоночный вид. Там свой хитрый алгоритм, почитайте в блоге
источник
22:13пожаловаться#19

ДЛ

Дмитрий Лукьянов... in pgsql – PostgreSQL
Виталий Кухарик
Пока почти 2TB.
В тестах при включении сжатия получили в 22х раз уменьшение объёма.
В скором времени включу сжатие на боевых данных, там уже и посмотрим какой будет коэффициент сжатия.
А что с бэкапами там? Все штатными средствами PG ведь?
источник
22:13пожаловаться#20