Database-এর ধরন আর কোনটা নেবে

এই লেসন শেষে তুমি পারবে

• কোন database নেবে, সেটা ঠিক করে দেয় এমন প্রশ্নগুলো নিজেকে করতে: read বেশি নাকি write বেশি, throughput আর হঠাৎ ভিড়, data-র পরিমাণ আর বৃদ্ধি, object-এর আকার, access pattern, durability আর আসল data কোথায় থাকবে, latency, একসাথে কতজন user, data model, join, schema, report, search আর licence-এর খরচ।
• Database-এর পরিবারগুলো (relational OLTP, key-value, in-memory, document, wide-column, graph, time series, ledger, object store, warehouse OLAP, search, S3-এর ওপর SQL) আর প্রত্যেকটার AWS service-এর নাম বলতে।
• OLTP আর OLAP আলাদা করে চিনতে, আর checkout-এর database-এ report চালালে কেন customer-রা ভোগে আর সেটা কোথায় চালানো উচিত (read replica, Redshift, Athena), বুঝিয়ে বলতে।
• RDS, Aurora, ElastiCache, MemoryDB, DynamoDB আর S3, প্রত্যেকটা কখন নেবে, তার পরীক্ষার keyword আর কখন নেবে না, এক কার্ডে মনে করতে।
• একটা decision map আর keyword map দিয়ে পরীক্ষার “কোন database?” প্রশ্নের উত্তর দিতে, আর ফাঁদের উত্তরটা ধরে ফেলতে।
• বন্ধ হয়ে যাওয়া বা বদলে যাওয়া service (Quantum Ledger Database, নতুন account-এর জন্য Timestream) আর নতুন service (Aurora DSQL, Valkey) চিনতে, আর পরীক্ষা এখনো কোন উত্তর চায় তা জানতে।

#কেন বেছে নেওয়াটা এত জরুরি

AWS-এ পনেরোটারও বেশি managed database আছে। এটা এমন কোনো menu না যেখানে একটা item সবার সেরা; প্রত্যেকটা বানানো হয়েছে নির্দিষ্ট এক ধরনের data আর নির্দিষ্ট এক ধরনের প্রশ্নের জন্য। ভুলটা নিলে app প্রথম দিন চলবে, তারপর বড় হতে হতে ধীর হবে, খরচ বাড়বে, বা data হারাবে। ঠিকটা নিলে কঠিন সমস্যাগুলোর বেশিরভাগ (scaling, failover, backup) আগে থেকেই সমাধান করা থাকে।

Note-এ কথাটা এভাবে বলা: প্রতিটা service কখন, কেন আর কোন architectural pattern-এ ব্যবহার করতে হয় জানলে পরীক্ষার database-এর বেশিরভাগ প্রশ্নের উত্তর দেওয়া যায়। Note আরও বলে, database আর storage থেকে ১৫ থেকে ২০% প্রশ্ন আসে। এই হিসাবটা অফিসিয়াল না: SAA-C03 পরীক্ষায় চারটা domain, Secure Architectures (৩০%), Resilient Architectures (২৬%), High-Performing Architectures (২৪%) আর Cost-Optimized Architectures (২০%), আর database-এর প্রশ্ন চারটাতেই আসে। যেভাবেই গোনো, প্রশ্ন অনেক।

এই লেসনটা পুরো chapter-এর ম্যাপ। RDS, Aurora আর ElastiCache পড়েছ chapter 7-এ, DynamoDB lesson 15.4 আর 15.5-এ, S3 আর Glacier chapter 10-এ। এখানে প্রত্যেকে পাবে একটা ছোট recap কার্ড আর পেছনের লেসনের link। চারটা purpose-built engine, DocumentDB, Neptune, Keyspaces আর Timestream, এখানে পাবে এক লাইন করে, আর পুরো একটা লেসন ঠিক পরেরটায়, 16.2।

#যে প্রশ্নগুলো নিজেকে করবে

Service-এর নাম বলার আগে এগুলোর উত্তর দাও। প্রতিটা প্রশ্ন কিছু পরিবারের দিকে ঠেলে দেয়, আর কিছু থেকে সরিয়ে আনে।

এর মধ্যে দুটো নিয়ে আরেকটু বলি।

