Структуры данных и их анализ. Сугубо техническое

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

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

Конечно, есть парсеры вроде HPricot, RubyfulSoup и BeautifulSoup которые дают больше возможностей за счёт гибкости используемых языков. Парсеры на Python и сам язык в этом плане приятное исключение — я хорошо понимаю его растущую популярность, но и у них есть недостатки, относительно низкая производительность.

Вообще же чем далее тем более я прихожу к выводу что модель работы с такого рода данными должна быть не в виде структуры дерева, а гибрида дерева + микро-реляционной БД + микро-OLAP. Но микро-OLAP — это пока что-то из ряда фантастики, тем более для подобной задачи.

И, конечно, отдельный вопрос это производительность и объёмы данных. Пока объекты рассматриваются на микроуровне — веб страница, PDF и так далее, то маштабирование является несложной задачей.  Когда же срезы данных идут на гигабайты, а число триплетов на миллиарды, то тут то и нужны механизмы HBase или HyperTable или, если говорить о научных данных, то использование HDF5.

Ещё одно решение в использовании баз данных с поддержкой XPath и XQuery, но все они относятся к Enterprise продуктам и непригодны для микро-анализа, а для значительных объемов данных слишком дороги в маштабировании и, в любом случае, не решают вопросов работы с полуструктурированными данными.

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

About This Author

  • Евгений

    Почему не берешь в расчет Native XML базы данных?

  • http://ivan.begtin.name ivbeg

    В основном из-за их производительности и сложности в освоении XQuery сторонними разработчиками.

Яндекс.Метрика