何时使用 dynamoDB -UseCases [英] When to use dynamoDB -UseCases

问题描述

我试图找出最适合 Amazon dynamoDB 的用例.

I've tried to figure out what will be the best use cases that suit for Amazon dynamoDB.

当我在谷歌上搜索时，大多数博客都说 DyanmoDb 将仅用于大量数据 (BigData).

When I googled most of the blogs says DyanmoDb will be used only for a large amount of data (BigData).

我有关系数据库的背景.NoSQL DB 对我来说是新的.所以当我试图将它与正常的关系数据库知识联系起来时.

I'm having a background of relational DB. NoSQL DB is new for me.So when I've tried to relate this to normal relation DB knowledge.

与 DynamoDb 相关的大部分概念是使用分区键/排序键创建无模式表.并尝试根据键来查询它们.另外，没有存储过程的概念，使查询更容易和简单.

Most of the concepts related to DynamoDb is to create a schema-less table with partition keys/sort keys. And try to query them based on the keys.Also, there is no such concept of stored procedure which makes queries easier and simple.

如果我们管理如此庞大的数据，每次都执行如此复杂的查询来检索数据将是没有存储过程的正确方法吗?

If we managing such huge Data's doing such complex queries each and every time to retrieve data will be the correct approach without a stored procedure?

注意:我可能对这个概念有错误的理解.所以，请任何人在这里澄清我的想法

Note: I've maybe had a wrong understanding of the concept. So, please anyone clear my thoughts here

提前致谢
周杰伦

Thanks in advance
Jay

推荐答案

简而言之，像 DynamoDB 这样的系统旨在通过水平扩展来支持大数据集(太大而无法容纳单个服务器)和高写入/读取吞吐量，如与垂直扩展相反，这是历史上关系数据库更常见的方法.

In short, systems like DynamoDB are designed to support big data sets (too big to fit a single server) and high write/read throughput by scaling horizontally, as opposed to scaling vertically, which is the more common approach for relational databases historically.

支持水平可扩展性的主要方法是对数据进行分区，即将数据集拆分为多个部分并分布在多个服务器之间.这样它可能会使用更多的存储空间和更多的 IOPS，从而允许更大的数据集和更高的读/写吞吐量.

The main approach to support horizontal scalability is by partitioning data, i.e. a data set is split into multiple pieces and distributed among multiple servers. This way it may use more storage and more IOPS, allowing bigger data sets and higher read/write throughput.

但是，由于数据分布在多个物理服务器之间，因此数据分区难以支持复杂的查询，例如连接等.至于存储过程，出于同样的原因，它们不受支持——历史上存储过程背后的思想是数据局部性，即它们在没有网络操作的情况下运行在靠近数据的服务器上，但是，如果数据分布在多个服务器之间，这种好处就消失了(至少以存储过程的形式).

However, data partitioning makes it difficult to support complex queries, such as joins etc., as data is distributed among multiple physical servers. As for stored procedures, they are not supported for the same reason - historically the idea behind stored procedures is data locality, i.e. they run on the server near the data without network operations, however, if data is distributed among multiple servers, this benefit disappears (at least in the form of stored procedure).

因此，从此类系统中查询数据的最有效方法是通过记录键，因为数据分区是基于键的，并且很容易找出给定键的记录物理位置.尽管许多此类系统也支持二级索引，但它们通常受到某种方式的限制或价格昂贵，并且可能不足以满足复杂软件解决方案的要求.一种非常常见的方法是拥有一个互补的索引/查询解决方案(我见过基于 Elasticsearch 和 Solr 的解决方案)，它允许对一些记录片段运行复杂的查询以找出一个记录键，然后用于加载记录.

Therefore the most efficient way to query data from such systems is by record key, as data partitioning is based on a key and it's easy to figure out where a record lives physically for a given key. While many such systems also support secondary indexes, they are usually restricted in some way or expensive and may not be enough to satisfy requirements in a complex software solution. A quite common approach is to have a complementary indexing/query solution (I've seen solutions based on Elasticsearch and Solr), which allows running complex queries over some fragments of records to figure out a record key, which then used to load the record.

这篇关于何时使用 dynamoDB -UseCases的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！