Решено: обработка большого текстового файла

[azsx]

Есть текстовой файл в утф8 на 53 гб (чуть позже напишу сколько строк, слов, символов - wc считает).
Думаю об способе выборки данных из этого файла по сложным условиям, например:
-ремонт пластиков(*) окн(а|о|ы) {в Москв(?)|в Санкт{-| }Петербурге|в Иванов(?)}
то есть:
- не надо брать слово;
* любое колличество текстовых символов;
? один символ;
| или другой символ или группа символов (окончания, приставки в слове).
Вопрос, какой программой удобнее всего будет делать такие выборки по одной и по несколько выборок за раз? Желательно софт для десктоп и консольного режима.
зы
сам уже пробовал загонять текстовой файл в mysql, но выборки занимают часы времени (при этом mysql имеет особенность она тормозит при большой выборке, хоть разревись). Думал об оптимизации данных, но это сложно программировать. В бд base я не понимаю как текстовой файл загнать. Знаю php чуть чуть и bash. Аналоги для винды, например KeyWordKeeper.
зызы

Keywords.txt: Words: 237 024 547 Lines: 1 052 839 850 Chars: 178 388 965
Grammar:
Sentences: 60 206 596
Words per sentence: 3.9
Characters per word: 0.8
зы
В итоге grep устраивает пока, более чем. По крайне мере не хуже, чем софт в винде по параметрам выборок и значительно быстрее (не знаю почему) по скорости выборки.

[Bizdelnick]

Как вариант - xapian.
Да, это не будет просто.

[azsx]

Вроде xapian используется для поиска на веб сайте, а мне надо на локальном компе.

[Bizdelnick]

Вроде xapian используется для поиска на веб сайте

Он используется для поиска где угодно. В частности, в Debian - для поиска по описаниям пакетов (см. /var/lib/apt-xapian-index/README).

[azsx]

ясно. А попроще способа нет?

[serzh-z]

ясно. А попроще способа нет?

Не понимаю, что значит "загонять текстовой файл в mysql", но почему бы не преобразовать этот файл в нормализованную базу данных и расставить индексы на столбцы, по которым нужно делать выборку? Можно, в конце концов, использовать фразовый индекс (см. FULLTEXT).

[azsx]

что значит "загонять текстовой файл в mysql"

это значит, что вставка приблизительно 12 гб с удалением дублей в mysql длилось около 6 часов на hdd. Выборка, даже по относительно простым запросам 2 часа минимум.

расставить индексы на столбцы, по которым нужно делать выборку?

в том то и дело, что всё это нужно только под сложные запросы. Под простые я кейвордкипером, кеймонстром или подобным выборку сделаю. А вот сложные запросы делать нечем. Вот искаю софт.

использовать фразовый индекс (см. FULLTEXT).

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

[serzh-z]

Я так понимаю, что файл представляет собою набор строк, где перечислены ключевые слова связанные с какими-то данные, типа телефона. Скажем:

ремонт непластиковых дверей в Москве\t12345678
ремонт пластиковых окон в Питере\t999999
продажа деревянных баклуш в Мухосранске\t0987654321

Для этого достаточно иметь пару таблиц, нечто типа:

Код: Выделить всё

create table foo (
id bigint primary key,
phone tinytext
);

create table keywords (
foo_id bigint foreign key references foo(id) on  update cascade on delete cascade,
keyword text not null,
fulltext (keyword)
);

И далее можно делать поиск по keywords.keyword, используя MATCH. Либо же разбить каждую строку файла на слова и сделать каждую запись в keywords одним словом, и используя обычный индекс. После чего можно делать поиск, используя DISTINCT-запрос с обычным LIKE.

[serzh-z]

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

Поиск по индексированному миллиарду записей в MySQL - это не два часа. Это секунды и минуты. Ну если только, может, запросы совсем уж "сложные" (т.е. не оптимизированные).

[azsx]