• আসল data কোথায় (source of truth)। প্রতিটা data-র জন্য ঠিক করো, আসল copy কোন store-এ থাকবে। বাকি সব (cache, search index, warehouse) হলো copy, যেটা একটু পিছিয়ে থাকতে পারে বা আবার বানানো যায়। Data হারানোর বেশিরভাগ গল্পের শুরু এমন একটা copy থেকে, যাকে আসল ভাবা হয়েছিল।
• Access pattern। Relational database-কে এমন প্রশ্নও করা যায় যেটা এখনো মাথায়ই আসেনি, কারণ SQL যেকোনো column দিয়ে filter, join আর group করতে পারে। Key-value store সবচেয়ে দ্রুত তখনই, যখন প্রতিটা প্রশ্ন আগে থেকে জানা আর তার জন্য key সাজানো। “আমরা এখনো জানি না কী জিজ্ঞেস করব”, এই কথাটা SQL-এর পক্ষে একটা জোরালো ভোট।

#হাতে-কলমে উদাহরণ: একটা ride-sharing app

ঢাকার Pathao-র মতো একটা ride app প্রশ্নগুলোর উত্তর দেয় এভাবে:

কয়েকটা store একসাথে ব্যবহার করা, প্রত্যেকটাকে তার সেরা কাজে, একে বলে polyglot persistence। AWS-এ এটাই স্বাভাবিক, আর এই লেসনের শেষে আবার দেখবে।

#Database-এর ধরন

Slide-এ AWS-এর database-গুলোকে পরিবারে ভাগ করা হয়েছে। নিচে প্রত্যেক পরিবার, তার service, data-র আকার, আর কোথায় ভালো, কোথায় দুর্বল।

Slide-এ relational database-কে বলা হয়েছে “join-এ দারুণ”, আর NoSQL-কে “join নেই, SQL নেই”। পরীক্ষার মনের ছবি এটাই; কয়েকটা NoSQL service-এর অবশ্য SQL-এর মতো ভাষা আছে (DynamoDB-র SQL-compatible query ভাষা, Keyspaces-এ Cassandra Query Language), কিন্তু কেউই relational database-এর মতো table join করে না।

#OLTP বনাম OLAP

“কোন database” প্রশ্নে এই দুটো শব্দ বারবার আসে।

• OLTP (online transaction processing) হলো একটা application-এর প্রতিদিনের কাজ: order দেওয়া, টাকা পাঠানো, profile বদলানো। অনেক user, অসংখ্য ছোট transaction, প্রত্যেকটা হাতে গোনা কয়েকটা row ছোঁয়, আর প্রত্যেকটাকে নিখুঁত (ACID) আর দ্রুত হতে হয়। Data রাখা থাকে row ধরে ধরে, কারণ একটা transaction পুরো একটা row পড়ে বা লেখে। AWS-এ: RDS আর Aurora।
• OLAP (online analytical processing) হলো ইতিহাস নিয়ে বড় বড় প্রশ্ন: তিন বছরের জেলা আর মাস ধরে মোট বিক্রি। অল্প user, অল্প query, কিন্তু প্রতিটা পড়ে লাখ লাখ বা কোটি কোটি row, যদিও মাত্র কয়েকটা column। Data রাখা থাকে column ধরে, compress করে, আর কাজটা অনেকগুলো node-এ ভাগ হয়ে যায়। AWS-এ: Redshift (আর S3-এর file-এর জন্য Athena)।

চিরচেনা ভুলটা হলো OLTP database-এর ওপর OLAP চালানো। দেখো কী হয়:

তাড়াতাড়ির সমাধান read replica: চাপটা writer থেকে সরিয়ে নেয়। কিন্তু replica-ও writer-এর মতো row ধরে রাখে, তাই বড় report ধীরই থাকে, আর তার মাপও app traffic-এর জন্য। সত্যিকারের analytics-এর জন্য data copy করো একটা warehouse-এ। Aurora, RDS for MySQL আর DynamoDB zero-ETL integration দিয়ে Redshift-এ data পাঠাতে পারে, কোনো pipeline বানাতে হয় না (lesson 7.3)। Data যদি আগে থেকেই S3-এ file হয়ে থাকে আর প্রশ্ন মাঝেমধ্যে আসে, Athena সেখানেই query করে, আর খরচ নেয় যতটা data scan হলো সেই ধরে। Redshift পড়বে lesson 17.2-এ, Athena lesson 17.1-এ; slide-ও বলে এগুলো data আর analytics অংশের বিষয়।

