Comments on Hacking Thought Blog: In love with Riak (NoSQL) design

Thanks Brume, I feel like there is this transitio...

2009-12-30T17:16:13.963-05:00

Thanks Brume,

I feel like there is this transition to a nonblocking IO web backend combined with a NoSQL document store (including mobile clients like Android). However there is a lot of dust to settle. I am not an ubercoder so I have to actually write lots of code to evaluate these new technology. It is hard to find the time especially if I need to write something like frisky to experiment with a new technique. I just hope I can share my learning by writing it down.

Thanks for keeping me thinking!
Lateef

Hey Lateef, Thanks for taking the time to clarify...

2009-12-30T16:58:47.437-05:00

Hey Lateef,

Thanks for taking the time to clarify all that. I always find your posts quite informative and I am curios to see how your choice of technology stack evolves - i.e frisky/magnum, riak, etc.

Thanks,

Brume

Brume, Sorry for not being clear I, was planning o...

2009-12-30T16:43:44.079-05:00

Brume,
Sorry for not being clear I, was planning on writing a follow up post however have not had time yet.
1. I was referring to map/reduce. There is a common complaint about map/reduce (not sure if this is just RDBMS fanboy) and I wanted to point out that I really like map/reduce. I have spent a good bit of time writing map/reduce in couchDB so I could speak from that experience. I am less excited with Riak erlang map/reduce but that is just because I have to learn erlang. CouchDB javascript map/reduce I thought was wonderful compared to writing the same queries in SQL.

2. Yes I was referring to CouchDB. I plan to write a post about this once I get enough application development experience with Riak that compares the data stores that I have extensive experience writing web applications with (Postgresql, MySQL, CouchDB and Riak). Off the top of my head the issues are:
* CouchDB size grew much faster than I expected during my testing a medium size web application with it. "Compacting" I believe is what it is called reduce this however I found this to leave a nasty taste in my mouth. Kinda like PostgreSQL before autovacuum was implemented. Sure it is great if you need it but autovacuum would have worked fine for all the web apps I have built using PostgreSQL in the last 9 years or so.
* Replication to me is disappointing. CouchDB replication forces you to do a lot of the thinking up front (some of which should be done any way) and it seemed like I would have to write a lot of replication code in my application . Compared to RDBMS systems it seem better but I was hoping for more.

Mainly I am impressed with the _design_ of Riak. The feature set like: link, scaling up and down, map/reduce and data constraints fits the niche of web applications that I am writing. From my perspective I develop on my laptop so I need the datastore to be usable and testable on a single node but also deploy to many nodes. I also need flexibility on how the data is replicated for performance and high-availability depends on the subset of application data.

I hope this helps.
Lateef.

Maybe its just me but the subject of a couple of t...

2009-12-30T13:22:19.027-05:00

Maybe its just me but the subject of a couple of the statements in this post is not clear to me. So I filled in the blanks based on what (in my opinion) appears to be mostly in support of the title.

1. "After I spent some time writing map/reduce javascript functions with CouchDB I find myself in love with it." (In love with Riak?)

2. "As much as it is a great database for doing specific types of document storage systems it had some side effects that I really didn't like." (Now you are referring to couchdb again - right i.e. couchdb had some side effects).

What by the way are those side effects you encountered?

Again it may just be me, but I thought it would help if you clarified those statements accordingly.

Thanks,

Brume.