1

I have read that a single partition of DynamoDB has a size limit of 10GB. This means if all my data are smaller as 10GB then I have only one partition?

There is also a limit of 3000 RCUs or 1000 WCUs on a single partition. This means this is also the limit for a small database which has only one partition?

I use the billing mode PAY_PER_REQUEST. On the database there are short usage peaks of approximate 50MB data. And then there is nothing for hours. How can I design the database to get the best peak performance? Or is DynamoDB a bad option for this use case?

Horcrux7
  • 23,758
  • 21
  • 98
  • 156

2 Answers2

0

A given partition key can't receive more than 3k RCUs/1k WCUs worth of requests at any given time and store more than 10GB in total if you're using an LSI (if not using an LSI, you can store more than 10GB assuming you're using a Sort Key). If your data definitely fits within those limits, there's no reason you can't use DDB with a single partition key value (and thus a single partition). It'd still be better to plan on a design that could scale.

The right design for you will depend on what your data model and access patterns look like. Given what you've described of some kind of periodic job, a timestamp could be used (although it has issues with hotspots you should be careful of). If you've got some kind of other unique id, like user_id or device_id, etc. that would be a better choice. There is some great documentation on that here.

Chris Anderson
  • 8,305
  • 2
  • 29
  • 37
  • 1
    Items sharing a single partition key can absolutely exceed 10 GB and can cross partitions, so long as you don't have a Local Secondary Index (LSI). – hunterhacker Aug 04 '22 at 17:07
  • Good point. Will amend. – Chris Anderson Aug 04 '22 at 17:18
  • @ChrisAnderson-AWS The question was not to partition keys. It was question to the performance behavior of small databases. Or do you want say that the 3k RCUs are per partition key and not per partition? – Horcrux7 Aug 05 '22 at 05:55
0

How to design a database to get best performance and picking the right database... these are deep questions.

DynamoDB works well for a wide variety of use cases. On the back end it uses partitions. You rarely have to think about partitions until you're at the high-end of scale. Are you?

Partition keys are used as a way to map data to partitions but it's not 1 to 1. If you don't follow best practice guidance and use one PK value, the database may still split the items across back-end partitions to spread the load. Just don't use a Local Secondary Index (LSI) or it prohibits this ability. The details of the mapping depend on your usage pattern.

One physical partition will be 10 GB or less, and has the 3,000 Read units and 1,000 Write units limit, which is why the database will spread load across partitions. If you use a lot of PK values you make it more straightforward for the database to do this.

If you're at a high enough scale to hit the performance limits, you'll have an AWS account manager you can ask to hook you up with a DynamoDB specialist.

hunterhacker
  • 6,378
  • 1
  • 14
  • 11
  • The question was not for partitions keys. It was for the the performance behavior of small databases with only one physical partition. The application use a user triggered data import of approximate 50 MB. This is not a high scale but a short peak on IO operation. – Horcrux7 Aug 05 '22 at 06:05
  • How are you going to create an On Demand table with just one partition? – hunterhacker Aug 05 '22 at 06:26
  • Do you means with `On Demand` table the billing mode PAY_PER_REQUEST? I create the table with the Java API. My understand is that every new database has only one physical partition until the data extends 10 GB. That I does not understand your question. – Horcrux7 Aug 05 '22 at 07:37
  • Ah, that isn’t how it works. My advice is just get going. If something is slow, ask about it specifically. There’s a lot of intelligence within DynamoDB. – hunterhacker Aug 05 '22 at 16:30