Техническое: Про NoSQL в ГосСети

By ivbeg On 11.06.2010 · Leave a Comment

В сети идёт активное обсуждение нужен ли NoSQL или не нужен рекомендую почитать посты тут — http://zabivator.livejournal.com/412053.html и http://rainman-rocks.livejournal.com/120682.html.

Ещё один технический нюанс ГосСети (www.govweb.ru) в том что в проекте частично использует NoSQL, а точнее — базу MongoDB (www.mongodb.org).

К примеру, как устроен проект ГосСетью.

Есть публичный фронтэнд (www.govweb.ru) в котором публикуется информация о сайтах. Сам проект живёт на Django + MySQL. Это позволяет вести разработку предельно быстро и удобно, но и имеет ряд ограничений, например, в том что в подобной схеме неудобно хранить данные не имеющие четкой структуризации.

Поэтому были самые разные идеи — от использования Semantic MediaWiki, до адаптации или разработки движка аналогичного FreeBase (но это оказалось слишком дорогой задачей). А Semantic MediaWiki хоть и выглядит соблазнительно, но вплане импорта/экспорта информации с ним нужно немало разбираться.

Однако вернёмся к NoSQL. Кроме, фронтэнда, отдельно от проектов и уже давно существует бэк-офисный непубличный движок и сервис который выдаёт для ГосСети следующие API методы:

извлечение данных из веб-страниц и сайтов: изображений, ссылок, объектов, метаданных и так далее
извлечение признаков из веб-страниц: определение CMS, технологий, счетчиков и так далее
получение, парсинг и классификация данных WHOIS
валидацию через W3C Validator
извлечение метаданных из веб-страниц
поиск RSS лент (для случаев когда RSS ленты не указываются в тэгах LINK)

и ещё несколько полезных инструментов.

Это такой SWISS Knife, но построенный на общем хранилище и на общих принципах. И хранилище это работает на том самом MongoDB. Почему именно так?

Причины в самом деле просты:

1. Удобство хранения

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

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

В случае если разносить все данные по отдельным таблицам, то, во-первых их наберётся не один десяток, а во вторых строить сложные запросы по таким таблицам означает заранее закладываться на планировщик СУБД.

Это как раз решается на уровне документо-ориентированных баз данных вроде MongoDB и CouchDB.

2. Легкость изменений структур

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

3. Map/Reduce

Собственно, не упомянутое авторами — это Map/Reduce. Это одна из наиболее интересных, полезных и, в некотором смысле, удобных фишек многих NoSQL движков.

Я могу посоветовать почитать про Map/Reduce в Википедии http://en.wikipedia.org/wiki/MapReduce и добавлю что нужно это далеко не всем, а только тем кто работает со сравнительно большим объёмом данных.

Лично я использую Map/Reduce в MongoDB уже давно, просто-напросто мало времени чтобы писать о технологиях.

4. SQL != фундамент разработки

Это вообще какое-то распространённое заблуждение что _способ работы с данными_ является неотъемлимой частью процесса разработки. Я могу лишь сказать, что у тех кто так действительно думает, по всей видимости, мало опыта в использовании других технологий. Например, такие движки как Metakit, BerkeleyDB, а также объектные и XML базы данных вполне себе давно существуют и активно используются. Я знаю несколько весьма серьёзных продуктов полностью построенных на BerkeleyDB.

—

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