#NoSQL মানে একটা জিনিস না

“NoSQL” শুধু বলে database-টা কী না। AWS-এর পাঁচটা NoSQL পরিবার একে অপরের থেকে একদম আলাদা:

• Key-value (DynamoDB): key দাও, item পাও। সবচেয়ে দ্রুত আর সবচেয়ে বেশি scale করে তখন, যখন প্রতিটা প্রশ্ন হলো “এই key-র জিনিসটা দাও” বা “এই partition key-র item-গুলো দাও, এই sort key ধরে সাজিয়ে”।
• In-memory (ElastiCache, MemoryDB): RAM-এ key-value, সাথে নানা data structure (sorted set, hash, list, geospatial)। Microsecond।
• Document (DocumentDB): প্রতিটা record একটা JSON document, যার ভেতরে আরও জিনিস সাজানো থাকতে পারে, আর একেকটা একেক রকম হতে পারে; document-এর ভেতরের field দিয়েও query আর index করা যায়। MongoDB application-এর উত্তর।
• Wide-column (Keyspaces): row-গুলো partition-এ ভাগ করা, অনেক node জুড়ে বিপুল পরিমাণ write নেওয়ার জন্য বানানো। Apache Cassandra application-এর উত্তর।
• Graph (Neptune): সম্পর্কগুলোই এখানে data। “বন্ধুর বন্ধু”, “প্রতারকের সাথে যুক্ত account”, “যারা এটা কিনেছে তারা ওটাও কিনেছে”।

Slide-এ Neptune দুবার আছে, একবার NoSQL-এর মধ্যে, আরেকবার graph হিসেবে; service কিন্তু একটাই।

#Search, analytics আর বাকিরা, এক লাইনে

• OpenSearch (AWS-এ Elasticsearch-এর উত্তরসূরি): একটা search আর log analytics engine। তোমার data-র একটা copy দাও, পাবে free-text search, আংশিক আর আনুমানিক মিল, relevance ধরে সাজানো ফল আর log dashboard। কখনোই আসল data-র জায়গা না। Lesson 17.3।
• Redshift: OLAP আর BI-এর data warehouse। Lesson 17.2।
• Athena: S3-এর file-এর ওপর সরাসরি serverless SQL। Lesson 17.1।
• EMR: big-data processing-এর জন্য managed Hadoop আর Spark cluster; slide এটাকে warehouse-এর দলে রেখেছে। Lesson 17.4।

#Ledger: Quantum Ledger Database অবসরে গেছে

#নতুন service আর নাম, ২০২৪ থেকে ২০২৬

#Recap কার্ড: যে পাঁচটা service তুমি আগেই চেনো

Note-এ প্রতিটা service-এর একটা ছোট পরিচিতি আছে। এখানে সেগুলোই কার্ড আকারে: কী, কখন নেবে, পরীক্ষার keyword, আর কখন নেবে না। পুরো লেসনের জন্য link ধরে যাও।

#Amazon RDS

কী: একটা managed relational database service। Cloud-এ চিরাচরিত SQL (table, row, column); provisioning, OS patching আর backup সামলায় AWS। তুমি বেছে নাও instance-এর মাপ আর EBS storage-এর ধরন ও আকার (storage auto scaling চাইলে সেটা বাড়িয়ে দিতে পারে)।

Engine: PostgreSQL, MySQL, MariaDB, Oracle, Microsoft SQL Server আর IBM Db2। Aurora আলাদা, AWS-এর নিজের বানানো engine, তার কার্ড নিচে। RDS Custom দিয়ে Oracle আর SQL Server-এর নিচের OS আর database-এ ঢোকা যায়।

মূল feature:

