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

Есть программа, которая исполняя роль прокси-сервера, попутно индексирует адреса, и их HTTP-залоговки, которые запросил пользователь.
Для индексации программа использует текстовый файл и работает с ним посредством StringList. Сначала записывается адрес, далее - заголовки. Потом второй адрес и его заголовки и т.д. Как вы уже поняли, такой список сортировать нельзя.
Когда пользователь заново запрашивает адрес, который уже "проиндексирован", программа должна определить номер строки необходимого адреса в индекс-файле и выдать следующие строки (это как бы заголовки) до тех пор, когда первые символы следующей выдаваемой строки будут "http://", к примеру.
Поначалу поиск необходимого адреса я делал с помощью функции IndexOf, но когда размер индекс-файла переваливает за 20Мб уже создаются сложности в виду медлительности. Частично "порог" удалось отодвинуть заменив эту функцию на Pos(CRLF+link+CRLF, indx.Text) (CRLF =  #$0D+#$0A;).
Но уже на 30Мб всё уже возвращается на свои места.

Вопрос: существует хоть какой-то вид альтернативы StringList'у? Необходимо записывать данные в конец, но при этом иметь возможность читать файл с начала, чтобы искать необходимые строки (адреса ссылок) и читать строки далее (получать заголовки) (ReadLn???)

Спасибо за понимание.

Может стоит посмотреть в сторону базы данных?

Нет. Условие - работа с текстовыми файлами, простота доступа пользователя к этому файлу.
В конце-концов это как суточный лог-файл - сутки закончатся и будет новый индекс-файл.
Зачем же это всё впихать в одну базу?
Необходимо, чтобы это был именно файл, а не БД.
Помогите.

Есть "легкие" базы данных, например VolgaDB. Высокая скорость работы, вся база в одном файле и т.д. 
Если не устраивает, попробуй FileMapping.

Как насчёт TFileStream?

а списки... TList

Что мешает работать с базой данных, а когда нужен лог - один раз его создавать из базы и давать пользователю (или что там надо?). А саму непосредственную работу проводить с базой.

Ага, я понял, щас объясню.
Обычно файлы индексации весят от 200Мб, поэтому использовать TList, на мой взгляд, не уместно, т.к. файл будет грузиться в оперативную память, а она не резиновая.
TFileStream не позволяет работать с файлом как с набором строк (как это делает TextFile) произвольной длины.
Но TextFile, в свою очередь не может решить вопрос о работе с файлом как для записи строк (в конец) так и чтения всех строк (от 0 - необ. задачи).
THashedStringList такой же тупой как и TStringList - он помещает мой 340Мб файл в ОЗУ, а что другим программам оставить???
К тому же это не лог-файл. Он должен так выглядеть (как лог-файл).
Условие осталось прежним: это должен быть текстовый файл, и ни какая БД.


Это сообщение отредактировал(а) Stern87 - 18.2.2008, 11:17

  Поскольку строки не меняются и не удаляются, то для их хранения можно использовать файл подкачки или просто файл отображаемый в память. Вместо AnsiString юзать PChar. Каждый раз когда нужно будет выделить новый кусок мы просто присваиваем текущий указатель и затем смещаем его на длину строки. Тогда строки будут подгружаться в память по мере обращения, но работа замедлится по сравнению если бы они были в оперативке. Освобождаем удалением файла. Не будет 2х копий. 
  Stern87, в любом случае дешевле купить 2 гига оперативки чем платить тебе зарплату, за то что ты будешь месяц прогу писать  . 

Причём здесь моя зарплата и работа как таковая??
Это - прихоть.
А если индекс-файл может быть больше 2Гб - еще оперативы докупать?
Можно получить такой же "инструмент" как TStringList (в частности: добавление в конец и обращение к конкретной строке) только такой, который бы НЕ загружал этот текстовый файл в ОЗУ? (Это, можно сказать, тот самый вопрос из первого поста)

Это сообщение отредактировал(а) Stern87 - 18.2.2008, 12:27

Можно увидеть обоснование этого? Почему именно так и не иначе? Или дело просто в: 


Это сообщение отредактировал(а) Poseidon - 18.2.2008, 12:32

  Так я ж описал механизм. Скопируй сорс TStringList и переопредели выделение памяти строк инициализацию и т.д. короче все что понадобиться. Но память выделяй сам используя файл отображаемый в память.

Я бы базу в Access хотя бы создал и с ней работал. Вот и альтернатива. 

  Дело в цене, если игра не стоит свеч, то зачем мучаться? Да и как за день может набраться лог на 2 Гига? Поиск в ОЗУ будет самым быстрым. Если грузить с харда, то все намного замедлиться.

Stern87, 
а если попробовать так:
пришем в файл фиксированную длину строки, заведомо большую чем самая длинная
далее через seek бегаем по файлу

Задолбешься бегать по тридцатимегабайтному текстовому файлу...

Сокращенно "прихоть" не получилось 
Можно. Программа уже n-й версии. И "структура" этих индекс-файлов не меняется уже очень долго. Люди пользуются разными версиями этой программы и они могут обменивать этими файлами, объединять их, или просто править в обыкновенном блокноте. Очень желательно, чтобы "структура" осталась такой же открытой и доступной.

Звучит неплохо. Вот я и спросил: если ли уже что-то готовое, потому что найти неполучается((( ??

Но это делает программу зависимой от Microsoft Office. А если программа работает на простеньком сервере в маленькой локальной сети? Ради её еще и Office ставить? Нет, спасибо за предложение, но альтернатива плохая.

А как узнать какая может попаться самый большой HTTP-адрес? В принципе, по RTF это 4096 (поправьте, если я не прав). Но а как же тогда будут сохраняться POST или куки всякие??


Можно даже упростить главный вопрос сформулировав так: что вы будете предпринимать, если окажется, что некогда ваш механизм оперирования с текстовым файлом (посредством TStringList) будет слишком медлительным и использовать слишком много ОЗУ (увеличить которое сможет далеко не каждый ваш потенциальный пользователь), и изменить структуру того текстового файла вы не можете?

Stern87, ты хочешь и рыбку съесть и вырезано цензурой.
Выиграешь в скорости - потеряешь в памяти и наоборот.

Да я уже скорость и не прошу. Мне просто нужно, чтобы ОЗУ не так кушало, а удобство было такое же как и работа с TStringList. Или, еще проще, навигация по строкам и добавление строки в конец. Вот и всё! Не так уж и много надо.

вместо tstringlist использовать массив строк, если сравнить: поиск по массиву будет происходить раз в 5-10 быстрее чем по tstringlist, т.к. если нужно быстрота, то объекты в твоем случае лучше отбросить, только лишь на вызов TStringList.Items[i] тратиться в 10 раз больше времени чем на тот же массив arr[i]... Так что загоняй строки в массив, и работай с ним ... естественно используй динамические массивы...

Это сообщение отредактировал(а) lukas - 18.2.2008, 17:35

Объясни в чем заключается удобство. Проще будет думать.

Добавлено через 10 минут и 46 секунд

Append? 


А вот это я не понял

Писал уже - можно легко добавить строку в конец, а также, можно обратиться к любой строчке.

Он открывает текстовый файл для записи строк в конец. Читать им строки открытого файла, кажется, нельзя.

Да, но что мешает Reset - прочитать - закрыть, Append - записать - закрыть. 
Или я что-то не понимаю?

грузить 200 метров текста в память??? я бы тоже БД использовал

Добавлено через 7 минут и 49 секунд

акцесс тормознутый

Добавлено через 9 минут и 46 секунд

firebird

При таких жестких условиях я бы FileStream использовал. При более мягких:

так если использовать файлстрим, то нужно весь файл грузить в память?
а как искать инфу в тексте, если текст не загрузить в память? по одной строчке? типа загрузил одну, проверил, не то, выгрузил и т.д.

Скорее не целиком, а блоками...

Stern87
Запись текстового файла (то бишь Ваша строка) состоит из двух частей: ключ поиска - это URL-адрес поста, информация записи - текст поста юзера. Длина ключа поиска и длина информационной части записи являются переменными. Правильно понимаю условие задачи?

Мне кажется, что GreenPC предлагает хорошую идею: использовать Seek.

Только надо немного дополнить:
- надо преобразовать ключ поиска в 16-ный хэш, н-р, использовать SHA-1, который выдает 20 байтный хэш;
- в памяти хранить этот хэш и Integer-смещение записи от начала текстового файла; 
- итого: длина элемента динамического массива равна 24 байтам.

Тогда требование к памяти должно снизиться и Вы можете делать поиск хэша для ключа, введенного  юзером. 

Можно также отсортировать массив и применить бинарный поиск, или, в крайнем случае создать двоичное дерево вместо массива.



Это сообщение отредактировал(а) mutex - 19.2.2008, 03:42

mutex, 

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

Poseidon, зато не кушаю память ,
на текущий момент средняя скорость чтения с винта 20-30 мб/с
а если файл еще записан одним куском (не дефрагментирован) то скорости должно хватить

ЗЫ: например Kerio держит в файле индексов абсолютное смещение от начала файла, соответственно нет фиксированной длины строки.
делаем seek & readln. кстати для лога 30мб файл индесков всего 800к

Это сообщение отредактировал(а) greenpc - 19.2.2008, 08:54

Ребята!
Да не лог это. Это своеобразный индекс-файл: строка HTTP-адреса (текст, рисунок - всё что только может запросить браузер), а следующие строки - HTTP-заголовки этого адреса; потом опять строка HTTP-адреса, заголовки и так по кругу. Он может и выглядит из-за этого как лог, но им он не является.
Еще заметил, что когда я вызываю
где indx - TStringList, то функция Pos зажирает примерно столько, сколько весит индекс файл. И не освободит память до тех пор, пока программа не выйдет из функции в которой и была вызвана эта Pos!!
Определил это на глаз с помощью sleep(7000).
Может я чего-то не понимаю? Почему Pos не освободил память, которую он для себя занял?

Все он освободил, просто системе значит эта память пока не нужна. Как понадобиться она ее заберет.

Мдя... 

1) Качаешь этот архив: http://www.torry.net/vcl/internet/html/Alc...cmp_3_52_15.zip
2) Находишь там юнит alFcnString
3) Используешь в своей программе аналоги функций, Pos -> ALPos, таким образом увеличишь скорость работы и не придется бороться с форматом
4) Внимательно посмотри состав архива, может еще что-нить интересное для себя найдешь.