Я так понимаю, что файл представляет собою набор строк, где перечислены ключевые слова связанные с какими-то данные, типа телефона.

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

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

уметь бы это еще всё, ведь после разбивки на слова мне потом то надо вернуть именно конечные строки!

непластиковых

то есть как пример, надо выборку
{-не|*|}пластиков(??)
то есть исключая слова начинающиеся с приставки "не", вместе со всеми словами с приставками или без них, корень слова "пластиков"и окончание слова не более двух букв, после корня (ых, ые, ый и прочее).
Вот может для вас это просто, но как такие выборки делать в MATCH я не понимаю.

[drBatty]

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

из 53Гб получится 146Гб индексов. В RAM это не войдёт, однозначно.

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

если я правильно понял постановку задачи, то кроме regex(7) ничего лучше не придумать. Из командной строки это sed(1), из C/C++ это regexec(3)

FULLTEXT из MySQL вам тут вряд-ли поможет, если конечно вы не можете вырезать часть текста, по которой надо искать от всего остального. Если у вас структура типа:

1. поле со строкой вида "ремонт пластиковых окон в Москве"
2. поле с кучей разного текста/картинок и т.п., в котором искать НЕ нужно

то поля №1 можно загнать в FULLTEXT индекс, и если он влезет в память(оперативную), то будет годно.

Если не влезет, то от индексов проку нет, особенно на HDD. Sed на порядок быстрее работает. На SSD не знаю точно, но думаю тоже нет смысла.

Поиск по индексированному миллиарду записей

"миллиард записей в MySQL" это всего навсего 4 гигабайта. Если у вас есть 4Gb памяти с произвольной выборкой, то да, всё будет мгновенно.

т.е. не оптимизированные

LIKE %... не оптимизируется MySQL даже для CHAR. Т.е. работает на порядки медленнее просмотра sed или regexec(3).

А вот FULLTEXT думаю тупо не влезет даже на 1Tb, а если и влезет,то месяц будет отробатывать и год строится.

[drBatty]

Либо же разбить каждую строку файла на слова

не подходит. Вот это не сработает:

Код: Выделить всё

окн(а|о|ы)

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

Код: Выделить всё

(окна|окно|окны)

но в общем случае это не сработает.

Тут вам уже надо разбивать слова на корни/приставки/суффиксы/окончания, а эта задачка для русского языка в принципе неразрешима.

Самое печальное в этой задаче то, что даже если вы её решите (путём вбивания всех 100500 исключений), то всё равно не взлетит. Разгадка проста: элементарная неграмотность операторов убьёт любой поиск.

Конечно есть такая штука, как метрика Левенштейна, но это в теории. А практике там получается совсем медленно. Да, гугл как-то считает, но у гнугла и серверов как блох у Барбоски.

[azsx]

Тут вам уже надо разбивать слова на корни/приставки/суффиксы/окончания, а эта задачка для русского языка в принципе неразрешима.

вообще как я понимаю, тогда правильнее разбить по шинглам разной размерности, а не по словам. Тогда удалится изббыточность данных при поиске, что однозначно сыграет в плюс при поиске. Зато файлов станет в разы больше, так как надо делать шинглы разной размерности, например от 2 до 15. Причем улучшение производительности будет вне зависимости приставка или окончания слова изменена. Другой вопрос, что в текстовой базе мне надо будет организовать связь, которая очень легко может быть нарушена. Конечно, можно сделать опцию переиндексации. И да, это очень сложно, это всё надо програмировать!!!

Из командной строки это sed(1), из C/C++ это regexec(3)

