11–20 of 21 posts
The code looks great. The mapping features seem strong (thanks in part to the power of ActiveModel). However, by restricting the adapter interface to a simple key/value store, don't you lose access to many of the features that make each backend distinct?
I think Redis, Cassandra, MongoDB, etc. are great, but to me it't the differences amongst them which are interesting, not the similarities.
if you need a ORM for key/value storage, you're doing it (very) wrong
Anyways, I'll definitely check it out. Maybe I'm missing something.
I'm not sure I quite get this. The code looks great. The mapping features seem strong (thanks in part to the power of ActiveModel). However, by restricting the adapter interface to a simple key/value store, don't you lose access to many of the features that make each backend distinct? I think Redis, Cassandra, MongoDB, etc. are great, but to me it't the differences amongst them which are interesting, not the similari…
http://railstips.org/blog/archives/2011/01/27/data-modeling-...
So John in the above link was talking about how when you scale, you end up looking at bottlenecks, which are usually slow data accesses, and moving them into some sort of key-value store--that usually are based on a key-value access pattern. So by the time you're well into scaling your app, you noticed that much of your data access has turned into limiting yourself to doing key lookups to attain the performance you need.
Since (according to his experiences scaling) most of the performance bottlenecks seem to have this pattern, he asked, "what if you restricted your data access to just using key-value pairs from the very beginning?" That way you avoid some of the data access headaches later on. In answering that question, this is what they got.
[deleted]
DictShield: https://github.com/j2labs/dictshield
if you need a ORM for key/value storage, you're doing it (very) wrong
if you need a ORM for key/value storage, you're doing it (very) wrong
Exactly. I'm not sure why this is necessary. If you want to store rich objects, just serialize them and create your indexes as necessary. Anyways, I'll definitely check it out. Maybe I'm missing something.
At a certain point, servers are only so fast and disks only so large and fast.
And it's ActiveModel-based! Hallelujah! For those not of a rails persuasion, ActiveModel is basically all the non-datastore stuff abstracted out from ActiveRecord, rails' ORM. So, this Toy Store lib will share all its validation, accessor etc. apis with ActiveRecord and so will already automatically be compatible with the huge range of rails libraries out there. A good example is simple_form, a rails gem for doing lo…
I'm not sure I quite get this. The code looks great. The mapping features seem strong (thanks in part to the power of ActiveModel). However, by restricting the adapter interface to a simple key/value store, don't you lose access to many of the features that make each backend distinct? I think Redis, Cassandra, MongoDB, etc. are great, but to me it't the differences amongst them which are interesting, not the similari…
New does travel quick. I was just reading about this thing this morning. http://railstips.org/blog/archives/2011/01/27/data-modeling-... So John in the above link was talking about how when you scale, you end up looking at bottlenecks, which are usually slow data accesses, and moving them into some sort of key-value store--that usually are based on a key-value access pattern. So by the time you're well into scaling y…
By forcing yourself into this tactic you end up having to consider all the scaling complexity in the prototyping stage before your app has even proven itself potentially successful. If your app becomes wildly popular then the combination of your early work and Google's behind the scene scaling means there are far less problems for you to worry about.
My major concern with this method is that people already focus far too much on premature optimizations before they even know where the real bottlenecks are in their application. If premature optimization leads to burn out or less features then it's a poison to our projects and should be avoided.
[1] http://code.google.com/appengine/articles/scaling/overview.h...