> > Are you for real here?Nobody will ever guarantee you these %1 numbers > ... come on. I think we are > super paranoid about performance when we are not paranoid enough about > security. This is a two way street. > People are willing to give up on performance if security is a must. >
I am for real that we should aspire to test performance (in addition to correctness) when we implement complex features that impact performance of the database. Given that the alternatives (e.g. using your cloud providers out of the box encrypted ephemeral drives) have essentially no performance penalty I think it's important to document how/if we are worse (we might not be). I don't actually think the 1% number is important, and I certainly don't think we give any kind of guarantee, I'm just trying to say that if we invest in encryption of the storage engine I hope we have clear metrics we will measure that implementation by so we can try to gauge whether it is worth doing and maintaining generally. > You do not need to use it if you do not want to, > it is not like we are going to turn it on and you have to stick with > that. Are you just saying that we are going to > protect people from using some security features because their db > might be slow? What if they just dont care? > Certainly we can add this to the list of features that Cassandra supports but few if any users can actually use due to either correctness issues (e.g. not actually secure), usability (e.g. you have to configure 4 different properties to setup the various encryption options and restart the database every week to rotate keys) or performance issues (e.g. compaction slows down by 25x). I am just saying having a bit of design (either on the ticket or the CEP) for how we might avoid that situation might help. -Joey
