В чем разница между узлом, кластером и центром обработки данных в базе данных cassandra nosql?

Иерархия элементов в Cassandra:

• Cluster
  • Data center(s)
    • Rack(s)
      • Server(s)
        • Node (more accurately, a vnode)

Кластер - это набор центров обработки данных.

Дата-центр - это набор стоек.

Стойка - это набор серверов.

По умолчанию Сервер содержит 256 виртуальных узлов (или vnodes).

Vnode - это уровень хранения данных на сервере.

Примечание. Сервер - это программа Cassandra. Сервер устанавливается на машине, где машина является либо физическим сервером, либо экземпляром EC2, либо подобным.

А теперь конкретно отвечу на ваши вопросы.

Отдельная единица данных называется разделом. И да, разделы реплицируются на несколько узлов. Каждая копия раздела называется репликой.

В кластере с несколькими центрами обработки данных репликация выполняется для каждого центра обработки данных. Например, если у вас есть центр обработки данных в Сан-Франциско с именем dc-sf и другой в Нью-Йорке с именем dc-ny, вы можете контролировать количество реплик в центре обработки данных.

Например, вы можете установить dc-sf на 3 реплики и dc-ny на 2 реплики.

Эти числа называются коэффициентом репликации. Вы бы специально сказали, что dc-sf имеет коэффициент репликации 3, а dc-ny имеет коэффициент репликации 2. Проще говоря, dc-sf будет иметь 3 копии данных, распределенных по трем vnodes, в то время как dc-sf будет иметь 2 копии данных распределены по двум виртуальным узлам.

Хотя каждый сервер по умолчанию имеет 256 виртуальных узлов, Cassandra достаточно умен, чтобы выбирать виртуальные узлы, существующие на разных физических серверах.

Обобщить:

• Данные реплицируются на несколько виртуальных узлов (по умолчанию каждый сервер содержит 256 виртуальных узлов)
• Каждая копия данных называется репликой.
• Единица данных называется разделом.
• Репликация контролируется по центру обработки данных

Узел - это отдельная машина, на которой работает Cassandra. Набор узлов, содержащих похожие данные, сгруппирован в так называемое «кольцо» или кластер.

Иногда, если у вас много данных или вы обслуживаете данные в разных географических областях, имеет смысл сгруппировать узлы вашего кластера в разные центры обработки данных. Хороший вариант использования - это веб-сайт электронной коммерции, у которого может быть много постоянных клиентов на восточном и западном побережье. Таким образом, ваши клиенты на восточном побережье подключаются к вашему DC на восточном побережье (для повышения производительности), но в конечном итоге получают доступ к тому же набору данных (оба DC находятся в одном кластере), что и клиенты на западном побережье.

Более подробную информацию об этом можно найти здесь: Об Apache Cassandra - Как работает Cassandra ?

И все узлы, содержащие одинаковые (дублированные) данные, составляют центр обработки данных. Это правильно?

Близко, но не обязательно. Уровень дублирования данных определяется вашим коэффициентом репликации, который устанавливается для каждого пространства ключей. Например, предположим, что у меня есть 3 узла в моем единственном контроллере домена, каждый из которых хранит 600 ГБ данных о продукте. Мое определение products пространства ключей может выглядеть так:

CREATE KEYSPACE products
WITH replication = {'class': 'NetworkTopologyStrategy', 'MyDC': '3'};

Это обеспечит одинаковую репликацию данных о моих продуктах на все 3 узла. Размер моего общего набора данных составляет 600 ГБ, дублируется на всех 3 узлах.

Но предположим, что мы развертываем новую, довольно большую линейку продуктов, и, по моим оценкам, у нас будет еще 300 ГБ данных, что может привести к увеличению максимальной емкости наших жестких дисков. Если мы не можем позволить себе обновить все наши жесткие диски прямо сейчас, я могу изменить коэффициент репликации следующим образом:

CREATE KEYSPACE products
WITH replication = {'class': 'NetworkTopologyStrategy', 'MyDC': '2'};

Это создаст 2 копии всех наших данных и сохранит их в нашем текущем кластере из 3 узлов. Размер нашего набора данных теперь составляет 900 ГБ, но, поскольку есть только две его копии (каждый узел, по сути, отвечает за 2/3 данных), наш размер на диске по-прежнему составляет 600 ГБ. Недостатком здесь является то, что (при условии, что я читаю и пишу на уровне согласованности ONE) я могу позволить себе потерять только 1 узел. Принимая во внимание, что с 3 узлами и RF 3 (снова чтение и запись с согласованностью ONE), я мог бы потерять 2 узла и по-прежнему обслуживать запросы.

Изменить 20181128

Когда я делаю сетевой запрос, делаю ли я это против сервера? или узел? Или я делаю запрос к серверу, он затем маршрутизирует его и читает с узла или что-то еще?

Итак, очень быстрое объяснение: сервер == узел

Что касается выполнения запроса к узлам в вашем кластере, это поведение фактически диктуется драйвером на стороне приложения. Фактически, драйвер поддерживает копию текущей топологии сети, поскольку он читает слухи о кластере аналогично тому, как это делают узлы.

На стороне приложения вы можете установить политику балансировки нагрузки. В частности, класс TokenAwareLoadBalancingPolicy проверяет ключ раздела каждого запроса, выясняет, какой узел (узлы) имеет данные, и отправляет запрос прямо туда.

Для других политик балансировки нагрузки или запросов, в которых невозможно определить единственный ключ раздела, запрос будет отправлен на единственный узел. Этот узел будет действовать как «координатор». Этот выбранный узел будет обрабатывать маршрутизацию запросов к узлам, ответственным за них, а также компиляцию / возврат любых наборов результатов.

Узел:

Машина, на которой хранится некоторая часть всей вашей базы данных. Это могут быть данные, реплицированные с другого узла, а также его собственные данные. То, за какие данные он отвечает, определяется диапазоном его токенов и стратегией репликации пространства ключей, содержащего данные.

Дата центр:

Логическая группа узлов, которые можно отделить от других узлов. Типичный вариант использования - AWS-EAST против AWS-WEST. Репликация NetworkTopologyStrategy используется, чтобы указать, сколько реплик всего пространства ключей должно существовать в любом данном центре обработки данных. Вот как пользователи Cassandra добиваются кросс-DC репликации. Кроме того, это политики уровня согласованности, требующие подтверждения только только в центре обработки данных координатора (LOCAL_*)

Кластер

Общая сумма всех машин в вашей базе данных, включая все центры обработки данных. Кросс-кластерной репликации нет.

Согласно нижеприведенным документам: - https://docs.datastax.com/en/archived/cassandra/3.0/cassandra/architecture/archIntro.html

Узел, где вы храните свои данные. Это базовый компонент инфраструктуры Cassandra.

Datacenter Набор связанных узлов. Центр обработки данных может быть физическим центром обработки данных или виртуальным центром обработки данных. Различные рабочие нагрузки должны использовать отдельные центры обработки данных, физические или виртуальные. Репликация устанавливается центром обработки данных. Использование отдельных центров обработки данных предотвращает влияние на транзакции Cassandra других рабочих нагрузок и сохраняет запросы близко друг к другу для уменьшения задержки. В зависимости от фактора репликации данные могут быть записаны в несколько центров обработки данных. центры обработки данных никогда не должны охватывать физические местоположения.

Кластер Кластер содержит один или несколько центров обработки данных. Он может охватывать физические местоположения.