5) Дополнительно, для освобождения памяти попробуй почаще вызывать такую функцию:


ЗЫ Я конечно бы рекомендовал использовать базу данных. Ну раз хочется - то попробуй мой совет. В противном случае тебе здесь никто больше помочь ничем не сможет. 

Это сообщение отредактировал(а) ASGDeveloper - 19.2.2008, 13:58

Тогда объясни нам зачем эти данные пользователям? Зачем они ими обмениваются?

Каждый их использует по-своему.

возьми модуль QStrings, работа со строками, для сравнения я проверял аналогичная функция Q_PosStr работает ровно в 4 раза быстрее чем стандартная функция Pos, что уж говорить о других аналогичных функциях в этом модуле... Из всего что я перепробовал, этот модуль самый быстрый при работе со строками (например тот же AcedUtils и FastStrings работает медленнее QStrings), а вообще еще раз повторюсь, используй массив вместо tstringlist, по крайней мере поиск будет в раз десять быстрее....

Я и так использую модуль FastCode (а также FastMove) в своих компонентах.

Это сообщение отредактировал(а) Stern87 - 19.2.2008, 21:53

И там есть такая функция? 

а де  QString   скачать? Нашел правда последнее изменение в 2000 году были может и не то... Но я провел эксперемен взял текстовый файл размером 50000 строк (2.6 мб) 
Делал я слудующие искал в каждои строке символ "=" и все что боло до него писал в БД.
Попробовал 3 способа:

