Debug School

rakesh kumar
rakesh kumar

Posted on • Updated on

Explain feature of AWS DynamoDB

Explain the difference between Aws dynamo Db vs Mongo Db
A table uses item made of attribute
Dynamically handles customer requests, ensuring high performance through automatic distribution of data and traffic across servers
To read table data what statement is to be used
Difference between Mongo DB and Dynamo DB
How to manage customer request in Dynamo DB
Dynamo Db is NoSQL database service or not
How DynamoDB give fast response times to read and write operational
How DynamoDB is fully managed service

DynamoDB allows users to create databases capable of storing and retrieving any amount of data and comes in handy while serving any amount of traffic. It dynamically manages each customer’s requests and provides high performance by automatically distributing data and traffic over servers. It is a fully managed NoSQL database service that is fast, predictable in terms of performance, and seamlessly scalable. It relieves the user from the administrative burdens of operating and scaling a distributed database as the user doesn’t have to worry about hardware provisioning, patching Softwares, or cluster scaling. It also eliminates the operational burden and complexity involved in protecting sensitive data by providing encryption at REST.

The below table provides us with core differences between a conventional relational database management system and AWS DynamoDB:

Image description

Image description

Image description

Here are key aspects of DynamoDB's role in AWS:


DynamoDB is designed for seamless and automatic scalability. It can handle massive amounts of data and traffic by distributing the data across multiple servers.
Low-Latency Performance:

DynamoDB offers single-digit millisecond latency for read and write operations, making it suitable for applications that require fast response times.
NoSQL Data Model:

DynamoDB uses a NoSQL data model, allowing flexible and schema-less data structures. Each item in a DynamoDB table can have a different set of attributes.
Fully Managed Service:

DynamoDB is a fully managed service, meaning AWS takes care of tasks like hardware provisioning, setup, configuration, and maintenance. This allows developers to focus on building applications rather than managing infrastructure.
Automatic Indexing:

DynamoDB automatically indexes all the data in a table, making it easy to query and access data efficiently. Global Secondary Indexes (GSIs) provide additional flexibility for querying data.
Security and Compliance:

DynamoDB offers robust security features, including encryption at rest and in transit, fine-grained access control through AWS Identity and Access Management (IAM), and integration with AWS Key Management Service (KMS). It is compliant with various industry standards.
Event-Driven Architecture:

DynamoDB integrates with AWS services like AWS Lambda and Amazon Kinesis, enabling developers to build event-driven architectures and trigger actions based on changes in the DynamoDB table.
Use Cases

DynamoDB is suitable for a variety of use cases, including but not limited to:
Web and Mobile Applications: Storing user profiles, session data, and user-generated content.
Gaming: Leaderboards, player data, and game state.
IoT: Storing and querying data from Internet of Things (IoT) devices.
Real-Time Analytics: Storing and querying large datasets for analytics.

Advantage of DynamoDB

The main advantages of opting for Dynamodb are listed below:

  1. It has fast and predictable performance.
  2. It is highly scalable.
  3. It offloads the administrative burden operation and scaling.
  4. It offers encryption at REST for data protection.
  5. Its scalability is highly flexible.
  6. AWS Management Console can be used to monitor resource utilization and performance metrics.
  7. It provides on-demand backups.
  8. It enables point-in-time recovery for your Amazon DynamoDB tables. Point-in-time recovery helps protect your tables from accidental write or delete operations. With point-in-time recovery, you can restore that table to any point in time during the last 35 days.
  9. It can be highly automated

Limitations of DynamoDB

  1. It has a low read capacity unit of 4kB per second and a write capacity unit of 1KB per second.
  2. All tables and global secondary indexes must have a minimum of one read and one write capacity unit.
  3. Table sizes have no limits, but accounts have a 256 table limit unless you request a higher cap.
  4. Only Five local and twenty global secondary (default quota) indexes per table are permitted.
  5. DynamoDB does not prevent the use of reserved words as names.
  6. Partition key length and value minimum length sits at 1 byte, and maximum at 2048 bytes, however, DynamoDB places no limit on values .

