DocumentDB, Neptune, Keyspaces আর Timestream

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

• AWS কেন purpose-built database দেয়, সেটা বলতে, আর এই লেসনের চার রকম data-র আকার চিনতে: document, graph, wide-column partition আর time series।
• Amazon DocumentDB বোঝাতে: MongoDB-র সাথে মেলে এমন JSON document database, যার storage চলে Aurora-র মতো (একটাই cluster volume, তিনটা AZ-এ ছয়টা copy, নিজে নিজে বাড়ে), সাথে ১৫টা পর্যন্ত replica, failover আর reader endpoint; আর elastic cluster, global cluster ও serverless বিকল্প কোথায় বসে, তাও জানতে।
• Graph database কোন কাজটা SQL-এর চেয়ে ভালো পারে, সেটা ব্যাখ্যা করতে, property graph model (Gremlin, openCypher) আর RDF (SPARQL) আলাদা করতে, আর Amazon Neptune বোঝাতে: AZ জুড়ে ১৫টা পর্যন্ত read replica, শত কোটি সম্পর্ক, millisecond-এ traversal, আর পরীক্ষায় যে use case-গুলো আসে (social network, fraud ধরা, knowledge graph, recommendation)।
• Neptune Streams ঠিকভাবে ব্যবহার করতে: ক্রম মানা, duplicate-ছাড়া একটা change log, যা HTTP দিয়ে পড়া হয়, আর যা দিয়ে notification পাঠানো, OpenSearch, S3 বা ElastiCache-কে মিলিয়ে রাখা, বা অন্য Region-এ copy করা যায়; এর retention কত, আর Neptune Global Database কী করে, সেটাও জানতে।
• Apache Cassandra (masterless, wide-column, write-ভারী) আর Amazon Keyspaces বোঝাতে: serverless, CQL, AZ জুড়ে তিন copy, on-demand বা provisioned capacity, ৩৫ দিনের PITR, multi-Region replication, আর পরীক্ষার “existing Cassandra workload”-এর উত্তর।
• Time-series data কী আর Amazon Timestream কী, সেটা বলতে: serverless, memory store আর magnetic store, সময়ের function-সহ SQL, scheduled query, data ঢোকা আর দেখানোর architecture, আর ২০২৫-এর বদল, যার পরে নতুন customer-রা Timestream for Live Analytics-এর বদলে Timestream for InfluxDB পায়।
• প্রতিটা engine-এর জন্য একটা বাস্তব উদাহরণ দিতে, সেখানে কেন সেটা DynamoDB বা RDS-কে হারায় বলতে, আর পরীক্ষার keyword দেখে বেছে নিতে; ভুল পছন্দগুলোও ধরতে (graph-কে SQL self-join বানানো, time series দিয়ে RDS ফুলিয়ে ফেলা, document-এ ping-এর স্রোত ঢালা)।

#Purpose-built database কেন

Lesson 16.1-এ তুমি দেখেছ কোন প্রশ্নগুলো নিজেকে করতে হয়, আর পেয়েছ বাছাইয়ের ম্যাপ: transaction আর join-এর জন্য relational (RDS, Aurora), যেকোনো scale-এ key-value (DynamoDB), in-memory (ElastiCache, MemoryDB), object (S3), analytics-এর জন্য warehouse আর search (Redshift, OpenSearch)। ওই ম্যাপে আরও চারটা ঘর আছে, আর সেগুলোই এই লেসন। প্রতিটার জন্ম হয়েছে কারণ কিছু data-র এমন একটা আকার আছে, যেটা সাধারণ database ভালো রাখতে পারে না:

AWS এর নাম দিয়েছে purpose-built database: সব রকম data জোর করে একটা relational engine-এ না ঢুকিয়ে, এমন engine বাছো যার model data আর প্রশ্নের সাথে মেলে। বাস্তবের একটা application প্রায়ই একসাথে কয়েকটা ব্যবহার করে। তাতে কোনো সমস্যা নেই; প্রত্যেকে সেই data রাখে, যেটাতে সে ভালো।

একই কথা একটা ride-sharing app-এর একটা ride দিয়ে পরখ করো। একটা engine আর একটা প্রশ্ন বেছে দেখো কোন জোড়া মেলে:

মনে রাখার pattern: DocumentDB “এই জিনিসটা আনো”-র জন্য, Neptune “সংযোগ ধরে এগোও”-র জন্য, Keyspaces “স্রোতের মতো লেখো, key দিয়ে ফেরত পড়ো”-র জন্য, Timestream “সময়ের সাথে কী ঘটল”-র জন্য। Explorer-এ যেগুলো মানায় না, সেগুলোর প্রতিটাই পরীক্ষার একেকটা ফাঁদ।

#Amazon DocumentDB

#এটা কী

Amazon DocumentDB (with MongoDB compatibility) হলো fully managed একটা JSON document database, যেটা MongoDB API-তে কথা বলে। তোমার application তার MongoDB driver, query (find, insertOne, aggregation pipeline) আর mongosh-এর মতো tool সব রেখে দেয়; শুধু একটা DocumentDB endpoint-এর দিকে তাক করে। Hardware, patch, backup, replication আর failover সামলায় AWS।

