Making CommitLog pluggable
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
Re: Making CommitLog pluggable
Hi, There are pluggable elements to the commit log such as those used to support mmap or compressed. Can you describe at a high level what a new implementation would look like and why it can't be a mode of the existing implementation? You are not proposing changing the format correct? Regards, Ariel On Tue, Oct 31, 2017, at 04:09 PM, 大平怜 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 - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Making CommitLog pluggable
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, 大平怜 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
Re: Making CommitLog pluggable
P.S. I am excited to hear about what new hardware can do in this area compared to existing non-volatile write caches. On Tue, Oct 31, 2017, at 04:38 PM, Ariel Weisberg wrote: > Hi, > > There are pluggable elements to the commit log such as those used to > support mmap or compressed. > > Can you describe at a high level what a new implementation would look > like and why it can't be a mode of the existing implementation? > > You are not proposing changing the format correct? > > Regards, > Ariel > > On Tue, Oct 31, 2017, at 04:09 PM, 大平怜 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 > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Somewhat Weekly Cassandra Dev Wrapup
It's usually pretty clear what is a fix in the changes log but they definitely require checking. However I'd say putting more boilerplate in the changes log isn't really necessary and would be hard to enforce. If we could generate a report with this information from JIRA with desired information would be better (e.g all ticket names, type, maybe even labels). I'd hope JIRA has this functionality...
Re: Somewhat Weekly Cassandra Dev Wrapup
On 10/31/2017 07:17 PM, kurt greaves wrote: > It's usually pretty clear what is a fix in the changes log but they > definitely require checking. However I'd say putting more boilerplate in > the changes log isn't really necessary and would be hard to enforce. If we > could generate a report with this information from JIRA with desired > information would be better (e.g all ticket names, type, maybe even > labels). I'd hope JIRA has this functionality... > It does have release notes that is split up by issue type: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310865&version=12336842 -- Michael - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Somewhat Weekly Cassandra Dev Wrapup
Looks like that solves that problem. Probably wouldn't be a bad idea to include that list in the release posts as well as link to changes.txt? At the very least it will make us a bit more careful about assigning fix versions (maybe). On 1 November 2017 at 00:36, Michael Shuler wrote: > On 10/31/2017 07:17 PM, kurt greaves wrote: > > It's usually pretty clear what is a fix in the changes log but they > > definitely require checking. However I'd say putting more boilerplate in > > the changes log isn't really necessary and would be hard to enforce. If > we > > could generate a report with this information from JIRA with desired > > information would be better (e.g all ticket names, type, maybe even > > labels). I'd hope JIRA has this functionality... > > > > It does have release notes that is split up by issue type: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa? > projectId=12310865&version=12336842 > > -- > Michael > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: Somewhat Weekly Cassandra Dev Wrapup
On the hashCode violations they are all on https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/dht/Range.java which does seem to get the correct hashcode impl from https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/dht/AbstractBounds.java Jeff On Tue, Oct 31, 2017 at 7:42 PM kurt greaves wrote: > Looks like that solves that problem. Probably wouldn't be a bad idea to > include that list in the release posts as well as link to changes.txt? At > the very least it will make us a bit more careful about assigning fix > versions (maybe). > > On 1 November 2017 at 00:36, Michael Shuler > wrote: > > > On 10/31/2017 07:17 PM, kurt greaves wrote: > > > It's usually pretty clear what is a fix in the changes log but they > > > definitely require checking. However I'd say putting more boilerplate > in > > > the changes log isn't really necessary and would be hard to enforce. If > > we > > > could generate a report with this information from JIRA with desired > > > information would be better (e.g all ticket names, type, maybe even > > > labels). I'd hope JIRA has this functionality... > > > > > > > It does have release notes that is split up by issue type: > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa? > > projectId=12310865&version=12336842 > > > > -- > > Michael > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >
