Нужно выбрать лучшее решение по скорости мелких файлов
 

Может быть не в том разделе пишу, просьба тогда перенести тему.
В общем, нужно подобрать лучшее решение которое существует на момент сентября 2022.
Задача заключается в следующем: есть очень много мелких файлов в разных папках. более 1 миллиона текстовых файлов, весом от 1 до 500 КБ. Эти файлы в разных папках находятся. Нужно найти решение, которое способно максимально быстро, насколько это возможно, архивировать эти файлы, разархивировать, копировать из всех папок, и переносить в одну. Короче обычная простая работа с файлами, казалось бы, на первый взгляд. Но нет. Скорости этих операций очень низкие. Времени очень много уходит на все эти сортировки.
Все тесты по возможности могу предоставить.
Сразу скажу, что обыденные потребительские SSD/HDD тут не особо выкручивают ситуацию по скоростям. Нужно что-то другое выбирать. Я могу ещё больше мыслей предложить на счёт этой темы, но мне хотелось бы услышать сначала экспертов/энтузиастов/инженеров/сис.админов серверов и т.д.

Прежде чем отвечать, прочитайте весь топик! А также, отвечайте развёрнуто, а не просто "Попробуй что-то".

Может, стоит начать с того, что пересмотреть способ хранения и процесс работы? Например, хранить документы в document-oriented database, или использовать object storage.

Я наверное забыл уточнить, какой тип файлов у меня, что внутри этих файлов и их важность.
Начнём с того, что у меня только .txt файлы. В них содержатся данные такого вида:

Либо такое же, только без text7: text8

Честно, я даже не знаю что именно подходит под такие задачи:

1. Скачать архив
2. Выгрузить
3. Разархивировать архив (где около 100к папок, а в папках по 10-15 файлов)
4. Найти через поиск только определённое название файла.txt
5. Все найденные файлы скопировать в новую созданную папку
6. Получится около 1 млн .txt файлов, с таким типом, который указан в спойлере
7. Удалить все дубликатные файлы, ибо их будет очень много
8. Объединить все .txt файлы в 1 .txt файл

Но уж точно никак не подходит mysql база данных под txt файлы, их удаление на дубликаты, и объединение в 1 файл.

А кто сказал про MySQL? я сказал про Документоориентированная СУБД
NoSQL, например, mongo.

Кроме Есть какие-то другие решения? И я не видел, где вы написали почему именно это рекомендуете.

Просто, мне всего лишь то надо отсортировать очень быстро, и к себе на комп скачать 1 готовый отсортированный файл из миллиона мелких файлов. Хранить мне эти миллионы файлов не нужно нигде.

Потому и предложил варианты с базой и объектным хранилищем. Но то канеш требует некоторых телодвижений... А быстро на обычной фс не будет никак. Ну, может, на ReiserFS 4, или на ZFS, или на btrfs. Эти файловые системы на винде не работают, если что :)

quesd, есть программки быстрого поиска. Например Everything
Даёте ему проиндексироваться (это 1-2 мин).
Далее в нём поиском по простому шаблону *.txt, отмечаете все файлы, снимаете метку с ненужных и самым простым образом копируете/перемещаете отмеченные простым перетаскиванием в нужную вам папку.

У меня к сожалению нет опыта работы с этим. И я не знаю насколько это будет эффективно, по сравнению с NTFS например. Но я продолжаю ждать ваши новые идеи на данную тему.

Уже знаю и пользовался этой программой. Вещь конечно хорошая, но когда требуется быстро перегонять терабайты данных, и ждать вот эту индексацию её, это занимает нереально долго. Уж на NTFS + SSD на pcie 4.0 это было примерно полдня (8-10 часов).
Да и на счёт архивирования и разархивирования терабайтов данных уж точно никак не ускорит данная программа.

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

Если даже и так, то каким образом мне создать базу данных, если у меня в архиве, в разных папках эти txt разбросаны? Мне в любом случае сначала разархивировать архив, потом найти эти текстовые файлы, потом удалить дубли из них, и объединить в 1 файл.
Либо я не понимаю концепцию, либо база данных мне вообще не нужна в данной задаче.

И опять же, мне это лишь временно нужно. Т.е отсортировать - и скачать к себе на комп готовый отсортированный файл. Всё остальное удалить.
Про RAM-диски слышали? Я на них намёк веду.

Цитата:

Цитата quesd уж точно никак не ускорит данная программа. »

Впихнуть невпихуемо - расскажите остальным.
Ну или в принципе все варианты рабочие.
Другого решения у меня нет.
Может кто и подскажет.
Быстрое решение я вам предложил.

Это совсем другая тема