একটা document হলো একটা JSON object (১৬ MB পর্যন্ত), থাকে একটা collection-এ। এক collection-এর সব document-এর field এক রকম হতে হয় না, ভেতরে object আর array থাকতে পারে, আর যেকোনো field-এ index বানানো যায়, ভেতরের nested field-এও। শুধু key দিয়ে না, index করা যেকোনো field দিয়ে query করা যায়।

DocumentDB হলো AWS-এর নিজের engine, যেটা MongoDB API মেনে চলে; MongoDB-র source code না। এটা MongoDB 3.6, 4.0, 5.0 আর ২০২৫ থেকে 8.0 API-র সাথে মেলে। বেশিরভাগ application কিছু না বদলেই চলে, কিন্তু MongoDB-র কিছু feature নেই বা একটু অন্যভাবে চলে, তাই migrate করার আগে compatibility তালিকা দেখে নাও। Notes-এ নাম লেখা “AWS DocumentDB”; আসল নাম Amazon DocumentDB (with MongoDB compatibility)।

#MongoDB-র জন্য Aurora-র architecture

Slide এক লাইনে বলে দেয়: Aurora হলো MySQL আর PostgreSQL-এর AWS-এর নিজস্ব রূপ, আর DocumentDB একই ধারণা MongoDB-র জন্য। Deployment-এর ধারণাগুলো Aurora-র মতোই (lesson 7.3), কারণ compute আর storage আলাদা (notes-এ লেখা “disconnected”; ঠিক শব্দটা হলো decoupled, মানে আলাদা করা):

• একটাই cluster volume-এ data থাকে, SSD-তে, তিনটা Availability Zone জুড়ে ছয়টা copy হিসেবে। বেশিরভাগ copy-তে পৌঁছালেই write acknowledge হয়, তাই একটা পুরো AZ গেলেও কিছু হারায় না।
• Data বাড়লে storage নিজে নিজেই বাড়ে, আর যতটুকু ব্যবহার, ততটুকুরই দাম, প্রতি cluster-এ ১২৮ TiB পর্যন্ত (engine 8.0-তে ২৫৬ TiB)। Slide-এর “১০ GB করে বাড়ে” কথাটা একই আচরণের পুরোনো বর্ণনা; storage কখনো আগে থেকে বরাদ্দ করতে হয় না।
• Instance শুধু হিসাব করে: একটা primary, যে read আর write করে, আর ১৫টা পর্যন্ত replica, যারা শুধু read করে। Replica-রা একই volume পড়ে, তাই সাধারণত ১০০ ms-এরও কম পিছিয়ে থাকে, আর data যত বড়ই হোক, কয়েক মিনিটে যোগ করা যায়।
• Endpoint: cluster endpoint সবসময় এখনকার primary-কে দেখায় (write-এর জন্য এটা), reader endpoint replica-দের মধ্যে connection ভাগ করে, আর প্রতিটা instance-এর নিজের endpoint থাকে (application-এ এটা এড়িয়ে চলো)।
• Failover: primary নষ্ট হলে একটা replica-কে (priority tier তুমি ঠিক করো) primary বানানো হয়, cluster endpoint তার দিকে ঘুরে যায়, সাধারণত এক মিনিটেরও অনেক কম সময়ে, আর storage shared বলে কোনো data হারায় না। কোনো replica না থাকলে DocumentDB-কে নতুন primary বানাতে হয়, যাতে অনেক বেশি সময় লাগে।
• Replica থেকে read eventually consistent; driver-এর read preference ঠিক করে কোথা থেকে পড়বে: write-এর পরেই ঠিক data চাইলে primary, primary-র চাপ কমাতে secondaryPreferred।
• Backup চলে অবিরাম, point-in-time restore সহ (১ থেকে ৩৫ দিন), at rest encryption হয় KMS দিয়ে (lesson 21.2), আর cluster থাকে তোমার VPC-র ভেতরে।

Slide-এর “প্রতি সেকেন্ডে লাখ লাখ request সামলায়” কথাটা সত্যি elastic cluster-এর বেলায় (নিচে), যেটা data-কে shard করে ভাগ করে। সাধারণ instance-ভিত্তিক cluster-এ writer একটাই, read বাড়ানো হয় replica দিয়ে।

#DynamoDB বা RDS না নিয়ে DocumentDB কেন

#পাশের কথা: elastic cluster, global cluster আর serverless

#Amazon Neptune

#Graph: vertex, edge আর property

একটা graph রাখে vertex (node-ও বলে: মানুষ, wallet, phone, product, জায়গা) আর edge (সম্পর্ক: চেনে, ব্যবহার করেছে, কিনেছে, অবস্থিত), আর দুটোরই property থাকতে পারে (নাম, টাকার অঙ্ক, তারিখ)। Graph database-এর আসল কথা হলো সম্পর্কগুলো রাখা থাকে, হিসাব করে বের করতে হয় না: প্রতিটা vertex তার edge নিজের কাছে রাখে, তাই একটা vertex থেকে পাশেরগুলোতে যাওয়া একটা সস্তা ধাপ, একে বলে hop বা লাফ, graph যত বড়ই হোক। Query মানে একটা traversal: কোথাও থেকে শুরু করে edge ধরে ধরে এগোনো।

