130

I've been using MySQL for a fair while now and I'm comfortable with its structure & SQL Queries etc.

Currently building a new system in AWS and I've been looking at DynamoDB. Currently I only know a little about it.

Is one better then the other?

What are the advantage of DynamoDB?

what is the transition like from MySQL queries etc to this flat style DB?

Cœur
  • 37,241
  • 25
  • 195
  • 267
Adam
  • 19,932
  • 36
  • 124
  • 207

4 Answers4

313

Really DynamoDB and MySQL are apples and oranges. DynamoDB is a NoSQL storage layer while MySQL is used for relational storage. You should pick what to use based on the actual needs of your application. In fact, some applications might be well served by using both.

If, for example, you are storing data that does not lend itself well to a relational schema (tree structures, schema-less JSON representations, etc.) that can be looked up against a single key or a key/range combination then DynamoDB (or some other NoSQL store) would likely be your best bet.

If you have a well-defined schema for your data that can fit well in a relational structure and you need the flexibility to query the data in a number of different ways (adding indexes as necessary of course), then RDS might be a better solution.

The main benefit for using DynamoDB as a NoSQL store is that you get guaranteed read/write throughput at whatever level you require without having to worry about managing a clustered data store. So if your application requires 1000 reads/writes per second, you can just provision your DynamoDB table for that level of throughput and not really have to worry about the underlying infrastructure.

RDS has much of the same benefit of not having to worry about the infrastructure itself, however if you end up needing to do a significant number of writes to the point where the largest instance size will no longer keep up, you are kind of left without options (you can scale horizontally for reads using read replicas).

Updated note: DynamoDb does now support global secondary indexing, so you do now have the capability to perform optimized lookups on data fields other than the hash or combination of hash and range keys.

Mike Brant
  • 70,514
  • 10
  • 99
  • 103
  • 14
    If I could upvote your answer by 100, I would. – Salil Mar 12 '14 at 16:53
  • Some kind of problems in an information model tend well to a NoSQL kind of implementation. When you stumble across such problems ask yourself a question if it would make sense to have a NoSQL Db. Some of these entities are: Logs, Time series data, Social Networks, Content Management, Product Catalog etc. – user398039 Mar 15 '19 at 17:54
181

We have just migrated all of our DynamoDB tables to RDS MySQL.

While using DynamoDB for specific tasks may make sense, building a new system on top of DynamoDB is really a bad idea. Best laid plans etc., you always need that extra flexibility from your DB.

Here are our reasons we moved from DynamoDB:

  1. Indexing - Changing or adding keys on-the-fly is impossible without creating a new table.
  2. Queries - Querying data is extremely limited. Especially if you want to query non-indexed data. Joins are of course impossible so you have to manage complex data relations on your code/cache layer.
  3. Backup - Such a tedious backup procedure is a disappointing surprise compared to the slick backup of RDS
  4. GUI - bad UX, limited search, no fun.
  5. Speed - Response time is problematic compared to RDS. You find yourself building elaborate caching mechanism to compensate for it in places you would have settled for RDS's internal caching.
  6. Data Integrity - While the concept of fluid data structure sounds nice to begin with, some of your data is better "set in stone". Strong typing is a blessing when a little bug tries to destroy your database. With DynamoDB anything is possible and indeed anything that can go wrong does.

We now use DynamoDB as a backup for some systems and I'm sure we'll use it in the future for specific, well defined tasks. It's not a bad DB, it's just not the DB to serve 100% of your core system.

As far as advantages go, I'd say Scalability and Durability. It scales incredibly and transparently and it's (sort of) always up. These are really great features, but they do not compensate in any way for the downside aspects.

GWed
  • 15,167
  • 5
  • 62
  • 99
Yami Glick
  • 2,006
  • 1
  • 12
  • 6
  • It is also a very different model, so you really need to understand how to use it, which I don't think they document very well. – Zachary K Jul 30 '13 at 07:58
  • 21
    Some of this is out of date. For example, 1 is no longer true. – mbroshi Dec 13 '16 at 21:43
  • 2
    Very well documented answer. However, some of these concerns may be specific to rare use cases. Number 2 - "Joins are of course impossible" - DynamoDB data structures should not have any relations - period. Table should be completely de-normalized. That means some attributes get duplicated. For such cases, use a dynamo trigger or conditional writes. If users cannot deal with latency for conditional writes, put an SQS queue between the application and dynamo. Further, point number 6 is misnamed to the point that it casts a doubt on DynamoDB's "integrity" - that might not be the intention... – doles Feb 10 '17 at 15:41
  • 1
    Dynamo still lacks flexibility while queries. Though GSI are a huge help but still we can model our data better with RDBMS schema. – Pavan Feb 15 '18 at 05:18
  • #1 is not completely out of date...You can add/delete GSI's on the fly, however you cannot modify the primary key (hash/sort). – Brooks Feb 24 '18 at 17:53
  • 1
    I would add that the query capabilities within DynamoDB have a few "gotchas". For example, if your primary key consists of a hash only, a Dynamo query can only return 1 entry, you can't provide a range to a hash-only key at query time, nor can you query without knowing the specific hash of the item you're looking for. BatchGet accepts only 100 gets in the request, 1MB total response-size or 1MB total query-size, whichever comes first. Scan gives you flexible searching, but is highly inefficient and costly, returning the whole table before filtering. – Brooks Feb 24 '18 at 18:07
  • "Joins are of course impossible so you have to manage complex data relations on your code/cache layer" this is probably a sign of bad design: https://www.alexdebrie.com/posts/dynamodb-one-to-many/ – Gastón Fournier Aug 06 '21 at 16:22
  • Why do you say that joins are "of course impossible" ? – linSESH Jul 19 '22 at 16:51
75

You can read AWS explanation about it here.

In short, if you have mainly Lookup queries (and not Join queries), DynamoDB (and other NoSQL DB) is better. If you need to handle a lot of data, you will be limited when using MySQL (and other RDBMS).

You can't reuse your MySQL queries nor your data schema, but if you spend the effort to learn NoSQL, you will add an important tool to your tool box. There are many cases where DynamoDB is giving the simplest solution.

Guy
  • 12,388
  • 3
  • 45
  • 67
19

When using DynamoDB you should also know that the items/records in DynamoDB are limited to 400KB (See DynamoDB Limits). For many use cases this will not work. So DynamoDB will be good for few things but not all. Same goes for many of the other NoSQL database.

O.Badr
  • 2,853
  • 2
  • 27
  • 36
Ali
  • 289
  • 1
  • 3