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

[Busla]

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

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

[Iska]

Busla, тогда соглашусь с Вами.

Дело в том, что, по оценкам примерно пятнадцатилетней давности, даже самое лучшее, вылизанное от и до с точки зрения эффективности времени исполнения приложение, созданное высококлассным программистом с идеальным исходным алгоритмом, будучи написано на каком-нибудь Watcom C (даже не C++, который с этой точки зрения ещё хуже) со всеми оптимизациями, с профилированием и последующей заменой критических участков на ассемблерные вставки, и каком-нибудь произвольном ассемблере — давало тридцати-сорокапроцентную разницу во времени исполнения. Такая же ситуация и по затратам памяти. Это в идеальных условиях. В не идеальных, в случае обычных программистов — разница бывала уже кратная.

Почему же все не пишут на ассемблере — это тоже понятно: оплачивается время работы программистов, а критическая эффективность исполнения требуется в очень и очень немногих случаях, и приоритет отдаётся первому (почему мы все не летаем на вертолётах, скажем — да?). Плюс, многие вещи на ЯВУ, существенные для корректного исполнения приложений, но занудные для постоянного ручного отслеживания (вроде выхода индекса за пределы массива) там делаются автоматически — не следует считать, что компиляторы «просто хуже» [Busla, это я уже не для Вас пишу, а для тех, кто будет читать и при том достаточно далёк от низкоуровнего программирования].

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

[Sham]

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

[Jula0071]

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

[Sham]

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

[Jula0071]

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

[Iska]

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

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

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

[Jula0071]

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

[Iska]

И реляционная сожрёт всю память и сдохнет. »
Вы это сейчас серьёзно? Вы проверяли подобное утверждение или это Ваши предположения?

[Jula0071]

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

[Iska]

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

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

[Sham]

я бы даже sqlite попробовал (https://stackoverflow.com/a/27640661/3491376)

[Busla]

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

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

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

[Iska]

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

[r-studio]

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