ALL COVERED TOPICS

NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter

NAVIGATE MAIN CATEGORIES

Close

Top 10 Reasons to Get More Information about SimpleDB

I am not really sure where ☞ this old article popped up from, but I think it is somehow good that others are ☞ still reacting and showing how wrong it can be:

1. Data integrity is not guaranteed

There are two and a half points I’d like to make. First, constraints are usually the first to go because they’re costly. Costly to implement and costly at runtime. Especially when the system is being designed with the ability to run on multiple machines. […]

3. Aggregate operations will require more coding.

If Ryan really wanted to make an argument about aggregates, the best thing would be to go on about how a non-RDBMS requires you to know what type of aggregates you’ll want up front and then do insert time calculations for these values. While that will work just fine, it makes ad-hoc queries harder.

4. Complicated reports, and ad hoc queries, will require a lot more coding.

As far as I can tell, the argument is that SQL makes complex reports easy even though it still might take hundreds of lines to get the data required. And the other thing that’s not mentioned, these reports can still take a substantial amount of time to generate.

5. Aggregate operations will be much slower if you don’t use an RDBMS.

I’ll just point out that there are non-RDBMS systems that provide aggregate functionality and anything that uses a b+tree probably uses binary search.

8. Relational databases are scalable, even with massive data sets.

I don’t have a better response than the commenter jackson on the original blog post. Once an RDBMS is scaled to multiple machines, lots of the benefits are nullified and you’re dealing with the same issues that the non-RDBMS folks are.

9. Super-scalability is overrated. Slowing the pace of your product development is even worse.

[…] But in reality, the issue isn’t adding the hundredth node to a system, its adding the second. […]

And there is also a set of “hmmm… are you serious?” points… (Paul Davis is a bit more “polite” about them).

2. Inconsistency will provide a terrible user experience

6. Data import, export, and backup will be slow and difficult.

7. SimpleDB isn’t that fast.

9. SimpleDB is useful, but only in certain contexts.

Now, I guess the only “excuse” would be that at the time of the article, there was no MyNoSQL to get informed about NoSQL solutions.