• Multi-AZ: আরেকটা Availability Zone-এ একটা synchronous standby copy, primary বিকল হলে নিজে থেকে failover। এটা availability-র জন্য, performance-এর জন্য না: Multi-AZ instance-এর standby কোনো read নেয় না। এটা AZ বিকল হওয়া থেকে বাঁচায়, Region বিকল হওয়া থেকে না (lesson 7.1)।
• Read replica: asynchronous copy, শুধু read query নেয়, বেশিরভাগ engine-এ প্রতি source-এ ১৫টা পর্যন্ত (note-এ ৫, যেটা পুরোনো সীমা; Db2-তে ৩টা)। Replica অন্য Region-এ-ও রাখা যায়, যেটা disaster recovery-তেও কাজে আসে।
• Backup: ১ থেকে ৩৫ দিন পর্যন্ত point-in-time recovery সহ automated backup, আর যতদিন খুশি রাখা যায় এমন manual snapshot (lesson 7.2)।
• Security: IAM database authentication, security group, KMS দিয়ে at rest encryption, transit-এ TLS, Secrets Manager-এর সাথে যোগ (lesson 7.4)। Maintenance managed আর সময় ঠিক করা, তাতে অল্প সময় বন্ধ থাকতে পারে।

কখন নেবে: relational data, SQL আর transaction, বিশেষ করে Oracle, SQL Server বা Db2-তে, বা ছোট আর স্থির MySQL/PostgreSQL কাজ যেখানে খরচই সবচেয়ে জরুরি।

পরীক্ষার keyword: “high availability / disaster recovery” → Multi-AZ; “read performance scaling” → read replica; “OS বা database-এর ভেতরে root access” → RDS Custom (Oracle, SQL Server)।

কখন না: সীমাহীন write scale, সেকেন্ডে লাখো key lookup, বড় file, free-text search, primary-তে ভারী analytics।

#Amazon Aurora

কী: AWS-এর নিজের বানানো enterprise-class relational database, MySQL আর PostgreSQL-এর সাথে compatible। AWS বলে একই hardware-এ MySQL-এর ৫ গুণ আর PostgreSQL-এর ৩ গুণ throughput পর্যন্ত; এটাকে কাজভেদে বদলানো একটা marketing হিসাব ধরো।

মূল feature (lesson 7.3):

• Compute থেকে আলাদা storage: data থাকে ৩টা AZ জুড়ে ৬টা copy-তে, নিজেই নিজেকে সারায়, আর 10 GiB-র ধাপে নিজে থেকে বেড়ে যায় 128 TiB পর্যন্ত (নতুন engine version-এ 256 TiB; note-এ 128 TB)।
• ১৫টা পর্যন্ত Aurora Replica, খুব কম lag সহ, replica-র auto scaling, writer আর reader endpoint (আর custom endpoint)। Failover সাধারণত ৩০ সেকেন্ডের কমে শেষ হয়; note-এ “millisecond” লেখা, যেটা আসলে replica lag-এর কথা, failover-এর না।
• Aurora Serverless v2: কয়েক সেকেন্ডে capacity ওঠানামা করে; অনিশ্চিত বা থেমে থেমে আসা কাজের জন্য, capacity planning ছাড়াই।
• Global Database: একটা primary Region আর ১০টা পর্যন্ত secondary Region (প্রত্যেকটায় ১৬টা পর্যন্ত read instance), storage পর্যায়ে এক সেকেন্ডের কমে replication।
• আরও: backtrack আর restore-এর নানা উপায়, cloning (চালু cluster থেকে নতুন cluster, snapshot restore-এর চেয়ে দ্রুত), Aurora machine learning (SQL থেকে SageMaker, Comprehend, Bedrock), SQL Server app-এর জন্য Babelfish।

কখন নেবে: RDS-এর মতো একই কাজে, কম maintenance আর বেশি performance, availability আর feature সহ।

পরীক্ষার keyword: “PostgreSQL/MySQL compatible”, সাথে “max performance”, “auto-scaling storage”, “15 replicas” → Aurora। “বিশ্বজুড়ে কম latency-র read আর Region পর্যায়ের DR” → Aurora Global Database।

কখন না: Babelfish ছাড়া Oracle, SQL Server বা Db2 (RDS নাও), বা এমন ছোট্ট database যেখানে খরচই আসল কথা।

#Amazon ElastiCache, আর MemoryDB

