Rows entered with hard coded hashkey but with different range key

Question

I'm trying to create a car booking app. Users can book cars located around many offices.

Wondering if I could put ALL the bookings into a single hard coded hashkey "Bookings" but with unique Range Key.

I want to have a reference to ALL the bookings so that the "Super Admin" can go in and view everything. Bookings need to be stored for 10 years, so I suppose I will end up with around 50 million records under the same hashkey but with different unique Range Keys. Search needs to be done based with three different date criteria, Local Secondary Index 1-3.

Thinking something like this (Including only the specific "Entity")

            Hash Key    Range Key   LSI-1       LSI-2       LSI-3       Other Attributes...
            -------------------------------------------------------------------------------
Bookings    "Bookings"  UUID        CreatedAt   BookedFrom  BookedTo    ...........
                        UUID        CreatedAt   BookedFrom  BookedTo    ...........
                        UUID        CreatedAt   BookedFrom  BookedTo    ...........
                        UUID        CreatedAt   BookedFrom  BookedTo    ...........
                        UUID        CreatedAt   BookedFrom  BookedTo    ...........
                        UUID        CreatedAt   BookedFrom  BookedTo    ...........

Is this how it's supposed to be done? Will this cause Hot Spots/Hot Partitions? Grateful for any tips.

score 0 · Accepted Answer · answered Jul 15 '19 at 14:24

0

I'd say no, that's not how it's supposed to be done...

First off, DDB can only store 10GB in a single partition, with 50m rows they'd have to be awfully small to fit.

I'd recommend vehicleID (UUID or VIN or STOCK#) as the hash key and bookingID (UUID or Timestamp or ???) as the sort key.

In order to show all bookings, you'd need to Query() on each vehicleID, but your app could query in parallel. Optionally, a Scan() always looks at every partition.

You could include a record with hashkey = "VEHICLES" that contained a list of vechicleIDs if you don't have anyplace else to store the list.

Additionally, a record with vechicleID and sortley = "INFO" for instance, could be used to store vehicle details.

But you don't really provide enough information to really design a DDB solution.

With a RDB, you have to know what you plan to store. With DDB, you don't have to know exactly what you plan to store, but you do need to know exactly how that data will need to be accessed.

answered Jul 15 '19 at 14:24

Charles

21,637
1
20
44

I wanted to ask because I saw one solution out in the internet that did the thing I mentioned above (had never seen it again being done in that way). So you nailed it! BTW the example I mentioned, https://www.trek10.com/blog/dynamodb-single-table-relational-modeling/ – Dimman Jul 18 '19 at 16:39
@Dimman I looked at your link, it certainly doesn't show all orders under a single "ORDERS" hash key like you describe in your question. They do use a static value for some of the the GSI hash key, but that's not the same thing. – Charles Jul 18 '19 at 16:59
Charles, won't all orders end up in a GSI hash key with primary key "ORDERS" and sort key orderDate? If so, does that mean that it's OK to collect them all in the GSI under a single hardcoded primary key, but not in the main table? – Dimman Jul 18 '19 at 18:11
1

Correct, GSI doesn't have the same limits as the physical table. Duplicates are allowed for instance along with no 10GB limit. But note LSI do have a 10GB limit. – Charles Jul 18 '19 at 18:32

Rows entered with hard coded hashkey but with different range key

1 Answers1