Relational database-এ একই data থাকে table-এ, আর প্রতিটা লাফ একটা join। এক-দুটো join-এ সমস্যা নেই। কিন্তু “বন্ধুর বন্ধুর বন্ধু” বা “flagged account থেকে ছয়টা লেনদেনের মধ্যে যেকোনো account” হয়ে দাঁড়ায় বিশাল table-এর ওপর একের পর এক self-join, যার মাঝের ফল গুণ হয়ে বাড়ে; query ধীর হয়, লেখা কঠিন হয়, ঠিকঠাক চালানো আরও কঠিন। Notes সহজ করে বলে: সম্পর্কগুলো যখন জটিল আর খুব বেশি জড়ানো, তখন relational আর সাধারণ NoSQL database হিমশিম খায়, আর সেখানেই আসে Neptune। (Data তারা রাখতে পারে ঠিকই; শুধু অনেক লাফের প্রশ্নের উত্তর খারাপভাবে দেয়।)

#Property graph না RDF

Neptune দুটো graph model সমর্থন করে, প্রত্যেকটার নিজের query language আছে। Notes-এ আছে Gremlin আর SPARQL; তৃতীয়টা openCypher, এখন খুব চালু:

একটা Neptune cluster একই property graph Gremlin আর openCypher দুই দিয়েই দিতে পারে; RDF data query হয় SPARQL দিয়ে।

#Neptune তোমাকে কী দেয়

• Fully managed graph database, শত কোটি সম্পর্ক রেখে millisecond latency-তে query করার জন্য বানানো।
• Aurora-র মতোই cluster-এর নকশা: একটা primary যে write করে, ১৫টা পর্যন্ত read replica, তিনটা AZ জুড়ে replicate করা একটা shared cluster volume (নিজে নিজে বাড়ে, ১২৮ TiB পর্যন্ত), replica-তে automatic failover, S3-এ অবিরাম backup আর point-in-time restore, KMS দিয়ে encryption, তোমার VPC-র ভেতরে।
• HTTPS-এ endpoint (default port 8182): /gremlin, /openCypher, /sparql, সাথে একটা bulk loader, যেটা S3 থেকে CSV বা RDF file import করে।
• Neptune-এ writer একটাই, data shard করা হয় না: read বাড়ে replica দিয়ে, write বাড়ে বড় primary দিয়ে। প্রতি সেকেন্ডে লাখ লাখ ছোট write-এর স্রোত DynamoDB বা Keyspaces-এর কাজ, graph-এর না।

#Graph যেখানে জেতে

Slide-এর চেনা উদাহরণ একটা social network: user-দের বন্ধু আছে, post-এ comment আছে, comment-এ user-দের like আছে, user-রা post share করে আর like দেয়। Notes আর slide পরীক্ষার যে ব্যবহারগুলোর নাম বলে:

• Social network: কে কার সাথে যুক্ত, “যাদের তুমি চিনতে পারো”, mutual friend।
• আর্থিক লেনদেনে fraud ধরা: একই device, ঠিকানা বা cash-out-এর জায়গা ভাগ করা account-এর চক্র।
• Recommendation engine: “যারা এটা কিনেছে, তারা এটাও কিনেছে”, কেনাকাটার পথ ধরে।
• Knowledge graph (Wikipedia-র মতো, বা একটা কোম্পানির product, document আর মানুষ), network আর IT নিরাপত্তার ম্যাপ, ওষুধ আবিষ্কার।

#DynamoDB বা RDS না নিয়ে Neptune কেন

DynamoDB-তে join-ই নেই; সম্পর্ক ধরে এগোতে হলে application code থেকে প্রতি লাফে একটা করে request। RDS join করতে পারে, কিন্তু প্রতিটা লাফ একটা join, data বাড়লে যার খরচও বাড়ে, আর গভীর বা অনির্দিষ্ট গভীরতার প্রশ্ন (“যত লাফেই হোক”) SQL-এ যন্ত্রণার। যখন সম্পর্কগুলোই আসল data, তখন অন্যরা যে উত্তর সেকেন্ড বা মিনিটে দেয়, graph database সেটা দেয় millisecond-এ। আর data যদি মূলত আলাদা আলাদা record হয়, তাহলে Neptune বাড়াবাড়ি: রসিদ রাখো DocumentDB বা DynamoDB-তে, সংযোগের জন্য graph।

#Neptune Streams

Neptune Streams হলো graph-এর একটা change log। চালু করলে (cluster parameter neptune_streams = 1), প্রতিটা বদল (vertex বা edge যোগ, property বদল, triple মুছে ফেলা) বদলটার সাথে একই transaction-এ stream-এ লেখা হয়। এর নিশ্চয়তাগুলো:

• সাথে সাথে আর ক্রম মেনে: transaction commit হওয়ামাত্র record পাওয়া যায়, ঠিক যে ক্রমে বদল হয়েছে সেই ক্রমে, একটা transaction-এর ভেতরের ক্রমসহ।
• Duplicate নেই, কিছু বাদও পড়ে না: প্রতিটা বদল ঠিক একবার আসে।
• HTTP REST API দিয়ে পড়া: reader একটা commit number থেকে শুরু করে /propertygraph/stream-এ (Gremlin আর openCypher-এর data) বা /sparql/stream-এ (RDF) HTTP GET পাঠায়, আর পাতার পর পাতা record পড়ে। Writer বা replica, যেকোনোটা থেকে পড়া যায়।
• Retention: default-এ ৭ দিন পরে record মুছে যায়, ১ থেকে ৯০ দিন পর্যন্ত বদলানো যায় (neptune_streams_expiry_days)। Stream বন্ধ করলে log সাথে সাথে পড়ার অযোগ্য হয়ে যায়।
• এতে I/O আর storage-এর খরচ বাড়ে, write একটু ধীর হয়। এটা নিজে থেকে Lambda চালায় না: একটা poller চালাতে হয় (AWS একটা তৈরি poller দেয়, যেটা schedule-এ Lambda চালায়)।

