Мне бы хотелось найти пост, похожий на этот, в котором перечислены практические проблемы проектирования модели данных с использованием Cassandra (или другой базы данных NoSQL) и соответствующие ответы для их преодоления. Не поймите неправильно то, что я говорю, есть множество хороших материалов, дающих хорошие вводные руководства ( WTF — это супер-столбец — введение в модель данных Cassandra) . Но я обнаружил, что на самом деле очень мало статей, перечисляющих препятствия, с которыми вы столкнетесь, когда начнете выполнять настоящую работу с этим зверем. Этот блог — моя попытка решить эту проблему, в надежде, что другие будут спасены от этой боли.
Наиболее важный момент, который относится ко многим людям, использующим Cassandra из реляционной базы данных, которая составляет 99,9% людей, заключается в том, что
NoSQL означает отсутствие SQL
Хотя это звучит отсталым и совершенно очевидно, это один из самых важных моментов для понимания. Я говорю это, потому что вижу, что многие люди не понимают этого и погружаются в NoSQL, надеясь, что это будет ответом на глобальное потепление.
Вставить данные в NoSQL, IMO, довольно легко, и есть множество статей, которые помогут вам это сделать. Это трудно читать. Почему это? Это потому, что нет SQL. Нет языка, который вы могли бы использовать для запроса данных, которые вы вставили. Так что, если вы похожи на меня и начали с создания случайных UUID в качестве ключей строк и задаетесь вопросом, как я собираюсь запрашивать эти данные, вы теперь предупреждены!
Давайте возьмем пример из WSO2 BAM (это кодовая база, с которой я больше всего знаком). Сервер BAM хранит события, полученные от других серверов для мониторинга. Таким образом, типичная структура данных будет выглядеть следующим образом.
Событие CF (семейство столбцов) = {«Метка времени + UUID»: {«activity_id»: «some_id», «message_body»: «<xml> some xml body </ xml>»… .. «other_event_attributes»: «Соответственно_значения»}
Итак, как мы можем использовать эти данные сейчас? Давайте посмотрим, что думает типичный парень RDBMS. Он захочет что-то вроде «Я хочу получить все сообщения, которые содержат« WTF »в теле сообщения». Итак, как мы это сделаем? Простой ответ: «Вы не можете». Теперь это отстой! Это просто базовая вещь, которую вы можете сделать в СУБД с SQL. Это правда, если это то, что вы хотели, почему вы переключили на Cassandra хранилище данных «NoSQL» (см. Это знаменитое видео по SQL против NoSQL — http://www.youtube.com/watch?v=b2F-DItXtZs ).
Так что теперь мы сожалеем о переходе на Кассандру, посмотрим, как это можно решить. Мы делаем то, что РСУБД делают в тишине. Мы используем свойство, где каждый столбец может иметь произвольное количество строк. Мы создаем семейство столбцов (CF) с именем Message_Search. Давайте использовать этот CF для хранения индекса слов в поле message_body. Например, теперь, когда мы вставляем полученное нами событие в Кассандру, мы так и поступаем.
1. Мы анализируем и вставляем событие в CF события и получаем ссылку на это конкретное событие. Пример:
{ “10:43 PM 02-Nov-2011 + abcd-3hbs-2123-sfasf” : { “activity_id” : “asfd-1212-sdfs-2124″ , message_body : “WTF do you mean Cassandra sucks ? ” }
2. Теперь мы получаем ключ строки и держим его при себе. Пусть foo = 22:43 02 ноября 2011 + abcd-3hbs-2123-sfasf
3. Теперь мы разделяем message_body по пробелам и сохраняем каждое слово как ключ строки в Message_Search. Например, «WTF» будет ключом строки, а ключи столбцов будут идентификатором события, т.е. Timestamp + UUID. (Здесь мы не будем использовать значения столбцов, поэтому оставим это поле пустым)
Message_Search Column Family = { “WTF” : { “foo”, “some_other_event_uuid” } } , { “do” : “foo”} } , { “you” : “foo”} } , { “mean” : “foo”} } , { “Cassandra” : “foo”} } , { “sucks” : “foof”} } , { “?” : { “foo”} }
ХОРОШО! Большинству из вас следует выяснить, как мы можем запросить «WTF» в поле message_body. Вот скучное объяснение ради полноты.
Теперь, когда мы получаем запрос,
1. Переходим к Message_Search CF с «WTF» в качестве ключа строки и получаем соответствующие столбцы. Мы получаем «foo» (помните foo = 10:43 PM 02-Nov-2011 + abcd-3hbs-2123-sfasf) и «some_other_event_uuid» в качестве результатов.
2. Теперь мы идем в Event CF и делаем запрос с ключами строки «foo» и «some_other_event_uuid», и мы получим события.
3. Чтобы отобразить message_body событий, мы просто получаем значение столбца ключей столбца «message_body».
Это так просто, не правда ли? Но зачем нам проходить через все эти неприятности, когда мы можем просто перейти на СУРБД. Ну, ты должен, если мог. Но для продукта, которым я руководствую, то есть WSO2 BAM, мы имеем дело с огромным количеством монтируемых данных до 100 ТБ, и нам нужна такая масштабируемость хранения больших данных, которую обеспечивает Cassandra. О, и я уже говорил, что это супер быстро. Конечно, как вы видели выше, все это имеет свою цену.
КОНЕЦ