Re: Multi-tenancy, and authentication and authorization
Have a read about JVM heap sizing here http://wiki.apache.org/cassandra/MemtableThresholds If you let people create keyspaces with a mouse click you will soon run out of memory. I use Cassandra to provide a self service "storage service" at my organisation. All virtual databases operate in the same Cassandra keyspace (which does not change), and I use namespaces in the keys to separate things. Take a look at how amazon S3 works, it may give you some ideas. If you want to continue to discussion let's move this to the user list. A On 17/01/2011, at 7:44 PM, indika kumara wrote: > Hi Stu, > > In our app, we would like to offer cassandra 'as-is' to tenants. It that > case, each tenant should be able to create Keyspaces as needed. Based on the > authorization, I expect to implement it. In my view, the implementation > options are as follows. > > 1) The name of a keyspace would be 'the actual keyspace name' + 'tenant ID' > > 2) The name of a keyspace would not be changed, but the name of a column > family would be the 'the actual column family name' + 'tenant ID'. It is > needed to keep a separate mapping for keyspace vs tenants. > > 3) The name of a keypace or a column family would not be changed, but the > name of a column would be 'the actual column name' + 'tenant ID'. It is > needed to keep separate mappings for keyspace vs tenants and column family > vs tenants > > Could you please give your opinions on the above three options? if there > are any issue regarding above approaches and if those issues can be solved, > I would love to contribute on that. > > Thanks, > > Indika > > > On Fri, Jan 7, 2011 at 11:22 AM, Stu Hood wrote: > >>> (1) has the problem of multiple memtables (a large amount just isn't >> viable >> There are some very straightforward solutions to this particular problem: I >> wouldn't rule out running with a very large number of >> keyspace/columnfamilies given some minor changes. >> >> As Brandon said, some of the folks that were working on multi-tenancy for >> Cassandra are no longer focused on it. But the code that was generated >> during our efforts is very much available, and is unlikely to have gone >> stale. Would love to talk about this with you. >> >> Thanks, >> Stu >> >> On Thu, Jan 6, 2011 at 8:08 PM, indika kumara >> wrote: >> >>> Thank you very much Brandon! >>> >>> On Fri, Jan 7, 2011 at 12:40 AM, Brandon Williams >>> wrote: >>> On Thu, Jan 6, 2011 at 12:33 PM, indika kumara wrote: > Hi Brandon, > > I would like you feedback on my two ideas for implementing mufti >>> tenancy > with the existing implementation. Would those be possible to >>> implement? > > Thanks, > > Indika > >> Two vague ideas: (1) qualified keyspaces (by the tenet domain) >>> (2) > multiple Cassandra storage configurations in a single node (one per > tenant). > For both options, the resource hierarchy would be /cassandra/ > //keyspaces// > (1) has the problem of multiple memtables (a large amount just isn't >>> viable right now.) (2) more or less has the same problem, but in JVM >> instances. I would suggest a) not trying to offer cassandra itself, and instead >>> build a service that uses cassandra under the hood, and b) splitting up tenants >>> in this layer. -Brandon >>> >>
Replacing ivy with maven-ant-tasks
Is this something that people are OK with? It will result in the version details being specified from the build.xml and not a separate ivy.xml Which branch shall I target first... My preference is to target 0.7 and then when the modularization takes place in trunk/0.8 it will be on top of the maven-ant-tasks changes. If everyone is OK I'll create a JIRA against Core with fixVersion 0.7 and add my patch there. -Stephen
Re: Replacing ivy with maven-ant-tasks
On Tue, 2011-01-18 at 13:13 +, Stephen Connolly wrote: > Is this something that people are OK with? Why? What are the advantages? -- Eric Evans eev...@rackspace.com
Re: Replacing ivy with maven-ant-tasks
On 18 January 2011 14:30, Eric Evans wrote: > On Tue, 2011-01-18 at 13:13 +, Stephen Connolly wrote: >> Is this something that people are OK with? > > Why? What are the advantages? 1. It will make deploying to central easier (as ivy does not deploy correct poms, and maven-ant-tasks can generate correct poms) 2. _You_ seemed to think it would be better keeping all the version information in build.xml rather than in a separate file 3. You seemed to think it might be a good idea when you saw the mavebn-ant-tasks stuff for deploying to central There's probably some more but those are the main drivers from my perspective. Note Maven-Ant-Tasks is not Maven... it provides essentially the same functionality as ivy only targetted exclusively at Maven repositories... (which are the only really repository format (other than p2) to take off) -Stephen
Re: Avro in the Cassandra core
On Jan 17, 2011, at 9:01 PM, Eric Evans wrote: > On Mon, 2011-01-17 at 12:12 -0500, Jake Luciani wrote: >> Some context: We have begun the process of removing Avro from the >> service layer CASSANDRA-926. We currently use Avro for schema >> migrations internally, and we have two open items that are using Avro >> for our internal file storage. CASSANDRA-1472 and CASSANDRA-674. > > FWIW, this should be done (removing the RPC interface). Anything missed > is deserving of a bug report > >> My opinion is we need to control the lowest layers of the code and not >> rely on a third party library. By using a third party library like >> Avro, it becomes a black box that we need to deeply understand and >> work around. Also, since Avro is developed separately we have another >> core dependency that could disrupt releases (say a bug in Avro). > > +1 > > The Avro RPC interface was an experiment, and it was always the case > that if it didn't supplant the Thrift interface as status quo, that it'd > be removed. However, as I remember it, part of the justification for > using it in migrations was that it was already there. In hindsight that > was probably a mistake. > > Anyway, we have too many dependencies as it is, I'd rather move toward > eliminating it entirely unless there is a very compelling reason not to > (I don't think there is). Just saw Stu's comment on CASSANDRA-1472: "I think that implementing a compressible block based file format is a non-trivial task, and that before we commit to re-implementing Avro's (in a bounded timeframe especially), we should review our requirements. This decision needs to be made for technical reasons and not grounded in NIH." Is that a compelling reason to use avro for some of the internals or is that something that someone is willing to implement/maintain? Just trying to bridge discussion here with comments on the ticket. > > -- > Eric Evans > eev...@rackspace.com >
Re: Proposal: fixed release schedule
On Fri, 2011-01-14 at 13:11 -0600, Eric Evans wrote: > > Everyone on chrome commits to trunk first. I think the important > > change we could make is to keep everyone closer to trunk. We spend a > > good deal of effort back-porting patches between major versions. I > > think we should make the major versions less different. This would > > mean letting them live for shorter amounts of time and possibly > > making them bugfix only. Currently we add new features in stable > > branches, but I think if we made the major release schedule more > > predictable people would be more comfortable with letting their new > > feature wait until the next major version. > > I'll call your keep-close-to-trunk, and raise you a: > > * branch as soon as all planned features land in trunk > * iteratively release betas w/ bug-fixes only > * release candidates are actual candidates for the final (not > releases) > > The time between creating the branch and making the release should be > as short as practical, and there should be no backward incompatible > changes between the first beta, and final release. The discussion seems to be petering out and I wonder if that means folks are still trying to wrap their heads around everything, or if we have consensus. If we're in agreement on 4 months between releases, and feature-freezing branches in the run-up, then that would leave us with say 7 weeks (give or take) to land everything in trunk that we expect in the next release (and I would think that at this point we'd at least have a good idea what that'd be). -- Eric Evans eev...@rackspace.com