কী: একটা managed in-memory cache: database-এর চাপ কমায়, আর response time millisecond থেকে নামিয়ে আনে microsecond-এ। Engine: Valkey, Redis OSS আর Memcached (lesson 7.5)। তুমি একটা node type বেছে নাও (যেমন cache.m6g.large), নয়তো ElastiCache Serverless ব্যবহার করো।

Note দুটো চিরচেনা engine পাশাপাশি রেখেছে:

Caching-এর কৌশল: lazy loading (request এসে cache-এ না পেলে তবেই load করা) আর write-through (database-এ লেখার সাথে সাথে cache-ও আপডেট)।

কখন নেবে: query-র ফল cache করা, read বেশি আর write কম, web server-এর session data, আবার বানানো যায় এমন leaderboard আর counter। App-এ code বদলাতে হয় (app নিজে cache-এর সাথে কথা বলে), আর এতে SQL চলে না।

পরীক্ষার keyword: “session store”, “persistence / Multi-AZ সহ user profile” → Redis; “শুধু caching, সাধারণ key-value, multi-threaded” → Memcached।

Cache-কেই যখন database হতে হয়: MemoryDB। ElastiCache asynchronous ভাবে replicate করে, তাই failover-এ শেষ কয়েকটা write হারাতে পারে; এটা cache, এমন data-র copy যার আসলটা থাকে অন্য কোথাও। MemoryDB হলো Valkey আর Redis OSS-compatible একটা primary database: প্রতিটা write নিশ্চিত করার আগে একটা Multi-AZ transaction log-এ জমা হয়, তাই node বা AZ বিকল হলেও data টিকে থাকে। Read তবুও microsecond-এ; write-এ লাগে single-digit millisecond। Keyword: “durable in-memory database”, “Redis-compatible primary database”, “data হারাবে না” → MemoryDB।

#Amazon DynamoDB

কী: AWS-এর fully managed, serverless NoSQL database, key-value আর document data-র জন্য, যেকোনো মাপে single-digit millisecond latency। Default-এই Multi-AZ (lesson 15.4 আর 15.5)।

মূল feature:

• Capacity mode: on-demand (নিজে থেকে scale করে, request ধরে খরচ) আর provisioned (তুমি RCU আর WCU ঠিক করো, চাইলে auto scaling সহ; note বলে provisioned মানে নির্দিষ্ট, কিন্তু auto scaling অনেক দিন ধরেই আছে)।
• DAX: DynamoDB API-র একটা in-memory cache; read latency microsecond-এ।
• DynamoDB Streams: প্রতিটা insert, update আর delete হয়ে যায় একটা event, যেমন একটা Lambda function চালাতে (বা Kinesis Data Streams-এ পাঠাতে)।
• Global Tables: multi-Region, active-active replication।
• Transaction, item মেয়াদোত্তীর্ণ করতে TTL, ৩৫ দিন পর্যন্ত PITR backup, on-demand backup, capacity খরচ না করে S3-এ export আর S3 থেকে import, সব access control IAM দিয়ে।

কখন নেবে: serverless app, যেকোনো মাপে key lookup, হঠাৎ লাফ দেওয়া traffic, কয়েকশো KB পর্যন্ত item, দ্রুত বদলানো schema। Slide আরও বলে, data durable আর serverless চাইলে key-value store হিসেবে DynamoDB ElastiCache-এর জায়গা নিতে পারে, যেমন TTL সহ session-এর জন্য।

পরীক্ষার keyword: “serverless key-value store with massive scale” → DynamoDB; “microsecond latency” → DAX।

কখন না: join, হঠাৎ জাগা report, 400 KB-র বড় item, free-text search।

#Amazon S3 আর Glacier

কী: serverless object storage: file, ছবি, video আর backup, bucket-এ object হিসেবে রাখা (block storage না, file system-ও না)। Durability 99.999999999% (এগারোটা নয়), object 50 TB পর্যন্ত, আর capacity নিয়ে কোনো ভাবনা নেই। Slide S3-কে বলে object-এর key-value store: বড় object-এর জন্য দারুণ, অসংখ্য ছোট্ট জিনিসের জন্য না (chapter 10, শুরু lesson 10.1 থেকে)।