1. Символ искал с помощью Copy если не "=" то прибовлял к строке текущий символ (тоесть проверял каждый символ пока не встречал "=") затрачено времяни 1 минута 27 секунд.

2. Символ искал с помощью Pos затем результат делал с помощью Copy () затрачено времяни 1 минута 32 секунд.

3. Символ искал с помощью Q_PosStr затем результат делал с помощью Q_Copyleft () затрачено времяни 1 минута 48 секунд.
Отсюда вывод что QString нехрена не быстрее... Либо я что то не так делаю...


Это сообщение отредактировал(а) WaReZMEN - 20.2.2008, 04:03

А где пункт 4 с ALPos?

ASGDeveloper, а это где взять?

WaReZMEN, внимательно перечитай ветку. или хотя бы последние 15 постов.
QStrings можешь скачать на TORRY.net - просто введи в поиск "QStrings" и всё.

P.S. Q_PosStr хрена и быстрее. просто ты что-то не так делаешь.

Это сообщение отредактировал(а) Stern87 - 20.2.2008, 11:40

WaReZMEN, 

Где нибудь вставь эти 2 процедуры, и сравни что быстрее.... как говориться всю работу со строками я испытал на своей крове, и ни один из FastStrings, AcedUtils не дает больше скорости чем QString, просто нужно смотреть, какие функции там работают быстрее чем обычно, например замена Delete (Q_Delete), тоже работает там намного быстрее чем обычно...

