как работать с большими файлами
 

есть файл весит хрен знает сколько , сотни гигов, в этом файле одни цифры, их надо упорядочить от 0 и до победного конца
вопрос как это сделать, чтобы сервак совсем не крякнуть

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

А толку бить на куски, если потом всё равно надо отсортированные куски составлять вместе и сортировать заново?

Ну или можно попробовать через Powershell Core 7, очень эффективная и быстрая штука.
Непонятно только, что за сервер и что за файл, и есть ли требования к инструменту сортировки - питон там, удав или ещё что.

т.е. текстовый файл?!

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

и что за средства есть в седьмом PoSh'е для сортировки файлов без загрузки в память?

Busla, не знаю, в соседней ветке был случай с group, так PS 5.1 у меня пыхтел больше суток и так и не сделал, а PS 7 работал минут 15-20. Допускаю, что и с sort могло произойти нечто подобное.

Ребят, спасибо за подсказки, по крайней мере понял на что смотреть.

Никакие PowerShell'ы, хоть обычные, хоть Core'ы, сюда не годятся по определению. Чистый (без .Net) C/C++, а лучше ассемблер.

Но начинать надо с:

Iska, txt файл

Iska, и как ассемблер может тут помочь?

Вы можете упаковать его некоторую часть (пару-тройку мегабайт) в архив, каковой выложить на облако/вменяемый обменник?

Скоростью обработки. Фактически, что напишете — то и будет в машинных кодах, без включения лишнего.

Iska, вы чушь пиш и eте.
Языки высокого уровня потому и существуют, что это по сути набор ассемблерных функций надёжность и эффективность которых за вас вылизывала толпа умнейших людей.
Самостоятельно на ассемблере имеет смысл реализовывать новый алгоритм.

Не факт, что малоопытный в вопросах оптимизации человек напишет на асме код более оптимальным образом, чем это сделает высокоуровневый компилятор, написанный профессионалами. А если учитывать совокупное время на написание кода + выполнение задачи.....

Iska,
https://dropmefiles.com/5j6Y5

r-studio, сортировка должна быть текстовая или числовая?
какая максимальная разрядность чисел?
распределение примерно равномерное?

Busla,числовое, нет распределение не равномерное, это точно.

И что делать с дублями?
На unix-like такое делается как два пальца, например вот в убунте WSL на винде 10 сортируем как числа с убиранием дублей, второй вариант - распараллеливаем на два потока для ускорения:

Код:

---

time $(sort -u -n 445.txt -o 445_sorted.txt)

real    0m0.799s
user    0m2.844s
sys    0m0.453s

time $(sort --parallel=2 -u -n 445.txt -o 445_sorted.txt)

real    0m1.071s
user    0m1.609s
sys    0m0.203s

---

Для очень больших файлов (гигабайты, десятки гигабайт и больше) имеет смысл применять сжатие временных файлов, напр. --compress-program=lzop и указывать специальную временную директорию --temporary-directory=/mnt/1TB_partition/

UPD нагуглил скрипт, использующий всё тот же sort, но c разбитием исходного файла на куски (split,sort,merge). Автор говорит, что так быстрее. Но проверить это можно только на реально большом файле, который не помещается в память.

Цитата:

Цитата Busla Iska, вы чушь пишите. »

Спасибо за пожелание, но — нет :lol:. Я не планирую писать чушь.

Цитата:

Цитата Busla Языки высокого уровня потому и существуют, что это по сути набор ассемблерных функций надёжность и эффективность которых за вас вылизывала толпа умнейших людей. »

ЯВУ существуют исключительно для того, чтобы сократить временные затраты на написание приложений, а вовсе не потому, что озвучили Вы, коллега.

Цитата:

Цитата Busla Самостоятельно на ассемблере имеет смысл реализовывать новый алгоритм. »

Разумеется.

Цитата:

Цитата iglezz Не факт, что малоопытный в вопросах оптимизации человек напишет на асме код более оптимальным образом, чем это сделает высокоуровневый компилятор, написанный профессионалами. »

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

Цитата:

Цитата iglezz А если учитывать совокупное время на написание кода + выполнение задачи..... »

Вот здесь — в точку. Но смотреть именно на время выполнения задачи — надо. Потому как может оказаться, что «Лучше день потерять, потом за час долететь» отработает быстрее, нежели «Что тут думать — трусить надо» ;). Выбор того или иного подхода будет напрямую зависеть от конкретики задачи.


r-studio, спасибо, ясно. Какова конечная цель? Для чего делается сортировка? Что будет происходить с этим отсортированным файлом дальше, для чего он нужен в отсортированном виде?

Iska, а далее для чего продакт манагер решит , мы не знаем что у Богов на уме)) Возможно будет джойн какой-то или назначение категорий к числам.

Ух… Это печально. Можете выяснить?

Iska, ну сегодня вряд ли, Боги отдыхают скорее всего, но главное вряд ли скажут, но у думаю моя версия будет джойн какой-то или назначение категорий к числам.
в итоге будет файл
число и его тестовая расшифровка

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

Какую именно - реляционную, ключ-значение типа redis, или, может, документоориентрованную? Также интересно узнать прикидки, сколько такого ненужного ресурса как RAM понадобится, чтобы провести сортировку 100 гигабайт.

Можно поменьше файл сгенерировать для бенчмарков с разными БД. Redis in-memory же.

Так задача как раз гигантский текстовый файл отсортировать.

Именно так. Я всё ждал, предложит ли сие кто-нибудь — и не ошибся ;). При всех недостатках данный способ позволяет не заморачиваться деталями реализации того или иного выбранного конкретного алгоритма внешней сортировки, а поручить сие самой СУБД (примерно то, что озвучил ранее коллега Busla). Рекордов производительности ждать, понятно, також не стоит, но при данном подходе это меньшее из зол (и наиболее управляемое в дальнейшем).

Обратно, возможно, и не понадобится. Я таки надеюсь, что коллега r-studio выяснит конечную цель сего действа, и, возможно, задача упростится.

Угу. Есть ли смысл, при текущих озвученных условиях, пользовать что-то другое?!

Нет никакого смысла для решения задачи использовать любую субд. Они не для этого. И реляционная сожрёт всю память и сдохнет. Чудес не бывает.

Вы это сейчас серьёзно? Вы проверяли подобное утверждение или это Ваши предположения?

Печаль такая, всю жизнь работаешь с базами данных, оптимизируешь всяко, и тут такой приходит с вопросом "проверял ли ты лучший способ положить базу?"
Нет, конечно не проверял. И проверять не буду - если я захочу завершить карьеру взрывным способом, то как-нибудь в другой раз.
Iska, какая у вас должность и зарплата? тысчонок хотя бы 30 евро в год? Ну так, чтоб я понимал ваш уровень.

Jula0071, спасибо за Ваш вопрос «Если ты такой умный, то почему не богатый», как говорится — «Ваше мнение очень ценно для нас». Разумеется, нет, коллега, откуда такие зарплаты в нашей деревне :lol:.

Тем не менее, постарайтесь не переходить на личности, равно как не воспринимать мои слова как попытку как-то дискредитировать Ваши утверждения. Я вполне серьёзно хотел бы, чтобы Вы, если у Вас есть таковая возможность, проверили, как будет работать конфигурация, например, на виртуальной машине из 2-4 гигабайт оперативной памяти, x64 ОС и одного из типичных не специализированных серверов баз данных, паре таблиц — Table1 с одним полем Field1 типа INTEGER размером, скажем, в 6-10 гигабайт и аналогичной ей пустой Table2, при использовании банальной конструкции типа SELECT Field1 INTO Table2 FROM Table1 ORDER BY Field1.

я бы даже sqlite попробовал

Ничего с ней не будет. Максимум клиенты по таймауту начнут отваливаться. Но в контексте задачи их нет.

Сортировка как таковая для задачи не требуется - потому что данные в БД нужно ещё загрузить. Добавление записи в БД - более чем типовая операция, от этого СУБД не дохнет. Если же делать массовый импорт, а затем добавить индекс или переиндексировать, то это хоть и тяжелая операция, но так же вполне стабильно работающая.

формально RAM нужна только для нескольких промежуточных переменных. Но в памяти лопатить данные быстрее, поэтому нужно выбрать алгоритм умеющий производить сортировку порциями данных.
По тому образцу данных, что предоставил топикстартер вообще создаётся впечатление, что можно делать сортировку подсчётом.

Угу.

Ребят ссориться не обязательно. В принципе направление мысли я получил, так что тему помечаю как решенная