mayton2019

Самым быстрым являются хешмапы в памяти приложения. Но вопрос на самом деле более сложный. Как только нам нужно делать 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.

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

Полностью согласен с ораторами насчет виртуализации.

По поводу ситуации что уже случилась. Скорее всего заход в баш вам ничего не даст. Т.к. любые команды что вы будете выполнять будут запускать процессы и вы будете снова и снова получать ту-же ситуацию что и с башом. Тоесть каким-то чудом зашли но ничего сделать толком нельзя.

Нужно 100% собрать логи и посмертные снимки памяти приложений. Или приложения. Скорее всего оно одно. И оно-же является источником проблемы. Это приложение надо перенести в докер к лимитами по памяти и там запускать.

Дампы памяти надо проанализировать и понять что флудит. С точки зрения приложения должны быть какие-то гарантии или требования по штатному режиму работы. Тоесть если ему надо 8Г то дайте ему ровно 8 и не больше.