в предыдущей версии был сломан скрипт initdb, а сейчас start.

в предыдущей версии был сломан скрипт initdb, а сейчас start.

Pg_ctl-наше фсё

Почему-то не хочет копировать через COPY FROM из csv, пишет что отказано в доступе, хотя все родительские папки и сама csv с chmod +777, а вот если я csv кидаю в папку кластера то копирует нормально, я так понимаю нужно в настройках что-то поменять, может кто знает куда глянуть?

селинукс вроде не стоит у меня арч

Pg_ctl-наше фсё

ну тогда распространяли бы в tar.gz и не мучали бы попу

ну тогда распространяли бы в tar.gz и не мучали бы попу

Tar почти готов. Разбираются с gzip

Tar почти готов. Разбираются с gzip

Лучше rar, там сразу письмом можно послать

Всем добрый вечер. Кто-то пользовался https://www.citusdata.com ? Как оно для горизонтального масштабирования посгре? Написано вроде красиво, но хотелось бы реальные отзывы услышать

В какой-то момент было не очень работоспособно, сейчас может что изменилось

это примерно когда было?

Где-то месяц назад, до выхода 7.1

Как бы, полноценные транзакции в рамках кластера вот только вышли. До этого citus годился для "аналитики". Может быть, если не выходить за границу шарда в транзакции, оно тоже работало (они ведь пиарили "multi-tenant database")

Как бы, полноценные транзакции в рамках кластера вот только вышли. До этого citus годился для "аналитики". Может быть, если не выходить за границу шарда в транзакции, оно тоже работало (они ведь пиарили "multi-tenant database")

А это действительно работает? А то "полноценные" в их понимании могут ничего общего с реальностью не иметь (как это нередко бывает)...

А это действительно работает? А то "полноценные" в их понимании могут ничего общего с реальностью не иметь (как это нередко бывает)...

А кто ж его знает. Еще ни кто не пробовал. Ну и зависит от от значения "полноценные": мне кажется, serializable всё-таки нет. Но кто использует serializable?

А кто ж его знает. Еще ни кто не пробовал. Ну и зависит от от значения "полноценные": мне кажется, serializable всё-таки нет. Но кто использует serializable?

А кто не использует? Без него full ACID не бывает.

А если его нет, то это уже далеко не так интересно.

А кто не использует? Без него full ACID не бывает.

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

А если его нет, то это уже далеко не так интересно.

Дистрибьютед-сериалайзбл - это очень трудно.

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

Это нередко значит, что и СУБД им на самом деле-то и не была нужна...

Это нередко значит, что и СУБД им на самом деле-то и не была нужна...

+1

если цитус не подходит, то у кого-то есть реальный опыт масштабирования погре? или он совсем не фонтан для масштабирования?

если цитус не подходит, то у кого-то есть реальный опыт масштабирования погре? или он совсем не фонтан для масштабирования?

Хмм... а в чём проблема-то?

как раз в масштабировании и проблема, много слишком противоречивой инфы. судя по этой информации лучшее что придумали это шардинг таблиц и все.

Бд от игровых серверов требуется масштабировать.

с масштабированием у постгре (как и у всякой базы) всё по-разному: надо понимать какие у вас типы нагрузки и что именно вы пытаетесь масштабировать

как раз в масштабировании и проблема, много слишком противоречивой инфы. судя по этой информации лучшее что придумали это шардинг таблиц и все.

"Усиливаете" железо и всего делов. А шардинг работает только тогда, когда базу можно разделить на независимые куски, или же ACID Вам не критичен.

Бд от игровых серверов требуется масштабировать.

а какого рода игра?

онлайн игра, типа ворд оф варкрафт

по локациям пошардируйте

и да, в каком месте проседает?

онлайн игра, типа ворд оф варкрафт

С виду, ACID тут не важен, да и шардинг по locations или что-то вроде тоже подойдёт.

пока не проседает, беспокоимся о будущем. нужны варианты наперед, как можно масштабировать. Железом вертикально не очень удобно, рассматриваем как самый последний вариант. ACID важен.

какой онлайн планируется?

50000 человек расчетный

сколько они событий, пишущихся в базу, в секунду генерируют?

пока неизвестно, это расчетный онлайн

