RE: NEQ-restriction in select-where clause
Hi, You can only use IF = or IF != on insert, update or delete statements, it does not work on select. When using it, it will create a LWT transaction and you'll need full PK in the where condition, you can apply the IF on values of the row. For example: update table set type = 'somethingelse' where pk='42' if type != 'something'; -- Jacques-Henri Berthemet -Original Message- From: Dmitry Lazurkin Sent: Sunday, September 09, 2018 2:12 AM To: dev@cassandra.apache.org Subject: NEQ-restriction in select-where clause Hello. Does it make sense to implement != restriction in select-where clause? Is it possible? Thank you. PS. I want to implement that. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
RE: Apache Cassandra Blog is now live
Hi Scott, Here is the ticket: https://issues.apache.org/jira/browse/CASSANDRA-14631 Regards, -- Jacques-Henri Berthemet -Original Message- From: Scott Andreas Sent: Wednesday, August 08, 2018 6:53 PM To: dev@cassandra.apache.org Subject: Re: Apache Cassandra Blog is now live Please feel free to file a ticket (label: Documentation and Website). It looks like Jekyll, the static site generator used to build the website, has a plugin that generates Atom feeds if someone would like to work on adding one: https://github.com/jekyll/jekyll-feed From: Jacques-Henri Berthemet Sent: Wednesday, August 8, 2018 1:32:23 AM To: dev@cassandra.apache.org Subject: RE: Apache Cassandra Blog is now live It is possible to setup RSS on the blog? Should I create a Jira about that? -- Jacques-Henri Berthemet -Original Message- From: Mick Semb Wever Sent: Wednesday, August 08, 2018 8:17 AM To: dev@cassandra.apache.org Subject: Re: Apache Cassandra Blog is now live > We are also interested in contributing to the blog, what's the process? Dikang, it's part of the website, https://svn.apache.org/repos/asf/cassandra/site/src/README regards, Mick - 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: Apache Cassandra Blog is now live
It is possible to setup RSS on the blog? Should I create a Jira about that? -- Jacques-Henri Berthemet -Original Message- From: Mick Semb Wever Sent: Wednesday, August 08, 2018 8:17 AM To: dev@cassandra.apache.org Subject: Re: Apache Cassandra Blog is now live > We are also interested in contributing to the blog, what's the process? Dikang, it's part of the website, https://svn.apache.org/repos/asf/cassandra/site/src/README regards, Mick - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [VOTE] Release Apache Cassandra 3.11.3 (Take 2)
+1 From: Aleksey Yeschenko Sent: Wednesday, July 25, 2018 9:16:02 PM To: dev@cassandra.apache.org Subject: Re: [VOTE] Release Apache Cassandra 3.11.3 (Take 2) +1 — AY On 25 July 2018 at 20:14:08, Jonathan Haddad (j...@jonhaddad.com) wrote: +1 On Wed, Jul 25, 2018 at 11:35 AM Jeff Jirsa wrote: > +1 > > On Wed, Jul 25, 2018 at 12:16 AM, Michael Shuler > wrote: > > > I propose the following artifacts for release as 3.11.3. > > > > sha1: 31d5d870f9f5b56391db46ba6cdf9e0882d8a5c0 > > Git: > > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a= > > shortlog;h=refs/tags/3.11.3-tentative > > Artifacts: > > https://repository.apache.org/content/repositories/ > > orgapachecassandra-1164/org/apache/cassandra/apache-cassandra/3.11.3/ > > Staging repository: > > https://repository.apache.org/content/repositories/ > > orgapachecassandra-1164/ > > > > The Debian and RPM packages are available here: > > http://people.apache.org/~mshuler > > > > The vote will be open for 72 hours (longer if needed). > > > > [1]: CHANGES.txt: > > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a= > > blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.3-tentative > > [2]: NEWS.txt: > > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a= > > blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.3-tentative > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > -- Jon Haddad http://www.rustyrazorblade.com twitter: rustyrazorblade
RE: Debug logging enabled by default since 2.2
If debug log is not a real debug then you should rename it to something else, maybe production.log. Also, I have the impression that all logs in system.log are also contained in debug.log so it's not really useful. I feel that be moving all verbose debug logs to trace we're losing the good info in debug logs. I've been trying to troubleshoot issues from our QA and debug.log didn't really help me. From my point of view there should be a single log file, defaults to info. Debug level should contain all useful info even if it means lower performance, trace should contain all possible relevant info. If some loggers (or groups) are known to cause huge performance hits they should be disabled by default. -- Jacques-Henri Berthemet -Original Message- From: kurt greaves [mailto:k...@instaclustr.com] Sent: Monday, March 19, 2018 3:18 AM To: dev@cassandra.apache.org Subject: Re: Debug logging enabled by default since 2.2 On the same page as Michael here. We disable debug logs in production due to the performance impact. Personally I think if debug logging is necessary for users to use the software we're doing something wrong. Also in my experience, if something doesn't reproduce it will not get fixed. Debug logging helps, but I've never seen a case where an actual bug simply *doesn't* reproduce eventually, and I'm sure if this issue appears debug logging could be enabled after the fact for the relevant classes and eventually it will reoccur and we could solve the problem. I've never seen a user say no to helping debug a problem with patched jars/changes to their system (like logging). I'd much prefer we pushed that harder rather than just saying "Everyone gets debug logging!". I'm also really not sold that debug logging saves the day. To me it mostly just speeds up the identification process, it generally doesn't expose magical information that wasn't available before, you just had to think about it a bit more. In a way the real issue might be that we don’t have nightly performance > runs that would make an accidentally introduced debug statement obvious. This is an issue, but I don't think it's the *real* issue. As already noted, debug logging is for debugging, which normal users shouldn't have to think about when they are just operating the software. We shouldn't risk performance regressions just for developer convenience. On 19 March 2018 at 00:55, Ariel Weisberg <adwei...@fastmail.fm> wrote: > Hi, > > In a way the real issue might be that we don’t have nightly > performance runs that would make an accidentally introduced debug statement > obvious. > > A log statement that runs once or more per read or write should be > easy to spot. I haven’t measured the impact though. And as a bonus by > having this we can spot a variety of performance issues introduced by > all kinds of changes. > > Ariel > > > On Mar 18, 2018, at 3:46 PM, Jeff Jirsa <jji...@gmail.com> wrote: > > > > In Cassandra-10241 I said I was torn on this whole ticket, since > > most > people would end up turning it off if it had a negative impact. You said: > > > > “I'd like to emphasize that we're not talking about turning debug or > trace on for client-generated request paths. There's way too much data > generated and it's unlikely to be useful. > > What we're proposing is enabling debug logging ONLY for cluster > > state > changes like gossip and schema, and infrequent activities like repair. > “ > > > > Clearly there’s a disconnect here - we’ve turned debug logging on > > for > everything and shuffled some stuff to trace, which is a one time > action but is hard to protect against regression. In fact, just > looking at the read callback shows two instances of debug log in the > client request path (exercise for the reader to “git blame”). > > > > Either we can go clean up all the surprises that leaked through, or > > we > can turn off debug and start backing out some of the changes in 10241. > Putting stuff like compaction in the same bucket as digest mismatch > and gossip state doesn’t make life materially better for most people. > > > > > > -- > > Jeff Jirsa > > > > > >> On Mar 18, 2018, at 11:21 AM, Jonathan Ellis <jbel...@gmail.com> wrote: > >> > >> That really depends on whether you're judicious in deciding what to > >> log > at > >> debug, doesn't it? > >> > >> On Sun, Mar 18, 2018 at 12:57 PM, Michael Kjellman > >> <kjell...@apple.com> > >> wrote: > >> > >>> +1. this is how it works. > >>> > >>> your computer doesn’t run at debug logging by default. your phone > doesn’t > >>> either. neither does your smar
RE: Can API be an alternative for MBeans?
I didn't know about it, I'm now witching it, thank you! -- Jacques-Henri Berthemet -Original Message- From: Murukesh Mohanan [mailto:murukesh.moha...@gmail.com] Sent: Thursday, February 22, 2018 10:08 AM To: dev@cassandra.apache.org Subject: Re: Can API be an alternative for MBeans? You might want to keep an eye on https://issues.apache.org/jira/browse/CASSANDRA-7622 (I suspect you might already be doing so, but just in case...) On Thu, 22 Feb 2018 at 17:57 Jacques-Henri Berthemet < jacques-henri.berthe...@genesys.com> wrote: > Hi, > > What would be great would be to be able to query stats using CQL on > some "virtual" systems tables. Exposing a REST API would be another > endpoint to secure. > > -- > Jacques-Henri Berthemet > > -Original Message- > From: Nicolas Guyomar [mailto:nicolas.guyo...@gmail.com] > Sent: Thursday, February 22, 2018 9:51 AM > To: dev@cassandra.apache.org > Subject: Re: Can API be an alternative for MBeans? > > Hi, > > Jolokia 'for instance) is making exposing MBean with Http so easy > (with "just" a simple jar addition) that I think this is not really > needed within Cassandra > > > On 22 February 2018 at 09:10, Venkata Hari Krishna Nukala < > n.v.harikrishna.apa...@gmail.com> wrote: > > > Hi, > > > > I saw lots of information exposed through MBeans (like status, > > cfstats etc...). I feel exposing them like as API has few advantages > > like, it is more open (different types of clients can use) and more > > expressible for request and response. Does the option of exposing > > such functionality through API (REST) was considered at any point of time? > > Are there any advantages or compelling reasons to stick with MBeans? > > > > Thanks! > > > -- Murukesh Mohanan, Yahoo! Japan
RE: Can API be an alternative for MBeans?
Hi, What would be great would be to be able to query stats using CQL on some "virtual" systems tables. Exposing a REST API would be another endpoint to secure. -- Jacques-Henri Berthemet -Original Message- From: Nicolas Guyomar [mailto:nicolas.guyo...@gmail.com] Sent: Thursday, February 22, 2018 9:51 AM To: dev@cassandra.apache.org Subject: Re: Can API be an alternative for MBeans? Hi, Jolokia 'for instance) is making exposing MBean with Http so easy (with "just" a simple jar addition) that I think this is not really needed within Cassandra On 22 February 2018 at 09:10, Venkata Hari Krishna Nukala < n.v.harikrishna.apa...@gmail.com> wrote: > Hi, > > I saw lots of information exposed through MBeans (like status, cfstats > etc...). I feel exposing them like as API has few advantages like, it > is more open (different types of clients can use) and more expressible > for request and response. Does the option of exposing such > functionality through API (REST) was considered at any point of time? > Are there any advantages or compelling reasons to stick with MBeans? > > Thanks! >
RE: Cassandra Needs to Grow Up by Version Five!
Hi Kenneth, As a Cassandra user I value usability, but since it's a database I value consistency and performance even more. If you want usability and documentation you can use Datastax DSE, after all that's where they add value on top of Cassandra. Since Datastax actually paid dev to work Cassandra internals, it's understandable that they kept some part (usability) for their own product. We all notice that when you google for some CQL commands you'll always end up to Datastax site, it would be great if that was not the case but it would take a lot of time. Also, as a manager you're not supposed to fight with devs but to allocate tasks/time. If you have to choose between enhancing documentation and fixing this bad race condition that corrupts data, I hope you'd choose the later. As for filling Jiras, if you create one like "I want a UI to setup TLS" it would be the kind of Jira nobody would implement, it takes a lot of time, touches security and may not be that useful in the end. Last point on usability for Cassandra, as an end user it's very difficult to see the progress on it, but since I'm using Cassandra internals for my custom secondary index I can tell you that there was a huge rework between Cassandra 2.2 and 3.x, PartitionIterators are a very elegant solution and is really helpful in my case, great work guys :) -- Jacques-Henri Berthemet -Original Message- From: Kenneth Brotman [mailto:kenbrot...@yahoo.com.INVALID] Sent: Wednesday, February 21, 2018 11:54 PM To: dev@cassandra.apache.org Cc: u...@cassandra.apache.org Subject: RE: Cassandra Needs to Grow Up by Version Five! Hi Akash, I get the part about outside work which is why in replying to Jeff Jirsa I was suggesting the big companies could justify taking it on easy enough and you know actually pay the people who would be working at it so those people could have a life. The part I don't get is the aversion to usability. Isn't that what you think about when you are coding? "Am I making this thing I'm building easy to use?" If you were programming for me, we would be constantly talking about what we are building and how we can make things easier for users. If I had to fight with a developer, architect or engineer about usability all the time, they would be gone and quick. How do approach programming if you aren't trying to make things easy. Kenneth Brotman -Original Message- From: Akash Gangil [mailto:akashg1...@gmail.com] Sent: Wednesday, February 21, 2018 2:24 PM To: dev@cassandra.apache.org Cc: u...@cassandra.apache.org Subject: Re: Cassandra Needs to Grow Up by Version Five! I would second Jon in the arguments he made. Contributing outside work is draining and really requires a lot of commitment. If someone requires features around usability etc, just pay for it, period. On Wed, Feb 21, 2018 at 2:20 PM, Kenneth Brotman < kenbrot...@yahoo.com.invalid> wrote: > Jon, > > Very sorry that you don't see the value of the time I'm taking for this. > I don't have demands; I do have a stern warning and I'm right Jon. > Please be very careful not to mischaracterized my words Jon. > > You suggest I put things in JIRA's, then seem to suggest that I'd be > lucky if anyone looked at it and did anything. That's what I figured too. > > I don't appreciate the hostility. You will understand more fully in > the next post where I'm coming from. Try to keep the conversation civilized. > I'm trying or at least so you understand I think what I'm doing is > saving your gig and mine. I really like a lot of people is this group. > > I've come to a preliminary assessment on things. Soon the cloud will > clear or I'll be gone. Don't worry. I'm a very peaceful person and > like you I am driven by real important projects that I feel compelled > to work on for the good of others. I don't have time for people to > hand hold a database and I can't get stuck with my projects on the wrong > stuff. > > Kenneth Brotman > > > -Original Message- > From: Jon Haddad [mailto:jonathan.had...@gmail.com] On Behalf Of Jon > Haddad > Sent: Wednesday, February 21, 2018 12:44 PM > To: u...@cassandra.apache.org > Cc: dev@cassandra.apache.org > Subject: Re: Cassandra Needs to Grow Up by Version Five! > > Ken, > > Maybe it’s not clear how open source projects work, so let me try to > explain. There’s a bunch of us who either get paid by someone or > volunteer on our free time. The folks that get paid, (yay!) usually > take direction on what the priorities are, and work on projects that > directly affect our jobs. That means that someone needs to care > enough about the features you want to work on them, if you’re not going to do > it yourself. > > Now as others have said already, please put your list of demands in > JIRA, if someone is interest
RE: CASSANDRA-14183 review request -> logback upgrade to fix CVE
Hi, I suppose upgrading Logback breaks Cassandra because some classes are used directly like in StorageService, ThreadAwareSecurityManager and StorageServiceMBean. This was a problem in my case as we're embedding Cassandra for our functional tests, I had to stub it as it was conflicting with log4j2 configuration. Ideally Cassandra should only use pure SLF4J so that logging can be easily upgraded or changed. -- Jacques-Henri Berthemet -Original Message- From: Ariel Weisberg [mailto:ar...@weisberg.ws] Sent: Tuesday, February 13, 2018 6:28 PM To: dev@cassandra.apache.org Subject: Re: CASSANDRA-14183 review request -> logback upgrade to fix CVE Hi, So our options are: 1. Ignore it. Most people aren't using this functionality. Most people aren't and shouldn't be exposing the logging port to untrusted networks But everyone loses at defense in depth (or is it breadth) if they use this functionality and someone might expose the port 2. Remove the offending classes from the 1.1.10 jar My crazy idea, break it, but only for the people using the vulnerable functionality. Possibly no one, but probably someone. Maybe they can upgrade it manually for their usage? This also has an issue when working with maven. 3. Upgrade it Definitely going to break some apps according to Michael Shuler. Happened when he tried it. Certainly we can upgrade in trunk? While we are at it come up to the latest version. Ariel On Tue, Feb 13, 2018, at 12:03 PM, Ariel Weisberg wrote: > Hi, > > I don't think the fix is in 1.1.11 looking at the diff between 1.1.11 > and 1.2.0 > https://github.com/qos-ch/logback/compare/v_1.1.11...v_1.2.0 > .com > > I looked at 1.1.11 and 1.1.10 and didn't see it there either. > > When you say stuff broke do you mean stuff not in the dtests or utests? > > Ariel > > On Tue, Feb 13, 2018, at 11:57 AM, Michael Shuler wrote: > > I tried a logback 1.2.x jar update a number of months ago to fix the > > broken log rotation (try setting rotation to a large number - you'll > > find you only get I think it was 10 files, regardless of setting). > > > > Like we've found updating other jars in the past, this seemingly > > "simple" update broke a number of application components, so we > > rolled it back and worked out another log rotation method. > > > > Looking at the logback changelog, I cannot tell if version 1.1.11 is > > fixed for this, or if that might be less breakage? There are a > > pretty significant number of API-looking changes from 1.1.3 to > > 1.2.3, so I do not wish to break other user's applications, as I have > > experienced. > > > > I do not think this should block the current releases, unless > > someone wants to do some significant testing and user outreach for > > tentatively breaking their applications. > > > > -- > > Michael > > > > On 02/13/2018 10:48 AM, Jason Brown wrote: > > > Ariel, > > > > > > If this is a legit CVE, then we would want to patch all the > > > current versions we support - which is 2.1 and higher. > > > > > > Also, is this worth stopping the current open vote for this patch? > > > (Not in a place to look at the patch and affects to impacted branches > > > right now). > > > > > > Jason > > > > > > On Tue, Feb 13, 2018 at 08:43 Ariel Weisberg <ar...@weisberg.ws> wrote: > > > > > >> Hi, > > >> > > >> Seems like users could conceivably be using the vulnerable > > >> component. Also seems like like we need potentially need to do this as > > >> far back as 2.1? > > >> > > >> Anyone else have an opinion before I commit this? What version to > > >> start from? > > >> > > >> Ariel > > >> > > >> On Tue, Feb 13, 2018, at 5:59 AM, Thiago Veronezi wrote: > > >>> Hi dev team, > > >>> > > >>> Sorry to keep bothering you. > > >>> > > >>> This is just a friendly reminder that I would like to contribute > > >>> to this project starting with a fix for CASSANDRA-14183 > > >>> <https://issues.apache.org/jira/browse/CASSANDRA-14183>. > > >>> > > >>> []s, > > >>> Thiago. > > >>> > > >>> > > >>> > > >>> On Tue, Jan 30, 2018 at 8:05 AM, Thiago Veronezi > > >>> <thi...@veronezi.org> > > >>> wrote: > > >>> > > >>>> Hi dev team, > > >>>> > > >>>> Can one of you guys take
RE: custom validation before replication
Hi, You can't prevent the replication because if you manage to return a failure the other node will keep trying to send the data. What would be more relevant is to prevent the modification in the first place. You could try to implement a custom trigger and load it in Cassandra: http://cassandra.apache.org/doc/latest/cql/triggers.html https://github.com/apache/cassandra/tree/cassandra-3.11/examples/triggers In your trigger implementation, you'll need to validate the data and throw an exception if it does not meet your security settings. However, I don't think you'll have access to the current username/role at this level. It may be simpler for you to work with regular authentication and roles: http://cassandra.apache.org/doc/latest/cql/security.html Regards, -- Jacques-Henri Berthemet -Original Message- From: Abdelkrim Fitouri [mailto:abdou@gmail.com] Sent: jeudi 16 novembre 2017 18:31 To: dev@cassandra.apache.org Subject: custom validation before replication Hi, I have some security constraint on a project, and i need to validate or unvalidate changes made on a keyspace via cql or via an other ways before replication. for example in the case of multinode cluster with replication, if data was changed locally using cqlsh, data will be replicated (that is normal working way for cassandra) is there a possibility to call a custom validation function just before data replication ? Many thanks for any help. -- Best Regards. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
RE: CHANGES.txt
I also think all issues should be kept in CHANGES.txt, it very useful either to find what changed or to track some obscure bugs months after the release. Sometime when developing plugins for Cassandra you find solutions/resolution there. Maybe if you want to reduce the list you could provide a link to a Jira filter that lists all the fixed issues for 4.0 in the CHANGES.txt, but an offline list is always more convenient. -- Jacques-Henri Berthemet -Original Message- From: Eric Evans [mailto:john.eric.ev...@gmail.com] Sent: mardi 18 juillet 2017 07:09 To: dev@cassandra.apache.org Subject: Re: CHANGES.txt On Tue, Jul 18, 2017 at 8:10 AM, Stefan Podkowinski <s...@apache.org> wrote: > Has there been any consensus in the past about what goes into > CHANGES.txt and what not? My naive assumption was that the intended > audience for the file are users who want to know about changes between > new releases. Having that in mind, I skipped changes.txt once in a > while for updates that have no relevance except for developers. For > releases, such as 4.0, the list is already substantial and hard to > digest. I'm also wondering how informative entries such as e.g. > "Remove unused method" are for the general user. So my question is, > should we add all resolved tickets to changes.txt, or should we try to > keep the list less verbose in the future? One problem with trying to be selective, is that it invites judgment as to what is or is not worthy for inclusion, and that's bound to be a slippery slope. I also think it's not uncommon for what appears to be a trivial change for one person, to be very important to someone else. I wonder if the length of the list for 4.0 doesn't have as much to do with the delays in getting it released. -- Eric Evans john.eric.ev...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
RE: Cassandra on RocksDB experiment result
It's an interesting experiment! Did you test with more than 2 nodes? Do you expect scalability to be as linear as regular Cassandra? -- Jacques-Henri Berthemet -Original Message- From: Eric Stevens [mailto:migh...@gmail.com] Sent: jeudi 20 avril 2017 00:41 To: dev@cassandra.apache.org Subject: Re: Cassandra on RocksDB experiment result > Right now all the compaction strategies share the assumption that the data > structure and layout on disk is fixed. With pluggable storage engine, we > need to special case each compaction strategy (or at least the Abstract > class of compaction strategy) for each engine. As Ben points out, compaction should be treated as _part_ of the storage layer. The need to engage in compaction is a consequence of immutable data stores behind a mutable interface. A different storage layer might require a different approach or might not even require compaction in the same sense. On Wed, Apr 19, 2017 at 4:01 PM Ben Bromhead <b...@instaclustr.com> wrote: > This looks super cool would love to see more details. > > On a general note, a pluggable storage layer allows other storage engines > (and possibly datastores) to leverage Cassandras distributed primitives > (dynamo, gossip, paxsos?, drivers, cql etc). This could allow Cassandra to > fill similar use cases as Dynomite from Netflix. > > Also as Sankalp mentioned we get some other benefits including better > testability. > > In my experience with pluggable storage engines (in the MySQL world), the > > engine manages all storage that it "owns." The higher tiers in the > > architecture don't need to get involved unless multiple storage engines > > have to deal with compaction (or similar) issues over the entire > database, > > e.g., every storage engine has read/write access to every piece of data, > > even if that data is owned by another storage engine. > > > > I don't know enough about Cassandra internals to have an opinion as to > > whether or not the above scenario makes sense in the Cassandra context. > But > > "sharing" (processes or data) between storage engines gets pretty hairy, > > easily deadlocky (!), even in something as relatively straightforward as > > MySQL. > > > This would be an implementation detail, but given that tables in Cassandra > don't know about each other (no joins, foreign keys etc... ignore mv for > the moment), but storage engine interactions probably wouldn't be an issue. > > > > This was a long and old debate we had several times in the past. One of > > the difficulty of pluggable storage engine is that we need to manage the > > differences between the LSMT of native C* and RockDB engine for > compaction, > > repair, streaming etc... > > > > Right now all the compaction strategies share the assumption that the > data > > structure and layout on disk is fixed. With pluggable storage engine, we > > need to special case each compaction strategy (or at least the Abstract > > class of compaction strategy) for each engine. > > > > The current approach is one storage engine, many compaction strategies > for > > different use-cases (TWCS for time series, LCS for heavy update...). > > > > With pluggable storage engine, we'll have a matrix of storage engine x > > compaction strategies. > > > > Compaction is part of the storage engine, and if I understand Dikangs > design spec, it is bypassed? > > Cassandras currently storage engine is a log structured merge tree. RocksDB > does it's own thing. > > Again this is an implementation detail about where the storage engine > interface line is drawn, but from the above example compaction I think it > is a non issue? > > > > And not even mentioning the other operations to handle like streaming and > > repair. > > > > Streaming and repair would be the harder problem to solve than compaction > imho. > -- > Ben Bromhead > CTO | Instaclustr <https://www.instaclustr.com/> > +1 650 284 9692 <(650)%20284-9692> > Managed Cassandra / Spark on AWS, Azure and Softlayer >
RE: Where do I find EverywhereStrategy?
Hi James, It looks like it's a DSE class, not OSS Cassandra: https://support.datastax.com/hc/en-us/articles/208026816-DSE-EverywhereStrategy-is-not-understood-by-COSS-nodes-and-can-cause-restart-failures Regards, -- Jacques-Henri Berthemet -Original Message- From: James Carman [mailto:ja...@carmanconsulting.com] Sent: mercredi 30 novembre 2016 15:30 To: dev@cassandra.apache.org Subject: Where do I find EverywhereStrategy? I came across the class name "org.apache.cassandra.locator.EverywhereStrategy" in an error message, so I started searching through the code for it. I can't seem to find it. Any pointers? Thanks, James
RE: Cassandra Mutation object decoding
I worked on a custom PerRowSecondaryIndex to synchronize data to another system and there was no way to know the difference between an insert and an update at this level (I'm using Cassandra 2.2). The solution for me was simply to us an upsert operation in the target system. There is also the QueryHandler interface that would allow you to intercept the queries, but I found it difficult to use because you have to make you how query interpreter. However, with Cassandra 3.x the Index interface was refactored and you now have insert and update methods, you even have the old and new rows in the update! Check the SASI index implementation: https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/sasi/SASIIndex.java If I'm not mistaken the Mutation are only used with thrift and don't have the notion of insert or updates with columnFamilies. Currently CQL queries use the native protocol: https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=doc/native_protocol_v3.spec. If you want to stay at protocol level you need to check native protocol implementation and how to decode it. -- Jacques-Henri Berthemet -Original Message- From: J. D. Jordan [mailto:jeremiah.jor...@gmail.com] Sent: mercredi 23 novembre 2016 07:13 To: dev@cassandra.apache.org Subject: Re: Cassandra Mutation object decoding You may also want to look at the triggers interface. > On Nov 22, 2016, at 7:45 PM, Chris Lohfink <chris.lohf...@datastax.com> wrote: > > There are different kinds of tombstones, a partition tombstone is held in > the MutableDeletionInfo of the PartitionUpdate that you can get from > deletionInfo() method which returns the private deletionInfo field from the > holder. There are also row and cell deletions so you have to handle each of > those. It can be a little non-trivial to work backwards but all the > information is there in the Mutation (if you have full access to cfmetadata > etc), may be easier to go directly to whatever output your looking for. > > A lot of the metadata is driven from system though, you need to be either > be on a Cassandra node or rebuild them with the same cfids. In sstable-tools > <https://github.com/tolbertam/sstable-tools> we rebuild the tables from the > source cluster to parse the Mutations for replaying/viewing hints and > commitlogs. But that had to be a bit (massively) hackier since its for 3.7 > before CASSANDRA-8844 <https://issues.apache.org/jira/browse/CASSANDRA-8844>. > Its definitely possible but not easy (which is probably why it hasn't been > added in yet). > > Chris > > On Tue, Nov 22, 2016 at 6:59 PM, Sanal Vasudevan <get2sa...@gmail.com> > wrote: > >> Hi Bejamin, >> >> Nice to hear from you. >> >> My goal is to reconstruct the CQL operation from the Mutation object. >> So that I can trigger the same action on another NoSQL target like MongoDB. >> >> Please let me know know if you have ideas? >> >> Many thanks. >> Sanal >> >> >> On Tue, Nov 22, 2016 at 7:28 PM, Benjamin Lerer < >> benjamin.le...@datastax.com >>> wrote: >> >>> Hi Sanal, >>> >>> What you want to do is not an easy stuff and it might break with new >> major >>> releases. >>> >>> My question would be: why do you want to do that? There might be another >>> way to reach the same goal. >>> >>> Benjamin >>> >>> On Mon, Nov 21, 2016 at 7:14 PM, Sanal Vasudevan <get2sa...@gmail.com> >>> wrote: >>> >>>> Thank you Vladimir. >>>> Anyone else has any other ideas as to how this can be done? >>>> >>>> >>>> Many thanks, >>>> Sanal >>>> >>>> >>>> On Sun, Nov 20, 2016 at 4:46 AM, Vladimir Yudovin < >> vla...@winguzone.com> >>>> wrote: >>>> >>>>> Hi Sanal, >>>>> >>>>> >>>>> >>>>> do we have metadata inside Mutation object to decode whether the >>> CQL >>>>> was an INSERT or UPDATE operation? >>>>> >>>>> I'm not sure it's possible to distinguish them - both of them just >> add >>>>> data to SSTable. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Best regards, Vladimir Yudovin, >>>>> >>>>> Winguzone - Hosted Cloud Cassandra >>>>> Launch your cluster in minutes. >>>>> >>>>> >>>>> >>>>> >>>>> >>>&
RE: [VOTE] Release Apache Cassandra 2.2.5
+1 -- Jacques-Henri Berthemet -Original Message- From: jak...@gmail.com [mailto:jak...@gmail.com] On Behalf Of Jake Luciani Sent: mercredi 3 février 2016 14:51 To: dev@cassandra.apache.org Subject: [VOTE] Release Apache Cassandra 2.2.5 I propose the following artifacts for release as 2.2.5. sha1: dd76858c7652541c7b137323f7b9e154686d6fba Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.5-tentative Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-1099/org/apache/cassandra/apache-cassandra/2.2.5/ Staging repository: https://repository.apache.org/content/repositories/orgapachecassandra-1099/ The artifacts as well as the debian package are also available here: http://people.apache.org/~jake The vote will be open for 72 hours (longer if needed). [1]: http://goo.gl/GVE9VN (CHANGES.txt) [2]: http://goo.gl/kbrReO (NEWS.txt) [3]: https://goo.gl/QCHBW3 (DataStax Test Report)
RE: [VOTE] Release Apache Cassandra 2.2.4
+1 -- Jacques-Henri Berthemet -Original Message- From: jak...@gmail.com [mailto:jak...@gmail.com] On Behalf Of Jake Luciani Sent: mercredi 2 décembre 2015 18:27 To: dev@cassandra.apache.org Subject: [VOTE] Release Apache Cassandra 2.2.4 I propose the following artifacts for release as 2.2.4. sha1: 16045358a43656a756574cba03f51ab3db6cc2b7 Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.4-tentative Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-1091/org/apache/cassandra/apache-cassandra/2.2.4/ Staging repository: https://repository.apache.org/content/repositories/orgapachecassandra-1091/ The artifacts as well as the debian package are also available here: http://people.apache.org/~jake The vote will be open for 72 hours (longer if needed). [1]: http://goo.gl/CIJhEb (CHANGES.txt) [2]: http://goo.gl/vNzv9u (NEWS.txt)
RE: [VOTE] Release Apache Cassandra 2.2.3 (Attempt #2)
+1 -- Jacques-Henri Berthemet -Original Message- From: jak...@gmail.com [mailto:jak...@gmail.com] On Behalf Of Jake Luciani Sent: mardi 13 octobre 2015 20:59 To: dev@cassandra.apache.org Subject: [VOTE] Release Apache Cassandra 2.2.3 (Attempt #2) I propose the following artifacts for release as 2.2.3. sha1: 89596682e8c495f0c6c76e0f7a21a6db96d00552 Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.3-tentative Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-1087/org/apache/cassandra/apache-cassandra/2.2.3/ Staging repository: https://repository.apache.org/content/repositories/orgapachecassandra-1087/ The artifacts as well as the debian package are also available here: http://people.apache.org/~jake The vote will be open for 48 hours (longer if needed). [1]: http://goo.gl/dmpzjR (CHANGES.txt) [2]: http://goo.gl/ACOC01 (NEWS.txt)
RE: [VOTE] Release Apache Cassandra 2.2.3
+1 -- Jacques-Henri Berthemet -Original Message- From: jak...@gmail.com [mailto:jak...@gmail.com] On Behalf Of Jake Luciani Sent: lundi 12 octobre 2015 20:28 To: dev@cassandra.apache.org Subject: [VOTE] Release Apache Cassandra 2.2.3 I propose the following artifacts for release as 2.2.3. sha1: 0c051a46c54fd1a2f151e1a68f4556faca02be8d Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.3-tentative Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-1085/org/apache/cassandra/apache-cassandra/2.2.3/ Staging repository: https://repository.apache.org/content/repositories/orgapachecassandra-1085/ The artifacts as well as the debian package are also available here: http://people.apache.org/~jake The vote will be open for 48 hours (longer if needed). [1]: http://goo.gl/dmpzjR (CHANGES.txt) [2]: http://goo.gl/ACOC01 (NEWS.txt)
RE: Knowning which node received a search request.
I managed to have my query sent to only one node by adding below statement to the CQL query: and token(pk)=0; If I use consistency QUORUM then it is sent to a node that own the '0' token even if the node receiving the request is not the one owning 0. Now I think it may be better to use a random number instead of 0 to load balance the search requests. -- Jacques-Henri Berthemet -Original Message- From: Jacques-Henri Berthemet Sent: jeudi 27 novembre 2014 12:08 To: dev@cassandra.apache.org Subject: Knowning which node received a search request. Hi, I'm implementing a PerRowSecondaryIndex, when receiving a search request on org.apache.cassandra.db.index.SecondaryIndexSearcher impl, is there a way to know if I'm the node that received the request or if it's a replica? Currently the request is sent to all the nodes and then all results are aggregated so I have duplicates. Ideally I'd like the request to be sent only to one node, this may not be possible. So I'd like the other nodes to return nothing. In my implementation, a single node is needed to aggregate the results. Thank you, -- Jacques-Henri Berthemet
Knowning which node received a search request.
Hi, I'm implementing a PerRowSecondaryIndex, when receiving a search request on org.apache.cassandra.db.index.SecondaryIndexSearcher impl, is there a way to know if I'm the node that received the request or if it's a replica? Currently the request is sent to all the nodes and then all results are aggregated so I have duplicates. Ideally I'd like the request to be sent only to one node, this may not be possible. So I'd like the other nodes to return nothing. In my implementation, a single node is needed to aggregate the results. Thank you, -- Jacques-Henri Berthemet
RE: Retrieving clustering columns values from cell names
I found the solution, here it is if someone needs it:
CellNameType cellComparator = columnFamily.getComparator();
int clusteringPrefixSize = cellComparator.clusteringPrefixSize();
for (int prefixNb = 0; prefixNb clusteringPrefixSize; prefixNb++) {
AbstractType? subtype = cellComparator.subtype(prefixNb);
ByteBuffer clusteringKeyBytes = cell.name().get(prefixNb);
String value = subtype.getString(clusteringKeyBytes);
...
}
--
Jacques-Henri Berthemet
-Original Message-
From: Jacques-Henri Berthemet [mailto:jacques-henri.berthe...@genesys.com]
Sent: vendredi 7 novembre 2014 19:14
To: dev@cassandra.apache.org
Subject: Retrieving clustering columns values from cell names
Hi Cassandra developers,
I'm implementing a custom PerRowSecondaryIndex and I managed to extract all
data I need but clustering columns values from cell names. I know that they are
part of the cell name itself and it's easy to extract the CQL column name:
public static String cellNameToString(CFMetaData metadata, Cell cell)
throws CharacterCodingException {
if (metadata.isCQL3Table()) {
return
ByteBufferUtil.string(cell.name().cql3ColumnName(metadata).bytes);
But I don't understand how to extract the clustering column values from cell's
name. Could someone share some info about that?
Thank you,
--
Jacques-Henri Berthemet
Retrieving clustering columns values from cell names
Hi Cassandra developers,
I'm implementing a custom PerRowSecondaryIndex and I managed to extract all
data I need but clustering columns values from cell names. I know that they are
part of the cell name itself and it's easy to extract the CQL column name:
public static String cellNameToString(CFMetaData metadata, Cell cell)
throws CharacterCodingException {
if (metadata.isCQL3Table()) {
return
ByteBufferUtil.string(cell.name().cql3ColumnName(metadata).bytes);
But I don't understand how to extract the clustering column values from cell's
name. Could someone share some info about that?
Thank you,
--
Jacques-Henri Berthemet
