Hi Caleb, This is exciting news !
On Tue, Aug 2, 2011 at 11:51 PM, Caleb James DeLisle <[email protected]> wrote: > I have an instance of XWiki finally running on Cassandra. > http://kk.l.to:8080/xwikiOnCassandra/ > > Cassandra is a "NoSQL" database, unlike a traditional SQL database it cannot > do advanced queries but it can store data in a more flexible way eg: each row > is like a hashtable where additional "columns" can be added at will. Do we have a clear view of what XWQL queries will/will not be supported, or is it too soon to say ? > The most important feature of Cassandra is that multiple Cassandra nodes can > be connected together into potentially very large "swarms" of nodes which > reside in different racks or even data centers continents apart, yet all of > them represent the same database. > Cassandra was developed by Facebook and their swarm was said to be over 200 > nodes strong. > In it's application with XWiki, each node can have an XWiki engine sitting on > top of it and users can be directed to the geographically closest node or to > the node which is most likely to have a cache of the page which they are > looking for. > Where a traditional cluster is a group of XWiki engines sitting atop a single > MySQL engine, this allows for a group of XWiki engines to sit atop a group of > Cassandra engines in a potentially very scalable way. > In a cloud setting, one would either buy access to a provided NoSQL store > such as Google's BigTable or they would setup a number of XWiki/Cassandra > stacks in a less managed cloud such as Rackspace's or Amazon's. > > How it works: > XWiki objects in the traditional Hibernate based storage engine are persisted > by breaking them up into properties which are then joined again when the > object is loaded. > A user object which has a name and an age will occupy a row in each of three > tables, the xwikiobjects table, the xwikistrings table, and the xwikiintegers > table. > The object's metadata will be in the xwikiobjects table while the name will > be in a row in the xwikistrings table and the age, a number, will go in the > xwikiintegers table. > The NoSQL/Datanucleus based storage engine does this differently, the same > object only occupies space in the XWikiDocument table where it takes > advantage of Cassandra's flexibility by simply adding a new column for each > property. > NOTE: this is not fully implemented yet, objects are still stored serialized. > > What works > > * Document storage > * Classes and Objects > * Attachments > * Links and Locks > * Basic querying with JDOQL > > What doesn't work > > * Querying inside of objects > * JPQL/XWQL queries > * Document history > * Permissions (requires unimplemented queries) > * The feature you want > > > I am interested in what the community thinks is the first priority, I can > work on performance which will likely lead to patches being merged into > master which will benefit everyone You mean global performance of XWiki, or something in a specific area ? FYI in case you would have missed it there was a mail by Paul Libbrecht about a possible fine tuning of Hibernate cache that could boost performance ([xwiki-devs] hibernate cache optimization?). To answer your question, as member of the community I am interested in performance of XWiki with big number of documents ; I'd say both generic performance improvements or experimental work on Cassandra fits in this line :) Jerome > or I can work on more features which will benefit people who want to use > XWiki as a traditional application wiki but use it on top of Cassandra. > You can reply here or add comments to the wiki ;) > > Caleb > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
