I think pluggable commit log is a great idea if we can do it right! 😃 *Especially* given the intent here seems to be motivated by improving endurance and performance on the given storage you're running C* on. We've actually been looking at commit log a bunch recently and doing a pretty deep dive -- even getting a low level as looking at how commit log interacts with a drive with a SATA protocol analyzer and working to understand how this actually impacts the underlying NAND and various drives GC algorithms. I totally think we should have different implementations of commit log optimized for the storage you're running on. Ideally, we would even automatically suggest the implementation that we think will work best for your hardware.
Looking forward to seeing your changes on a branch somewhere! best, kjellman On Oct 31, 2017, at 1:09 PM, 大平怜 <rei.oda...@gmail.com<mailto:rei.oda...@gmail.com>> wrote: Hello, We are developing a Cassandra plugin to store CommitLog on our low-latency Flash device (CAPI-Flash). To do that, the original CommitLog interface must be changed to allow plugins. Anyone has any thoughts about it? We have our codebase ready, but we think we should start with high-level discussion. The runtime overhead will be minimal. The only overhead will be changing method invocations to CommitLog#add(), CommitLog#getCurrentPosition(), etc. into interface invocations. Synching to CommitLog is one of the performance bottlenecks in Cassandra especially with batch commit. I think the pluggable CommitLog will allow other interesting alternatives, such as one using SPDK. Appreciate any comments. Regards, Rei Odaira