игра пока в збт

так в збт тоже, наверное, видно соотношение онлайна к пишущим транзакциям? можно же экстраполировать

пока не проседает, беспокоимся о будущем. нужны варианты наперед, как можно масштабировать. Железом вертикально не очень удобно, рассматриваем как самый последний вариант. ACID важен.

Зачем Вам ACID, в самом деле? Вы понимаете, что при этом у Вас (чтобы всё это не останавливалось при падении хоть чего-то) должна быть существенная избыточность по железу и администрированию (т.е. скорее всего, куда дороже обойдётся)? А уж решение с полноценным isolation (distributed serializaibility) вообще трудно найти (да и зачем оно Вам, опять же?).

Зачем Вам ACID, в самом деле? Вы понимаете, что при этом у Вас (чтобы всё это не останавливалось при падении хоть чего-то) должна быть существенная избыточность по железу и администрированию (т.е. скорее всего, куда дороже обойдётся)? А уж решение с полноценным isolation (distributed serializaibility) вообще трудно найти (да и зачем оно Вам, опять же?).

игрок получил эпический предмет с шансом выпадения 0,001%, из-за сбоя предмет игрок увидит и поднимет, но из-за сбоя предмет не попадет в бд. помоему после этого начнется холивар) я уж не говорю, если донат спишется с карты, но на счет в игре не попадет.

так в збт тоже, наверное, видно соотношение онлайна к пишущим транзакциям? можно же экстраполировать

данных пока очень мало, и они не особо укладываются в какую то красивую статистику

игрок получил эпический предмет с шансом выпадения 0,001%, из-за сбоя предмет игрок увидит и поднимет, но из-за сбоя предмет не попадет в бд. помоему после этого начнется холивар) я уж не говорю, если донат спишется с карты, но на счет в игре не попадет.

в среднестсатистической игре просто ляжет всё и на очевидном сбое все пять минут обойдутся без ничего

или полчаса

мы в древние времена на mangos делали просто отдельный текстовый лог для доната и эпиков

игрок получил эпический предмет с шансом выпадения 0,001%, из-за сбоя предмет игрок увидит и поднимет, но из-за сбоя предмет не попадет в бд. помоему после этого начнется холивар) я уж не говорю, если донат спишется с карты, но на счет в игре не попадет.

донат спишется с карты, попадёт в игру, потом пользователь зароллбечит транзакцию в банке

при этом мангос хранил дельту, насколько я помню, и периодически скидывал её на диск (читай в бд)

игрок получил эпический предмет с шансом выпадения 0,001%, из-за сбоя предмет игрок увидит и поднимет, но из-за сбоя предмет не попадет в бд. помоему после этого начнется холивар) я уж не говорю, если донат спишется с карты, но на счет в игре не попадет.

Ну и что? ;) Потерпят —- пускай админы разбираются. Игроку выдадут нарисованный предмет, донат исправят вручную... Я Вам больше скажу, так часто случается и в учёте настоящих предметов / денег (но тут уже чаще из-за некомпетентности или ошибок программистов).

вообще при расчетном онлайне 50к на ЗБТ должно быть хотя бы 3-5к онлайна на реалм; при нагрузке в 10% циферки уже должны биться Если 3-5к тестового онлайна нет - цифра про 50к выглядит странно... и для 50к онлайна нужно достаточно хитро вертеться по архитектуре и шардить как соединения, так и сами данные

вариант "купить толстую железку и молиться" (в моём понимании) не должен работать, там транзакций на запись несколько десятков тысяч в секунду

опять же по опыту mangos (который откровенно неаккуратно работал с данными)

вариант "купить толстую железку и молиться" (в моём понимании) не должен работать, там транзакций на запись несколько десятков тысяч в секунду

Зависит от получающегося "потока" данных, разве нет? Современные железки можно вертикально масшатбировать очень существенно.

всё верно я привёл усредненное на онлайнера для mangos (там около десяти апдейтов в секунду назревало; потом стало собираться в пачки и отдельным потоком заливаться в ХХ минут в базу) 50к онлайна ~ 500k write ops/sec отмасштабирвать 500к хороших write на толстую таблицу - никаких вычислительных ядер не хватит