Slide-এর use case-গুলো:

১. নির্দিষ্ট কিছু বদল হলে notification পাঠানো (কোনো wallet flagged device-এর সাথে যুক্ত হলো → fraud team-কে alert)। ২. Graph-এর data অন্য store-এ মিলিয়ে রাখা: archive-এর জন্য S3, full-text search-এর জন্য OpenSearch (graph কোনো search engine না), cache-এর জন্য ElastiCache। ৩. অন্য Neptune cluster-এ Region জুড়ে replicate করা।

#পাশের কথা: Neptune Serverless, Neptune Analytics, Global Database

#Amazon Keyspaces (for Apache Cassandra)

#এক মিনিটে Apache Cassandra

Apache Cassandra হলো open-source, ব্যাপকভাবে ছড়ানো একটা wide-column NoSQL database। কেন এটা এত জনপ্রিয়:

• Masterless: সব node সমান, যেকোনোটা read আর write নিতে পারে, partition key-র hash দেখে data node-এর একটা আংটির মতো সাজানো ring-এ ছড়ানো থাকে, আর কয়েকটা node-এ copy হয়। কোনো একক point of failure নেই।
• Write-এর জন্য বানানো: write একটা log আর memory-তে যোগ হয়, তাই খুব write-ভারী workload, petabyte-এর মাপে, কয়েকটা data center জুড়ে, এটাই এর ঘরের মাঠ: IoT data logging, time-series tracking, messaging, activity feed।
• Wide-column data model: একটা table-এর একটা partition key থাকে (ঠিক করে row কোন partition-এ, মানে কোন node-গুলোতে থাকবে), আর ইচ্ছে হলে clustering column (partition-এর ভেতরে row সাজায়)। Join নেই, তাই প্রতিটা query-র জন্য একটা table বানাতে হয়, দরকারমতো data একাধিক জায়গায় লিখে (denormalise করে)।
• CQL (Cassandra Query Language) দেখতে SQL-এর মতো: create table, insert, select … where ride_id = …।

দামটা দিতে হয় চালানোয়: কাউকে না কাউকে cluster চালাতে হয়, node patch আর বদলাতে হয়, repair চালাতে হয়, compaction ঠিক করতে হয়, প্রতিটা ভিড়ের আগে node যোগ করতে হয়, backup নিতে হয়।

#Keyspaces তোমার হয়ে কী সামলায়

Amazon Keyspaces (for Apache Cassandra) হলো managed, serverless, Cassandra-র সাথে মেলে এমন database। Cluster বানানো নেই, node সামলানো নেই, software upgrade নেই: তুমি keyspace আর table বানাও, আর তোমার আগের Cassandra driver আর cqlsh দিয়েই CQL চালাও, শুধু Keyspaces endpoint-এর দিকে তাক করে (port 9142, TLS বাধ্যতামূলক, authentication হয় SigV4 plugin দিয়ে IAM-এ, বা service-specific credential দিয়ে)।

• Highly available: প্রতিটা write একাধিক AZ জুড়ে তিনবার জমা হয় (write সবসময় LOCAL_QUORUM-এ; read হতে পারে LOCAL_QUORUM, ONE বা LOCAL_ONE)।
• যেকোনো scale-এ দ্রুত: এক অঙ্কের millisecond latency, প্রতি table-এ প্রতি সেকেন্ডে হাজার হাজার request বা আরও বেশি, storage কার্যত সীমাহীন। Traffic অনুযায়ী table নিজে নিজে বড়-ছোট হয়।
• Capacity: on-demand (প্রতি read আর write-এ দাম, আগে থেকে আন্দাজ করা যায় না এমন traffic-এর জন্য) বা auto scaling সহ provisioned (আন্দাজ করা যায় এমন traffic-এর জন্য, সস্তা)। একটা table-এর mode দিনে একবার বদলানো যায়।
• Backup আর নিরাপত্তা: at rest (AWS-এর key বা তোমার KMS key) আর in transit encryption সবসময় চালু; প্রতি table-এ চালু করা যায় point-in-time recovery, শেষ ৩৫ দিনের যেকোনো সেকেন্ডে ফেরা যায়; row-এর মেয়াদ শেষে মুছতে TTL; IAM আর VPC endpoint।
• Multi-Region replication (২০২৩): কয়েকটা Region-এ একটা active-active keyspace, প্রতিটা Region নিজের জায়গায় read আর write করে, বদল সাধারণত এক সেকেন্ডের মধ্যে replicate হয়, গোলমাল মেটে timestamp দেখে (শেষে যে লিখেছে সে জেতে)। CDC stream (২০২৫) row-এর বদল প্রকাশ করে, অন্য system সেগুলো নিতে পারে।
• Cassandra-র সব feature নেই (যেমন materialized view বা user-defined function নেই), তাই আগে compatibility দেখে নাও।

Notes বলে Keyspaces নিলে backup নিয়ে আর ভাবতে হয় না। আরও ঠিক করে বললে: চালানোর মতো কিছু নেই, কিন্তু PITR তোমাকেই চালু করতে হবে; এটা একটা setting, default না।

