Amazon tabular database11/20/2023 There’s no query planner to parse your query into a multi-step process to read, join, and aggregate data from different places on disk. The big difference between DynamoDB and other databases is how natively DynamoDB exposes these data structures to you. Every NoSQL database uses some form of partitioning to horizontally scale, and every database under the sun uses B-trees (or close relatives) in indexing operations. Partitioning and B-trees are interesting, but they’re hardly unique to DynamoDB. Direct access to the data structures with a focused API This use of a B-tree on subsets of your data allows for highly efficient range queries of items with the same partition key. This B-tree provides logarithmic time complexity for finding a key. This is useful in many data applications, such as sorting usernames in alphabetical order or sorting e-commerce orders by the order timestamp.ĭynamoDB stores the items on each partition in a B-tree that are ordered according to their partition key and (if used by the table) sort key. A B-tree is an efficient way to maintain sorted data. That’s where DynamoDB’s second core mechanism comes in. While partitioning enables horizontal scaling, we often need to fetch a range of related items in a single request. The metadata subsystem retains a mapping of partition key ranges to storage nodes and can quickly route your request to the relevant partition. Under the hood, DynamoDB is sharding your database into segments called partitions (as shown in Figure 1 that follows), each of which holds a maximum of 10 GB of data.įigure 2: Request routed to the appropriate partition for processingĪs your table grows, DynamoDB can seamlessly add new partitions and redistribute your data to scale with your workload. Each item in your DynamoDB table will include a partition key. To avoid this, DynamoDB uses partitioning to provide horizontal scalability. However, vertical scaling has its limits, and often you find that the performance of relational databases degrade as data size increases. As your data or usage grows, you might increase your instance size to keep up. In a traditional relational database, you store all items on a single node. With these solid foundations, DynamoDB is able to scale tables to petabytes of data and millions of concurrent queries. To do this, DynamoDB relies on two core mechanisms: partitioning and the B-tree. No matter the size of your database or the number of concurrent queries, DynamoDB aims to provide the same single-digit millisecond response time for all operations. Reliance on two core mechanisms for consistent scalingĪbove all else, DynamoDB wants to provide consistent performance as your application scales. With that in mind, let’s review some distinctive features of DynamoDB. Because these details are hidden, these databases can scale in unpredictable ways or make it difficult to understand what your database will cost as usage grows. These abstractions make it easier for you to query your data in flexible ways, but they also hide important details from you. Most databases provide an abstraction over the low-level bits. multi-table debate.Īs we cover these, there’s one overarching theme that ties them together: DynamoDB wants to expose reality to you, so that you can make the right decision for your application’s needs. We don’t have room to exhaustively cover everything here, but I want to hit a few points that are relevant to the single- vs. multi-table design, let’s start with some background on DynamoDB. Relevant background on DynamoDBīefore we get too far into the merits of single- vs. Finally, we’ll conclude with some instances where using multiple tables in DynamoDB might be better for you. Then, we’ll discuss when single-table design can be helpful in your application. We’ll start off with some relevant background on DynamoDB that will inform the data modeling discussion. In this post, we’ll talk about single-table design in DynamoDB. I want to look at the topic at a higher level with a specific focus on arguments both for and against single-table design. You can read the DynamoDB documentation, watch re:Invent talks or other videos, or check out my book to learn some of the design patterns with single-table design in DynamoDB. Rather than the relational notion of having a table per entity, DynamoDB tables often include multiple different entities in a single table. This is a guest post by Alex DeBrie, an AWS Hero.įor people learning about Amazon DynamoDB, the idea of single-table design is one of the most mind-bending concepts out there.
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |