Проблема при работе с большими файлами (~ 5 Гб)

Russian main discussion
  • Author
  • Message
Offline
Posts: 15
Joined: Wed Dec 08, 2010 9:47 am

Post by Goodvin »

FeyFre wrote:Goodvin
Я вижу два выхода:
1. Либо учим Акел(а заодно и плагины) работать со свопингом, что совсем не просто и займет уйму(уймище) времени.
2. Либо делаем Акел 64-битным(и перекладываем всю ответственность на кол-во памяти у пользователя), что немного быстрее, но я не уверен что мы имеем достаточно опыта миграции на 64, и выловим все подводные камни(что опять таки выльется в доп. время), да плагин тоже перевести нужно будет.
На мой скромный взгляд - алгоритм работы с гигантскими файлами немного в стороне от этого.
Например, связан с индексированием файла и работой по индексу.
Возможно, есть смысл посмотреть как работает с гигантскими файлами пресловутый вышеупомянутый EmEditor. Что делает со свопом, какие временныые файлы создает и т.п.
FeyFre wrote: 3. А разделить файлы на куски поменьше не пробовали? Я так понимаю качество обработки от этого не пострадает.
Увы, разделять не выйдет. Весь 5-гиговый файл - это цельный структурированный XML. Если разбить его на куски, то невозможно будет отследить по смыслу XML-объекты внутри него. Файл потеряет человекочитабельность.

Offline
Posts: 876
Joined: Tue Jul 24, 2007 8:54 am

Post by Fr0sT »

Goodvin
Эти 5 гигов - это XML-дамп большой базы данных.
Как раз в plain-тексте дампа поправить несколько строчек, а потом загрузить исправленное снова в БД значительно проще и нагляднее.
Хм, я сам ненавижу, когда на вопрос начинают вместо ответа предлагать варианты, как это сделать окольнейшими путями, но всё-таки, не легче ли это реализовать SQL командой или хранимой процедурой?
Что касается EmEditor, то я поражён его талантами в области огромных файлов. И еще при этом сохраняют возможность редактирования! Боюсь, если добиться тех же умений от Акеля, он будет стоить столько же, сколько Em :)

Offline
Posts: 2247
Joined: Tue Aug 07, 2007 2:03 pm
Location: Vinnitsa, Ukraine

Post by FeyFre »

Увы, разделять не выйдет. Весь 5-гиговый файл - это цельный структурированный XML. Если разбить его на куски, то невозможно будет отследить по смыслу XML-объекты внутри него. Файл потеряет человекочитабельность.
Выше сказано что это дамп БД. Я так догадываюсь что это дамп релятивной БД. А раз так, и в БД оно лежит уже разбито по самостоятельным подобъектам: строчки, поля в строчках. А раз так, то разбить и обработать не проблема. Да, нужно будет сделать несколько итераций по всем файлас, с сохранением промежуточных данных. Но это пока единственный фаш выход.
И да, Fr0sT прав: на какой делать таким обходом? SQL-лями можно сделать почти всё(остальное делаем клиентом который SQL пускает). Другие варианты смахивают на велосипедостроение.

Offline
Posts: 15
Joined: Wed Dec 08, 2010 9:47 am

Post by Goodvin »

Fr0sT wrote:Goodvin
Эти 5 гигов - это XML-дамп большой базы данных.
Как раз в plain-тексте дампа поправить несколько строчек, а потом загрузить исправленное снова в БД значительно проще и нагляднее.
Хм, я сам ненавижу, когда на вопрос начинают вместо ответа предлагать варианты, как это сделать окольнейшими путями, но всё-таки, не легче ли это реализовать SQL командой или хранимой процедурой?
если бы такое было применимо, вопрос бы вообще не стоял.
А редактировать дамп нужно как раз тогда, когда с БД работать нет возможности, в основном это случаи всякого ремонта, отката, восстановления целостности (надо загружать разные периоды в БД) и т.п.
При интенсивной работе возникают периодически.
и когда времени мало - редактировать простой xml в текстовом редакторе значительно эффективнее, чем поднимать второй сервер БД, которого может и не быть в пределах доступности.