а зачем?
Если имеет значение только содержание, то алгоритм такой:
открывается файл, строки из него переносятся в базу, последняя - закрывается, открывается следующий и т.д.
Насрать, если будут дубли.
Просто в базе сортируете значения (напр, по возрастанию, не суть), далее простейший цикл "если строка №+1 = строке №, удалить строку №+1".

Профит. Далее играйтесь с этим как угодно.

Вам оптимизировать работу надо, а не ускорить.
Положить водопровод, а не искать сапоги скороходы, чтоб быстрее носить воду вёдрами.

@bredych Вы мне сейчас рассказали работу как сделать свой антипаблик с помощью базы данных. Меня такой вариант не устраивает. У меня уже есть самописный софт для таких задач.
Мне просто нужно решение, которое как можно быстрее разархивирует архив, находит файлы, удаляет дубликатные файлы, копирует миллион файлов в другую одну папку, объединяет всё в 1 файл.
И уже этот 1 файл у меня воспринимает и парсит определённые данные. Если что, я создам новую тему, какие ещё есть методы чтобы быстрее парсить данные. Это тоже мне нужно.
Но на данный момент, в приоритете у меня скорее это

Скажем так: например, число ПИ, записанное в текстовый файл с точностью до 2 миллиардов знаков (по сути, это текстовый файл около 2Гб), в поиске 8 символов, парсится за 4523,2777 миллисекунд до смещения 1816743898 - это тяжелый парсинг? :)

С помощью потокового чтения, например парсинг можно ускорить, но в Вашем случае вопрос немного в другом... всё будет упираться в архивацию, копирование множества файлов, а также их последовательное открытие-закрытие (чтение/запись)... при указываемых Вами количествах таких файлов... хмм, даже не знаю, с помощью чего тут можно ускорить процесс...
Ну и собственно, судя по Вашему запросу, задача одноразовая? Тут проще таки воспользоваться какими-то готовыми решениями, пусть даже с немаленькими временными затратами...

В каком плане? Мне очень часто нужно будет сортировать файлы. Сегодня одни файлы, завтра другие и т.д. Тогда ответ нет.
Если же в плане, закинуть архив, распаковать, отсортировать файлы и удалить архив и все эти файлы - то ответ да. Здесь не нужно хранить будет файлы, т.к я один отсортированный файл скачаю к себе на комп.

Например?

Было бы всё так просто)) Цифры очень легко сортируются, парсятся и т.д. Но если же в текстовом документе спец. символы, буквы на разных языках, цифры - то тут уже гораздо дольше времени уйдёт на сортировку.

Про что идёт речь? Если про единичный файл - то да, здесь соглашусь. В одном мелком файле, очень мало данных, по сравнению, если все эти мелкие файлы объединить в один большой, и его уже парсить на определённые данные.
Если же речь идёт про архивирование/копирование/перетаскивание - то тут наоборот всё. Один большой файл займёт на все эти операции очень мало времени, по сравнению с миллионами мелких файлов, которые могут растянуться на очень много часов. Ну по крайней мере, это так работает на NTFS. В других ФС я не тестил. Но очень хотелось бы протестировать! Но не знаю с какой ФС начать, и какую выбрать, чтобы гарантированно были максимальные скорости на мелкие файлы!!! Как раз по этому вы и видите этот топик - чтобы ответить на этот вопрос. Ну точнее, один из моих вопросов.

Сейчас у меня есть самописный сортировщик. Делалось на заказ. Написан на C# буквально на коленке. Он требует большой доработки и оптимизации и ускорении работы. Но сейчас вообще нет времени тестировать этот сортировщик на наличие багов, оптимизацию, делать замеры и т.д. По этому и ищу более лёгкие, быстрые, проверенные решения на данную тему!

Ну, то бишь задача периодическая? Тогда имеет смысл её автоматизировать... но чтобы её автоматизировать, необходимы не общие пронумерованные вводные, а подробная формулировка, причем с примерами данных...

У меня нет примеров... я ведь не понимаю до сих пор смысл задачи...

Конечно, скорость будет зависеть от объемов данных и от количества файлов (особенно от количества), ну и от, собственно, действий, которые необходимо выполнить с найденными данными, но содержимое, то бишь тип символов, на сам парсинг сильно влиять не будет, для парсера нет разницы какие символы парсить.

+
противоречие.
Или однократная задача, или регулярная. И то и другое сразу - не бывает.

Предположим, средний размер 250 КБ, миллион таких файлов это довольно скромные 250 гигабайт... не то что бы с таким объёмом данных легко работать, но ничего особенного... у вас лыжи не едут. И смазывай их или не смазывай - в смысле переходи на супер-пупер быстрый сторедж - они быстрее не поедут. Нужно пересаживаться с лыж на то-то более подходящее.

Какая модель? Если с 2-канальным контроллером и без буфера DDR, то будет чуть быстрее SATA

Я на данный момент использую Seagate Firecuda 530