За пару дней на мой небольшой домашний сервер удалось собрать информацию по доменам в зоне SU, корневые страницы, данные whois и так далее и теперь могу говорить о [...]]]> В эти выходные мне сравнительно немного удалось поработать за компьютером, была уйма других дел, а вот краулеры и нагрузочные тесты на CouchDb как раз смогли отработать полностью.

За пару дней на мой небольшой домашний сервер удалось собрать информацию по доменам в зоне SU, корневые страницы, данные whois и так далее и теперь могу говорить о CouchDb с большей однозначностью.

Основное, пожалуй, то что движок позволяет делать очень быстрые запросы на добавление и получение отдельных документов по ключу. Для систем со стратегией работы с данными по CRD (Create, Read, Delete) движок весьма удобен, например, у него есть хороший потенциал в качестве использования как хранилища логов. А вот для CRUD в классическом понимании будут свои особенности, в частности то как CouchDb работает с версиями будет отрицательно сказываться на объёмах хранимых данных.

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

Открытый вопрос тут в том какую стратегию использовать при хранении документов с версиями — использовать ли механизм ревизий CouchDb или нет. Вариант — это, например, изменение логики движка с возможностью указания постоянства хранения (флаг persist) для новый версий в тех случаях когда есть желание не потерять их при последующих запусках compact.

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

А вот хранение метаданных обеспечивается очень удобно — за счёт того что всё в JSON можно использовать любые иерархии вложенных объектов, а также их списки. Например, это позволяет хранить ссылки в распакованном формате — с разделёнными префиксами и суффиксами доменов, элементов пути, параметров и так далее. Точно также HTTP заголовки можно хранить не отдельной SQL таблицей, а в виде перечня объектов (структур) вложенных в описание выгруженной страницы и, несмотря на то что можно реализовать схожее на SQL, тем не менее подобный механизм хранения вложенных структур очень удобен. При семантическом/онтологическом связывании данных — то чем я занимаюсь, это особенно важно, так как иной раз на один объект может приходится до десятка меток и хранение их в отдельной SQL таблице убивает производительность.

Точно также удобно использование механизма View — которые являются аналогом «материализованных вью» в SQL базах данных, с той лишь разницей что могут формироваться двумя функциями map/reduce и обслуживаться внешними серверами. Последнее особенно интересно и хотя я механизм ViewServer ещё не пробовал, но возможностей у его использования множество. К примеру, ViewServer с использованием реплик данных может позволить решить проблемы долгого выполнения запросов.

В совокупности как дешёвая и удобная альтернатива HBase продукт очень интересен, я скорее всего большую часть своих исследовательских проектов — выявление новостей (Скиур), геотаггинг, выявление SEO-ссылок, Социоранк буду переводить на CouchDB.