Fr0sT wrote: Что касается EmEditor, то я поражён его талантами в области огромных файлов. И еще при этом сохраняют возможность редактирования! Боюсь, если добиться тех же умений от Акеля, он будет стоить столько же, сколько Em :)
Вот потому меня и волнует вопрос - нужно ли кому-то в принципе этим заниматься, есть ли к этому интерес?
Если есть, то я бы пытался всячески помогать и т.д.
А если нет, то надо просто-напросто убрать из описания AkelPad-а на главной странице проекта строчку о том, что размер файла не ограничен. И указать предельный размер файла было бы неплохо.
Last edited by Goodvin on Thu Dec 09, 2010 7:23 pm, edited 1 time in total.

Offline
Posts: 15
Joined: Wed Dec 08, 2010 9:47 am

Post by Goodvin »

FeyFre wrote:
Увы, разделять не выйдет. Весь 5-гиговый файл - это цельный структурированный XML. Если разбить его на куски, то невозможно будет отследить по смыслу XML-объекты внутри него. Файл потеряет человекочитабельность.
Выше сказано что это дамп БД. Я так догадываюсь что это дамп релятивной БД. А раз так, и в БД оно лежит уже разбито по самостоятельным подобъектам: строчки, поля в строчках. А раз так, то разбить и обработать не проблема. Да, нужно будет сделать несколько итераций по всем файлас, с сохранением промежуточных данных. Но это пока единственный фаш выход.
И да, Fr0sT прав: на какой делать таким обходом? SQL-лями можно сделать почти всё(остальное делаем клиентом который SQL пускает). Другие варианты смахивают на велосипедостроение.
Вы всё верно говорите, друзья, но !
Почему-то всё время в общении смещается вектор с решения конкретной задачи на критику условий этой самой задачи.
Я ж не дурак, и прежде, чем приходить сюда с вопросом, тщательно всё обдумывал, искал варианты, много всего пробовал.
И уж если пишу, что вот есть такая задача "визуально читать и редактировать большой файл порядка 5 гигабайт", то задача у меня именно такая.
И именно такая возможность задекларирована у программы AkelPad.
Но, как выяснилось, функция не работает.
Притом, если другие программы, не сумев открыть такой большой файл, честно об этом сообщают различными способами, AkelPad просто молча показывает не весь файл.
И мой приход сюда был в надежде на то, что обнаруженная мной неработоспособность заявленной функции будет кому-то интересна и мой опыт поможет сделать AkelPad лучше, и я готов в этом улучшении участвовать в меру сил.

А мне раз за разом рассказывают, что я хочу не того, чего надо, и делать мне надо что-то другое.
[пожимает плечами с недоумением]

Offline
Site Admin
Posts: 6311
Joined: Thu Jul 06, 2006 7:20 am

Post by Instructor »

Goodvin
А если нет, то надо просто-напросто убрать из описания AkelPad-а на главной странице проекта строчку о том, что размер файла не ограничен.
Та фраза благополучно перекочевала из AkelPad 2.x.x. На практике мной проверялись файлы от силы пару сотен мегабайт.

DV
Offline
Posts: 1250
Joined: Thu Nov 16, 2006 11:53 am
Location: Kyiv, Ukraine

Post by DV »

Instructor wrote:Та фраза благополучно перекочевала из AkelPad 2.x.x. На практике мной проверялись файлы от силы пару сотен мегабайт.
Стало быть, реально должны поддерживаться файлы где-то до 2 ГБ (что, по идее, ограничивается адресацией с помощью 32-битных указателей). А для не-Юникодных файлов - где-то до 1 ГБ, потому что для них требуется дополнительная память для преобразования в Юникод.

Offline
Posts: 876
Joined: Tue Jul 24, 2007 8:54 am

Post by Fr0sT »

Goodvin
Почему-то всё время в общении смещается вектор с решения конкретной задачи на критику условий этой самой задачи.
А так всегда, если задача не особенно коррелируется с понятиями других (ака весьма экзотична) :)
В принципе, я был бы очень рад, если бы Акель стал пошустрее обрабатывать хотя бы 50-меговые файлы, не говоря уже о бОльших, но 5 гигов - это уж совсем экстремально. Скажи, а этот Em умеет работать с разными кодировками? То есть если файл, например, в KOI8 - он преобразует его правильно? У Акеля-то основная загвоздка в том, что после прочтения файла он перегоняется в utf16.

Offline
Posts: 2247
Joined: Tue Aug 07, 2007 2:03 pm
Location: Vinnitsa, Ukraine

Post by FeyFre »