#DynamoDB না নিয়ে Keyspaces কেন

দুটোই serverless, key দিয়ে ভাগ করা NoSQL service, এক অঙ্কের millisecond latency, on-demand বা provisioned capacity, PITR আর multi-Region replication আছে। পার্থক্য API-তে: Keyspaces CQL-এ কথা বলে, তাই আগে থেকে চলা একটা Cassandra application তার code, driver আর data model অক্ষত রেখে চলে আসে। Cassandra-র কোনো ইতিহাস নেই এমন নতুন application সাধারণত DynamoDB নেয়, যার AWS-এর সাথে মেলবন্ধন বেশি গভীর (Lambda-তে Streams, DAX, global table, chapter 15-এর serverless pattern)। আর EC2-তে নিজের চালানো Cassandra-র তুলনায় Keyspaces node চালানোর সব কাজ সরিয়ে দেয়।

#Amazon Timestream

#Time-series data কী

Time-series data হলো মাপের একটা ধারা, যার প্রতিটায় একটা সময়ের ছাপ: প্রতি মিনিটে একটা meter-এর kWh, প্রতি ১০ সেকেন্ডে একটা server-এর CPU, একটা sensor-এর তাপমাত্রা, ঘটার সাথে সাথে page-এর click। ব্যবসার record-এর সাথে এর অভ্যাস মেলে না:

• আসে দ্রুত আর অবিরাম, আর প্রায় সবসময় শুধু যোগ হয়, কদাচিৎ বদলায়;
• query হয় সময়ের জানালা ধরে: গত এক ঘণ্টা, ৫ মিনিট করে, আজ বনাম গত সপ্তাহ;
• নতুন data গরম, বারবার পড়া হয়; পুরোনো data কম পড়া হয়, আর সেটা সস্তায় রাখা উচিত, তারপর মুছে ফেলা।

একটা relational table এটা রাখতে পারে, কিন্তু দিনে লাখ লাখ row হলে index, storage আর মোছামুছি একটা পুরো সময়ের চাকরি হয়ে যায়, আর জানালা ধরে query ধীর হয়। Time-series database এই অভ্যাসগুলো মাথায় রেখেই বানানো।

#Timestream for Live Analytics

Amazon Timestream for Live Analytics (আসল Timestream, notes আর slide যেটার কথা বলে) হলো fully managed, serverless time-series database:

• সামলানোর মতো কোনো server বা capacity নেই: নিজে নিজে বড়-ছোট হয়, দিনে লক্ষ কোটি event রাখে আর বিশ্লেষণ করে। AWS-এর দাবি, time-series-এর কাজে relational database-এর চেয়ে ১,০০০ গুণ পর্যন্ত দ্রুত, খরচ দশ ভাগের এক ভাগ।
• Data model: একটা record-এ থাকে একটা time, উৎসের পরিচয় দেওয়া কিছু dimension (meter_id, area) আর এক বা একাধিক measure (kwh); multi-measure record একই মুহূর্তের কয়েকটা measure এক row-এ রাখে।
• Storage tiering (notes-এর auto-tiering): নতুন data থাকে memory store-এ, দ্রুত write আর তাৎক্ষণিক query-র জন্য বানানো; memory retention-এর চেয়ে পুরোনো হলেই সেটা নিজে থেকে চলে যায় খরচ-বাঁচানো magnetic store-এ, যেটা লম্বা সময়ের analytical query-র জন্য সাজানো। একটা query দুটোই পড়ে। প্রতি table-এ দুটো retention তুমি ঠিক করো (memory ১ ঘণ্টা থেকে ১ বছর, magnetic ১ দিন থেকে ২০০ বছর); magnetic retention পার হলে data মুছে যায়।
• Memory retention-এর চেয়ে পুরোনো দেরিতে আসা data বাতিল হয়, যদি না table-এ magnetic store write চালু থাকে।
• Time-series-এর built-in function-সহ SQL: bin(), ago(), ফাঁক পূরণের interpolation, smoothing, প্রায় সাথে সাথে trend আর pattern বিশ্লেষণ।
• Scheduled query নিজে থেকেই rollup (ঘণ্টার গড়, দিনের মোট) হিসাব করে আরেকটা table-এ রাখে, তাই dashboard ছোট table পড়ে।
• In transit আর at rest encryption সবসময় চালু (magnetic store-এর জন্য KMS key)।

Notes-এর ব্যবহারগুলো: IoT sensor-এর data (তাপমাত্রা, চাপ), DevOps metrics (সময়ের সাথে CPU আর memory), e-commerce clickstream; slide যোগ করে operational application আর real-time analytics।

#২০২৫-এর বদল: Live Analytics নাকি InfluxDB

#Architecture: data কোথা থেকে আসে, কোথায় যায়

Slide-এর architecture পাতাটা তালিকা করে:

