всем привет!

взялся тут за text mining, приходится работать с большими объёмами текстовой инфы... а потом выяснилась, что лучшая на сегодня библиотека для извлечения информации из текстов написана на Perl, с которым у меня было ну уж очень короткое знакомство... поэтому обращаюсь к уважаемым гуру, дабы заинтересовать их проблемой и попросить помощи!

итак. есть текстовый файл ~180 Мб
в нём 7.500.000 строк, каждая из них в таком формате:



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

мне просто кажется, что стандартный код типа



не есть самое эффективное решение в данном случае...

заранее признателен за любую помощь/идеи/советы/предложения!



Это сообщение отредактировал(а) yorc - 26.12.2009, 23:23

поиск по _чему_ ?

Если по номеру строки - оптимально хранить  в массиве.
Если полнотекстовый - нужно строить инверсный индекс.

P.S.
А еще совет - попробуйте для начала использовать обычный grep (unix) -  180 МБ хорошо ложаться в кеш операционки, поэтому это может быть довольно таки быстрый поиск.

поиск самый примитивный: если среди записей из файла ЕСТЬ слово из текста, то нужно вернуть две цифры, которые соответствуют этому слову в файле. я бы не сказал, что это полнотекстовый поиск, т.к. разделять слова не нужно. будет ли в этом случае оптимальным решением обычная операция проверки существования элемента массива с заданным ключом и извлечение данных при положительной проверке?

насчёт grep не понял?..  вы предлагаете делать системный вызов? и как это связано с кешем системы?

если вы 180 метров засунете в perl - хэш - это будут все 300. которые будут висеть у вас в памяти. 
Доступ по ключу в хэше конечно быстрый.. вот только вопрос - вам точно нужна такая скорость ?

если да.. то



P.S. как вы планируете использовать этот файл ? опишите полностью задачу, плиз

Это сообщение отредактировал(а) sir_nuf_nuf - 27.12.2009, 11:50

Больше (гораздо) 

yorc, совет sir_nuf_nuf про grep, IMHO, хорош. В самом деле, попробуйте, если у Вас *nix. После первого поиска файл закешируется (будет в памяти) и при следующих поисках система фактически уже не будет читать его с диска, возьмет из памяти, а 180 М grep прошерстит быстро.

Вот еще, нашел у себя скриптик и переделал его немного под Вашу задачу. На диске будет храниться БД, надеюсь, поиск в ней будет быстрым.

sir_nuf_nuf : спасибо за помощь!

запустил код на VDS с 800 MHz ядром + 1 Гб памяти
загрузка занимает в среднем 2,5 минуты

после окончания загрузки поиск моментальный! здорово))

заметил только 3 момента, когда тестировал:

1. print $index{"DHIFFUSHI"}[1]."\n"; выдало 28 вместо 14. как видим:



2. print $index{"CATHOLIC APOSTOLIC CHURCH"}[0]."\n"; выдало



В строке 16 при этом как раз:



3. print scalar (keys %index); выдаёт каждый раз разные результаты, далёкие от истины: 1930032, 1930033 и т.д.
это может быть связано с ограничением памяти на 1 процесс, я думаю...

вывод: чем заморачиваться с хэшами, лучше залью всё в БД!
была ещё мысль использовать биндинг memcached для перла
но это только если тесты на БД будут неудовлетворительными

задача же моя крайне критична по времени и ресурсам: обрабатываю текст, извлекаю слова, считаю определённые параметры исходя из данных таблицы. при этом всё делается на лету, планируется онлайн-сервис. скорость должна быть максимальной!

и тогда такой вопрос: что, по Вашему, будет быстрее, MySQL или, может, BerkeleyDB ? или PostgreSQL ?

Быстрее всего будет BerkleyDB / memcachedb
Но если нужна нормальная сортировка, выборка, то лучще юзать какую-нибудь реляционную бд. ( mysql или postgresql )

Если нужно очень быстро, то использовать для этого списка BerkleyDB/memcached(b), а для хранения юзеров и т.д. реляционную.

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

Фразы эти лучше хешировать ( md5, sha1 ), тогда проблем не будет

сдается мне - быстрее всего будет может быть grep. А если и не быстре - то проще всего.

yorc, я бы еще посоветовал почитать как ведут себя такие функции как substring, index.. регулярные выражения с текстовыми строками большого объема.. Ибо в перле есть не самое хорошее поведение, при работе с большими данными, когда окажется что памяти расходуется много больше чем предполагалось. 

решил проблему установкой Redis-сервера с Перл-биндингом

всем спасибо!