если это единственный варианты, то плохи мои дела. Интересно, сколько стоит програма на с в консоли?
Я вот думаю:
1. оказывается на linux идет freepascal. Может в нем?
2. Может написать в джава? Всё равно для универа желательно учить джава. netbeans я на убунту установил
3. Почему не php? В php есть серьезный плюс - я некоторые команды в нем знаю!
Или по производительности все те три решения ужасно проигрывают? Хотя как они могут проигрывать, даже не смотря на то, что я хочу разделить файл на 3 hdd диска, один фиг скорость получения с диска будет в разы дольше, чем скорость обработки данных с на i5 проце, верно?
зы
кстати могу эту задачу решать на одном из двух компов
1. i7 - 2 диска, но могу поискать третий; 30 гб оперативной свободно.
2. i5 3 диска и могу подключить еще парочку. 10 гб оперативной свободно.

[Hephaestus]

это база пастухова

Насколько я понял, эта штука не бесплатная.
И продаётся в комплекте с виндовой программой.
Если оно у Вас официально куплено, пинайте распространителей/разработчиков на предмет использования в "не Windows".
Если же оно Вам досталось каким-либо другим путём, тогда...
Я не совсем понимаю, 53Гб - это исходное состояние файла или что это? Оно так и продаётся в одном файле на 53Гб? Вообще, откуда он такой взялся?
Откажитесь от первоначальной схемы. Хранить данные в одном файле на 53Гб - это... Не говоря уже о возможности сбоя или повреждения (как тогда быть?), обрабатывать это в таком виде - Вам никаких мощностей не хватит.
А вообще, Вы недостаточно внятно сформулировали задачу. Что Вы хотите получить в итоге?

[azsx]

Я не совсем понимаю, 53Гб - это исходное состояние файла или что это? Оно так и продаётся в одном файле на 53Гб? Вообще, откуда он такой взялся?

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

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

архив файла?
в каком виде лучше обрабатывать? Думаете лучше иметь 100 файлов по 50 мб? Мне кажется у них дольше процедура открытия будет идти.

Что Вы хотите получить в итоге?

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

[Hephaestus]

архив файла?

На 53Гб? Или сколько оно там в архиве? 39Гб?
Смешно.

в каком виде лучше обрабатывать? Думаете лучше иметь 100 файлов по 50 мб? Мне кажется у них дольше процедура открытия будет идти.

Лучше иметь нормальную БД. С индексами и прочими причиндалами.

я так понимаю, что готового решения в никс нет, придется писать программу

Правильно понимаете. И программа уже написана. Официальная. Под винду. (Кстати, Вы её пробовали, как она в работе? Устраивает?)
У Вас не винда. Поэтому я и говорю, если Вы лицензионный пользователь, напрягите разработчиков на предмет "не все в этом мире используют винду".
Глядишь, что-нибудь и сваяют.

Просто люди пишут что выборки в консоли делают (только не говорят как).

Делают. Но это не один файл размером 53Гб.

Кстати, я сомневаюсь, что официальная программа так и держит всё в одном файле на 53Гб.
И даже если так, то всё равно наверняка используются индексы. Без индексов это ОЧЕНЬ медленно. Мало-мальски сложная обработка базы в dbf (кстати, тоже один файл в 600Мб) у меня крутилась полдня. С индексами - меньше минуты.

[Bizdelnick]

Просто люди пишут что выборки в консоли делают (только не говорят как).

Конвейер grep'ов? Медленно, но верно. Только в первом надо задать наиболее редко используемое слово.

[azsx]

И программа уже написана. Официальная. Под винду.

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

Глядишь, что-нибудь и сваяют.

нуну или пошлют, что гораздо проще. Тут уж наверное или сам или никак.

Лучше иметь нормальную БД. С индексами и прочими причиндалами.

1. Я загонял бд в mysql. Тогда же узнал, что используется только одно ядро и mysql для других запросов умирает, когда делает ресурсоекую выборку.
2. Мне кажется drBatty прав, что индексы реально не влезут в оперативную память и потому не дадут мне положительных няшек.
3. лучше получать выборку, а не иметь файл в базе данных.

Мало-мальски сложная обработка базы в dbf (кстати, тоже один файл в 600Мб) у меня крутилась полдня.

