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

Question

Пожалуйста, объясните мне, кто-нибудь знает, что такое Commit Log и его использование.

В Cassandra, в то время как запись на диск является журналом фиксации первой точкой входа или MemTables.

Если Memtables - это то, что сбрасывается на диск, то, что использует журнал Commit, является единственной целью журнала фиксации - это проблемы с синхронизацией сервера, если узел данных не работает?

Answer 1

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

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

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

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

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

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

Answer 2

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

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

Memtable и CommitLog являются НЕ письменного (вид) параллельно. Запись в 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, чтобы иметь возможность воссоздать memtable после узла аварий или получает перезагружается. Это важно, так как memtable только сбрасывается на диск, когда он «заполнен» - это означает, что настроенный размер memtable исключен - или сброс выполняется с помощью nodetool или opscenter. Таким образом, данные в memtable не сохраняются напрямую.

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