Или это сильнее нагружает БД?

в базе, в бекенде очень часто потом время начинает разъезжаться

а расскажите, чем порассматривать многомерный \crosstab?

Привет, сообщество. А как-то можно при INSERT ON CONFLICT UPDATE смержить два jsonb с помощью json_object? Как мне использовать текущее значение колонки?

https://www.postgresql.org/docs/9.6/static/sql-insert.html искать EXCLUDED

UPDATE SET json_col = json_col || EXCLUDED.json_col

UPDATE SET json_col = json_col || EXCLUDED.json_col

ERROR: column reference "json_col" is ambiguous

ERROR: column reference "json_col" is ambiguous

всё ок, сработало, над добавить название таблицы=)

привет!

Задача: будет большая субд, около 20-50TB, требования: 1) целостность данных, т.е. все что записалось надо хранить как зеницу ока 2) отказоустойчивость

и шо?)

синхронный мультимастер? синхронный мастерслейв?

и шо?)

как сделать чтобы было хорошо:)

nosql

nosql с целостностью беда

как сделать чтобы было хорошо:)

наймите DBA

Тут вроде были dba как раз

?

Задача: будет большая субд, около 20-50TB, требования: 1) целостность данных, т.е. все что записалось надо хранить как зеницу ока 2) отказоустойчивость

cassandra?

cassandra?

ну, как вариант в принципе

а. запись 95%, 5% чтение

ну и старые записи в будущем куда-нибудь в архив

ну, как вариант в принципе

Но подумайте о профиле запросов, если вы не вписываетесь в паттерн "запросы только по основным ключам" Cassandra вам не подходит. Но с вашим профилем нагрузки она может дать необходимую сохранность данных и простоту настройки кластера

Но подумайте о профиле запросов, если вы не вписываетесь в паттерн "запросы только по основным ключам" Cassandra вам не подходит. Но с вашим профилем нагрузки она может дать необходимую сохранность данных и простоту настройки кластера

вероятно что профиль запросов как раз ограничивается K-V

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

Задача: будет большая субд, около 20-50TB, требования: 1) целостность данных, т.е. все что записалось надо хранить как зеницу ока 2) отказоустойчивость

mssql - 500 Тб размер

mssql - 500 Тб размер

максимальный?

да

https://msdn.microsoft.com/en-us/library/ms143432.aspx Может неправильно прочитал...

Если так, не пинайте

Подозреваю что оракл тоже должен большие базы держать

Задача: будет большая субд, около 20-50TB, требования: 1) целостность данных, т.е. все что записалось надо хранить как зеницу ока 2) отказоустойчивость

а че внутри храниться-то будет?

Они, конечно, коммерческие, но такие объемы данных уже не стартап :)

а че внутри храниться-то будет?

какие-то мифические "пакеты" в несколько кб

а то может OLAP там, все такое greenplum, vertica, clickhouse, хуемое

а, тогда не по адресу

постгре с перконой можно не смотреть?

32Тб

перкона мультимастер, например

это постгре?

да

если таблицы разбить - можно и бещлимитно :)

https://www.postgresql.org/about/

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

В postgre лимит на таблицу есть. Может ине будет таого объема. Подумайте. Тогда и postgres подойдет

Но железо всеравно придетсяпокупать

Стебелек бд подойдет

Но железо всеравно придетсяпокупать

ну это-то ясно

На амазоне имхо такое только пускать

Своё дорого брать будет столько железа

А что за данные?

Прям интересно стало

На амазоне имхо такое только пускать

надо в рф хранить :(

сервера то хоть свои ?

сервера то хоть свои ?

ага

А что за данные?

точно не знаю, какие-то "пакеты данных"

секционирование по времени и вперед.

говорят что план в год 30Tb ?

как-то впритык

разве что по полгода разбивать

+ как-то или каскадную репликацию, или синхронную multislave

если идти с PG и иметь горизонтальное масштабирование, то я бы на Citus еще глянул

Месяцами норм было б

Хоть до посинения фигачить

как вариант. а как насчет HA?

синхронный мультислейв?

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

не записать и сообзить об этом клиенту - допустимо

Ну слейв по дефолту надо. Дампить такие объемы наверное смысла не имеет.

а если помер мастер, вручную переключаться на слейв?

Угу

Ну слейв по дефолту надо. Дампить такие объемы наверное смысла не имеет.

Слейв не бекап ))

Ну два сервака сразу не умрет)

люди хотят Master-Slave x 3 DC

А поднять 50ТБ+ из бекапа

то еще удовольствие

максимальный даунтайм наверное с час

Этого более чем

чтобы переключится

Если целостность важна – то автоматика может неприятно удивить (я бы автофейловерам не доверял, наверняка кто-нибудь посоветует)

ок, зачем вы беретесь за то в чем вообще не разбираетесь, если им (заказчикам) важна сохранность данных, то какого, извините, черта вы туда лезете ?

Ещё раз отпишусь - слейв не замена бекапа. Лишь отчасти если есть задержка большая между мастером и слейвом на пару часов.

Это какой надо иметь поток записи, чтобы таймлаг был в часах.

ок, зачем вы беретесь за то в чем вообще не разбираетесь, если им (заказчикам) важна сохранность данных, то какого, извините, черта вы туда лезете ?

?

Это какой надо иметь поток записи, чтобы таймлаг был в часах.

видимо, имелось ввиду, ручками выставить задержку

Все равно непрерывный бекап скушает место и ресурсы.

видимо, имелось ввиду, ручками выставить задержку

Ага

ок, зачем вы беретесь за то в чем вообще не разбираетесь, если им (заказчикам) важна сохранность данных, то какого, извините, черта вы туда лезете ?

разобраться ж можно;)

разбираются обычно к третьей потере базы

разобраться ж можно;)

Может учиться начать не с 50 Тб баз?

Мастер+хот стендбай возможно будет не самым плохим вариантом, как мне кажется с таким объемом.

Из бекапа вы не поднимите этот объем за допустимый даунтайм

Может учиться начать не с 50 Тб баз?

ну так сначала MVP без ценных данных, тестирование всех кейсов