On Mon, May 9, 2011 at 5:04 PM, Paul J Stevens <[email protected]> wrote: > I really don't want to go into any kind of debate about (no)sql. But I > guess there's really no way around it in the end. From my point of view; > I know rdbms has a poor rep with regards to scaling out on blob storage. > Indexing is non-standard (fti), storage is sometimes poorly optimized, > and yes: better solutions exist to both problems (solr/lucene type > engines for indexing, and document-stores such as mongodb and couchdb - > or even plain file-systems for scalable blobstores). But like Harry > correctly pointed out, these rdbms' weaknesses are actively being > addressed - and sometimes even overstated.
In all honesty, I agree - the RDBMS' are working to improve performance in these areas. I don't subscribe to the NoSQL cult as much as others. I guess a lot of it in the end comes down to personal experiences, and what your scale out strategy looks like. For us, our scaling strategy consists of us being able to add in inexpensive storage nodes (backed by whatever - NFS, GlusterFS, Mongo, etc) rather than big beefy databases servers with SAS/SSD disks which we use for relational computation. A personal goal of mine is to get to the point where we don't need to worry about these "island" type setups with different users being allocated to different servers. > Having a plug-able architecture for blob-storage is definitely a boon. > Whether that entails openstack/s3/nfs or whatever is less interesting. > The _hard_ part is defining a complete interface, and implementing that > interface in a correct manner. > > Storage and indexing are absolutely orthogonal and should not be mixed > in any new implementations. > > Correct. I probably could have been clearer about that. You bought up indexing with me on the developers list, and I hadn't even considered it when I first started talking storage. Right now, I think it's more important than storage backends, as after bodies have been shifted out to an alternate backend they still need to somehow be searchable. As you mentioned, the interfaces for these kind of things need to be done right. I want your (and everyone else who's familiar with the internals) feedback on my proposed changes before I move forward with anything - you can expect to see that within the next few weeks once I have the opportunity to wrap up the proposal.
_______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
