Сен 08
Техническое: CouchDB и его применимость
В эти выходные мне сравнительно немного удалось поработать за компьютером, была уйма других дел, а вот краулеры и нагрузочные тесты на 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.
