Показать полную графическую версию : Нужно выбрать лучшее решение по скорости мелких файлов
Может быть не в том разделе пишу, просьба тогда перенести тему.
В общем, нужно подобрать лучшее решение которое существует на момент сентября 2022.
Задача заключается в следующем: есть очень много мелких файлов в разных папках. более 1 миллиона текстовых файлов, весом от 1 до 500 КБ. Эти файлы в разных папках находятся. Нужно найти решение, которое способно максимально быстро, насколько это возможно, архивировать эти файлы, разархивировать, копировать из всех папок, и переносить в одну. Короче обычная простая работа с файлами, казалось бы, на первый взгляд. Но нет. Скорости этих операций очень низкие. Времени очень много уходит на все эти сортировки.
Все тесты по возможности могу предоставить.
Сразу скажу, что обыденные потребительские SSD/HDD тут не особо выкручивают ситуацию по скоростям. Нужно что-то другое выбирать. Я могу ещё больше мыслей предложить на счёт этой темы, но мне хотелось бы услышать сначала экспертов/энтузиастов/инженеров/сис.админов серверов и т.д.
Прежде чем отвечать, прочитайте весь топик! А также, отвечайте развёрнуто, а не просто "Попробуй что-то".
Jula0071
30-09-2022, 11:56
архивировать эти файлы, разархивировать, копировать из всех папок, и переносить в одну. »
Может, стоит начать с того, что пересмотреть способ хранения и процесс работы? Например, хранить документы в document-oriented database, или использовать object storage.
Может, стоит начать с того, что пересмотреть способ хранения и процесс работы? Например, хранить документы в document-oriented database, или использовать object storage. »
Я наверное забыл уточнить, какой тип файлов у меня, что внутри этих файлов и их важность.
Начнём с того, что у меня только .txt файлы. В них содержатся данные такого вида:
-----
text1: text2
text3: text4
text5: text6
text7: text8
-----
text1: text2
text3: text4
text5: text6
text7: text8
-----
Либо такое же, только без text7: text8
Честно, я даже не знаю что именно подходит под такие задачи:
Скачать архив
Выгрузить
Разархивировать архив (где около 100к папок, а в папках по 10-15 файлов)
Найти через поиск только определённое название файла.txt
Все найденные файлы скопировать в новую созданную папку
Получится около 1 млн .txt файлов, с таким типом, который указан в спойлере
Удалить все дубликатные файлы, ибо их будет очень много
Объединить все .txt файлы в 1 .txt файл
Но уж точно никак не подходит mysql база данных под txt файлы, их удаление на дубликаты, и объединение в 1 файл.
Jula0071
30-09-2022, 14:19
Но уж точно никак не подходит mysql база данных под txt файлы »
А кто сказал про MySQL? я сказал про document-oriented database»
Документоориентированная СУБД (https://ru.wikipedia.org/wiki/%D0%94%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D0%BE%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1% 80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%B0%D1%8F_%D0%A1%D0%A3%D0%91%D0%94)
NoSQL, например, mongo (https://www.mongodb.com/docs/).
Кроме Документоориентированная СУБД » NoSQL, например, mongo. »
Есть какие-то другие решения? И я не видел, где вы написали почему именно это рекомендуете.
Просто, мне всего лишь то надо отсортировать очень быстро, и к себе на комп скачать 1 готовый отсортированный файл из миллиона мелких файлов. Хранить мне эти миллионы файлов не нужно нигде.
Jula0071
30-09-2022, 15:42
Просто, мне всего лишь то надо отсортировать очень быстро, и к себе на комп скачать 1 готовый отсортированный файл из миллиона мелких файлов. »
Потому и предложил варианты с базой и объектным хранилищем. Но то канеш требует некоторых телодвижений... А быстро на обычной фс не будет никак. Ну, может, на ReiserFS 4, или на ZFS, или на btrfs. Эти файловые системы на винде не работают, если что :)
quesd, есть программки быстрого поиска. Например Everything (https://disk.yandex.ru/d/xu1aowPKC7PeSw)
Даёте ему проиндексироваться (это 1-2 мин).
Далее в нём поиском по простому шаблону *.txt, отмечаете все файлы, снимаете метку с ненужных и самым простым образом копируете/перемещаете отмеченные простым перетаскиванием в нужную вам папку.
Потому и предложил варианты с базой и объектным хранилищем. Но то канеш требует некоторых телодвижений... »
У меня к сожалению нет опыта работы с этим. И я не знаю насколько это будет эффективно, по сравнению с NTFS например. Но я продолжаю ждать ваши новые идеи на данную тему.
есть программки быстрого поиска. Например Everything »
Уже знаю и пользовался этой программой. Вещь конечно хорошая, но когда требуется быстро перегонять терабайты данных, и ждать вот эту индексацию её, это занимает нереально долго. Уж на NTFS + SSD на pcie 4.0 это было примерно полдня (8-10 часов).
Да и на счёт архивирования и разархивирования терабайтов данных уж точно никак не ускорит данная программа.
а наличие в результате самих текстовых файлов является обязательным условием?
как понял, их содержание - это классические пары логин:пароль.
такое прекрасно впихуемо в любую бд, и это все прекрасно жмется, легко ищется, фильтруется и сортируется.
если критичен источник - вводите в бд третье поле и пишете его там.
ну и т.д.
а наличие в результате самих текстовых файлов является обязательным условием?
как понял, их содержание - это классические пары логин:пароль.
такое прекрасно впихуемо в любую бд, и это все прекрасно жмется, легко ищется, фильтруется и сортируется.
если критичен источник - вводите в бд третье поле и пишете его там.
ну и т.д. »
Если даже и так, то каким образом мне создать базу данных, если у меня в архиве, в разных папках эти txt разбросаны? Мне в любом случае сначала разархивировать архив, потом найти эти текстовые файлы, потом удалить дубли из них, и объединить в 1 файл.
Либо я не понимаю концепцию, либо база данных мне вообще не нужна в данной задаче.
И опять же, мне это лишь временно нужно. Т.е отсортировать - и скачать к себе на комп готовый отсортированный файл. Всё остальное удалить.
Про RAM-диски слышали? Я на них намёк веду.
уж точно никак не ускорит данная программа. »Впихнуть невпихуемо - расскажите остальным.
Ну или в принципе все варианты рабочие.
Другого решения у меня нет.
Может кто и подскажет.
Быстрое решение я вам предложил.
эти текстовые файлы, потом удалить дубли из них, и объединить в 1 файл. »Это совсем другая тема
Если даже и так, то каким образом мне создать базу данных, если у меня в архиве, в разных папках эти txt разбросаны? Мне в любом случае сначала разархивировать архив, потом найти эти текстовые файлы, потом удалить дубли из них, и объединить в 1 файл. »
а зачем?
Если имеет значение только содержание, то алгоритм такой:
открывается файл, строки из него переносятся в базу, последняя - закрывается, открывается следующий и т.д.
Насрать, если будут дубли.
Просто в базе сортируете значения (напр, по возрастанию, не суть), далее простейший цикл "если строка №+1 = строке №, удалить строку №+1".
Профит. Далее играйтесь с этим как угодно.
Про RAM-диски слышали? Я на них намёк веду. »Вам оптимизировать работу надо, а не ускорить.
Положить водопровод, а не искать сапоги скороходы, чтоб быстрее носить воду вёдрами.
@bredych Вы мне сейчас рассказали работу как сделать свой антипаблик с помощью базы данных. Меня такой вариант не устраивает. У меня уже есть самописный софт для таких задач.
Мне просто нужно решение, которое как можно быстрее разархивирует архив, находит файлы, удаляет дубликатные файлы, копирует миллион файлов в другую одну папку, объединяет всё в 1 файл.
И уже этот 1 файл у меня воспринимает и парсит определённые данные. Если что, я создам новую тему, какие ещё есть методы чтобы быстрее парсить данные. Это тоже мне нужно.
Но на данный момент, в приоритете у меня скорее это искать сапоги скороходы, чтоб быстрее носить воду вёдрами. »
dmitryst
01-10-2022, 18:27
какие ещё есть методы чтобы быстрее парсить данные »
парсить большой файл в целом, тяжелее, чем множество мелких. Вполне может быть, что упрётесь в какие-нибудь ограничения. Как вообще парсить собираетесь, хотя бы ЯП какой?
парсить большой файл в целом, тяжелее, чем множество мелких. »
Скажем так: например, число ПИ, записанное в текстовый файл с точностью до 2 миллиардов знаков (по сути, это текстовый файл около 2Гб), в поиске 8 символов, парсится за 4523,2777 миллисекунд до смещения 1816743898 - это тяжелый парсинг? :)
какие ещё есть методы чтобы быстрее парсить данные. »
С помощью потокового чтения, например парсинг можно ускорить, но в Вашем случае вопрос немного в другом... всё будет упираться в архивацию, копирование множества файлов, а также их последовательное открытие-закрытие (чтение/запись)... при указываемых Вами количествах таких файлов... хмм, даже не знаю, с помощью чего тут можно ускорить процесс...
Ну и собственно, судя по Вашему запросу, задача одноразовая? Тут проще таки воспользоваться какими-то готовыми решениями, пусть даже с немаленькими временными затратами...
задача одноразовая? »
В каком плане? Мне очень часто нужно будет сортировать файлы. Сегодня одни файлы, завтра другие и т.д. Тогда ответ нет.
Если же в плане, закинуть архив, распаковать, отсортировать файлы и удалить архив и все эти файлы - то ответ да. Здесь не нужно хранить будет файлы, т.к я один отсортированный файл скачаю к себе на комп.
Тут проще таки воспользоваться какими-то готовыми решениями »
Например?
число ПИ »
Было бы всё так просто)) Цифры очень легко сортируются, парсятся и т.д. Но если же в текстовом документе спец. символы, буквы на разных языках, цифры - то тут уже гораздо дольше времени уйдёт на сортировку.
парсить большой файл в целом, тяжелее, чем множество мелких »
Про что идёт речь? Если про единичный файл - то да, здесь соглашусь. В одном мелком файле, очень мало данных, по сравнению, если все эти мелкие файлы объединить в один большой, и его уже парсить на определённые данные.
Если же речь идёт про архивирование/копирование/перетаскивание - то тут наоборот всё. Один большой файл займёт на все эти операции очень мало времени, по сравнению с миллионами мелких файлов, которые могут растянуться на очень много часов. Ну по крайней мере, это так работает на NTFS. В других ФС я не тестил. Но очень хотелось бы протестировать! Но не знаю с какой ФС начать, и какую выбрать, чтобы гарантированно были максимальные скорости на мелкие файлы!!! Как раз по этому вы и видите этот топик - чтобы ответить на этот вопрос. Ну точнее, один из моих вопросов.
Как вообще парсить собираетесь, хотя бы ЯП какой? »
Сейчас у меня есть самописный сортировщик. Делалось на заказ. Написан на C# буквально на коленке. Он требует большой доработки и оптимизации и ускорении работы. Но сейчас вообще нет времени тестировать этот сортировщик на наличие багов, оптимизацию, делать замеры и т.д. По этому и ищу более лёгкие, быстрые, проверенные решения на данную тему!
Мне очень часто нужно будет сортировать файлы. Сегодня одни файлы, завтра другие и т.д. Тогда ответ нет. »
Ну, то бишь задача периодическая? Тогда имеет смысл её автоматизировать... но чтобы её автоматизировать, необходимы не общие пронумерованные вводные, а подробная формулировка, причем с примерами данных...
Например? »
У меня нет примеров... я ведь не понимаю до сих пор смысл задачи...
Цифры очень легко сортируются, парсятся и т.д. Но если же в текстовом документе спец. символы, буквы на разных языках, цифры - то тут уже гораздо дольше времени уйдёт на сортировку. »
Конечно, скорость будет зависеть от объемов данных и от количества файлов (особенно от количества), ну и от, собственно, действий, которые необходимо выполнить с найденными данными, но содержимое, то бишь тип символов, на сам парсинг сильно влиять не будет, для парсера нет разницы какие символы парсить.
Мне очень часто нужно будет сортировать файлы. Сегодня одни файлы, завтра другие и т.д. »+
Если же в плане, закинуть архив, распаковать, отсортировать файлы и удалить архив и все эти файлы - то ответ да. »
противоречие.
Или однократная задача, или регулярная. И то и другое сразу - не бывает.
Jula0071
05-10-2022, 17:46
более 1 миллиона текстовых файлов, весом от 1 до 500 КБ. »
Уж на NTFS + SSD на pcie 4.0 это было примерно полдня (8-10 часов). »
Предположим, средний размер 250 КБ, миллион таких файлов это довольно скромные 250 гигабайт... не то что бы с таким объёмом данных легко работать, но ничего особенного... у вас лыжи не едут. И смазывай их или не смазывай - в смысле переходи на супер-пупер быстрый сторедж - они быстрее не поедут. Нужно пересаживаться с лыж на то-то более подходящее.
sputnikk
05-10-2022, 18:50
SSD на pcie 4.0 »Какая модель? Если с 2-канальным контроллером и без буфера DDR, то будет чуть быстрее SATA
© OSzone.net 2001-2012
vBulletin v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.