LINUX.ORG.RU

Работа с текстом: выбор инструментов

 


0

1

Представим, на минутку, что у нас есть очень-очень много текста в виде кучи xml файлов средней степени сложности с юникодом. Очень-очень много это от 500Гб и до 10Тб и над ним надо делать кучу всего, поиск слов, выдергивание каких-то тегов, скармливание всего этого каким-то алгоритмам и т.д.. Сейчас над этим пыхтит питон, но пыхтит плохо, очень медленно, в один поток, пыхтит сутками. Надо эту штуку ускорять и уменьшать аппетиты в потреблении памяти. Какие другие более быстрые и кросс платформенные языки с хорошими библиотеками/фреймворками, заточенными под работу с юникодом и xml вы бы выбрали и почему? Кресты такое себе, там и разработка очень медленная и баги легко делаются, да и с юникодом работа через пятую точку.

PS

Интересно, чем поисковики пользуются, у них по идее похожая задача, только html ещё хуже xml.

★★★★★

Если эти задачи могут решаться grep’ом, то есть такая вот штука ещё: https://sift-tool.org/

А так подпишусь, интересно узнать что там на таких объёмах текста хорошо работает. Неужели Perl, который был заявлен как отличный язык для преобразования текстов.

EXL ★★★★★ ()
Ответ на: комментарий от EXL

Не, grep и даже регулярки не помогут. Я то скорее всего буду питон оптимизировать пытаться, но интересно, какой инструмент выбрали бы для задачи пользователи ЛОР-а.

peregrine ★★★★★ ()
Ответ на: комментарий от peregrine

Вполне возможно, что твою задачу можно разбить на две части: извлечение данных в удобном для обработки виде и непосредственно обработка. Тогда для первой части лично я бы использовал xpath-движок вроде xmllint, если xpath недостаточно то xquery-движок вроде кутишного xmlpatterns, если и этого мало, то написал бы свою прибулуду на c++ и pugixml. А дальше результаты парсинга скармливал питоновому обработчику с алгоритмами

annulen ★★★★★ ()

Интересно, чем поисковики пользуются, у них по идее похожая задача, только html ещё хуже xml.

Современным поисковикам надо и JS выполнять, и хотя бы примерно отлейаутить получившийся документ, чтобы узнать какой текст виден пользователю, а какой добавлен горе-сеошниками для «оптмизации»

annulen ★★★★★ ()
Ответ на: комментарий от EXL

Сейчас мешанина их модуля xml, думаю есть ли смысл переехать на lxml или нет. Наверное, нет, просто надо код причёсывать, т.к. он не мой и писался просто чтобы работало.

peregrine ★★★★★ ()
Ответ на: комментарий от anonymous

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

peregrine ★★★★★ ()
Ответ на: комментарий от peregrine

Но хотелось послушать срачик на работу со строками в разных ЯП

Дома, для xml, использую powershell. Легко написать, работает быстро, юникод. Даже можно без регулярок, просто, как свойства и методы объекта xml.

anonymous ()

Какие другие более быстрые и кросс платформенные языки с хорошими библиотеками/фреймворками, заточенными под работу с юникодом и xml вы бы выбрали и почему?

C# - и кроссплатформенный и библиотеки для работы с xml из коробки и с юникодом все нормально и довольно быстрый, если правильно применять. Со строками работа из коробки нормальная (но не забывать, что если нужна скорость часто полезнее StringBuilder, чем просто String)

Но подозреваю, что в итоге выйдет не сильно быстрее питона. Если основные потери времени на парсинге.

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

Регэкспами выцепляешь нужные данные и вперед, не требуется никаких проверок, никакого построения дерева разбора и т.д. на что уходят ресурсы. Да, есть некоторый риск сработать с ошибкой. Можно оценить насколько, проведя сравнение.

praseodim ★★★★ ()
Последнее исправление: praseodim (всего исправлений: 2)
Ответ на: комментарий от praseodim

