Tishka17, вопрос, как я понимаю, риторический.

Расскажи им про очереди и воркеры, например.

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

Tishka17, в постгресе есть система pubsub

я так делаю там, где поебать

Для газпрома - да. Только период синхронизации не 15 минут, а час... В итоге имеем задержку в 2 часа

ору

Вангую, что не в БД, а в тормозную хуйню. Это нормально. Можете попробовать pgaas, если влезете по размеру

Зато надёжно. А данных много? Ну и если ваша база какое-то древнее медленное легаси, то это может быть и нормой.

Tishka17, прочитал как "сервис А кладёт бд"

Нет

Есть же mq

Фублядь!

а что не фублядь?
// но вообще согласен, пока в очередь не пишешь - она не переполнится.

Tishka17, у нас примерно так:

Сервис А кладёт в MQ-A
MQ-A кладёт в приклад который пишет в БД ( там ещё маршрутизация осуществляется, кому что читать, но это опущу)
приклад вокруг БД кладёт в MQ-Б
Сервис Б читает из MQ-Б

Все занимает меньше секунды.

кстати, у нас тут почему-то тимлид захотел, чтоб у нас вместо специализированного адаптера для импорта с инкапсулированным кроном, обменные файлики внешних систем проходили через общий сервис-шлюз интеграций в котором все расписания и логики по общению со сторонней системой, а в адаптере была только логика импорта/экспорта.
Из этого возникла задача прокидывать между сервисами в качестве таска на импорт где-то гигабайт за раз. это как кузявее делать? файликом на люстре? smb-сервак держать для шаринга, s3? или на похер пропихивать через http телом?

Имхо, кузявее всего будет DHT

в смысле торрент-клиент-сервер демон на обоих машинах поднять? а с секьюрити как быть?

Не только на обоих, но и на нескольких резервных, чтобы отказоустойчивость была. А секурность обеспечивать iptables, которые не позволят с внешних сетей к этой таблице подключиться

понял, спасибо за идею, подумаю.

а сколько данных за раз просасываются? какие требования к транзакционности одной такой посылки? как решаются дубликаты/потеряшки (в зависимости от 0-1 или 1+)?

igelko, файлики, 2019, у меня ажно мурашки по спине бегают.

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

а сколько данных за раз просасываются?

Вопрос не очень понятен.

какие требования к транзакционности одной такой посылки?

Зависит от имплементации воркера и продюсера задач.

как решаются дубликаты/потеряшки (в зависимости от 0-1 или 1+)?

Дубликаты проще всего фиксить на воркере. Потеряшек быть не должно, если воркер релизит джоб после того как реально сохранил его в БД, а не просто от души.

smb-сервак держать для шаринга

NFS. Или там прямо на винду какую-то старую надо?

Хотя если подумать, гигабайт - это не так много. Можно по-разному просунуть. Тут главный вопрос в том насколько часто и другие побочные моменты.

Думать надо от задачи. Озвучивать тут все детали - явно некорректно.

Дельты можно и локально считать. Написать имплементацию UnitOfWork и всё такое.

Ещё вариантом бедного человека может быть передача ответственности на БД за принятие решения о записи и формировать такие запросы, чтобы при изменении данных UPDATE был, а без них - нет. Это тоже можно сделать двумя вариантами:

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

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

Вопрос не очень понятен.
Зависит от имплементации воркера и продюсера задач.

вопрос был не к тебе, а к fgntfg мне интересно, как у них.

Потеряшки могут возникать, если у тебя очередь обеспечивает семантику at least once.
(ну допустим у тебя очередь - это шардированный нереплицированный неперсистентный кластер rabbitmq из 2х нод и одна упала - будут потеряшки).

ну вот смотри. в сторонней системе люди как-то работают, изменяя данные. этот выхлоп может попадать к нам или полными дампами состояния под гигабайт каждый, или дельтами (по сути лог изменений - add,modify,delete).
Желаемая задержка появления и применения данных в нашей системе - 10 минут.
Стороннюю систему разрабатываем и пишем не мы, так что у нас нет 100% уверенности, что дельты будут формироваться корректно или какая-то из дельт может быть потеряна (мало ли что - место, допустим, кончилось).
Каждый раз отдавать полный стейт - порнография, забивание жёстких дисков и лишнее нагревание воздуха.|
Потому раз в сутки они нам шлют полный дамп, чтобы уж точно не обосраться.

В свою очередь или базу мы их не имеем права пустить, и вместо веб-сервисов используем файлики через шару, потому что это относительно просто отлаживать и просматривать ad-hoc.

ок, тоже посмотрю.

Одно сообщение до, кажется 8мб, не это все настройками решалось. Сообщений сотни тысяч в час. Я не считал.
У каждого сообщения уникальный ID. Дубликаты решаются на стороне приемника, потеряшки - смотря где потеря. Обычно это переотправка из источника.

В yt

Ну а я что сказал?

но там же вроде есть "быстрые" таблицы?

То что у них время доступа меньше минуты не делает их «быстрыми»

я про динамические таблицы? они же вроде не так фатально тормозят?

Но использовать их для менеджмента задач — это пиздец. Нужно обработать данные — залей их на сторадж и через зукипер передай ссылку на данные, а не клади в медленную стстему чтобы обработчик их оттуда медленно вычитывал

Спасибо. А то у меня за время работы тут сложилось ощущение, что это норма