Comments 13
что-то вы путаетесь: то 150 тысяч, то 150 миллионов... это немного разные поток.
Я правильно понял, что все документы кешируются в Redis? А сколько у вас оперативной памяти выделено для кеша?
150 000 файлов в сутки - и это скорость?!
Да, ладно, ребята. Вот если бы 150 000 файлов в минуту, то, да, ещё можно было бы почитать.
Но главное: вообще нет никаких данных о скорости каналов передачи/приёма информации, частоте прихода файлов, скорости хранилища файлов, итд.
Хотя бы какие-то выкладки должны быть, чтобы видеть, что ваше решение с Redis, Kafka, MinIO, Archive, Agent, Detector, Task-manager имеет преимущество над скриптом в 20 строк, кладущим входящие файлы в папку файловой системы и отдающим их, например, через curl.
Да, ладно, ребята. Вот если бы 150 000 файлов в минуту, то, да, ещё можно было бы почитать.
оперировать надо не кол-вом файлов, а объемом. В среднем получается 1.5 Тб. Нет задачи передать 1.5 Тб за минуту, задача передать все до последнего байта.
Но главное: вообще нет никаких данных о скорости каналов передачи/приёма информации, частоте прихода файлов, скорости хранилища файлов, итд.
Канал гигабитный. Нет определенной частоты прихода файлов, может 10 прилететь, а может 100 000 прилететь. Что имеется ввиду под скоростью хранилища файлов?
Хотя бы какие-то выкладки должны быть, чтобы видеть, что ваше решение с Redis, Kafka, MinIO, Archive, Agent, Detector, Task-manager имеет преимущество над скриптом в 20 строк, кладущим входящие файлы в папку файловой системы и отдающим их, например, через curl.
Среди готовых решений рассматривали Spring Data Flow, но от всего функционала подходил лишь транспортный уровень, так как у нас есть нетривиальная бизнес логика, то приняли решение разрабатывать своё решение на тех же компонентах что и Spring Data Flow.
Скрипт из 20 строк это конечно мощно. Очень хотел бы глянуть )))
В статье https://habr.com/ru/company/veeam/blog/517392/ в комментариях описали проблемы minio при работе с большим количеством файлов. Вы как-то дополнительно тюнили MinIO?
И это все ради 18 мб/сек?
Использовать Oracle как персистентное хранилище правил и их истории - ну, такое себе (вроде как платное и тяжелое, есть куча бесплатных легких решений для этого).
Использовать Kafka для транспорта файлов - ну, такое себе (вроде как есть ограничения по размеру и более простые паттерны).
Ну и вообще непонятно, куда надо эти файлы транспортировать, зачем, какие требования? Почему просто не положить в S3 и не транспортировать линки? Речь вроде как идет о внутренней инфраструктуре.
Использовать Oracle как персистентное хранилище правил и их истории - ну, такое себе (вроде как платное и тяжелое, есть куча бесплатных легких решений для этого).
требование заказчика
Использовать Kafka для транспорта файлов - ну, такое себе (вроде как есть ограничения по размеру и более простые паттерны).
кафка для передачи событий а не файлов
Ну и вообще непонятно, куда надо эти файлы транспортировать, зачем, какие требования? Почему просто не положить в S3 и не транспортировать линки? Речь вроде как идет о внутренней инфраструктуре.
переместить файл с SMB на FTP, выполнить кучу проверок до и после перемещения, положить в архив если надо и т.д. Защитится от того что кто то файл дописывает на источнике, восстановить работу если приемник отвалился. это если кратко о требованиях
Движение по магистрали без аварий. Или как передавать 1,5 терабайта в сутки и ни одного не потерять?