Cassandra, используемая NetFlix, eBay, Twitter, Reddit и многими другими , является одной из самых популярных на сегодняшний день баз данных NoSQL. Согласно веб-сайту , самая большая из известных установок Cassandra включает более 300 ТБ данных на более чем 400 машинах.
Cassandra предоставляет масштабируемое хранилище данных высокой доступности без единой точки отказа. Первоначально разработанный Авинашем Лакшманом (автором Amazon Dynamo) и Прашантом Маликом в Facebook для решения проблемы поиска в Inbox, код был опубликован в июле 2008 года как свободное программное обеспечение под лицензией Apache V2. Разработка продолжалась в удивительном темпе, частично благодаря вкладу IBM, Twitter и Rackspace. С февраля 2010 года Cassandra является «проектом верхнего уровня Apache».
Архитектура
Интересно, что Кассандра отказывается от широко используемой установки Master-Slave в пользу однорангового кластера. Это способствует тому, что у Cassandra нет единой точки отказа, поскольку нет главного сервера, который, столкнувшись с большим количеством запросов или при сбое, сделал бы всех своих подчиненных бесполезными. Любое количество товарных серверов может быть сгруппировано в кластер Cassandra.
Эту архитектуру гораздо сложнее реализовать за кулисами, но нам не придется с этим сталкиваться. Приятные люди, работающие над ядром Cassandra, устремляются к причудам распределенных систем (заинтересованный читатель может начать здесь , здесь или здесь , чтобы узнать больше о том, как можно реализовать такой дизайн кластера).
Отсутствие необходимости различать ведущий и ведомый узлы позволяет добавлять любое количество машин в любой кластер в любом центре обработки данных, не беспокоясь о том, какой тип машины вам нужен в данный момент. Каждый сервер принимает запросы от любого клиента. Каждый сервер равен.
Теорема CAP и настраиваемая согласованность
Возможно, самой известной особенностью распределенных систем является теорема CAP доктора Э. А. Брюера. В нем говорится, что из трех атрибутов: согласованность C , доступность и допуск P artition, любая такая система может выполнять только два за раз (возьмем это с крошкой соли ).
Не вдаваясь в подробности, RDBMS в течение многих лет фокусировалась на первых двух, согласованности и доступности, что позволяет делать такие замечательные вещи, как транзакции. Все движение NoSQL (с точки зрения 10 000 футов) в основном заключается в выборе допуска раздела вместо (сильной) согласованности. Это привело к распространенному мнению, что базы данных NoSQL совершенно непригодны для приложений, требующих именно этого. И хотя это может быть правдой для некоторых, это не для Кассандры.
Одна из выдающихся особенностей Кассандры называется «Настраиваемая согласованность». Это означает, что программист может решить, важнее ли производительность или точность на уровне каждого запроса. Для запросов на запись Cassandra будет либо реплицироваться на любой доступный (репликационный) узел, кворум узлов, либо на все узлы, даже предоставляя варианты действий для установок с несколькими центрами данных.
Для запросов на чтение вы можете указать Cassandra либо дождаться любого доступного узла (который может вернуть устаревшие данные), кворума машин (тем самым уменьшая вероятность получения устаревших данных), либо ждать каждого узла, который всегда будет возвращать последние данные и предоставляют нам нашу долгожданную, сильную последовательность.
Узнайте больше о настраиваемой согласованности здесь.
Модель данных
На первый взгляд модель данных Кассандры выглядит довольно реляционной. Имея это в виду, более глубокое погружение в ColumnFamilies, SuperColumns и тому подобное, сделает Cassandra похожей на незавершенную СУБД, в которой отсутствуют такие функции, как JOINS и большинство возможностей расширенного запроса.
Чтобы понять, почему базы данных, такие как Cassandra, HBase и BigTable (отныне я буду называть их DSS, службы распределенного хранения ), были спроектированы такими, какие они есть, сначала нам нужно понять, для чего они были созданы.
DSS были разработаны для обработки огромных объемов данных, которые хранятся в миллиардах строк в больших кластерах. Реляционные базы данных включают в себя множество вещей, которые затрудняют их эффективное распределение на нескольких машинах. DSS просто удалить некоторые или все эти связи. Не допускаются никакие операции, требующие сканирования обширных частей набора данных, то есть никаких JOINS или rich-запросов.
Есть только два способа сделать запрос, по ключу или по диапазону ключей. Причина, по которой DSS сводят свою модель данных к минимуму, заключается в том, что одну таблицу гораздо проще распределить по нескольким машинам, чем по нескольким нормализованным отношениям или графам.
Представьте, что модель ColumnFamily представляет собой (распределенную хэш-карту) с тремя измерениями. Двумерная установка состоит только из семейства ColumnFamily с несколькими столбцами в нем, «некоторые» означают пару миллиардов, если хотите. Таким образом, ColumnFamily — это просто карта столбцов.
Мне еще предстоит выяснить, почему, но кажется, что все эти термины являются просто названиями для разных измерений карты. Трехмерная «таблица» Кассандры может быть достигнута путем помещения SuperColumns в ColumnFamily, что делает ее SuperColumnFamily (пожалуйста, воздержитесь от любых криков удивления), карты карты столбцов.
В этой настройке SuperColumnFamily будет представлять самое высокое измерение, а SuperColumn будет представлять два оставшихся измерения, занимая место ColumnFamily в предыдущем примере. Эта многомерная карта содержит столбцы, триплеты, состоящие из имени, значения и отметки времени.
Хранение данных в Cassandra ориентировано на строки, что означает, что все содержимое строки сериализуется вместе на диске. Каждый ряд столбцов имеет свой уникальный ключ. Каждая строка может содержать до 2 миллиардов столбцов [²]. Кроме того, каждая строка должна соответствовать одному серверу, потому что данные разделены исключительно по ключу строки. Как обсуждено более подробно здесь , применяются некоторые другие ограничения, которые в большинстве случаев не должны касаться вас.
Кассандра подходит мне?
Cassandra в значительной степени опирается на BigTable (модель данных) и Dynamo (архитектура), две из самых известных и мощных баз данных на сегодняшний день. Одного этого может быть достаточно, чтобы рассмотреть это, но я продолжу и приведу список вопросов, которые вы можете задать себе:
1 Требуется ли исключительная производительность для больших наборов данных?
Cassandra обеспечивает фантастическую скорость записи и очень хорошую пропускную способность чтения ( опережая большинство популярных конкурентов ), сравнимую только с HBase. Выбор между ними в основном зависит от личных предпочтений. Если вам не нужен весь стек Hadoop со всеми его движущимися частями и повышенной архитектурной сложностью, выберите Cassandra, если с Hadoop все в порядке, HBase может быть лучше интегрированной подгонки. Если вы имеете дело с небольшими или средними объемами данных, реляционные решения становятся намного интереснее благодаря гибкости, которую они предоставляют.
2 Вам нужны богатые, гибкие запросы и модель данных высокого уровня?
Cassandra снижает свою модель данных до абсолютного минимума, чтобы сохранить набор данных как можно более разделенным. Это окупается, когда речь идет о линейной масштабируемости, но оставляет вас «не более», чем распределенная хэш-карта. Но не судите слишком рано, поскольку даже одна из основных технологий Google, BigTable , делает то же самое. Подобно тому, как C предоставляет программисту фантастическую производительность за счет некоторых удобных функций, таких как сборка мусора, Cassandra предоставляет вам основной элемент технологии масштаба Google, за счет самостоятельной работы с индексами или обдумывания запросов, которые вам понадобятся заранее.
3 Требуется ли прозрачность приложения?
Из-за очень низкоуровневой модели данных Cassandra приложения требуют обширных знаний о наборе данных. Если вам нужна прозрачность приложений, Cassandra не для вас.
Начиная
Если вы решили, что Кассандру стоит попробовать, я перечислю здесь несколько отправных пунктов. DataStax, компания, предоставляющая предприятиям инструменты, поддержку и решения Cassandra, предлагает выпуск для сообщества, чтобы упростить вам задачу. Пакет включает в себя умные установщики для всех основных ОС, утилиту DataStax для визуального управления настройками Cassandra и некоторые примеры приложений / баз данных.
Осторожно, однако, пакет поставляется с включенным Python, который может испортить ваш интерпретатор Python по умолчанию. В этом случае просто удалите каталог Python DataStax из переменной (PYTHON) PATH. Теперь выберите клиента (рекомендуется) или используйте Thrift , среду для независимых от языка сервисов.
С этого момента вы можете проверить этот список чтения , сразу же начать экспериментировать, следуя этому руководству, или попробовать Cassandra на примере .