The main selling point of the various NoSQL products out there today isn't the schemaless storage, instead it's the ability to grow beyond a single server that's compelling. 228MB of data is nothing, it fits in RAM of any machine. What would the examples in this blog post look like if it was 228GB of data spread across 10 servers instead? How would you grow/shrink such a cluster? How would you perform a query that cu…
The main selling point of the various NoSQL products out there today isn't the schemaless storage, instead it's the ability to grow beyond a single server that's compelling. That's just not true. Some NoSQL products (HDFS, Cassandra etc) sell on the ability to easily scale out. Other (CouchDB, MongoDB etc) focus on other features. CouchDB (for example) doesn't have a real scale-out story at all (beyond "manually shar…
The key value store we ignored (Postgresql)
61–65 of 65 posts
Re: The key value store we ignored (Postgresql)
#62> ...database grew to a size of 239691780 bytes (Just 228MB) > ...gives me 14689 rows just under 360ms on average Uh, 360ms seems like an awfully long time to query such a small dataset.
Re: The key value store we ignored (Postgresql)
#63Earlier quoted context omitted.
> I think for schema-less storage systems we know 2 major competitors in market. MongoDB and CouchDB. Um, what about Riak, Cassandra, Voldemort, and Hbase? (I'm sure there's a bunch more I'm forgetting)
Cassandra, Hbase -> Column Oriented! Not schema less! Riak -> Actually a key/value store with link walking, you can just write map reduce for that document oriented feel! Again I won't bother writing a map-reduce job just to fetch out document with particular values. Voldermort -> Distributed key value. Again you are missing the point of maturity and a proven user base, and it's comparing apple with bananas! Try putt…
Re: The key value store we ignored (Postgresql)
#64Re: The key value store we ignored (Postgresql)
#65Earlier quoted context omitted.
I can sustain this claim. I work with a system implemented almost entirely in Oracle PL/SQL. Some tables in the system are nearing 800-900 columns, their size often exceeds 600 GB per table (not many of such large tables though). Querying isn't a problem at all. Large schema changes are also mostly painless. The only point at which one has to be really careful is when a schema change requires actual calculations base…
A lot of criticisms I read about the immutable limits of RDBMSes turn out, upon closer inspection, to be criticisms of MySQL. Oracle sort of sails past these limitations like a superliner: expensively and gracefully. Not that I particularly like Oracle as a programmer. I have to check my calendar every time I hit the 32-character limit for names or once again have to write some_field_expressing_truth varchar2(1); con…