Explain the difference between Aws dynamo Db vs Mongo Db

Image description

Image description

Image description

Image description

Image description

Image description

Image description

Image description

Deployment Environments
MongoDB can be run anywhere – from a developer’s laptop to an on-premises data center to any of the public cloud platforms. As mentioned above, MongoDB is also available as a fully managed cloud database with MongoDB Atlas; this model is most similar to how DynamoDB is delivered.

In contrast, DynamoDB is a proprietary database only available on Amazon Web Services. While a downloadable version of the database is available for prototyping on a local machine, the database can only be run in production in AWS. Organizations looking into DynamoDB should consider the implications of building on a data layer that is locked in to a single cloud vendor., the UK’s leading price comparison service, completed a transition from on-prem deployments with Microsoft SQL Server to AWS and MongoDB. When asked why they hadn’t selected DynamoDB, a company representative was quoted as saying "DynamoDB was eschewed to help avoid AWS vendor lock-in."

Data Model
MongoDB stores data in a JSON-like format called BSON, which allows the database to support a wide spectrum of data types including dates, timestamps, 64-bit integers, & Decimal128. MongoDB documents can be up to 16 MB in size; with GridFS, even larger assets can be natively stored within the database.

Unlike some NoSQL databases that push enforcement of data quality controls back into the application code, MongoDB provides built-in schema validation. Users can enforce checks on document structure, data types, data ranges and the presence of mandatory fields. As a result, DBAs can apply data governance standards, while developers maintain the benefits of a flexible document model.

DynamoDB is a key-value store with added support for JSON to provide document-like data structures that better match with objects in application code. An item or record cannot exceed 400KB. Compared to MongoDB, DynamoDB has limited support for different data types. For example, it supports only one numeric type and does not support dates. As a result, developers must preserve data types on the client, which adds application complexity and reduces data re-use across different applications. DynamoDB does not have native data validation capabilities.

Queries and Indexes
MongoDB's API enables developers to build applications that can query and analyze their data in multiple ways – by single keys, ranges, faceted search, graph traversals, JOINs and geospatial queries through to complex aggregations, returning responses in milliseconds. Complex queries are executed natively in the database without having to use additional analytics frameworks or tools. This helps users avoid the latency that comes from syncing data between operational and analytical engines.

MongoDB ensures fast access to data by any field with full support for secondary indexes. Indexes can be applied to any field in a document, down to individual values in arrays.

MongoDB supports multi-document transactions, making it the only database to combine the ACID guarantees of traditional relational databases; the speed, flexibility, and power of the document model; and the intelligent distributed systems design to scale-out and place data where you need it.

Multi-document transactions feel just like the transactions developers are familiar with from relational databases – multi-statement, similar syntax, and easy to add to any application. Through snapshot isolation, transactions provide a globally consistent view of data and enforce all-or-nothing execution. MongoDB allows reads and writes against the same documents and fields within the transaction. For example, users can check the status of an item before updating it. MongoDB best practices advise up to 1,000 operations in a single transaction. Learn more about MongoDB transactions here.

Supported indexing strategies such as compound, unique, array, partial, TTL, geospatial, sparse, hash, wildcard and text ensure optimal performance for multiple query patterns, data types, and application requirements. Indexes are strongly consistent with the underlying data.

DynamoDB supports key-value queries only. For queries requiring aggregations, graph traversals, or search, data must be copied into additional AWS technologies, such as Elastic MapReduce or Redshift, increasing latency, cost, and developer work. The database supports two types of indexes: Global secondary indexes (GSIs) and local secondary indexes (LSIs). Users can define up to 5 LSIs and 20 GSIs per table. Indexes can be defined as hash or hash-range indexes; more advanced indexing strategies are not supported.

GSIs, which are eventually consistent with the underlying data, do not support ad-hoc queries and usage requires knowledge of data access patterns in advance. GSIs can also not index any element below the top level record structure – so you cannot index sub-documents or arrays. LSIs can be queried to return strongly consistent data, but must be defined when the table is created. They cannot be added to existing tables and they cannot be removed without dropping the table.

