If you want to do queries on your table, they can only be done on the sort key and this is why you need to be careful with your key schema. Your primary key can just be a partition key or a combination of a partition key and a sort key. This couldn’t be more wrong! It is extremely important to pick good primary keys for your tables. A common misconception is that because the tables don’t have a fixed schema, you wouldn’t need to focus on table design. The items in a table don’t even need to have the same attributes. At any point you can then decide to add any kind of attribute to any of your items. This means that you don’t define a strict schema for your tables but rather just define the primary key and indexes.
Table DesignĭynamoDB, like most other NoSQL databases, is (almost) schema-less. DynamoDB is also very durable storage because there will be three geographically distributed replicas of your tables. This scalability is managed by AWS when you use DynamoDB and all you need to take care of is table and query design and making sure you have enough throughput provisioned. So, why to use them? The upside of such system is that you can actually make them highly scalable and distributed since key-value stores are easier to spread over multiple partitions. The lack of relations is important for the design, so they can also be called non relational databases. So, first of all, what is a NoSQL database? The idea of these databases is that they are key-value stores that cannot use complex SQL queries or relations. I will cover five of the most important ones here. I’ve used it in production on a large scale and learned my lessons on some things that you really need to know when you start using DynamoDB and NoSQL databases in general. DynamoDB is the managed NoSQL database service of AWS.
0 kommentar(er)