Note-এর storage class table, এখনকার তথ্য সহ (lesson 10.5):

S3 Object Lock object রাখে WORM (write once, read many) হিসেবে: নির্দিষ্ট মেয়াদ পর্যন্ত কেউ মুছতে বা ওপরে লিখতে পারে না, নিয়মকানুন মানার জন্য। Compliance mode-এ root user-ও পারে না (lesson 10.9)।

পরীক্ষার keyword: “unknown access patterns” → S3 Intelligent-Tiering; “cheapest storage for long-term compliance backup” → S3 Glacier Deep Archive; “root সহ কোনো user মুছতে পারবে না” → compliance mode-এ S3 Object Lock।

কখন না: server-দের ভাগ করা file system (সেটা EFS বা FSx, lesson 5.4 আর 12.2), বা file-এর ভেতরে ঘনঘন ছোট update।

#চারটা purpose-built engine, এক লাইনে

চারটাই, বাস্তব scenario আর নিজস্ব animation সহ, আছে lesson 16.2-এ।

#Decision map

Requirement পড়ো, তারপর এই ধাপগুলো ক্রমানুসারে পার হও। প্রথম যে ধাপটা মিলে যায়, সাধারণত সেটাই উত্তর।

1. এটা কি file বা বড় object?

   ছবি, video, backup, log, megabyte বা তার বেশি মাপের যেকোনো কিছু: S3, access pattern অনুযায়ী একটা storage class, আর archive-এর জন্য Glacier class। Database রাখে শুধু object key।

2. এটা কি app চালানো না, বরং ইতিহাসের ওপর analytics?

   Report, BI, terabyte-ভর্তি data-র dashboard: Redshift। আগে থেকেই S3-এ থাকা file-এর ওপর মাঝেমধ্যে SQL: Athena। কখনোই OLTP primary-তে না।

3. এটা কি search?

   Free text, আংশিক বা আনুমানিক মিল, relevance, log খোঁজা: OpenSearch, আসল data-র জায়গা থেকে data নিয়ে।

4. Data-র কি বিশেষ কোনো আকার, বা আগে থেকে চালু কোনো engine আছে?

   সম্পর্কের graph: Neptune। সময় লেখা reading: Timestream। চালু MongoDB: DocumentDB। চালু Cassandra: Keyspaces। Oracle, SQL Server বা Db2 যেমন আছে তেমন রাখতে হবে: ওই engine-এর RDS।

5. Join, একাধিক জিনিস জুড়ে transaction, বা হঠাৎ জাগা SQL লাগবে?

   হ্যাঁ হলে relational। Performance, অনেক replica, নিজে বাড়া storage আর বিশ্বজোড়া নাগালের জন্য Aurora; অনিশ্চিত load-এর জন্য Aurora Serverless v2; commercial engine বা ছোট, সস্তা, স্থির database-এর জন্য RDS।

6. এটা কি বড় বা লাফ দেওয়া মাপে key দিয়ে খোঁজা হয়?

   DynamoDB (serverless, single-digit ms)। তার ওপর microsecond read: DAX।

7. এটা কি একটা দ্রুত copy, নাকি memory-র গতির data-কে durable হতে হবে?

   Cache, session, আবার বানানো যায় এমন data: ElastiCache। যে in-memory store-ই আসল data-র জায়গা: MemoryDB।

#Keyword map

Note শেষ হয়েছে একটা দ্রুত revision-এর cheat sheet দিয়ে। এখানে সেটাই, সংশোধন করে, আর slide-এর পরিবারগুলো যোগ করে:

এবার অনুশীলন। নিচের প্রতিটা scenario শুরু হয় requirement দিয়ে, তারপর দেখায় লোভনীয় ভুল উত্তরটা কেন বাদ পড়ে, শেষে ঠিকটা:

আর যখন পরীক্ষার প্রশ্ন নেই, শুধু তোমার নিজের app, তখন প্রশ্নগুলোর উত্তর দাও একটা একটা করে:

#কোথায় গোলমাল হয়

AWS-এ database-এর বেশিরভাগ ঝামেলা database-এর bug না; ঝামেলা হলো database-কে এমন কাজে লাগানো, যেটার জন্য সে বানানোই হয়নি। ছয়টা চেনা ভুল পছন্দ:

#System design-এ database

• প্রতিটা কাজের জন্য একটা store, প্রতিটা তথ্যের জন্য একটাই আসল জায়গা। Polyglot persistence স্বাভাবিক, কিন্তু প্রতিটা তথ্যের ঠিক একটা ঘর দরকার। Cache, search index আর warehouse সেখান থেকে data পাওয়া copy, আর প্রতিটা copy একটু পিছিয়ে থাকে।
• ফ্যাশন না, data model আর access pattern ঠিক করুক। “এটা scale করে” relational data-র জন্য DynamoDB নেওয়ার কারণ না; “আমরা SQL জানি” graph বা time-series data RDS-এ রেখে দেওয়ার কারণ না।
• প্রথম দিন থেকেই OLTP আর OLAP আলাদা। ছোট একটা দোকানও report পাঠাক replica-তে, আর বড় হলে Redshift বা Athena-তে।
• Load অনিশ্চিত হলে serverless। DynamoDB on-demand, Aurora Serverless v2, ElastiCache Serverless, Athena: capacity traffic-এর পিছু পিছু চলে।
• Encryption আর access সব জায়গায় একই নিয়মে: at rest data-র জন্য KMS key (chapter 21, lesson 21.2), transit-এ TLS, access-এর জন্য IAM আর security group।
• পুরোনো engine ছেড়ে আসা: DMS অল্প downtime-এ data copy করে, engine বদলালে SCT schema রূপান্তর করে (Oracle থেকে Aurora PostgreSQL), Babelfish SQL Server app-কে Aurora-তে চালু রাখে (lesson 23.3)।

এখানে একটা দোকান ছয়টা store ব্যবহার করছে, আর copy নিয়ে দুটো জিনিস গোলমাল হচ্ছে:

#নিজে করে দেখো

#অনুশীলন: store বেছে নাও

তালিকার নিচের সমাধান পড়ার আগে প্রতিটার উত্তর দাও।

১. একটা বিশ্ববিদ্যালয় student, course আর semester সহ পরীক্ষার ফল রাখে, আর registrar প্রতি term-এ নতুন নতুন query চালান। ২. একটা mobile game-এ প্রত্যেক player-এর inventory লাগে, player ID দিয়ে পড়া-লেখা, launch-এর দিন সেকেন্ডে ২,০০,০০০ বার। ৩. একই game-এর বিশ্বজোড়া top-100 leaderboard real time-এ আপডেট হতে হবে; inventory থেকে এটা আবার বানানো যায়। ৪. একটা bank-কে খুঁজে বের করতে হবে, পরিচিত একটা mule account থেকে চারটা লেনদেনের মধ্যে কোন কোন account যুক্ত। ৫. একটা logistics company audit-এর জন্য ৭ বছরের delivery record রাখে, যা প্রায় কখনো পড়া হয় না। ৬. একটা marketing team মাসে দুবার গত মাসের app log নিয়ে SQL প্রশ্ন করতে চায়, log আগে থেকেই S3-এ।

সমাধান: (১) Aurora বা RDS, হঠাৎ জাগা query সহ relational; (২) DynamoDB on-demand, বিশাল মাপে key দিয়ে access; (৩) ElastiCache sorted set (আবার বানানো যায়), বা durable হতে হলে MemoryDB; (৪) Neptune; (৫) S3 Glacier Deep Archive, কেউ বদলাতে না পারার দরকার হলে Object Lock সহ; (৬) Athena।

#তোমার Region-এ কী কী আছে দেখো

এই read-only command-গুলো দেখায় প্রতিটা service কোন কোন engine আর version দেয়। Region ap-southeast-1; output ছোট করা।

# RDS engines and versions (Db2 included)
aws rds describe-db-engine-versions --query 'DBEngineVersions[].Engine' --output text | tr '\t' '\n' | sort -u
#   aurora-mysql  aurora-postgresql  custom-oracle-ee  custom-sqlserver-ee  db2-ae  db2-se
#   mariadb  mysql  oracle-ee  oracle-se2  postgres  sqlserver-ee  sqlserver-ex  sqlserver-se  sqlserver-web