хз, у меня выборка по like из базы в 60 гб (но именно в бд, в тексте меньше было) без индексов шла 2 часа на hdd винте.

Без индексов это ОЧЕНЬ медленно.

ага согласен, но скорость тут не очень важна.

Конвейер grep'ов? Медленно, но верно.

скорее всего нет. Любой язык программирования даст полный контроль над выборкой. А grep и sed будут весьма запутаным решением. Для меня по сути, что софт на джава писать, что sed учить - всё едино по трудоемкости.

[Bizdelnick]

Любой язык программирования даст полный контроль над выборкой. А grep и sed будут весьма запутаным решением.

Что Вы понимаете под "полным контролем"?

Для меня по сути, что софт на джава писать, что sed учить - всё едино по трудоемкости.

А Вам в любом случае придётся регулярные выражения осилить. Да, sed тут вообще никаким боком, откуда Вы его взяли?

[azsx]

какие нужны выборки я написал с старт посте (извините просто скопирую то же самое).

sed тут вообще никаким боком, откуда Вы его взяли?

сам придумал. Я ведь слабо понимаю что делает sed.

[Hephaestus]

также делает выборки из текстовых файлов.

Из одного файла огромных размеров? Или всё-таки там несколько файлов, но поменьше?

нуну или пошлют, что гораздо проще.

Пошлют пользователя, купившего лицензию?
Я знаю только одну контору, которая может себе это позволить без каких-либо последствий.

2. Мне кажется drBatty прав, что индексы реально не влезут в оперативную память и потому не дадут мне положительных няшек.

Так, стоп. Официальная программа каким-то образом работает? Работает.
Скорость работы приемлема? Вы об этом не сказали, но полагаю, что да.
И это в результате работы с одним файлом на 53Гб и без индексов? Не поверю.
По Вашим же словам

хз, у меня выборка по like из базы в 60 гб (но именно в бд, в тексте меньше было) без индексов шла 2 часа на hdd винте.

Так вот с этим файлом в 53Гб не думаю, что будет быстрее.
Официальная программа работает с такой же скоростью?

ага согласен, но скорость тут не очень важна.

Как это не важна?
Нет, ну если Вы готовы каждую выборку ждать по полтора-два-четыре часа...
Тогда берите что угодно, хоть

Конвейер grep'ов?

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

1. Я загонял бд в mysql. Тогда же узнал, что используется только одно ядро и mysql для других запросов умирает, когда делает ресурсоекую выборку.

Просто загнать мало. Надо разделить. Спроектировать БД, одним словом. Если, конечно, данные позволяют.

3. лучше получать выборку, а не иметь файл в базе данных.

Ну, файл в базе данных - это не просто ради смеха. Там всё-таки предполагается некая обработка.

Любой язык программирования даст полный контроль над выборкой. А grep и sed будут весьма запутаным решением.

Понимаю так, что Вы уже приняли решение.
В таком случае, данная тема исчерпана.

[Bizdelnick]

и будет он Вам крутить это дело по полдня на каждый запрос.

Ой, да ладно. Будет крутить столько, сколько потребуется на однократное чтение файла. Не больше 10 минут на HDD, а на SSD и того быстрее.

[Hephaestus]

Ой, да ладно. Будет крутить столько, сколько потребуется на однократное чтение файла. Не больше 10 минут на HDD, а на SSD и того быстрее.

Может быть. Спорить не буду.
Однако у меня есть файл логов неротированный. Размером не 53Гб, а гораздо меньше, что-то там около двух гигов что ли...
Так я его открывал, например, в vim - ждать надоело. И даже если откроет, перемещаться по файлу невозможно, сами понимаете.
Попробовал перенаправить на вход less и перейти в конец - не смог, зависает.
Так что у меня нет впечатления, что большие текстовые файлы на десятки гигов так вот прям лихо будут обрабатываться за считанные минуты.

