How should a database specialist implement these requirements with DynamoDB?
Enable Amazon DynamoDB Streams on the table. Create an AWS Lambda function triggered by the stream. Write the log entries to an Amazon S3 object.
Create a backup plan in AWS Backup to back up the DynamoDB table once a day. Create an AWS Lambda function that restores the backup in another table and compares both tables for changes. Generate the log entries and write them to an Amazon S3 object.
Enable AWS CloudTrail logs on the table. Create an AWS Lambda function that reads the log files once an hour and filters DynamoDB API actions. Write the filtered log files to Amazon S3.
Enable Amazon DynamoDB Streams on the table. Create an AWS Lambda function triggered by the stream. Write the log entries to an Amazon Kinesis Data Firehose delivery stream with buffering and Amazon S3 as the destination.
Explanations:
While enabling DynamoDB Streams and using Lambda for logging is a valid approach, this option does not mention handling batch processing of 100,000 records or storing logs in Apache Parquet format, which is a key requirement.
Using AWS Backup for daily backups and comparing tables is inefficient for real-time logging. It does not provide a way to track database changes immediately and does not address the requirement of storing logs in Apache Parquet format.
AWS CloudTrail logs track API activity, but this option doesn’t meet the performance requirements for logging 500,000 entries per minute and doesn’t address the batch processing or Parquet format requirements.
Enabling DynamoDB Streams with Lambda and writing the logs to an Amazon Kinesis Data Firehose delivery stream allows efficient handling of large volumes of data, with buffering, and can easily integrate with Amazon S3 for storing logs in Apache Parquet format. This satisfies the requirement of storing logs in batches.