Но подозреваю, что в итоге выйдет не сильно быстрее питона. Если основные потери времени на парсинге.

О, нашел в чём основная проблема. Там не парсер даже виноват, а нехороший человек, который в tmp срал временными файлами, а чистить за собой не хотел, да и не хочет, говорит не баг, а фича, что tmp чистится непонятно когда и непонятно как, когда оно потупит некоторое время.

peregrine ★★★★★ ()

Переложи xml в базу и ей пользуйся.

Была такая симпатичная sedna. Маленькая, шустрая и с xquery.

И да, проблемы с юникодом придётся решать до экспорта.

MKuznetsov ★★★★★ ()

Не надо путать кресты и C, разработка на крестах такая же по скорости как на питоне, если писать именно на плюсах, а не на C с классами. icu для юникода, любой подходящий парсер для XML. Единственное - парсеры на C, так что придётся писать обёртку. С другой стороны, и на питоне SAX делается через жопу.

slovazap ★★★★★ ()
Ответ на: комментарий от slovazap

разработка на крестах такая же по скорости как на питоне

Процентов на 30 медленнее, как минимум. Но не в несколько раз, это да. Особенно если обмазываться всякими Qt и иже с ними.

peregrine ★★★★★ ()
Последнее исправление: peregrine (всего исправлений: 2)
Ответ на: комментарий от slovazap

Не надо путать кресты и C, разработка на крестах такая же по скорости как на питоне, если писать именно на плюсах

ахахах смешно.

после пятнадцати лет изучения С++ конечно

anonymous ()
Ответ на: комментарий от peregrine

Конкретные цифры для общего случая = ты их взял с потолка. Но да, примерно так. Базовая императивная часть ложится 1:1, кое-для чего нужен boost но тоже 1:1, у питона плюс по comprehensions и генераторам, у плюсов - по нормальным лямбдам. Увы, нормальной функциональщины нет ни там ни там.

slovazap ★★★★★ ()
Ответ на: комментарий от anonymous

До 11 стандарта в плюсах ничего подобного не было в принципе, так что про 15 лет ты написал чушь. А так фичи 11 стандарта осваиваются за полчаса чтением списка из википедии. А базовые конструкции языка и стандартная библиотека c++ гораздо проще и меньше питоновских.

slovazap ★★★★★ ()
Ответ на: комментарий от anonymous

То что файл в формате XML еще не означает, что его обязательно надо по правилам XML парсить.

Так что обыкновенные регулярки: для нужных тегов с данными. Хотя можно и поиском в строке воспользоваться, регулярка просто проще.

praseodim ★★★★ ()
Последнее исправление: praseodim (всего исправлений: 1)
Ответ на: комментарий от anonymous

А открой сайт lxml и посмотри на сравнение скорости. Батарейки в среднем не так уж и быстрее. Есть ряд задач, где они сильно выигрывают, но есть и где проигрывают.

peregrine ★★★★★ ()
Последнее исправление: peregrine (всего исправлений: 1)

Я бы брал MR. Из доступного наверное смотрел бы в сторону HBase + Spark, но я не сильно в курсе текущих веяний open source. На самом деле 10Тб это не так уж и много, пару дней сырых логов.

xpahos ★★★★★ ()
Ответ на: комментарий от xpahos

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

Iron_Bug ★★★★ ()
Последнее исправление: Iron_Bug (всего исправлений: 2)
Ответ на: комментарий от Iron_Bug

Дело не в Си vs Perl, а в используемых алгоритмах. Но в целом ничего не мешает собрать кластер на пару тысяч машин с Hadoop и считать на нем, тогда даже Perl будет быстро.

xpahos ★★★★★ ()
Ответ на: комментарий от xpahos

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

Iron_Bug ★★★★ ()
Последнее исправление: Iron_Bug (всего исправлений: 1)