Какова цель журнала регистрации Cassandra?

Ответ 1

Вы можете рассматривать журнал фиксации как оптимизацию, но Cassandra будет безжизненно замедляться без него. Когда MemTables записываются на диск, мы называем их SSTables. SSTables являются неизменяемыми, то есть когда Cassandra записывает их на диск, он не обновляет их. Поэтому, когда столбец изменяется, Cassandra нужно написать новый SSTable на диск. Если бы Cassandra записывала эти SSTables при каждом обновлении, она была бы полностью привязана к IO и очень медленной.

Итак, Cassandra использует несколько трюков для повышения производительности. Вместо того, чтобы записывать SSTables на диск при каждом обновлении столбцов, он сохраняет обновления в памяти и периодически меняет эти изменения на диск, чтобы поддерживать IO на разумном уровне. Но это приводит к очевидной проблеме: если машина опустится или Cassandra выйдет из строя, вы потеряете данные на этом node. Чтобы избежать потери данных, в дополнение к сохранению последних изменений в памяти, Cassandra записывает изменения в свой CommitLog.

Возможно, вы спрашиваете, почему писать в CommitLog лучше, чем просто писать SSTables. CommitLog оптимизирован для записи. В отличие от SSTables, которые хранят строки в отсортированном порядке, CommitLog хранит обновления в том порядке, в котором они были обработаны Cassandra. CommitLog также сохраняет изменения для всех семейств столбцов в одном файле, поэтому на диске не нужно делать кучу запросов, когда он получает обновления для нескольких семейств столбцов одновременно.

В принципе, это лучше, потому что он должен писать меньше данных, чем писать SSTables, и записывает все эти данные в одно место на диске.

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

Когда Cassandra запускается, он должен прочитать журнал фиксации с этого последнего известного момента времени (точка, в которой мы знаем, что все предыдущие записи были записаны в SSTable). Он повторно применяет изменения в журнале фиксации к своим MemTables, чтобы он мог попасть в одно и то же состояние, когда он остановился. Этот процесс может быть медленным, поэтому, если вы останавливаете Cassandra node для обслуживания, рекомендуется использовать nodetool drain, прежде чем отключать его, что будет сбрасывать все в MemTables на SSTables и значительно увеличить объем работы при запуске меньше.

Ответ 2

Путь записи в cassandra работает следующим образом:

Cassandra Node ---->Commitlog-----------------> Memtable
                         |                       |
                         |                       |
                         |---> Periodically      |---> Periodically
                              sync to  disk          flush to SSTable

Memtable и CommitLog - это NOT, написанные (вид) параллельно. Запись в CommitLog должна быть завершена до начала записи в Memtable. Связанный стек исходного кода:

org.apache.cassandra.service.StorageProxy.mutateMV:mutation.apply->
org.apache.cassandra.db.Mutation.apply:Keyspace.open(keyspaceName).apply->
org.apache.cassandra.db.Keyspace.apply->
org.apache.cassandra.db.Keyspace.applyInternal{
    Tracing.trace("Appending to commitlog");
    commitLogPosition = CommitLog.instance.add(mutation)
    ...
    Tracing.trace("Adding to {} memtable",...
    ...
    upd.metadata().name(...);
    ...
    cfs.apply(...);
    ...
}

Цель commitlog состоит в том, чтобы иметь возможность воссоздать память после того, как node сработает или перезагрузится. Это важно, так как memtable только сбрасывается на диск, когда он "заполнен" - это означает, что настроенный размер memtable исключен - или сброс выполняется с помощью nodetool или opscenter. Таким образом, данные в memtable не сохраняются напрямую.

Сказав это, хорошая вещь перед перезагрузкой node заключается в вызове "nodetool flush", чтобы убедиться, что ваш memtable сохранен. Это также уменьшит время воспроизведения блока фиксации после появления node.