Да. Подобную автоматизацию можно вполне сделать на Питоне.
Только дьявол кроется в деталях. И я-бы спросил автора
- что делать с дубликатами имен файлов? Переписывать или предупреждать?
- что делать с файлами которым не нашлось ключа в таблице?
- почему автор пишет "рассортировать". Эта задача не является сортировкой. Просто для термина уже
существуют устойчивые определния и то что хочет автор - это скорее классификация.
У тебя очень перегретое ТЗ. Лучше из него убрать такие поэтические метафоры экстремально
или "чем быстрее, тем лучше". Потому что под них невозможно написать никаких SLA, AC.
Лучше нарисовать картинкой диаграмму из кубиков где слева течет информация
и описать роли и отвественности кубиков.
Разуместся главный кубик - это язык С++ и использование AsyncIO API. В Linux оно называется
multiplexing IO. Там кажется всего три функции select, poll, epoll.
В современных C++ фреймворках эти функции могут быть просто завернуты в какое-то громкий API.
Какой - я к сожалению не знаю т.к. давно уже не писал ничего на С++.
Да. Если будешь подписываться на какие-то SLA, то никогда не указывай максимумы минимумы и средние.
Пиши про 95 процентиль например. Типа 95 % всех сигналов будут обработаны за 1мс.
Araya, человек сам не может определиться. Это - нормальная ситуация. Я в 16 лет вообще не мог определиться
чего я хочу. Поэтому не надо прессовать этим вопросом.
Надо попробовать максимальное число вариантов вширь. А потом желание придет само.
Мне знакома ситуация с выгоранием. Чтоб не выгорать ты не должен быть сам постановщиком задания.
Кто-то должен тебе его ставить со стороны. И должен быть контроль. Должны быть встречи хотя-б раз
в 2-3 дня чтоб посмотреть прогресс. Самостоятельно - мало кто может себя мотивировать.
Попробуй поищи на бирже фриланса простые задачи. И попробуй зайди стажером в любые софтверные
компании. Даже за бесплатно. Получишь ценный опыт.
Sergey_fraerok, ну вот когда у вас был код в стабильном состоянии - вы должны были сделать git commit -m "Hurray, it works" && git push
Вот. В этом простом правиле - успех на 99% всей ентерпрайз разработки.
Даже мои коллеги предпочитают не решать проблемы а просто наблюдать
изменения и анализировать что привело к проблемам. И эта инженерия
реально работат. Берите diff изменений и приносите сюда для анализа.
Разумеется у вас должна появитсья до этого культура ведения коммитов.
Судя по описанию https://en.wikipedia.org/wiki/Trusted_Platform_Module TPM модуль не занимается
шифрованием файлов на файловой системе. Он вроде как предоставляет рандом-генераторы, RSA генераторы,
хранилище ключей и прочее.
Шифрованием файлов вроде как занимаются другие утилиты и это к ним вопрос.
Ваша задача выглядит как типичная задача на BigData.
Я не буду спорить по поводу сравнения zstd и прочее. На это может ответить только практика
и бенчмарки. Если вы будете читать из Ruby в 1 поток - то используйте zstd.
There are no limits to the number of objects you can store in your S3 bucket
Я не могу найти пруфы на оригинальном сайте. Но это в чем-то похоже на правду.
Про Microsoft Blob тоже можно найти нечто подобное.
Но я не очень понимаю твой перфекционизм. Никто сразу не строит масштабируемое приложение с нуля.
Его рост - это плавная эволюция. Я убежден что еще до того как ты выйдешь на границы лимитов
у тебя будет огромная куча других технических проблем и с объемом диска и с лимитом на число сетевых
сокетов. И вообще очень крупные системы - это не один физический хост. Это грид из множества
хостов объединенный в одну логическую сервисную среду.
My1Name, в облаках кроме файловых систем используются хранилища. Amazon S3, Microsoft Blob.
У них - свои утилиты для наблюдения за местом.
- s3
- az
Дай больше конкретики и тебе помогут точнее.
Только дьявол кроется в деталях. И я-бы спросил автора
- что делать с дубликатами имен файлов? Переписывать или предупреждать?
- что делать с файлами которым не нашлось ключа в таблице?
- почему автор пишет "рассортировать". Эта задача не является сортировкой. Просто для термина уже
существуют устойчивые определния и то что хочет автор - это скорее классификация.