DynamoDB indexes are sized and provisioned separately from the underlying tables, which may result in unforeseen issues at runtime. The DynamoDB documentation explains,

"In order for a table write to succeed, the provisioned throughput settings for the table and all of its global secondary indexes must have enough write capacity to accommodate the write; otherwise, the write to the table will be throttled."

DynamoDB also supports multi-record ACID transactions. Unlike MongoDB transactions, each DynamoDB transaction is limited to just 100 write operations; the same item also cannot be targeted with multiple operations as a part of the same transaction. As a result, complex business logic may require multiple, independent transactions, which would add more code and overhead to the application, while also resulting in the possibility of more conflicts and transaction failures. Only base data in a DynamoDB table is transactional. Secondary indexes, backups and streams are updated “eventually”. This can lead to “silent data loss”. Subsequent queries against indexes can return data that is has not been updated data from the base tables, breaking transactional semantics. Similarly data restored from backups may not be transactionally consistent with the original table.

MongoDB is strongly consistent by default as all read/writes go to the primary in a MongoDB replica set, scaled across multiple partitions (shards). If desired, consistency requirements for read operations can be relaxed. Through secondary consistency controls, read queries can be routed only to secondary replicas that fall within acceptable consistency limits with the primary server.

DynamoDB is eventually consistent by default. Users can configure read operations to return only strongly consistent data, but this doubles the cost of the read (see Pricing and Commercial Considerations) and adds latency. There is also no way to guarantee read consistency when querying against DynamoDB’s global secondary indexes (GSIs); any operation performed against a GSI will be eventually consistent, returning potentially stale or deleted data, and therefore increasing application complexity.

Operational Maturity
MongoDB Atlas allows users to deploy, manage, and scale their MongoDB clusters using built in operational and security best practices, such as end-to-end encryption, network isolation, role-based access control, VPC peering, and more. Atlas deployments are guaranteed to be available and durable with distributed and auto-healing replica set members and continuous backups with point in time recovery to protect against data corruption. MongoDB Atlas is fully elastic with zero downtime configuration changes and auto-scaling both storage and compute capacity. Atlas also grants organizations deep insights into how their databases are performing with a comprehensive monitoring dashboard, a real-time performance panel, and customizable alerting.

For organizations that would prefer to run MongoDB on their own infrastructure, MongoDB, Inc. offers advanced operational tooling to handle the automation of the entire database lifecycle, comprehensive monitoring (tracking 100+ metrics that could impact performance), and continuous backup. Product packages like MongoDB Enterprise Advanced bundle operational tooling and visualization and performance optimization platforms with end-to-end security controls for applications managing sensitive data.

MongoDB’s deployment flexibility allows single clusters to span racks, data centers and continents. With replica sets supporting up to 50 members and geography-aware sharding across regions, administrators can provision clusters that support globally deployments, with write local/read global access patterns and data locality. Using Atlas Global Clusters, developers can deploy fully managed “write anywhere” active-active clusters, allowing data to be localized to any region. With each region acting as primary for its own data, the risks of data loss and eventual consistency imposed by the multi-primary approach used by DynamoDB are eliminated, and customers can meet the data sovereignty demands of new privacy regulations. Finally, multi-cloud clusters enable users to provision clusters that span across AWS, Azure, and Google Cloud, giving maximum resilience and flexibility in terms of data distribution.

Offered only as a managed service on AWS, DynamoDB abstracts away its underlying partitioning and replication schemes. While provisioning is simple, other key operational tasks are lacking when compared to MongoDB:

Fewer than 35 database metrics are reported by AWS Cloudwatch, which limits visibility into real-time database behavior

AWS CloudTrail can be used to create audit trails, but it only tracks a small subset of DDL (administrative) actions to the database, not all user access to individual tables or records

DynamoDB has limited tooling to allow developers and/or DBAs to optimize performance by visualizing schema or graphically profiling query performance

DynamoDB supports cross region replication with multi-primary global tables, however these add further application complexity and cost, with eventual consistency, risks of data loss due to write conflicts between regions, and no automatic client failover

Image description

Top comments (0)