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

Я бы посмотрел на существующие реализации XPath.

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

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

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

А, там у тебя XML. И какую батарейку для Python’а используешь?

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

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

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

Выдернуть данные в любую приличную СУБД?

На C(++) накатать.

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

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

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

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

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

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

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

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

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

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

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

Можно, если места хватит, tmp в tmpfs в RAM монтировать.

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

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

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

.net core, ручная обработка поверх XmlReader(т.е. SAX парсера)

Spark?

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

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

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

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

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

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

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

какие регулярки для XML? что ты несешь?

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

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

Ну как же ты так без lxml. Ты поехавший что ли? Какие разговоры о производительности питона могут быть без сишных батареек?

Если нужно выдирать данные из XML - могу пропиарить свой roxmltree для Rust. Он довольно быстрый.

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

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

Apache Camel

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

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

Perlовые регкэспы самые тормозные. Уже давно придумали PIRE, RE2 и Hyperscan.

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

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

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

Надо эту штуку ускорять и уменьшать аппетиты в потреблении памяти

Вангую, у тебя там DOM-парсер, перепиши через SAX-парсер.