Можно socials побить на partitions по 5 минут времени. Время микро-батча типа.
Вот. И обновлять статистику всех постов по всем соц-сетям за время этого батча.
Кумулятивно. Добавлять короче.
В статистике будет лаг. Но он будет регулируемый. Захотим - 1 минута будет.
Зато гарантировано константное время батча.
Щас уже никто так не делает. От joins отказались. Делают несколько разных систем. Одна - регистрирует клики. Другая хранит. Третья - сводит это в отчёты в реальном времени.
CityCat4, да. Клонов было до чорта. Я помню я поиграл в Doom Plutonia experiment. Ultimate. И фентези клоны Heretic, Hexen. Последний вообще кажется пройти было нереально. Это был не екшен а нудный квест по поиску скрытых кнопок.
Да. Обычно восставление - это тоже деструктивная операция. И чем больше восстанавают - тем менше вероятность до-восстановить оставшееся. Вполне разумная идея скопировать образы дисков куда-то и уже в новом месте искать убитое.
На успех очень сильно влияет сохранность дисков сразу после удаления. Нужно срочно их отмонтировать и не пытаться ничего на них делать без специалистов.
Я думаю что бедный несчастный автор будет заложником этого битого формата строки. И если говорить о техническом задании в большом понимании этого слова - то тут задания вобщем-то нету. Тут есть кусок навоза из которого хотят сделать конфету. При этом интуиция подсказывает что сортов навоза может быть очень много. И мы не напасёмся регулярок чтоб все из них декларировать.
Вот ты получил в качестве ответа vector. Что ты должен сделать первым делом? Ты должен ПРОВЕРИТЬ что там не ноль элементов. Не 1 элемент. А именно ДВА. Два мать ево. И эта проверка казалось бы пустяк является mandatory для дальнейшей логики. Ты вообще работая с сигнатурой функций должен всегда исходит из пессимистичного сценария. А что будет если функция не отработала как надо? Этот подход заложен почти во все системные вызовы.
Я тебе упростил контракт. Я заявил. Только ДВА, Два элемента и точка. Тебе не надо ничего проверять.
vitya_brodov, по поводу JDBC. Информация - по состоянию где-то на 2019 год. После этого я не тестил.
Мы обратили внимнание на переполнение памяти при процедурах массовой выгрузки из Postgres. Я анализировал через Eclipse/MA и заметил что по количеству штук лидируют jdbc.datarows входящие в namespace драйвера Postgres. Причем это были не наши бизнес-объекты а именно объекты самого драйвера. При том что внутри цикла мы наши объекты пере-используем. Тоесть не накапливаем.
Было 2 варианта фикса.
- читать пачками (хотя-б по 10000 строк) и закрывать курсор. Это форсировало удаление драйверных tuples, но замедляло execution на стороне БД потому что нам надо было фиксировать окно с сортировкой. Партишенинга не было. База была не наша и реструктурировать таблицу мы не могли.
- открывать курсор с опцией FORWARD и еще с какой-то второй. Не помню. В этом случае JDBC tuples не накапливались в памяти Java но сильно падала скорость выгрузки (2-3 раза). Возможно медленно шел FETCH.
Какое решение было применено я уж не помню. Для нас проект закончился с точки зрения активной разработки. Перевели в поддержку.