[Bizdelnick]

Так я его открывал, например, в vim - ждать надоело. И даже если откроет, перемещаться по файлу невозможно, сами понимаете.

vim считывает файл в память целиком, а grep - по строкам.

Попробовал перенаправить на вход less и перейти в конец - не смог, зависает.

Hint: use tail(1).

[azsx]

Hephaestus вы может говорите верно, но для моего уровня образованости - рано говорите. Надо подождать пока у меня хоть что то заработает, а уже потом говорить о бд которые надо спроектировать.

Официальная программа работает с такой же скоростью?

работает медленно, но у них есть чит - файлы разделены по языкам откуда собрали данные. Только вот при проектировании титлов интернет магазинов для буржуев приходится использовать всю бд. Но вообще бд пастухова работает более чем медлено в родной оболочке даже при выборке только ру кеев.
----------------------
хочу разобраться в grep, однако man по нерусски, а примеров в сети для меня явно не достаточно. В частности так и не понял как делать выборки типа:
* любое колличество текстовых символов;
? один символ;
| или другой символ или группа символов (окончания, приставки в слове).
---------------------
проведу эксперемент. запущу баш файл типа
date
grep 'газ' 111 | grep 'природный' >222.txt
date
sed '/газ/!d; /природный/!d' 111 >333.txt
date
завтра, если ничо не зависнет отчитаюсь об результатах.

[Bizdelnick]

В частности так и не понял как делать выборки типа:
* любое колличество текстовых символов;

.*

? один символ;

.

| или другой символ или группа символов (окончания, приставки в слове).

\| или | в расширенном синтаксисе.

А вообще по grep и регуляркам вообще в сети полно маналов. Вот первое, что нагуглилось:
http://rus-linux.net/nlib.php?name=/MyLDP/...guide-04-2.html
http://www.ibm.com/developerworks/ru/libra...-speakingunix9/

[azsx]

я в шоке. grep обработал файл за 9 минут (секунды сокращаю), sed обработал за 11 минут. Мне этой скорости хватает более чем. Возможностей по выборке мало. Только 2 вопроса:
1. получается считывал и обрабатывал винчестер у меня 98 мб в секунду. Это так то нормально для hdd винчестера, если учесть, что файл один. Верно?
2. вот ту по нерусски написано что то http://www.opennet.ru/man.shtml?topic=larg...&category=5
Что именно я не понимаю написано, однако волноваюсь. Здсь указано, что grep может не обрабатывать на некоторых файловых системах файлы больше 2 гб. А на ext4 обрабатывает больше 2 гб?

[Bizdelnick]

Возможностей по выборке мало.

Так я ж писал: конвейер делайте.

получается считывал и обрабатывал винчестер у меня 98 мб в секунду. Это так то нормально для hdd винчестера, если учесть, что файл один. Верно?

Нормально. Независимо от количества файлов (разве что их было бы очень много совсем маленьких - тогда было бы медленнее).

вот ту по нерусски написано что то http://www.opennet.ru/man.shtml?topic=larg...&category=5

Это про Solaris написано.

[azsx]

Так я ж писал: конвейер делайте.

покажите пожалуйста пример любого конвейера? Просто не понимаю что это такое, с любыми разумными словами.
-------------------
вот не могу понять, например мне надо определенное слово "газ"
в grep есть параметр -w однако, он именно берет слово с двумя пробелами (типа " газ "). А как сделать выборку именно по одному слову?
зы
кстати при выборке по . и .* работа замедляется в разы (минут 50 было сложное условие). Но это нормально.
Зато в винде выборка даже по одному слову (например по "кредиты" шла 40 минут на родной базе.

[Bizdelnick]

покажите пожалуйста пример любого конвейера?

википедия://Конвейер (UNIX)
grep 'пластиков' base.txt | grep 'ремонт' | grep -E 'ок(он|н[ао])'