2017-02-17 2 views
0

В моем приложении Java, доступном для Cassandra, он может вставлять 500 rows в секунду, но обновлять только 50 rows в секунду (фактически обновленные строки не существовали).Вставка в 10 раз быстрее, чем обновление в Кассандре. Это нормально?

Обновление сто полей происходит так же быстро, как обновление одного поля.

Я просто использую CQL statements в приложении Java.

В этой ситуации нормально? Как я могу улучшить свое приложение?

public void InsertSome(List<Data> data) { 

     String insertQuery = "INSERT INTO Data (E,D,A,S,C,......) values(?,?,?,?,?,.............); "; 
     if (prepared == null) 
      prepared = getSession().prepare(insertQuery); 

     count += data.size(); 
     for (int i = 0; i < data.size(); i++) { 

      List<Object> objs = getFiledValues(data.get(i)); 
      BoundStatement bs = prepared.bind(objs.toArray()); 
      getSession().execute(bs); 
     } 
    } 

    public void UpdateOneField(Data data) { 
     String updateQuery = "UPDATE Data set C=? where E=? and D=? and A=? and S=?; "; 

     if (prepared == null) 
      prepared = getSession().prepare(updateQuery); 

     BoundStatement bs = prepared.bind(data.getC(), data.getE(), 
       data.getD(), data.getA(), data.getS()); 
     getSession().execute(bs); 

    } 

    public void UpdateOne(Data data) { 
     String updateQuery = "UPDATE Data set C=?,U=?,F........where E=? and D=? and A=? and S=? and D=?; "; 

     if (prepared == null) 
      prepared = getSession().prepare(updateQuery); 

     ...... 
     BoundStatement bs = prepared.bind(objs2.toArray()); 
     getSession().execute(bs); 

    } 

Схема:

Create Table Data (
    E, 
    D, 
    A, 
    S, 
    D, 
    C, 
    U, 
    S, 
    ... 
    PRIMARY KEY ((E 
    D), 
    A, 
    S) 
) WITH compression = { 'sstable_compression' : 'DeflateCompressor', 'chunk_length_kb' : 64 } 
    AND compaction = { 'class' : 'LeveledCompactionStrategy' }; 

Другой сценарий:

Я использовал то же самое приложение для доступа к другому Кассандры кластера. Результат был другим. UPDATE было так же быстро, как INSERT. Но это только INSERT/UPDATE 5 строк в секунду. Этот кластер cassandra - это DataStax Enterprise, работающий на GCE (я использовал DataStax Enterprise по умолчанию в Google Cloud Launcher) Так что я думаю, что, вероятно, некоторые конфигурации являются причинами. Но я не знаю, кто они.

+0

Не могли бы вы также разместить схему своего стола? – markc

ответ

-1

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

На уровне кластера Cassandra также может добиться большей масштабируемости записи, разделив пространство ключа таким образом, чтобы каждая машина отвечала только за часть ключей. Это подразумевает более высокую пропускную способность записи, так как больше записей можно делать параллельно.

2

Концептуально UPDATE и INSERT - это то же самое, поэтому я ожидаю подобную производительность. UPDATE не проверяет, существуют ли данные (если вы не делаете легкую транзакцию с IF EXISTS).

Я заметил, что каждый из ваших методов подготовит оператор, если он не является нулевым. Возможно ли, что заявление каждый раз репрезентативно? Это добавило бы для обратной линии для каждого вызова метода. Я также заметил, что InsertSome выполняет несколько вставок на вызов, где UpdateOne/UpdateOneField выполняет одно утверждение. Поэтому, если оператор был подготовлен каждый раз, это вызов для каждого обновления, где он выполняется только один раз для каждой вставки для списка.

+0

Я использовал одно и то же приложение для доступа к другому кластеру cassandra. Результат был другим. UPDATE было так же быстро, как INSERT. Но это только INSERT/UPDATE 5 строк в секунду. Этот кластер cassandra - это DataStax Enterprise, работающий на GCE (я использовал DataStax Enterprise по умолчанию в Google Cloud Launcher) – niaomingjian