(Писал я вчера такую тераду, да забыл запостить)
Если кратко:
Моя позиции(и наверное ещё кого-то здесь):
Акел не потянет Ваш 5Гб файл в виду 32 битного ограничения по памяти(минимум). Это не баг, это врожденное. И потому мы пытаемся подсказать как решить Вашу задачу без АкелПада. Это не агрессия.

Offline
Posts: 3217
Joined: Wed Nov 29, 2006 1:19 pm
Location: Киев, Русь
Contact:

Post by VladSh »

Goodvin
Instructor, если он против, то обычно сразу говорит об этом.
Т.е. 2 варианта: либо уберут упоминание об этом, либо есть надежда, что реализуют (или во всяком случае попробуют).
Я не редактирую такие большие файлы, но, с моей точки зрения, было бы лучше, чтобы AkelPad обладал такими возможностями, это было бы его реальное преимущество перед другими, в отличие от подсветок и т.п., которые есть почти везде.

Касательно x32.
Компа на x32 уже не купишь. Глянуть на любые сайты-сборники прог, так уже около 50% есть версии под x64, и их количество продолжает расти. А там где есть версии под x64, x32-верии в плане каких-то серьёзных изменений уже никто не будет допиливать, т.к. это зря потраченные время и ресурсы. Ясно одно, x32 - это вчерашний день.

Offline
Site Admin
Posts: 6311
Joined: Thu Jul 06, 2006 7:20 am

Post by Instructor »

Goodvin
А если нет, то надо просто-напросто убрать из описания AkelPad-а на главной странице проекта строчку о том, что размер файла не ограничен.
Убрал. Проверил на Windows x64 с 4Gb ОЗУ - при достижении порога в 2Gb начинают выдаваться сообщения о нехватке памяти, затем программа с загруженным куском файла работает очень нестабильно.

Offline
Posts: 15
Joined: Wed Dec 08, 2010 9:47 am

Post by Goodvin »

Instructor wrote:Goodvin
А если нет, то надо просто-напросто убрать из описания AkelPad-а на главной странице проекта строчку о том, что размер файла не ограничен.
Та фраза благополучно перекочевала из AkelPad 2.x.x. На практике мной проверялись файлы от силы пару сотен мегабайт.
Понятно.

Offline
Posts: 15
Joined: Wed Dec 08, 2010 9:47 am

Post by Goodvin »

Fr0sT wrote:Goodvin
Почему-то всё время в общении смещается вектор с решения конкретной задачи на критику условий этой самой задачи.
А так всегда, если задача не особенно коррелируется с понятиями других (ака весьма экзотична) :)
В принципе, я был бы очень рад, если бы Акель стал пошустрее обрабатывать хотя бы 50-меговые файлы, не говоря уже о бОльших, но 5 гигов - это уж совсем экстремально. Скажи, а этот Em умеет работать с разными кодировками? То есть если файл, например, в KOI8 - он преобразует его правильно?
Проблем ни разу не встречал.
Насколько я понимаю - работает правильно.

Offline
Posts: 15
Joined: Wed Dec 08, 2010 9:47 am

Post by Goodvin »

FeyFre wrote:(Писал я вчера такую тераду, да забыл запостить)
Если кратко:
Моя позиции(и наверное ещё кого-то здесь):
Акел не потянет Ваш 5Гб файл в виду 32 битного ограничения по памяти(минимум). Это не баг, это врожденное. И потому мы пытаемся подсказать как решить Вашу задачу без АкелПада. Это не агрессия.
Это понятно.
Но багом точно является тот факт, что АкелПад, не сумев открыть большой файл, ничем мне как пользователю не сообщил. И ладно бы, если бы не сумел открыть - не показал вообще ничего, но он показывает только часть файла и молчит, словно всё в порядке.
Такое поведение программы я считаю неправильным.
Это и есть баг.
Надеюсь, это будет исправлено авторами.

Offline
Posts: 15
Joined: Wed Dec 08, 2010 9:47 am

Post by Goodvin »

Instructor wrote:Goodvin
А если нет, то надо просто-напросто убрать из описания AkelPad-а на главной странице проекта строчку о том, что размер файла не ограничен.
Убрал. Проверил на Windows x64 с 4Gb ОЗУ - при достижении порога в 2Gb начинают выдаваться сообщения о нехватке памяти, затем программа с загруженным куском файла работает очень нестабильно.
Понятно.
Спасибо за внимание к моей проблеме.
А чем может быть объяснено поведение программы, когда она показывает мне лишь часть файла и ничего не сообщает - ни ошибок, ни варнингов?
Post Reply