Cassandra 提交日志说明
Cassandra commit log clarification
我已经阅读了几个关于 Cassandra 提交日志的文件，对我来说，关于这个 "structure(s)" 的信息相互矛盾。该图显示，当写入发生时，Cassandra 写入内存表和提交日志。令人困惑的部分是此提交日志所在的位置。
我反复看到的图表显示了磁盘上的提交日志。但是，如果您多读一些书，他们还会谈论内存中的提交日志缓冲区——那块内存每 10 秒刷新一次到磁盘。
DataStax 文档指出：
"When a write occurs, Cassandra stores the data in a memory structure called memtable, and to provide configurable durability, it also appends writes to the commit log buffer in memory. This buffer is flushed to disk every 10 seconds"。
他们的图中没有任何地方显示称为提交日志缓冲区的内存结构。它们只显示驻留在磁盘上的提交日志。
它还指出：
"When a write occurs, Cassandra stores the data in a structure in memory, the memtable, and also appends writes to the commit log on disk."
所以我对上面的内容感到困惑。它是写入提交日志内存缓冲区，最终刷新到磁盘（我假设也称为 "commit log"），还是写入内存表和磁盘上的提交日志？
Apache 的文档说明了这一点：
“相反，与其他现代系统一样，Cassandra 通过首先将写入附加到提交日志来提供持久性。这意味着只有提交日志需要 fsync'd，如果提交日志在其自己的卷上，则无需查找，因为commitlog 是仅附加的。实现细节在 ArchitectureCommitLog 中。
Cassandra 的默认配置将 commitlog_sync 模式设置为周期性模式，导致提交日志每 commitlog_sync_period_in_ms 毫秒同步一次，因此如果所有副本在此期间崩溃，您可能会丢失那么多数据window 的时间。"
我从 Apache 声明中推断的是，仅由于写入的异步性质（缓存写入的确认），您可能会丢失数据（它甚至声明如果所有副本在它 flushed/sync')。
我不确定我能从 DataStax 文档和图表中推断出什么，因为他们提到了关于提交日志的两种不同的陈述 - 一种在内存中，一种在磁盘上。
任何人都可以澄清我所认为的措辞不佳且相互矛盾的文档集吗？
我假设有一个提交日志缓冲区，因为它们都引用了它（但 DataStax 没有在图中显示它）。我认为如何以及何时进行管理是理解的关键。
通常在解释写入路径时，提交日志被描述为一个文件——提交日志确实是提供持久性的磁盘存储机制。在更深入的过程中引入了混乱，并且引入了有关缓冲区缓存和必须发出 fsyncs 的部分。对 "commit log buffer in memory" 的引用是在谈论 OS 缓冲区缓存，而不是 Cassandra 中的内存结构。你可以在code that there's not a separate in-memory structure for the commit log, but rather the mutation is serialized and written to a file-backed buffer.
中看到
Cassandra 提供了两种在提交日志上管理 fsync 的策略。
commitlog_sync
(Default: periodic) The method that Cassandra uses to acknowledge writes in milliseconds:
periodic: (Default: 10000 milliseconds [10 seconds])
Used with commitlog_sync_period_in_ms to control how often the commit log is synchronized to disk. Periodic syncs are acknowledged immediately.
batch: (Default: disabled)note
Used with commitlog_sync_batch_window_in_ms (Default: 2 ms) to control how long Cassandra waits for other writes before performing a sync. When using this method, writes are not acknowledged until fsynced to disk.
periodic 以略微增加数据丢失的可能性为代价提供了更好的性能。 batch 设置以延迟为代价保证持久性。
我已经阅读了几个关于 Cassandra 提交日志的文件，对我来说，关于这个 "structure(s)" 的信息相互矛盾。该图显示，当写入发生时，Cassandra 写入内存表和提交日志。令人困惑的部分是此提交日志所在的位置。
我反复看到的图表显示了磁盘上的提交日志。但是，如果您多读一些书，他们还会谈论内存中的提交日志缓冲区——那块内存每 10 秒刷新一次到磁盘。
DataStax 文档指出： "When a write occurs, Cassandra stores the data in a memory structure called memtable, and to provide configurable durability, it also appends writes to the commit log buffer in memory. This buffer is flushed to disk every 10 seconds"。
他们的图中没有任何地方显示称为提交日志缓冲区的内存结构。它们只显示驻留在磁盘上的提交日志。
它还指出： "When a write occurs, Cassandra stores the data in a structure in memory, the memtable, and also appends writes to the commit log on disk."
所以我对上面的内容感到困惑。它是写入提交日志内存缓冲区，最终刷新到磁盘（我假设也称为 "commit log"），还是写入内存表和磁盘上的提交日志？
Apache 的文档说明了这一点： “相反，与其他现代系统一样，Cassandra 通过首先将写入附加到提交日志来提供持久性。这意味着只有提交日志需要 fsync'd，如果提交日志在其自己的卷上，则无需查找，因为commitlog 是仅附加的。实现细节在 ArchitectureCommitLog 中。
Cassandra 的默认配置将 commitlog_sync 模式设置为周期性模式，导致提交日志每 commitlog_sync_period_in_ms 毫秒同步一次，因此如果所有副本在此期间崩溃，您可能会丢失那么多数据window 的时间。"
我从 Apache 声明中推断的是，仅由于写入的异步性质（缓存写入的确认），您可能会丢失数据（它甚至声明如果所有副本在它 flushed/sync')。
我不确定我能从 DataStax 文档和图表中推断出什么，因为他们提到了关于提交日志的两种不同的陈述 - 一种在内存中，一种在磁盘上。
任何人都可以澄清我所认为的措辞不佳且相互矛盾的文档集吗？
我假设有一个提交日志缓冲区，因为它们都引用了它（但 DataStax 没有在图中显示它）。我认为如何以及何时进行管理是理解的关键。
通常在解释写入路径时，提交日志被描述为一个文件——提交日志确实是提供持久性的磁盘存储机制。在更深入的过程中引入了混乱，并且引入了有关缓冲区缓存和必须发出 fsyncs 的部分。对 "commit log buffer in memory" 的引用是在谈论 OS 缓冲区缓存，而不是 Cassandra 中的内存结构。你可以在code that there's not a separate in-memory structure for the commit log, but rather the mutation is serialized and written to a file-backed buffer.
中看到Cassandra 提供了两种在提交日志上管理 fsync 的策略。
commitlog_sync
(Default: periodic) The method that Cassandra uses to acknowledge writes in milliseconds:
periodic: (Default: 10000 milliseconds [10 seconds])
Used with commitlog_sync_period_in_ms to control how often the commit log is synchronized to disk. Periodic syncs are acknowledged immediately.
batch: (Default: disabled)note
Used with commitlog_sync_batch_window_in_ms (Default: 2 ms) to control how long Cassandra waits for other writes before performing a sync. When using this method, writes are not acknowledged until fsynced to disk.
periodic 以略微增加数据丢失的可能性为代价提供了更好的性能。 batch 设置以延迟为代价保证持久性。