• Timestream-এ ঢোকে: AWS IoT Core থেকে (একটা IoT rule action device-এর message সরাসরি লেখে), Kinesis Data Streams (lesson 13.5) বা Amazon MSK থেকে Amazon Managed Service for Apache Flink হয়ে (যেটা stream-এর হিসাব করে ফল লেখে; slide-এ এর পুরোনো নাম, Kinesis Data Analytics for Apache Flink), Lambda থেকে (যেকোনো application event), আর infrastructure-এর metrics-এর জন্য Prometheus আর Telegraf থেকে।
• Timestream থেকে বের হয়: ব্যবসার dashboard-এর জন্য Amazon QuickSight-এ, operational dashboard-এর জন্য Grafana-য়, পুরোনো series-এর ওপর machine learning-এর জন্য Amazon SageMaker-এ, আর Timestream-এর JDBC driver দিয়ে যেকোনো JDBC client-এ।

#RDS বা DynamoDB না নিয়ে Timestream কেন

RDS reading রাখতে পারে, কিন্তু tiering, rollup আর মেয়াদ শেষে মোছা তোমার ঘাড়ে ছেড়ে দেয়, আর প্রতিটা insert-এ এর index বাড়ে। DynamoDB device আর সময় ধরে রাখতে পারে (মেয়াদ শেষে মুছতে TTL সহ), কিন্তু device আর সময়ের জানালা জুড়ে SQL aggregation নেই। Timestream ঠিক এই তিনটা কাজ নিজেই করে: বয়স অনুযায়ী সস্তা storage, সময়ের function, scheduled rollup।

#চারটা পাশাপাশি

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

#System design-এ purpose-built database

• Polyglot persistence। একটা application, কয়েকটা database, প্রত্যেকে যেটায় ভালো সেটা রাখে। ঢাকার দোকানটা: order Aurora-য় (transaction), catalogue DocumentDB-তে (document), session আর cart DynamoDB বা ElastiCache-এ, “যারা এটা কিনেছে তারা এটাও কিনেছে” Neptune-এ (graph), delivery bike-এর location ping Keyspaces-এ, site-এর metrics আর clickstream Timestream-এ, report Redshift-এ (lesson 17.2) আর search OpenSearch-এ (lesson 17.3)।
• প্রতিটা তথ্যের সত্যের উৎস একটাই। একই data দুই store-এ থাকলে ঠিক করো কোনটা আসল, আর কপি করো এক দিকে: Neptune Streams, DocumentDB change stream, DynamoDB Streams বা Keyspaces CDC stream বাকিদের খাওয়ায়। Application থেকে দুটো database-এ লিখে দুটোই সফল হবে, এই আশায় বসে থেকো না।
• প্রশ্ন থেকে নকশা। “এই জিনিসটা দেখাও”-র জন্য document, “সংযোগ ধরে এগোও”-র জন্য graph, “অনেক লেখো, key দিয়ে পড়ো”-র জন্য wide-column, “সময়ের সাথে কী ঘটল”-র জন্য time series। প্রশ্নের তালিকা যদি লম্বা আর এলোমেলো হয়, relational database বা warehouse হয়তো ভালো।
• Scale কীভাবে হয় জানো। DocumentDB আর Neptune: writer একটা, reader অনেক (বা DocumentDB elastic cluster দিয়ে sharding)। Keyspaces আর Timestream: serverless, write-ও বাড়ে।
• Migration-এর পথ। MongoDB → DocumentDB (DMS, mongodump), Cassandra → Keyspaces (cqlsh copy, dsbulk, দুই জায়গায় write), time series → Timestream for InfluxDB; DMS আছে migration chapter-এ (lesson 23.3)।

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

প্রত্যেকটার একটা করে বানাও, আর প্রত্যেকে যে query-তে ভালো সেটা চালাও। Output ছোট করে দেখানো; নাম, endpoint আর সংখ্যা উদাহরণ মাত্র। শেষে সব মুছে ফেলো: DocumentDB আর Neptune-এর instance ঘণ্টা ধরে bill হয়।

1. ১. Catalogue-এর জন্য একটা DocumentDB cluster

   aws docdb create-db-cluster --db-cluster-identifier shop-catalog \
     --engine docdb --engine-version 5.0.0 \
     --master-username shopadmin --master-user-password 'choose-a-strong-one' \
     --vpc-security-group-ids sg-0abc1234example --db-subnet-group-name shop-db-subnets
   
   aws docdb create-db-instance --db-instance-identifier shop-catalog-1 \
     --db-cluster-identifier shop-catalog --engine docdb --db-instance-class db.t4g.medium
   

   "DBClusterIdentifier": "shop-catalog",
   "Endpoint": "shop-catalog.cluster-c1ab2cd3ef4g.ap-southeast-1.docdb.amazonaws.com",
   "ReaderEndpoint": "shop-catalog.cluster-ro-c1ab2cd3ef4g.ap-southeast-1.docdb.amazonaws.com",
   "Status": "creating"
   

   একই VPC-র একটা EC2 instance থেকে mongosh আর TLS দিয়ে connect করো (আগে CA bundle global-bundle.pem নামিয়ে নাও), তারপর দুই রকম আকারের দুটো product ঢোকাও আর একটা nested field দিয়ে query করো:

   mongosh "mongodb://shopadmin@shop-catalog.cluster-c1ab2cd3ef4g.ap-southeast-1.docdb.amazonaws.com:27017/?tls=true&tlsCAFile=global-bundle.pem&replicaSet=rs0&readPreference=secondaryPreferred&retryWrites=false"
   

   db.products.insertOne({ _id: "p-7001", type: "phone", name: "Walton Primo X", specs: { ram: 8, storage: 128 }, price: 18500 })
   db.products.insertOne({ _id: "p-8120", type: "saree", name: "Jamdani", fabric: "cotton", length_m: 5.5, price: 7200 })
   db.products.createIndex({ "specs.ram": 1 })
   db.products.find({ "specs.ram": { $gte: 8 } })
   // [ { _id: 'p-7001', type: 'phone', name: 'Walton Primo X', ... } ]
   

   retryWrites=false খেয়াল করো: DocumentDB retryable write সমর্থন করে না।