а соединения зачем шардить? что имеется в виду? юзеры же напрямую в бд не пишут

я имел ввиду только шардинг данных, не соединений (шардинг соединений? шта? есть что про это почитать? о-О)

кажется понял. у нас апдейты идут либо от боевых серверов с арен, либо с кеширующих лобби серверов

вообще при расчетном онлайне 50к на ЗБТ должно быть хотя бы 3-5к онлайна на реалм; при нагрузке в 10% циферки уже должны биться Если 3-5к тестового онлайна нет - цифра про 50к выглядит странно... и для 50к онлайна нужно достаточно хитро вертеться по архитектуре и шардить как соединения, так и сами данные

а тут - про шардинг соединений!

нет, 50к онлайн пользователей -> 500к write transactions в сколько соединений это записать - вопрос к DBA и тому как это сервер реализует

for reference, в world of tanks сервер с аккаунтами примерно один

там кошерный read который отлично масштабируется же?

Добрый вечер ребят. Подскажите пожалуйста по stolon, вычитал в документации, что он может только с мастера реплику снимать, никакой каскадной репликации. Сильно ли это плохо при большой плотности записи? Как реализовать дополнительно чтение только реплики?

for reference, в world of tanks сервер с аккаунтами примерно один

откуда инфа?

нет, 50к онлайн пользователей -> 500к write transactions в сколько соединений это записать - вопрос к DBA и тому как это сервер реализует

сервер вообще может в памяти всё держать, писать надо только то, что меняет экономику

Это понятно. Я к тому что молиться на толстую железку не поможет.

WoT рассказывал про свою архитектуру, не вспомню навскидку ссылку Но там захватывающее чтиво

ну да, ждали 40000, пришёл миллион :)

ну да, ждали 40000, пришёл миллион :)

в геймдеве сколько придет непредсказуемо)

в основном не приходит, если что

Очень спорное утверждение

Что непредсказуемо

Но чаще всего не взлетает, да

еще чаще бюджет проедают и даже не запускают)

энивей, к 50к онлайна размер отдела суппорта, чинящий баги по ходу, легко справится с проблемами не-acid-ности транзакций в базе

потому что внезапно обнаружить, что где-то в апи пропущена валидация и можно перевести кому-то отрицательную сумму внутренних денег и вот уже месяц это эксплуатирует, более вероятно, чем свалить мастер в тот момент, когда кто-то получил эпик шмотку

Чувствую хороший опыт в геймдеве :)

потому что внезапно обнаружить, что где-то в апи пропущена валидация и можно перевести кому-то отрицательную сумму внутренних денег и вот уже месяц это эксплуатирует, более вероятно, чем свалить мастер в тот момент, когда кто-то получил эпик шмотку

Нечто из этой оперы было у Diablo 3 с аукционом: из-за переполнения переменной игроки неплохо нагрелись золотом ?

нет, 50к онлайн пользователей -> 500к write transactions в сколько соединений это записать - вопрос к DBA и тому как это сервер реализует

ознакомился с опытом wot, по их статистике на 800к юзеров в пике, у них 40к селектов, 1 к инсертов и 1к апдейтов

У них батл может умереть ну и ой :)

В этом соль

В этом соль

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

в бою вообще бд не используется

Неверно. Большая часть скоростных данных генерируется при высокой активности. Если их можно потерять - то и отлично, можно ничего не сохранять

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

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

если бой недоигран по причине падения сервера, то лучше бы и не списать их со счёта игрока

Это зависит от игровой механики и требований

как раз в масштабировании и проблема, много слишком противоречивой инфы. судя по этой информации лучшее что придумали это шардинг таблиц и все.

Не читай надписи на заборе, не слушай идиотов...

Привет!

Помогите со схемой бд для чата)

Пока в голове вот такие 2 схемы. Логика такая: последнее прочитанное сообщение может быть только одно у одного юзера в одном чате

остальное, думаю, и так понятно

2 вариант грозит большим кол-вом записи при присоединении пользователя к чату и при добавлении нового сообщения в чат, но легче делать выборки

50000 человек расчетный

Это одновременно играющих в одну игру друг с другом или одновременно играющих в 1000 игр поотдельности?

1 вариант - меньше вставок, но сложнее выборка