# Aurora PostgreSQL versions
aws rds describe-db-engine-versions --engine aurora-postgresql \
  --query 'DBEngineVersions[-3:].EngineVersion'
#   [ "16.6", "17.4", "17.5" ]

# ElastiCache and MemoryDB engines (Valkey is there)
aws elasticache describe-cache-engine-versions --query 'CacheEngineVersions[].Engine' --output text | tr '\t' '\n' | sort -u
#   memcached  redis  valkey
aws memorydb describe-engine-versions --query 'EngineVersions[].[Engine,EngineVersion]' --output text
#   redis   7.0
#   redis   7.1
#   valkey  7.2

# DocumentDB and Neptune use the RDS-style API (details in lesson 16.2)
aws docdb describe-db-engine-versions --query 'DBEngineVersions[].EngineVersion'
#   [ "4.0.0", "5.0.0", … ]   (lesson 16.2 checks which versions are current)
aws neptune describe-db-engine-versions --query 'DBEngineVersions[-1].EngineVersion'
#   "1.4.5.1"

# DynamoDB: one table, nothing to size in on-demand mode
aws dynamodb create-table --table-name carts-example \
  --attribute-definitions AttributeName=shopperId,AttributeType=S \
  --key-schema AttributeName=shopperId,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST
#   "TableStatus": "CREATING", "BillingModeSummary": { "BillingMode": "PAY_PER_REQUEST" }
aws dynamodb delete-table --table-name carts-example

Version-এর নম্বর প্রায়ই বদলায়; আসল কথা হলো চেহারাটা। RDS, Aurora, DocumentDB আর Neptune চায় engine, version আর instance। DynamoDB চাইল শুধু একটা key।

#সারসংক্ষেপ

মূল কথা

• বেছে নাও এই প্রশ্নগুলো করে: read/write-এর ভাগ, throughput আর হঠাৎ লাফ, data-র মাপ আর বৃদ্ধি, object-এর আকার, access pattern, durability আর আসল data কোথায়, latency, একসাথে কতজন, data model, join, schema, report, search, licence-এর খরচ।
• OLTP (অসংখ্য ছোট ACID transaction, row store) → RDS / Aurora। OLAP (ইতিহাস নিয়ে বড় প্রশ্ন, columnar) → Redshift; S3-এর file-এ SQL → Athena। OLTP primary-তে কখনো report না।
• NoSQL পরিবার: key-value DynamoDB, in-memory ElastiCache / MemoryDB, document DocumentDB, wide-column Keyspaces, graph Neptune, time series Timestream। সাথে object S3/Glacier আর search OpenSearch।
• RDS: Db2 সহ ছয়টা engine; Multi-AZ = synchronous, Region-এর ভেতরে HA; read replica = async, ১৫টা পর্যন্ত; PITR ১–৩৫ দিন; OS-এ ঢুকতে RDS Custom।
• Aurora: MySQL/PostgreSQL compatible, ৩ AZ-এ ৬টা copy, storage 128 TiB পর্যন্ত (নতুনে 256 TiB), ১৫টা replica, ৩০ সেকেন্ডের কমে failover, Serverless v2, Global Database।
• ElastiCache = cache (Redis/Valkey: persistence, Multi-AZ, data structure; Memcached: সাধারণ, multi-threaded)। MemoryDB = durable in-memory primary database।
• DynamoDB: serverless key-value, single-digit ms, on-demand বা provisioned (+ auto scaling), µs-এর জন্য DAX, Streams, Global Tables, 400 KB item।
• S3: এগারোটা নয়, ৫০ TB পর্যন্ত object; অজানা pattern-এ Intelligent-Tiering (ন্যূনতম মেয়াদ নেই), Deep Archive সবচেয়ে সস্তা, Object Lock compliance mode root-কেও আটকায়।
• QLDB-র support শেষ জুলাই ২০২৫-এ (Aurora PostgreSQL সুপারিশ)। Aurora DSQL আর Valkey নতুন; পরীক্ষার উত্তর এখনো Global Database আর “Redis”।

নিজেকে যাচাই করো: Database-এর ধরন আর কোনটা নেবে৩২টি প্রশ্ন