2. ২. একটা Neptune cluster আর বন্ধুর বন্ধুর query

   aws neptune create-db-cluster --db-cluster-identifier wallet-graph --engine neptune \
     --serverless-v2-scaling-configuration MinCapacity=1,MaxCapacity=8 \
     --vpc-security-group-ids sg-0abc1234example --db-subnet-group-name graph-subnets
   
   aws neptune create-db-instance --db-instance-identifier wallet-graph-1 \
     --db-cluster-identifier wallet-graph --engine neptune --db-instance-class db.serverless
   

   VPC-র ভেতর থেকে port 8182-এ HTTPS দিয়ে openCypher পাঠাও (IAM authentication চালু থাকলে request sign করতে হতো, যেমন awscurl দিয়ে):

   curl -s https://wallet-graph.cluster-c1ab2cd3ef4g.ap-southeast-1.neptune.amazonaws.com:8182/openCypher \
     -d "query=CREATE (h:Person {name:'Hasan'})-[:KNOWS]->(r:Person {name:'Rina'})-[:KNOWS]->(m:Person {name:'Mitu'})"
   
   curl -s https://wallet-graph.cluster-c1ab2cd3ef4g.ap-southeast-1.neptune.amazonaws.com:8182/openCypher \
     -d "query=MATCH (:Person {name:'Hasan'})-[:KNOWS]->()-[:KNOWS]->(fof) RETURN fof.name"
   

   {"results":[{"fof.name":"Mitu"}]}
   

3. ৩. Neptune Streams চালু করে change log পড়া

   aws neptune create-db-cluster-parameter-group --db-cluster-parameter-group-name graph-streams \
     --db-parameter-group-family neptune1.4 --description "streams on"
   aws neptune modify-db-cluster-parameter-group --db-cluster-parameter-group-name graph-streams \
     --parameters "ParameterName=neptune_streams,ParameterValue=1,ApplyMethod=pending-reboot" \
                  "ParameterName=neptune_streams_expiry_days,ParameterValue=14,ApplyMethod=pending-reboot"
   aws neptune modify-db-cluster --db-cluster-identifier wallet-graph \
     --db-cluster-parameter-group-name graph-streams
   aws neptune reboot-db-instance --db-instance-identifier wallet-graph-1
   

   নতুন একটা write-এর পরে প্রথম commit থেকে stream পড়ো:

   curl -s "https://wallet-graph.cluster-c1ab2cd3ef4g.ap-southeast-1.neptune.amazonaws.com:8182/propertygraph/stream?iteratorType=TRIM_HORIZON&limit=2"
   

   {"lastEventId":{"commitNum":12,"opNum":2},"lastTrxTimestamp":1793256300000,"format":"PG_JSON",
    "records":[{"eventId":{"commitNum":12,"opNum":1},"op":"ADD","data":{"id":"...","type":"vl","key":"label","value":{"value":"Person","dataType":"String"}}}, ...],
    "totalRecords":2}
   

   একটা reader commitNum-কে checkpoint হিসেবে রাখে, আর পরের বার চায় iteratorType=AFTER_SEQUENCE_NUMBER&commitNum=12।

4. ৪. Ride ping-এর জন্য একটা Keyspaces table

   aws keyspaces create-keyspace --keyspace-name rides
   
   aws keyspaces create-table --keyspace-name rides --table-name pings \
     --schema-definition 'allColumns=[{name=ride_id,type=text},{name=ts,type=timestamp},{name=lat,type=double},{name=lon,type=double}],partitionKeys=[{name=ride_id}],clusteringKeys=[{name=ts,orderBy=DESC}]' \
     --capacity-specification throughputMode=PAY_PER_REQUEST \
     --point-in-time-recovery status=ENABLED
   

   cqlsh দিয়ে connect করো (cqlsh-expansion package TLS আর SigV4 plugin জুড়ে দেয়), তারপর সাধারণ CQL চালাও:

   pip install cqlsh-expansion
   cqlsh-expansion cassandra.ap-southeast-1.amazonaws.com 9142 --ssl --auth-provider SigV4AuthProvider
   

   CONSISTENCY LOCAL_QUORUM;
   INSERT INTO rides.pings (ride_id, ts, lat, lon) VALUES ('r-5001', '2026-10-29 18:04:12', 23.7949, 90.4043);
   INSERT INTO rides.pings (ride_id, ts, lat, lon) VALUES ('r-5001', '2026-10-29 18:04:16', 23.7941, 90.4055);
   SELECT ts, lat, lon FROM rides.pings WHERE ride_id = 'r-5001';
   --  ts                              | lat     | lon
   --  2026-10-29 18:04:16.000000+0000 | 23.7941 | 90.4055
   --  2026-10-29 18:04:12.000000+0000 | 23.7949 | 90.4043
   SELECT * FROM rides.pings WHERE lat > 23.79;
   -- InvalidRequest: ... use ALLOW FILTERING
   

   দ্বিতীয় query-তে partition key নেই, তাই Keyspaces সেটা ফিরিয়ে দেয়: animation-এ দেখা নকশার নিয়মটাই।

