mayton2019

Автор пытается делать стеганографию. Тоесть в картинке скрывать информацию. Здесь выбор PNG полезен тем что инфа лежит плотно и в случае "гладкого" характера информации сжимается. Наподобие архиватора.

SVG - не подходит т.к. векторный и расточительный.
JPG - тоже не подходит т.к. повреждает информацию. Ее потом нельзя будет извлечь из файла без потерь.

По поводу дополнения файла до размера кратного длине строки (padding). Там не 00 не FF не подходит. Так как в оригинальном файле тоже могут быть эти константы и алгоритм даст сбой. Надо почитать как делается в криптографии. Там есть специальный workaround. Если его не реализовать правильно то при обратном декодировани картинки в файл мы можем получить ложное удлиннение файла на размер хвостика последней строки пикселов. Насколько это большой дэмедж для исходного файла - ХЗ. Но лучше конечно его не нелать чтоб обратное декодирование было надёжным с точки зрения длины файла.

Самым быстрым являются хешмапы в памяти приложения. Но вопрос на самом деле более сложный. Как только нам нужно делать join 2-3 таблиц тогда - работает сложная квантовая механика оптимизатора и вариантов быстроты становится целая матрица.

rar имеет консольный тул. Его можно вызвать как то так
$ rar -l <namefile>
И проанализировать листинг. Там скорее всего напротив каждого шифрованного файла будет какая-то пометка или символ.

Автору - неприлично спрашивать такой вопрос совсем не подготовившись.

Вызывать ее надо по другому. Создать массив и указать его как аргумент в quicksort(..)

Если речь идёт о русском языке - то читать про стемминг и лемматизацию.

Зачем вам сортировать все 50 миллионов? Задача топа - чтобы взять например top 10.
Сделайте себе временную табличку и по триггеру сливайте в нее по правилу паретто или больше 95%
где баланс больше X. И там будет не 50 миллионов а 100 тыс.

И эта мелкая табличка легко отсортируется и опубликуется.

Зависит от ценности этой информации. Если эту схему рассматривать как историю - то ничего удалять не надо. Просто перепишите ваши отчоты чтоб они делали GROUP BY и DISTINCT и просто игнорировали дубли.

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

Удалять - советчиков много. Но все они - безотвественные и если вам не стоит слушать советов по чистке данных именно здесь в тостере то вы рискуете какраз потерять нужные данные.

Как по мне - задача поставлена неверно. Или не хватает доп-условий. Например я считаю что общий префикс должен быть такой.

+-----------+------------------------+-------+
| parent_id | path                   | count |
+-----------+------------------------+-------+
| 7         | val1                   | 6     |
+-----------+------------------------+-------+

Если носитель информации - ненадежный - то к нему добавляют дополнительные коды типа Хэмминга которые восстанавливают поврежденные биты после сбоя. На 99% нормальных носителей это реализовано аппаратно. Если твоя флешка сбоит или не очень надежна то желательно купить новую. Если ты всё таки хочешь наковырять золота в навозе - посмотри в сторону утилиты par2 manpages.org/par2 она на десяток процентов увеличит размер твоих бэкапов но будет гарантировать фиксацию нескольких бит если такое будет. Она работает поверх обычной файловой системы и ее коды контроля будут просто дополнительными файлами рядышком.

А проверить восстановистя ли бэкап в принципе - невозможно. Как в той философской мысли - нельзя узнать какой пудинг пока ты его не съел. Поэтому и гарантировать целосность бэкапа на логическом уровне можно только проведя симуляцию его полного восстановления в БД.

Это архитектурный вопрос. Я имею в виду что выбор сервера приложений - это матрица стратегий. И ее нельзя сводить к простому вопросу - что быстрее. Это как дети обычно спрашивают - что лучше : грузовой трак или гоночный болид. Профанация выходит.

Интересный вопрос. Кмк форд-фалкерсон либо плохо параллелится. Либо после параллелизма просядет в блокировках вершин и ребер, что сделает его худшим по эффективности чем непараллельный.

Тут надо подумать.

Изучение Go, Rust я поддерживаю. Это развитие. Это хорошо.

Во фриланс особо не рвись. Я за свою жизнь не видел качественных продуктов в основе которых стоял бы фриланс.

Информатика и вычислительная техника и ЭВМ это немного архаичное название современных it наук таких как собственно программирование, FP, GA, NN, MV.

Старые слова можно много где встретить в старых книгах. У того же Дональда Кнута есть отсылки к алгоритмам сортировки на магнитных лентах.

Идея выглядит очень рискованной.

Несколько важных поинтов. Во первых у автора - путаница в голове. RSA относится не к шифрующим а к подписывающим и проверяющим алгоритмам. В учебных книжках описывают юзкейс как Алиса передает сообщение Бобу но это просто учебный пример. В реальных протоколах типа SSL работает бутерброд из двух технологий. Первое - это процесс рукопожатия автентификации где выясняется кто есть кто. Здесь может быть RSA. И обмен сеансовыми ключиками для симметрички. И второе - это открытие симметричного шифрованного канала где уже работает другой алгоритм типа AES/Blowfish.

И второй поинт. Зачем. Если просто разработать систему - то надо брать готовое под Питон. Если надо разбираться - то продуктовые шифры и алгоритмы очень сложны. Можете просидеть много месяцев. Остановитесь на учебных максимом до DES.

Автор очень быстро отбросил Postgres. Но я хочу спросить были ли исследованы все возможности? Например TimescaleDb.

Вопрос в том как прикладывать линейку. Автора будет интересовать Декартово расстояние? Или расстояние Манхеттена?