No/low code вполне себе годиться для MVP, но надо понимать что после MVP это выкидывается в помойку или переписывается потому что заказчик такое начинает генерить в бэклог ???. Иногда важно очень быстро релизнуть MVP что бы показать/доказать бизнес ценность продукта.
Собрал себе хостинг, медиа-сервер, файлопомойку на железе с алика, проц б/у xeon 24 потока (12 ядер) , 24 Гб оперативки, жёсткие брал насовские, цена пример 30-35 тыщ. деревянных. Тарахтит год без остановки и БЕЗ ups, raid программный 1, аппаратный дорого(( ОС ubuntu server 22. В принципе по соотношению цена-качество по моему оптимально
с помощью конфиг файлов это не на лету это минимум рестарт пода/контейнера/сервиса, мерить benchmark как раз имеет смысл до того как придет баг с прода что все медленно. если уж и подрубать на лету то это MBean(JMX)
Сделал подобное на китайском железе, заказал основу на xeon 2666v3 16gb ram, периферию типа БП и хдд брал в днс, тарахтит год без остановки. И свет отрубался и в грозу перепады были, цена вопроса 10 000 р. (Проц серверный, оперативка, мать). По функционалу докер демон, плекс как стриминг медиа, торрент для скачивания, ну и небольшое апп для поиска фильмов-торентов с автоматической закачкой.
Использовать Oracle как персистентное хранилище правил и их истории - ну, такое себе (вроде как платное и тяжелое, есть куча бесплатных легких решений для этого).
требование заказчика
Использовать Kafka для транспорта файлов - ну, такое себе (вроде как есть ограничения по размеру и более простые паттерны).
кафка для передачи событий а не файлов
Ну и вообще непонятно, куда надо эти файлы транспортировать, зачем, какие требования? Почему просто не положить в S3 и не транспортировать линки? Речь вроде как идет о внутренней инфраструктуре.
переместить файл с SMB на FTP, выполнить кучу проверок до и после перемещения, положить в архив если надо и т.д. Защитится от того что кто то файл дописывает на источнике, восстановить работу если приемник отвалился. это если кратко о требованиях
Ну большое кол-во как то абстрактно, если это в пределах миллиарда то у нас столько не будет, min io как временно хранилище, т.е. есть ttl у объекта, второй кейс это архив, что тоже временное хранилище с последующим перемещением на ленточные накопители.
Да, ладно, ребята. Вот если бы 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 строк это конечно мощно. Очень хотел бы глянуть )))
в кеш кладется информация по операциям, не бинарники которые летают. в моменте кеш около 1Гб (это если передавать 150 000 файлов), т.е. оперативки надо минимум 2 Гб (1 Гб системе, 1 Гб редису). И это можно настраивать из сервиса выставляя TTL для ключей.
No/low code вполне себе годиться для MVP, но надо понимать что после MVP это выкидывается в помойку или переписывается потому что заказчик такое начинает генерить в бэклог ???. Иногда важно очень быстро релизнуть MVP что бы показать/доказать бизнес ценность продукта.
CMR 3.5. SMR не годится под NAS
Seagate IronWolf 3Tb -- 2 шт
SSD Kingston 240Gb -- 1 шт
Собрал себе хостинг, медиа-сервер, файлопомойку на железе с алика, проц б/у xeon 24 потока (12 ядер) , 24 Гб оперативки, жёсткие брал насовские, цена пример 30-35 тыщ. деревянных. Тарахтит год без остановки и БЕЗ ups, raid программный 1, аппаратный дорого(( ОС ubuntu server 22. В принципе по соотношению цена-качество по моему оптимально
с помощью конфиг файлов это не на лету это минимум рестарт пода/контейнера/сервиса, мерить benchmark как раз имеет смысл до того как придет баг с прода что все медленно. если уж и подрубать на лету то это MBean(JMX)
Так есть же micro benchmarks https://www.baeldung.com/java-microbenchmark-harness для спринга. В чем смысл своего велосипеда?
Сделал подобное на китайском железе, заказал основу на xeon 2666v3 16gb ram, периферию типа БП и хдд брал в днс, тарахтит год без остановки. И свет отрубался и в грозу перепады были, цена вопроса 10 000 р. (Проц серверный, оперативка, мать). По функционалу докер демон, плекс как стриминг медиа, торрент для скачивания, ну и небольшое апп для поиска фильмов-торентов с автоматической закачкой.
требование заказчика
кафка для передачи событий а не файлов
переместить файл с SMB на FTP, выполнить кучу проверок до и после перемещения, положить в архив если надо и т.д. Защитится от того что кто то файл дописывает на источнике, восстановить работу если приемник отвалился. это если кратко о требованиях
у нас и такого не будет в моменте. TTL не большой. но спасибо учтем в будущем
Ну большое кол-во как то абстрактно, если это в пределах миллиарда то у нас столько не будет, min io как временно хранилище, т.е. есть ttl у объекта, второй кейс это архив, что тоже временное хранилище с последующим перемещением на ленточные накопители.
оперировать надо не кол-вом файлов, а объемом. В среднем получается 1.5 Тб. Нет задачи передать 1.5 Тб за минуту, задача передать все до последнего байта.
Канал гигабитный. Нет определенной частоты прихода файлов, может 10 прилететь, а может 100 000 прилететь. Что имеется ввиду под скоростью хранилища файлов?
Среди готовых решений рассматривали Spring Data Flow, но от всего функционала подходил лишь транспортный уровень, так как у нас есть нетривиальная бизнес логика, то приняли решение разрабатывать своё решение на тех же компонентах что и Spring Data Flow.
Скрипт из 20 строк это конечно мощно. Очень хотел бы глянуть )))
в кеш кладется информация по операциям, не бинарники которые летают. в моменте кеш около 1Гб (это если передавать 150 000 файлов), т.е. оперативки надо минимум 2 Гб (1 Гб системе, 1 Гб редису). И это можно настраивать из сервиса выставляя TTL для ключей.