5. ৫. Timestream: reading লেখা আর সময়ের জানালা ধরে query

   যে account আগে থেকেই Timestream for Live Analytics ব্যবহার করে, সেখানে:

   aws timestream-write create-database --database-name smartmeter
   aws timestream-write create-table --database-name smartmeter --table-name readings \
     --retention-properties MemoryStoreRetentionPeriodInHours=24,MagneticStoreRetentionPeriodInDays=365 \
     --magnetic-store-write-properties EnableMagneticStoreWrites=true
   
   aws timestream-write write-records --database-name smartmeter --table-name readings \
     --records '[{"Dimensions":[{"Name":"meter_id","Value":"m-1001"},{"Name":"area","Value":"Mirpur"}],
                  "MeasureName":"kwh","MeasureValue":"0.42","MeasureValueType":"DOUBLE",
                  "Time":"1793257500000","TimeUnit":"MILLISECONDS"}]'
   
   aws timestream-query query --query-string \
     "SELECT area, bin(time, 5m) AS t, avg(measure_value::double) AS kwh FROM smartmeter.readings WHERE time > ago(1h) GROUP BY area, bin(time, 5m) ORDER BY t"
   

   "Rows": [ { "Data": [ {"ScalarValue": "Mirpur"}, {"ScalarValue": "2026-10-29 19:05:00.000000000"}, {"ScalarValue": "0.42"} ] } ]
   

   নতুন account-এ প্রথম command-ই fail করে, কারণ Live Analytics আর নতুন customer নেয় না। সেখানে বরং একটা managed InfluxDB instance বানাও:

   aws timestream-influxdb create-db-instance --name meters --db-instance-type db.influx.medium \
     --allocated-storage 20 --password 'choose-a-strong-one' \
     --vpc-subnet-ids subnet-0abc1234example --vpc-security-group-ids sg-0abc1234example
   

6. ৬. পরিষ্কার করা

   aws docdb delete-db-instance --db-instance-identifier shop-catalog-1
   aws docdb delete-db-cluster --db-cluster-identifier shop-catalog --skip-final-snapshot
   aws neptune delete-db-instance --db-instance-identifier wallet-graph-1
   aws neptune delete-db-cluster --db-cluster-identifier wallet-graph --skip-final-snapshot
   aws keyspaces delete-keyspace --keyspace-name rides
   aws timestream-write delete-table --database-name smartmeter --table-name readings
   aws timestream-write delete-database --database-name smartmeter
   

#সারসংক্ষেপ

মূল কথাগুলো

• Purpose-built database engine-কে data-র আকারের সাথে মেলায়: document, graph, wide-column, time series। পুরো বাছাইয়ের ম্যাপ lesson 16.1-এ; বাস্তবের system কয়েকটা একসাথে ব্যবহার করে।
• DocumentDB = managed MongoDB-compatible JSON document database, Aurora-র architecture-এ: একটাই cluster volume, ৩ AZ-এ ৬ copy, নিজে নিজে বাড়ে (১২৮ TiB পর্যন্ত, 8.0-তে ২৫৬ TiB), একটা primary + ১৫টা পর্যন্ত replica, cluster আর reader endpoint, দ্রুত failover। Elastic cluster shard করে, global cluster Region পার হয়, serverless নতুন। Keyword: MongoDB → DocumentDB।
• Neptune = managed graph database: শত কোটি সম্পর্ক, millisecond-এ traversal, ৩ AZ জুড়ে ১৫টা read replica। Property graph-এ Gremlin / openCypher, RDF-এ SPARQL। Social network, fraud, knowledge graph, recommendation। ধীর বিকল্পটা হলো SQL self-join।
• Neptune Streams = একই transaction-এ লেখা, ক্রম মানা, duplicate-ছাড়া change log, পড়া হয় HTTP REST দিয়ে; notification, OpenSearch / S3 / ElastiCache-এ মিলিয়ে রাখা, Region জুড়ে copy। Default retention ৭ দিন (১–৯০)। Region জুড়ে managed DR হলো Global Database।
• Keyspaces = serverless, managed Apache Cassandra: CQL, TLS-সহ port 9142, AZ জুড়ে ৩ copy, এক অঙ্কের ms, on-demand বা provisioned, ৩৫ দিনের PITR, multi-Region active-active। Keyword: আগের Cassandra → Keyspaces। Join নেই: প্রতিটা query-র জন্য একটা table।
• Timestream = serverless time-series database: memory store → magnetic store নিজে থেকে, সময়ের function-সহ SQL (interpolation, smoothing), scheduled query, দিনে লক্ষ কোটি event; data আসে IoT Core, Kinesis, MSK + Flink, Lambda, Prometheus / Telegraf থেকে; পড়ে QuickSight, Grafana, SageMaker, JDBC। Keyword: IoT, metrics over time, clickstream, time-stamped।
• ২০২৫: Timestream for Live Analytics নতুন customer-দের জন্য বন্ধ (২০ জুন ২০২৫); নতুন project নেয় Timestream for InfluxDB। পরীক্ষার উত্তর এখনো “Timestream”।

নিজেকে যাচাই করো: DocumentDB, Neptune, Keyspaces আর Timestream৩০টি প্রশ্ন