Ну так я ж писал что может у меня либа не та я скачал щас с TORRY.net  посмотрел эта деиствительно работает быстрее...

Вот вы лучше раскажите как в lingvo так быстро слова фильтруются??? там же дофига слов... я вот базу сделал из 300000 слов так задержка заметная (около 1-2 сек). (База на Файрберде) 

Это смотря как ты фильтруешь. Запросом все делается быстро. А вообще тут это оффтоп.

Я предлагаю конкретизировать вопрос еще сильнее, чтобы не было вариантов типа БД и т.д.

Задача:
Есть огромный текстовый файл (он уже существует) размером 400Мб.
Есть чёткий запрет "Не загружать весь файл в ОЗУ", по объективным причинам (не все же могут позволить себе закупаться памятью).
Вы должны уметь записывать новые строки в конец этого файла, а также уметь читать все строки от самой первой, до последней.

Какие есть предложения?
Если есть возможность показывайте и код.
К примеру, если вы предлагаете использовать TFileStream - покажите код, который бы показывал как бы вы реализовывали эти "умения".
Спасибо!!

Stern87, как же ты не поймешь...

Что бы реализовать это  и это  в принципе нужно загрузить фесь файл в память. Есле еще второй можно как-то обскакать, загружая построчно или по блокам, то что бы записать что-то в конец, нужно этот конец найти. А что бы найти конец файла, нужно загрузить в память весь файл.

А вообще, я считаю, что "текстовый файл размером 400Мб" - это немецкое порно-извращение. Не всегда такую БД увидешь. Ни о какой производительности с такими обьемами и в текстовом формате речь идти не может. Выход у тебя один - переделывать архитектуру программы в сторонну БД. В БД можно запросом выбрать что тебе надо, не загружая все в память. А так же запросом добавлять новые записи, вообще не трогая старые. Так что подумай.

Poseidon,  а что его искать  - размер файла

кто Вам такое сказал ?
Stern87,  создавать файл индексов, но это уже почти переход на БД

Poseidon,  полностью согласен


Это сообщение отредактировал(а) greenpc - 22.2.2008, 09:49

  Несогласен. Чтобы дописать конец файла ничего не нужно грузить в память, а чтобы иметь произвольный доступ к строкам, совсем не обязательно читать весь файл. Я вот писал специальный модуль для работы с большими XML файлами, парсинг проводиться в 2 этапа. На 1 м этапе произодиться предварительный парсинг, цель которого разобрать общую структуру и создать дерево индексов. Запоминается номер 1го и последнего символа в строке и такая запись сохраняется. Теперь для получения произвольного доступа к записи, сначала идет обращение к этому индексу, потом из файла читается фрагмент начиная с 1го символа и длиной (последний - первый + 1). Но тут я его привести не могу, так как он узкоспециализированный и написан на С++   

Все это хорошо, но я не думаю что те XML были в 400МБ. Вы только вдумайтесь в это: 400МБ текста... Я вообще не представляю как с таким работать. Его хоть блокнот открывает?

блокнот такой файл не откроет, он с трудом открывает файлы размеров в несколько мегабайт

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

 Я имел ввиду вот это:

Замечательная идея. При 400-ти мегах может выручить только индекс-технология баз данных. Как говорит автор - Stern87, файл - суточный, временный и не редактируемый, кроме дозаписи в его конец. Значит такой парсинг надо делать на лету, при созданий строк файла, начиная с ноля часов. Если уж надо минимизировать память, эту структуру надо сбрасывать в отдельный файл, который и будет индексом текстовой БД.

Stern87, на Вашем месте, я бы  выставил кусок файла и привел пример ключа поиска и ответа на поиск. Кстати, как это за 24 часа удается набрать такой объем данных? Что за болтливый сайт, если не секрет?