High volume data series storage and queries
jeremiah.peschka at gmail.com
Tue Aug 9 11:45:30 EDT 2011
Oooh, loaded question :)
It depends on how you architect your data storage in one of the "other" tools that I mentioned. You could feasibly structure your data the same way you're structuring it in Riak: key + opaque binary value. Doing that eliminates a lot of the requirement for human intervention in schema changes.
If you're looking into scalability, there's enough on that front to write a book about, and many people have. I'll leave that as an exercise for the reader. But, no, it's not as easy as racking another server and saying "join this cluster". Depending on the solution you choose, it can be close, though.
Jeremiah Peschka - Founder, Brent Ozar PLF, LLC
Microsoft SQL Server MVP
On Aug 9, 2011, at 8:24 AM, Les Mikesell wrote:
> On 8/9/2011 10:14 AM, Jeremiah Peschka wrote:
>> Excellent points, Alex.
>> When you compare Riak's storage overhead to something like an RDBMS where you have maybe 24 bytes for row overhead (as is the case for PostgreSQL), you'll find that there's a tremendous economy of space elsewhere.
>> Riak is going to excel in applications where reads and writes will be truly random. Yes, there are Map Reduce features, but randomly organized data is still randomly organized data.
>> If you look at RDBMSes, horizontally partitioning your system through RDBMS features (SQL Server's partitioned tables, PostgreSQL's partitioned views, for example), gives you the ability to take advantage of many known quantities in that world - range queries can take advantage of sequential scan speeds across rotational disks.
> Do any of the 'other' tools that might be better at handling small or naturally-ordered bits of data match riak's ability to scale up and down or handle schema changes without a lot of human intervention?
> Les Mikesell
> lesmikesell at gmail.com
> riak-users mailing list
> riak-users at lists.basho.com
More information about the riak-users