Базы данных NoSQL можно разделить на категории KV, Document, Columnar и Graph. Я пытался выяснить, какой NoSQL использовать для другого сценария, прочитал пару блогов/статей и все еще запутался.
Допустим, я хочу сохранить данные о сотруднике. Его можно хранить в столбцовой БД, такой как HBase, и в БД документов, такой как Mongo. Итак, каков сценарий для Columnar vs Document? Я предполагаю, что на основе шаблона запроса должна быть выбрана соответствующая база данных.
Как упоминал Райан, шаблоны доступа к данным во многом связаны с этим. Поскольку Райан освещал сторону MongoDB (о которой я мало что знаю), я попытаюсь рассказать о стороне Hbase.
Для начала я предлагаю вам прочитать Бумага BigTable, поскольку ее дизайн сильно повлиял на Hbase. В этом видео также есть хорошие подробности об элементах дизайна Hbase. Также, если вас больше интересует Zookeeper, попробуйте прочитать Cubby Paper тоже.
На что следует обратить внимание при выборе Hbase:
Индексация строк: способ «индексирования» строк в Hbase (или Cassandra с использованием упорядоченного разделителя) это благословение и проклятие. Я считаю, что mongoDb использует B+Tree (поправьте меня, если я ошибаюсь), где Hbase просто хранит строки по порядку. Этот подход хорош для задач уменьшения карты и последовательного чтения. Для заданий уменьшения карты это означает локальность данных по отношению к региональным серверам, на которых выполняются задания. Это помогает последовательному чтению, позволяя контроллерам диска читать последовательные сектора на диске, выполняя «сканирование» ключей. Проклятие заключается в том, что данные хранятся в порядке... Поэтому, если вы плохо спроектируете свои строки, в конечном итоге вы получите «горячие» узлы. Например, если вы просто использовали временную метку в качестве ключа строки, вы можете получить один узел, который будет выполнять все операции записи, а другие ваши узлы будут бездействовать. Итак, проектирование ключей строк в Hbase очень важно. В этом видео об OpenTSDB подробно рассказывается о том, как они используют HBase.
Еще одним преимуществом столбцовых баз данных является то, что они могут использовать сжатие столбцов вместо сжатия строк. Обычно энтропия столбца намного ниже, чем энтропия строки. Таким образом, это делает сжатие более эффективным. Например, если в ваших столбцах хранятся пользовательские агенты, URL-адреса, ключевые слова и т. д., они будут очень хорошо сжиматься.
Пример решения Hbase. Предположим, вы хотите создать решение для отслеживания данных о посетителях на вашем сайте электронной коммерции с требованием поддерживать сводные данные по любому диапазону дат. Поскольку Hbase последовательно хранит ключи на диске, если ваши ключи хорошо спроектированы, Hbase может повысить производительность при последовательном сканировании в реальном времени.
Для этого примера предположим, что мы храним множество метрик о посетителях со следующей ключевой схемой ( {product-category}.{sub-category}.{metric}.{timestamp-rounded-the-minute} ). Например: при посещении одной страницы могут записываться следующие ключи: shoes.running.search-terms.1362818100, shoes.running.user-agents.1362818100, shoes.running.visitors-country.1362818100,... SideNote: все эти ключи в основном последовательные и, скорее всего, будут записаны на сервер одного региона, и вы можете захотеть, чтобы эти записи были распределены более чем на одну машину. Одним из решений может быть замена части ключа {product-category}.{sub-category} на HashOf({product-category}.{sub-category}). Или использовать поиск ключей, как это делает OpenTSDB.
Таким образом, с этим ключевым дизайном становится быстро выполнять специальный запрос этих показателей в реальном времени. Например, чтобы запросить все поисковые термины, использованные между 1331666259 (вт, 13 марта 2012 г.) и 1334344659 (пт, 13 апреля 2012 г.), вы должны выполнить сканирование для (shoes.running.search-terms.1331666259< /em> в shoes.running.search-terms.1334344659)
РЕДАКТИРОВАТЬ: я исправил пару опечаток
Я рискну ответить. У меня есть приличный опыт работы с документами и Mongo, но у меня нет опыта работы с базами данных столбцов.
Глубина и плоскость
Мое первое предположение состояло в том, что документы могут иметь вложенные вложенные документы и что, возможно, столбцовые базы данных являются строго плоскими записями.
Но после прочтения этого: http://wiki.apache.org/cassandra/DataModel кажется, что некоторые столбцовые базы данных также могут иметь глубину для записей.
На самом деле, если вы прочтете эту страницу о Cassandra, вы увидите, что они часто представляют концептуальную запись в виде JSON. Так что в этом смысле кажется, что нет никакой разницы между моделированием данных — по крайней мере, с концептуальной точки зрения.
Гомогенный и гетерогенный
Другая большая потенциальная разница заключается в гомогенных и гетерогенных моделях данных в одной коллекции/таблице.
Mongo позволяет хранить документы с разными схемами в одной и той же коллекции в базе данных.
Насколько я могу судить для HBase, каждая строка должна иметь одну и ту же схему таблицы. В разделе «Семейства столбцов» (http://wiki.apache.org/hadoop/Hbase/DataModel):
«Семейства являются частью схемы таблицы и остаются одинаковыми для каждой строки; что отличается от строк к строкам, так это то, что ключи столбцов могут быть очень разреженными».
Может быть, кто-нибудь поправит меня, если я ошибаюсь насчет HBase.
