Почему моя пропускная способность cassandra не улучшается при добавлении узлов?

Question

это вопрос новичка. Я пытался сделать домашнее задание, но я застрял, пытаясь узнать, как кассандра будет масштабироваться линейно, как рекламируется. Когда я бегу против одного узла кассандры, я получаю разумные ставки вставки. Вот некоторые соответствующие биты информации:

• CentOS 6,5
• Java 1.7.0_71
• Cassandra 2.1.4 двоичных загрузить
• данных и commitlog на разных дисках
• compaction_throughput_mb_per_sec: 0
• 10 000 000 вставок
• Вставка: ~ 110K вставки/с
• Еще не реализовано these settings, так как я не заинтересован в том, чтобы делать вещи быстрыми, как при наблюдении линейного масштабирования.

Мои определения ключевого пространства заключается в следующем:

create keyspace nms WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'datacenter1' : 1 }; 
use nms; 
CREATE TABLE RN(tableId int, sampleTime timestamp, sampleValue bigint, sampleStdev bigint, sampleRate bigint, tz_offset int, 
     PRIMARY KEY (tableId, sampleTime)); 

Мой соответствующий код Java выглядит следующим образом (примерно):

cluster = Cluster.builder().addContactPoint("138.42.229.240") 
       .withQueryOptions(new QueryOptions().setConsistencyLevel(ConsistencyLevel.ANY)) 
       .withRetryPolicy(DefaultRetryPolicy.INSTANCE) 
       .withLoadBalancingPolicy(new TokenAwarePolicy(new RoundRobinPolicy())) 
       .build(); 
session = cluster.connect("nms"); 
batch = new BatchStatement(); 
statement = session.prepare("INSERT INTO RN" + 
      "(tableId, sampleTime, sampleValue, sampleStdev, sampleRate, tz_offset)" + 
      "VALUES (?, ?, ?, ?, ?, ?);"); 

Я вставив 32 tableIds (ключевых разделов), каждый из «находящихся в собственности «одним потоком и уникальными образцами. Другие данные - это барахль наполнителя.

Я нашел, что сладкое пятно должно быть ~ 10 вставок в каждой партии и 10 групп вызовов executeAsync().

Пока все хорошо. Теперь добавлено 4 узла, скручивание аппаратных средств и 3 виртуальных машины, работающих на SSD SAN (не идеальное, я знаю). Я использовал подобную конфигурацию для каждого узла как то, что я описал выше, и провел мой простой тест, ожидая некоторых улучшений. Скорость ввода не изменилась. Я не могу это объяснить. Я бы ожидал некоторого улучшения. Более того, ставка остается практически неизменной с 2, 3, 4 и 5 узлами. Я понимаю, что странные числа, вероятно, не имеют никакого смысла, но я был в отчаянии.

Затем я попытался настроить пространство ключей с коэффициентом репликации равным нулю. Мои скорости передачи данных снизились до 1K вставки/с. Я не могу это объяснить. Я должен упустить что-то действительно очевидное, но я не вижу его.

Answer 1

Возможно, добавление клиентского приложения превышено, а не кластер?Мог бы попробовать использовать другую машину и запустить java-код на этом, а также посмотреть, равна ли пропускная способность или одинакова для обоих клиентов.

Answer 2

Вставьте ли вставки в свою партию не одну и ту же клавишу раздела (tableId)? Если они не вставляются в пакет с уникальным ключом раздела, он рассматривается как отдельная мутация на узле cassandra, который обрабатывает ваш запрос, и ему необходимо отправить эти мутации в ответственные реплики. По мере роста размера вашего кластера это может привести к ухудшению производительности, поскольку для завершения вашей партии необходимо связать больше реплик.

Если вы держите свои партии в одном разделе за партию или вообще не используете партии, вы должны повысить производительность с большим количеством узлов. См. 'Batch Loading without the Batch' ключевое слово в качестве хорошей справки о том, как его оптимизировать.

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

Answer 3

1) Вы можете максимизировать входной клиент, как предложил Крис.

2) Вы используете виртуальные машины на SAN, которые разделяют пропускную способность IO между всеми виртуальными машинами. По сути, вы не добавляете емкость столько, сколько распределяете нагрузку между более виртуальными репликами, использующими одни и те же ресурсы.

3) Партии обычно не предназначены для скорости, так как объединение нескольких операторов в отдельные логические операции. Вы много работаете над своим координатором, который в конечном итоге повредит масштабирование: http://docs.datastax.com/en/cql/3.1/cql/cql_using/useBatch.html