mayton2019

Вопрос в перспективе тянет на экспертную систему по выбору БД.

При данной постановке - можно брать любую документно-ориентированную. Все одинаково подходят.
Но если основной контент (80% берем по Паретто) это файлы - то можно брать Amazon S3, в дальнейшем с перспективой трансформировать это в DynamoDb если понадобятся транзакции или в Amazon Document Db (он же Mongo) если понадобится тонкая работа с атрибутами документов (или файлов).

Автор должен понять что в это вопросе нет единого правильного решения. Есть просто некая сравнительная табличка где есть набор фичей с одной стороны и набор DBMS с другой и нет такого покрытия которое бы закрыло ВСЕ фичи.

Если часто удаляется папка с over миллиардом файлов то можно пересмотреть эту задачу архитектурно. Например смонтировать эту папку как volume и форматировать ее. Это быстрее. В противоположность, файловые удаления по 1 штуке требуют фиксации транзакции для каждого файла. А это избыточные действия которые как раз и создают поток IOPs над структурами данных ext4. По аналогии с БД. То что делает автор это удаление каждой строчки из таблицы с коммитом. А то что я предлагаю - это по смыслу truncate table.

Если автору нужно хранить данные измерений (графики) в режиме append-only, то можно посмотреть в сторону InfluxDB.

Сразу 3 замечания.

Непонятно зачем автору считать 43 мегабайта на фоне 3Гб. Это 1%.
Непонятно зачем автор печатает физические размеры файлов. Ведь в них хранятся заголовки и всякие
прочие служебные структуры данных которые к размеру таблицы не относятся.
И непонятно зачем автор вывел длины файлов в размере который округлён в human-readable? Там все равно не учтены килобайты. Уж если пошёл счет на копейки так надо и копейки печатать.

Прости но уж очень много неточностей и косвенностей в самом вопросе. Просто нельзя так.

Почти таже самая проблема на стареньком HP Core i3. Пока стояла десятка все норм. Как только поставил Ubuntu 18 LTS - пошли регулярные дисконнекты. Субъективно вижу что очень низкая чувствительность антены приёмника в ноуте. Грешу на хреновые дрова. Так и не пролечил.

Workaround: Когда включаю смартфон в режиме wifi-точки и ложу его рядом прямо с корпусом ноута - связь появляется.

Можно эту прямоугольную "колбасу" вообще не поворачивать. А хранить вектор повернутости. И перегрузить оператор индекса чтобы доступ вел себя по правилам аффинных преобразований.

Вопрос звучит неправильно. Сам по себе С++ не имеет никаких встроенных в себя технологий для отрисовки графики. Это уже - задача библиотек которые будут зависеть от ОС или оконного менеджера.

И здесь Qt, Gnome, KDE, WTL просто производные от ОС.

Реляционная алгебра практически не умеет оперировать горизонтальными коллекциями. Такова она есть. И SQL создавался для других дел.

Самое правильное что можно сделать - создать временную табличку. Слить туда твои массивы с разворотом в 90 градусов и выполнить простейший (! реально простейший!) запрос с группировкой.

Это решение будет идеологически правильней, чем нагружать SQL не-свойственными ему задачами.

Делаешь две БД. И пишешь в одну все записи удовлетворяющие HASHCODE(primaryKeys, 2) == 0
а во вторую БД HASHCODE(primaryKeys, 2) == 1. При запросах соотв. делаешь запрос в две БД и объединяешь результат.

Господи как все сложно. Берешь и делаешь столько очередей - сколько надо приоритетов. И все.

Автор пытается делать стеганографию. Тоесть в картинке скрывать информацию. Здесь выбор 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     |
+-----------+------------------------+-------+