AWS SAA-C03 Study

← D3 · High-Performing 🖥️ Compute 💾 Storage 🌐 Networking & Delivery 📨 Messaging & Serverless 🏗️ Infrastructure 🗄️ Databases 📊 Analytics & Streaming

🗄️Databases↑ Top

D3 · High-Performing

Pilih Database

Which AWS Database? — purpose-built selector

"Tiap database ada KERJA dia — match shape data dengan engine"

🎯 Sebab Apa Wujud

Kad ni wujud sebab exam SAA-C03 suka uji 'pilih database betul ikut shape data + access pattern' — bukan satu DB untuk semua. AWS galak purpose-built: tiap engine optimize untuk satu corak data (relational, key-value, document, graph, wide-column, OLAP), jadi pilih salah = lambat/mahal. Kad ni map keyword soalan terus ke engine supaya kau tak teragak-agak.

Apa Dia

AWS galak "purpose-built database" — pilih ikut bentuk data dan cara access, bukan satu DB untuk semua. Relational (SQL, transaksi) → RDS/Aurora. Key-value laju → DynamoDB. Cache → ElastiCache. Document/Mongo → DocumentDB. Graph → Neptune. Wide-column → Keyspaces. Analytics/warehouse → Redshift. In-memory durable → MemoryDB.

Pilih database (decision tree)

Rendering diagram…

Mula-mula tanya "relational ke tak". Relational + transaksi → RDS/Aurora. Lepas tu match keyword soalan: "MongoDB" → DocumentDB, "graph/relationship/fraud" → Neptune, "Cassandra/wide-column" → Keyspaces, "warehouse/analytics" → Redshift, "microsecond cache" → DAX/ElastiCache.

Analogi Shopee — OLTP vs OLAP

Rendering diagram…

Analogi Shopee: setiap kali kau tekan Checkout = satu transaksi kecil pantas (tolak stok, simpan order dalam millisecond) = OLTP → RDS/Aurora/DynamoDB. Bila bos minta laporan "jumlah jualan semua kedai ikut negeri bulan ni" = baca & aggregate berjuta baris = OLAP → Redshift. Jangan keliru: checkout = OLTP, dashboard/laporan = OLAP.

Purpose-built database matrix

Engine	Jenis	Guna bila / keyword exam
RDS	Relational (managed)	MySQL/Postgres/Oracle/SQL Server, transaksi standard
Aurora	Relational (cloud-native)	HA hebat, 6 copies, 5x MySQL, auto-scale storage, Global DB
DynamoDB	Key-value / document NoSQL	Serverless, single-digit ms, any scale, spiky traffic
ElastiCache	In-memory cache	Kurangkan load DB, Redis/Memcached, session store
DAX	In-memory cache (DynamoDB)	Microsecond reads KHUSUS DynamoDB
DocumentDB	Document (Mongo-compat)	"Migrate MongoDB", JSON documents, collections
Neptune	Graph	Social network, fraud detection, relationship query
Keyspaces	Wide-column (Cassandra)	"Migrate Cassandra", CQL, wide-column
Redshift	Data warehouse (OLAP)	Analytics berulang, BI, aggregate berjuta baris
Timestream	Time-series	IoT sensor data, metrics ikut masa

Ingat: Exam fish for KEYWORD: "MongoDB"→DocumentDB, "Cassandra"→Keyspaces, "graph/relationship"→Neptune, "warehouse/analytics"→Redshift, "time-series/IoT metrics"→Timestream, "microsecond DynamoDB"→DAX, "transaksi + HA"→Aurora. Jangan jawab DynamoDB untuk soalan relational/transaksi.

Apa BAWAH RDS vs apa BUKAN RDS — + server-based vs serverless

Service	Bawah RDS?	Jenis	Server / Serverless
MySQL	✅ Ya (1 of 6 engine)	Relational SQL	Server-based (pilih instance)
PostgreSQL	✅ Ya	Relational SQL	Server-based
MariaDB	✅ Ya	Relational SQL	Server-based
Oracle	✅ Ya	Relational SQL (komersial)	Server-based
SQL Server	✅ Ya	Relational SQL (komersial)	Server-based
Aurora	✅ Ya (cloud-native; MySQL/PG je)	Relational SQL	Server-based ATAU Serverless v2
DynamoDB	❌ BUKAN	Key-value NoSQL	🟢 Serverless
ElastiCache	❌ BUKAN	In-memory cache (Redis/Memcached)	Server-based (node)
Redshift	❌ BUKAN	Data warehouse OLAP	Server-based (+Serverless)
DocumentDB	❌ BUKAN	Document (Mongo-compat)	Server-based
Neptune	❌ BUKAN	Graph	Server-based (+Serverless)
Keyspaces	❌ BUKAN	Wide-column (Cassandra)	🟢 Serverless
Timestream	❌ BUKAN	Time-series	🟢 Serverless

Ingat: RDS = PAYUNG untuk 6 enjin RELATIONAL/SQL je: MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Aurora. Apa-apa NoSQL / cache / warehouse / graph / time-series = BUKAN RDS walaupun ia "database". Server-based = pilih saiz instance, bayar 24/7 walau idle (RDS biasa, Aurora biasa). Serverless = auto-scale + bayar guna je / boleh scale near-zero (DynamoDB, Keyspaces, Aurora Serverless v2). PENTING: "Aurora" sendiri ≠ serverless — mesti ada perkataan "Serverless" di belakang nama.

⚡ Quick Sifir — hafal ni

▪Relational + transaksi OLTP → RDS (standard) / Aurora (HA hebat, auto-scale).
▪Key-value, ms latency, serverless, spiky → DynamoDB. Microsecond atas DynamoDB → +DAX.
▪MongoDB → DocumentDB. Cassandra → Keyspaces. Graph/relationship/fraud → Neptune.
▪Analytics/warehouse/aggregate berjuta baris (OLAP) → Redshift. Time-series/IoT → Timestream.
▪Cache depan SEBARANG DB → ElastiCache (Redis/Memcached).
▪Trap: OLTP (checkout/transaksi) = RDS/Aurora; OLAP (laporan/dashboard) = Redshift.
▪RDS = 6 enjin RELATIONAL je (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Aurora). NoSQL/cache/warehouse/graph/time-series = BUKAN RDS.
▪Server-based = bayar instance 24/7 walau idle (RDS biasa, Aurora biasa). Serverless = bayar guna je / scale near-zero (DynamoDB, Keyspaces, Aurora Serverless v2).
▪'Aurora' ≠ serverless melainkan ada perkataan 'Serverless' di belakang. Aurora biasa = server-based cluster.

🪤 Perangkap Soalan

Q: App perlu cari semua mutual friends & detect fraud ring dalam data berhubung-rapat (highly connected). Database?

⚠ Umpan: DynamoDB — sebab dia laju & scalable, ramai default pilih untuk apa-apa NoSQL.

✓ Betul: Neptune — keyword 'relationship / mutual friends / fraud ring / connected data' = graph = Neptune. DynamoDB key-value, teruk untuk traverse relationship.

Q: Aplikasi e-commerce transaksi (checkout, tolak stok, simpan order) perlukan consistency kuat & SQL. Database?

⚠ Umpan: Redshift — sebab dia handle data besar & SQL, nampak macam boleh.

✓ Betul: RDS/Aurora — keyword 'transaksi / checkout / OLTP' = relational OLTP = RDS/Aurora. Redshift = OLAP/analytics (aggregate), teruk untuk single-row insert/update.

Q: App relational MySQL dengan traffic ON-OFF teruk (dev-test waktu office je, malam sunyi). Nak bayar ikut guna & scale near-zero bila idle. Pilih?

⚠ Umpan: Amazon RDS MySQL (Multi-AZ) — sebab 'relational MySQL' terus pilih RDS biasa. SALAH: RDS biasa server-based, bayar instance 24/7 walau idle — bukan 'pay per use / scale to zero'.

✓ Betul: Aurora Serverless v2 — keyword 'unpredictable/intermittent/dev-test + scale near-zero + pay per use' = serverless. 'Aurora' je ≠ serverless; mesti ada 'Serverless' di belakang nama.

Q: Nak simpan shopping cart / user session berskala besar, schemaless, latency millisecond. Database?

⚠ Umpan: Amazon RDS — sebab 'database' biasa orang fikir SQL/RDS dulu. SALAH: cart/session = key-value schemaless, RDS (relational, fixed schema) leceh & susah scale.

✓ Betul: DynamoDB — keyword 'session / shopping cart / schemaless / any scale / single-digit ms' = key-value NoSQL = DynamoDB (BUKAN RDS — DynamoDB bukan bawah RDS langsung).

🧠 Cara Mudah Ingat

→OLTP (transaksi, banyak read/write baris tunggal) → RDS/Aurora. OLAP (analytics, aggregate besar) → Redshift. Ni beza paling kerap ditanya.
→SQL/relational + perlu HA terbaik + auto storage + global → Aurora. SQL standard / engine spesifik (Oracle, SQL Server) → RDS.
→NoSQL key-value serverless ms latency → DynamoDB. Perlu microsecond reads atas DynamoDB → tambah DAX.
→Keyword migrasi: "migrate MongoDB"→DocumentDB, "migrate Cassandra"→Keyspaces, "migrate Kafka"→MSK (streaming, bukan DB).
→Cache: ElastiCache = cache depan SEBARANG DB (Redis/Memcached). DAX = cache KHUSUS DynamoDB sahaja.
→Graph (mutual friends, fraud rings, recommendation) → Neptune. Bukan DynamoDB, bukan RDS.
→PRICING discriminator (model bil): DynamoDB & Keyspaces = serverless pay-per-request (boleh turun $0 bila idle). RDS/Aurora/DocumentDB/Neptune = instance-based (bayar/jam walau idle; Aurora & Neptune ada pilihan Serverless). "Spiky / idle selalu / tak nak urus kapasiti" condong serverless; "beban stabil 24/7" condong instance provisioned.

Guna Bila

Pilih database betul ikut shape data + access pattern (THE exam decision)

purpose-built databaseOLTP vs OLAPrelationalNoSQLkey-valuedocumentgraphwide-columntime-seriesdatabase selectionwhich databaseserverless vs instancepricingwhat is RDSnot RDSRDS enginessix RDS enginesMySQL PostgreSQL MariaDB Oracle SQL Serverserver-based vs serverlessRDS vs Aurora ServerlessAurora not serverless

📎 Choosing an AWS database service 📎 AWS purpose-built databases

D3 · High-Performing

DocumentDB

Amazon DocumentDB

"MongoDB dalam AWS — JSON documents"

🎯 Sebab Apa Wujud

DocumentDB wujud sebab company yang dah guna MongoDB nak pindah ke AWS tapi tak nak urus MongoDB sendiri atas EC2 (patch, scale, backup, replica). DocumentDB managed + MongoDB-compatible, jadi app sedia ada (yang cakap MongoDB API) boleh sambung tanpa tulis semula — AWS yang handle storage auto-scale, backup, HA.

Apa Dia

Fully managed document database yang compatible dengan MongoDB APIs. Store data sebagai JSON documents dalam collections. Auto-scale storage hingga 64TB.

Anatomy DocumentDB

Cluster → satu primary instance (read+write) + sampai 15 replica (read-only) merentas AZ untuk HA.

Compute & storage BERPISAH → instance handle query, storage layer auto-grow 10GB → 64TB sendiri (kau tak provision disk).

Storage replicate 6 salinan / 3 AZ (sama macam Aurora) → durable + failover auto.

Documents (BSON/JSON) simpan dalam collections; sambung guna MongoDB driver/API (v3.6 / 4.0 / 5.0 compatible).

Backup continuous ke S3 + point-in-time recovery (PITR).

Analogi — katering vs masak sendiri

Rendering diagram…

Analogi: app MongoDB kau dah pandai cakap "bahasa MongoDB". DocumentDB = katering — AWS yang masak & jaga dapur (patch, backup, scale, HA), kau makan guna pinggan sama (driver MongoDB). MongoDB atas EC2 = masak sendiri: bebas penuh tapi cuci pinggan sendiri. INGAT exam: "migrate MongoDB, jangan urus server" → DocumentDB.

DocumentDB vs DynamoDB vs MongoDB-on-EC2

	DocumentDB	DynamoDB	MongoDB atas EC2
Model data	Document (JSON/BSON)	Key-value / document	Document (JSON/BSON)
API	MongoDB-compatible	DynamoDB API (sendiri)	MongoDB tulen (native)
Urus server?	Managed (AWS jaga)	Serverless penuh	Kau urus semua (patch, scale, backup)
Scaling	Tambah replica + storage auto 64TB	Auto, tanpa had	Manual / sharding sendiri
Bila pilih	"Migrate MongoDB", perlu MongoDB API	Key-value laju, serverless, spiky	Perlu versi/feature MongoDB terkini yg DocumentDB belum sokong

Ingat: Keyword "MongoDB-compatible / migrate MongoDB tanpa ubah code" → DocumentDB. "Key-value serverless ms latency" → DynamoDB (API lain, app MongoDB kena tulis semula). "Perlu MongoDB versi terkini / feature DocumentDB tak ada" → MongoDB atas EC2 / Atlas. DocumentDB = managed MongoDB-compatible, BUKAN MongoDB tulen 100%.

⚡ Quick Sifir — hafal ni

▪DocumentDB = managed document DB, MongoDB-compatible (API/driver sama).
▪Keyword exam: 'migrate MongoDB' / 'JSON documents' / 'collections' → DocumentDB.
▪Storage auto-scale hingga 64TB; data simpan sebagai JSON documents.
▪BUKAN DynamoDB (key-value), BUKAN Neptune (graph).

💡 Exam Scenario

"Migrate MongoDB to AWS managed service" → DocumentDB. NOT Neptune (graph). NOT DynamoDB (key-value). DocumentDB = DOCUMENT/MONGODB. Keywords: JSON, semi-structured data, MongoDB compatible, collections.

🪤 Perangkap Soalan

Q: Syarikat nak migrate aplikasi MongoDB sedia ada ke AWS fully managed tanpa ubah code aplikasi. Service?

⚠ Umpan: DynamoDB — sebab dia NoSQL managed AWS, nampak macam pengganti semula jadi.

✓ Betul: DocumentDB — keyword 'MongoDB-compatible / migrate MongoDB tanpa ubah code' = DocumentDB. DynamoDB key-value, API berbeza, app MongoDB kena tulis semula.

🧠 Cara Mudah Ingat

→DocumentDB = MongoDB-COMPATIBLE, bukan MongoDB tulen. Sokong subset MongoDB API (v3.6/4.0/5.0). Kalau soalan tekankan "perlu feature MongoDB terkini yang DocumentDB tak sokong" → MongoDB atas EC2/Atlas.
→Compute & storage berpisah: storage auto-scale 10GB→64TB, 6 copies/3 AZ (macam Aurora). Tambah read replica untuk offload read.
→PRICING: instance-based (BUKAN serverless macam DynamoDB). Instance db.t3.medium ~$0.078/hr, db.r6g.large ~$0.226/hr (us-east-1). Storage $0.10/GB-bulan. I/O $0.20 per 1 juta request. Backup $0.021/GB-bulan. Ada pilihan I/O-Optimized (storage mahal sikit, I/O free) untuk workload baca/tulis tinggi.
→PRICING trap: DocumentDB takde free tier kekal — ada 30-hari free trial (db.t3.medium, 750 jam). Sebab instance-based, idle pun masih bayar instance/jam — beza dengan DynamoDB on-demand (bayar bila guna je).
→Jangan keliru: DocumentDB = document. Neptune = graph. Keyspaces = wide-column. DynamoDB = key-value. Semua NoSQL tapi shape data lain.

Guna Bila

JSON document store, MongoDB-compatible workloads migrate to AWS

MongoDB compatibledocument storeJSONBSONcollectionsNoSQLMongoDB migrationDocumentDB pricingpricing64TBI/O-Optimized

📎 What is Amazon DocumentDB 📎 DocumentDB MongoDB compatibility

D3 · High-Performing

Neptune

Amazon Neptune

"Database untuk connections antara data — graph"

🎯 Sebab Apa Wujud

Neptune wujud sebab data berhubung-rapat (siapa kawan siapa, transaksi mana bersambung) kalau simpan dalam SQL kena buat banyak JOIN bersarang yang jadi sangat lambat bila relationship dalam. Graph database optimize traverse relationship — query 'cari sambungan 5 lapisan dalam' jadi laju, jadi sesuai untuk social network, fraud detection, recommendation engine.

Apa Dia

Fully managed graph database. Optimized untuk traverse relationships dalam data. Support Gremlin (property graph) dan SPARQL (RDF). Highly connected datasets.

Anatomy Neptune

Data simpan sebagai nodes (benda) + edges (hubungan) + properties → bukan rows/columns. Query = "ikut benang hubungan", bukan JOIN table.

Cluster → 1 primary (write) + sampai 15 read replica merentas AZ; storage auto-grow ke 64TB, 6 copies / 3 AZ (macam Aurora).

Dua model query → Property Graph (guna Gremlin / openCypher) ATAU RDF (guna SPARQL). Pilih ikut data model app.

Neptune Serverless → auto-scale kapasiti ikut NCU (Neptune Capacity Units) untuk beban naik-turun.

Analogi — siasatan "siapa kenal siapa"

Rendering diagram…

Analogi: papan siasatan detektif dengan benang merah sambung gambar suspek — "siapa kenal siapa, siapa transaksi dengan siapa". Itu Neptune: node = orang/benda, edge = hubungan, query = ikut benang berlapis-lapis. Kalau kau cuba buat papan ni dengan table RDS (JOIN berlapis) ia jadi sangat lambat. INGAT exam: "mutual friends / fraud ring / recommendation / connected data" → Neptune.

Gremlin vs SPARQL vs openCypher (dalam Neptune)

Bahasa query	Model data	Guna bila / keyword
Gremlin	Property Graph	Traversal "ikut benang" (TinkerPop). Default ramai social/fraud app.
openCypher	Property Graph	Sintaks pattern-match (asal Neo4j). Senang baca, migrate dari Neo4j.
SPARQL	RDF (triple subject-predicate-object)	Knowledge graph, linked open data, standard W3C.

Ingat: Gremlin & openCypher = Property Graph (node+edge ada property). SPARQL = RDF (triples). Exam jarang paksa pilih bahasa — cukup tau Neptune sokong KEDUA model (property graph + RDF). Keyword "RDF / triple / SPARQL" pun masih → Neptune.

Neptune vs RDS-JOIN vs DynamoDB untuk data berhubung

	Neptune	RDS (relational)	DynamoDB
Model	Graph (node + edge)	Table + foreign key	Key-value / document
Deep relationship (5+ lapisan)	Laju — memang dibina untuk traverse	Lambat — JOIN bersarang makin dalam makin teruk	Teruk — kena banyak query / scan
Soalan "mutual friends / fraud ring / recommendation"	✅ jawapan	❌ umpan	❌ umpan
Bila pilih	Hubungan ITU sendiri yang penting	Data tabular, JOIN cetek, transaksi	Lookup laju ikut key, tanpa traverse

Ingat: Keyword "relationship / connected / mutual friends / fraud ring / recommendation / knowledge graph" → Neptune. RDS boleh JOIN tapi deep traversal jadi terlalu lambat (umpan paling biasa). DynamoDB hebat lookup-by-key, teruk untuk follow hubungan.

⚡ Quick Sifir — hafal ni

▪Neptune = managed graph DB — optimize traverse RELATIONSHIP.
▪Keyword: social network / fraud detection / recommendation / knowledge graph / connected data.
▪Support Gremlin (property graph) + SPARQL (RDF).
▪BUKAN DynamoDB (key-value), BUKAN RDS (tabular JOIN lambat untuk deep relationship).

💡 Exam Scenario

"Social network: cari semua mutual friends antara dua users" → Neptune (graph query efficient). "Fraud detection: cari pattern dalam linked transactions" → Neptune. Bukan DynamoDB (key-value) atau RDS (relational tabular). Keywords: graph, relationships, connected data.

🪤 Perangkap Soalan

Q: Platform perlu detect fraud ring dengan cari pattern dalam transaksi yang saling berhubung berlapis-lapis. Database?

⚠ Umpan: RDS — sebab relational boleh JOIN table transaksi, nampak boleh trace hubungan.

✓ Betul: Neptune — keyword 'fraud ring / relationship pattern / connected transactions' = graph = Neptune. RDS JOIN berlapis-lapis jadi terlalu lambat untuk deep relationship traversal.

🧠 Cara Mudah Ingat

→Keyword graph yang exam pakai: mutual friends, social network, fraud ring / fraud detection, recommendation engine, knowledge graph, "highly connected data", relationship traversal → semua Neptune.
→Neptune sokong DUA model: Property Graph (Gremlin / openCypher) + RDF (SPARQL). Nampak "RDF" atau "SPARQL" jangan terkejut — masih Neptune.
→Umpan paling biasa: RDS (boleh JOIN) atau DynamoDB (NoSQL default). Discriminator = "hubungan dalam / berlapis". RDS JOIN bersarang = lambat; DynamoDB tak boleh traverse. Hubungan dalam → Neptune.
→PRICING: instance-based. db.t3.medium ~$0.0832/hr (dev), db.r5.large ~$0.348/hr (prod) us-east-1. Storage $0.10/GB-bulan, I/O $0.20 per 1 juta request, backup $0.021/GB-bulan. Neptune Serverless ~$0.1608 per NCU-jam (auto-scale untuk beban naik-turun). Takde free tier.
→PRICING discriminator: beban graph stabil → instance provisioned (murah/jam). Beban naik-turun / spiky / dev → Neptune Serverless (bayar ikut NCU, tak idle-charge sebanyak instance penuh).

Guna Bila

Social networks, fraud detection, knowledge graphs, recommendation engines

graph databasesocial networkfraud detectionfraud ringrecommendation engineGremlinSPARQLopenCypherproperty graphRDFrelationshipsknowledge graphconnected dataNeptune ServerlessNCUpricing

📎 What is Amazon Neptune 📎 Neptune graph query languages

D3 · High-Performing

Keyspaces

Amazon Keyspaces

"Cassandra dalam AWS — wide column, IoT, time-series"

🎯 Sebab Apa Wujud

Keyspaces wujud sebab company yang guna Apache Cassandra nak masuk AWS tapi urus cluster Cassandra sendiri itu menyakitkan (node, replication, scaling, tuning). Keyspaces serverless + Cassandra-compatible (CQL sama), jadi app Cassandra sedia ada boleh sambung tanpa ubah query, AWS auto-scale ikut traffic dan kau bayar per request.

Apa Dia

Fully managed Cassandra-compatible database. Guna CQL (Cassandra Query Language) yang sama. Serverless — auto-scale, pay per request. High write throughput.

Anatomy Keyspaces

Keyspace → macam "database" dalam Cassandra; dalam dia ada tables (wide-column). Akses guna CQL (Cassandra Query Language) — sama macam Cassandra tulen.

Serverless penuh → takde node/cluster nak urus. AWS auto-scale throughput naik-turun ikut traffic.

Data replicate 3 salinan merentas AZ automatik → durable, HA.

Dua mode kapasiti → On-Demand (bayar per request, untuk traffic tak boleh agak) atau Provisioned (set RCU/WCU, untuk traffic stabil — lebih murah).

Analogi — pindah kedai, kekal resipi

Rendering diagram…

Analogi: kau pindah kedai (data center → AWS) tapi nak kekal resipi sama (CQL). Keyspaces = pindah ke dapur baru yang AWS uruskan sepenuhnya, resipi (CQL) tak berubah, app terus jalan. DynamoDB pun serverless NoSQL tapi "resipi" (API) lain — kena tulis semula. INGAT exam: "migrate Cassandra / CQL / wide-column tanpa urus cluster" → Keyspaces.

Keyspaces vs DynamoDB vs Cassandra-on-EC2

	Keyspaces	DynamoDB	Cassandra atas EC2
Model data	Wide-column	Key-value / document	Wide-column
Query language	CQL (Cassandra)	DynamoDB API (sendiri)	CQL (Cassandra tulen)
Urus server?	Serverless (AWS jaga)	Serverless penuh	Kau urus node, replication, tuning
Migrate app Cassandra?	Terus — CQL sama	Kena tulis semula (API lain)	Lift-and-shift, tapi kau jaga
Bila pilih	"Migrate Cassandra" tanpa urus cluster	NoSQL baru, tak terikat Cassandra	Perlu kawalan penuh / feature Cassandra spesifik

Ingat: Keyword "Cassandra / CQL / wide-column" → Keyspaces (serverless, app Cassandra terus sambung). DynamoDB pun serverless NoSQL tapi API lain — app Cassandra kena tulis semula (umpan biasa). "Nak kawalan penuh cluster Cassandra" → Cassandra atas EC2. Keyspaces = managed serverless Cassandra-compatible.

⚡ Quick Sifir — hafal ni

▪Keyspaces = managed serverless Cassandra-compatible DB, guna CQL.
▪Keyword: 'migrate Cassandra' / CQL / wide-column / high write throughput / IoT telemetry.
▪Serverless — auto-scale, pay-per-request (atau provisioned).
▪Wide-column model (bukan key-value DynamoDB, bukan document DocumentDB).

💡 Exam Scenario

"Migrate Apache Cassandra to fully managed AWS service" → Amazon Keyspaces. Same CQL queries, no server management. Atau IoT telemetry data yang perlu high write throughput. Keywords: Cassandra, CQL, wide column.

🪤 Perangkap Soalan

Q: Pasukan nak migrate Apache Cassandra workload ke AWS fully managed tanpa urus node/cluster, kekal guna CQL. Service?

⚠ Umpan: DynamoDB — sebab serverless NoSQL AWS, nampak macam pengganti Cassandra.

✓ Betul: Amazon Keyspaces — keyword 'Cassandra / CQL / wide-column' = Keyspaces. DynamoDB tak guna CQL & bukan wide-column, app Cassandra kena tulis semula.

🧠 Cara Mudah Ingat

→Discriminator exam: nampak "Cassandra", "CQL", atau "wide-column" → Keyspaces. DynamoDB ialah umpan (serverless NoSQL juga) tapi guna API sendiri, jadi app Cassandra kena re-write — Keyspaces tak.
→Serverless: takde node/cluster. On-Demand mode untuk traffic spiky / tak boleh agak; Provisioned mode (set RCU/WCU) untuk traffic stabil = lebih murah.
→PRICING: serverless, pay-per-request. On-Demand (us-east-1) ~$1.45 per 1 juta WRU (write), ~$0.29 per 1 juta RRU (read). Storage $0.30/GB-bulan. Provisioned mode untuk beban stabil boleh jauh lebih murah dari On-Demand.
→PRICING discriminator: storage Keyspaces $0.30/GB-bulan lebih mahal dari DynamoDB ($0.25/GB-bulan) — tapi exam pilih Keyspaces atas COMPATIBILITY (CQL), bukan kos. Kos jadi penentu hanya bila dua-dua sama-sama boleh.
→Jangan keliru "IoT telemetry / time-series" semestinya Keyspaces — kalau soalan sebut "purpose-built time-series" tulen, jawapan Timestream. Keyspaces hanya bila ada keyword Cassandra/CQL/wide-column.

Guna Bila

Migrate Apache Cassandra workloads, IoT telemetry, time-series data

Cassandra compatibleCQLwide columnIoT telemetrytime-serieshigh write throughputserverlesson-demand capacityprovisioned capacityWRURRUKeyspaces pricingpricing

📎 What is Amazon Keyspaces 📎 Keyspaces read/write capacity modes

D3 · High-Performing

Timestream

Amazon Timestream (for LiveAnalytics)

"Database khusus data ikut MASA — IoT sensor, metrics"

🎯 Sebab Apa Wujud

Timestream wujud sebab data time-series ada corak pelik: masuk BANYAK & laju (jutaan titik/saat), hampir tak pernah update (append je), dan data baru lagi penting dari data lama. Kalau simpan dalam RDS/DynamoDB, table membengkak, kos naik, query "purata 5 minit lepas merentas 10,000 sensor" jadi lambat. Timestream auto-pindah data lama ke storan murah + ada fungsi masa siap-siap, jadi kau tak reka sendiri lifecycle + rollup.

Apa Dia

Serverless time-series database — khusus simpan data yang setiap titik ada cap masa (timestamp) dan masuk laju & berterusan (suhu sensor tiap saat, CPU metric tiap minit). Auto-tier: data baru duduk dalam memory store (laju), data lama turun ke magnetic store (murah). Query guna SQL dengan fungsi masa terbina (interpolate, smoothing).

Anatomy Timestream

Ingestion → terima writes laju (jutaan/saat), serverless, auto-scale. Setiap rekod = timestamp + dimensions + measures.

Memory store → data BARU duduk sini: laju untuk query terkini + write. Mahal/GB. Kau set tempoh simpan (cth 12 jam).

Magnetic store → data LAMA auto-turun sini: murah, untuk query sejarah. Kau set retention (cth 1 tahun).

Query engine → SQL dengan fungsi masa terbina (interpolation, smoothing, time-bucketing) merentas kedua-dua tier secara telus.

Analogi — buku log suhu peti sejuk

Rendering diagram…

Analogi: buku log suhu peti sejuk kedai. Bacaan terbaru kau letak atas meja (memory store — capai laju, tapi meja mahal/terhad). Buku log lama kau simpan dalam stor belakang (magnetic store — murah, jarang semak). Timestream auto-pindah dari meja ke stor ikut tempoh kau set, dan boleh baca dua-dua bila kau tanya "purata suhu tiap 5 minit bulan lepas". INGAT exam: data ber-timestamp + ingest laju + tiering = Timestream.

Timestream vs DynamoDB vs Redshift untuk data masa

	Timestream	DynamoDB	Redshift
Khusus untuk	Time-series (data ber-timestamp)	Key-value lookup generik	OLAP warehouse (aggregate berstruktur)
Lifecycle data	Auto-tier memory→magnetic	Manual (TTL delete je)	Manual
Fungsi masa	Terbina (interpolate, smoothing)	Tiada	SQL biasa (tak khusus masa)
Corak guna	Ingest laju + query trend ikut masa	Lookup laju ikut key	Report berulang, BI
Keyword exam	IoT sensor, metrics over time, telemetry	session, cart, key-value	data warehouse, complex SQL BI

Ingat: Keyword "time-series / IoT sensor readings / metrics over time + timestamp + high ingest" → Timestream. DynamoDB = lookup-by-key (umpan sebab high write juga). Redshift = OLAP aggregate berstruktur (umpan sebab "analytics"). Timestream menang bila MASA itu paksi utama data.

⚡ Quick Sifir — hafal ni

▪Timestream = serverless time-series DB — data ber-timestamp, append-heavy, IoT/metrics.
▪Auto-tier: memory store (baru, laju, mahal) → magnetic store (lama, murah). Kau set tempoh.
▪Keyword: time-series, IoT sensor, telemetry, metrics over time, "millions of events per second".
▪BUKAN DynamoDB (key-value generik), BUKAN Redshift (OLAP warehouse), BUKAN Keyspaces (wide-column — kecuali ada keyword Cassandra).

💡 Exam Scenario

"Store & analyze IoT sensor / time-series data dengan timestamp, high ingest rate" → Amazon Timestream. NOT DynamoDB (key-value, takde time functions/tiering). NOT Redshift (OLAP warehouse). NOT Keyspaces (kecuali keyword Cassandra). Keywords: time-series, IoT telemetry, sensor, metrics over time.

🪤 Perangkap Soalan

Q: Platform IoT terima jutaan bacaan sensor sesaat (setiap satu ada timestamp) & perlu query trend ikut masa secara cekap. Database?

⚠ Umpan: DynamoDB — sebab dia handle write throughput tinggi & serverless, nampak muat.

✓ Betul: Amazon Timestream — keyword 'time-series / sensor readings dengan timestamp / query trend ikut masa' = purpose-built time-series = Timestream. DynamoDB boleh tampung write tapi takde auto-tiering + fungsi masa; kos & query trend jadi teruk.

Q: Pasukan nak analisa metrics aplikasi (CPU, latency) ikut masa, data lama jarang dibaca tapi nak kekal murah. Database?

⚠ Umpan: Redshift — sebab dia untuk analytics & SQL, nampak boleh handle metrics.

✓ Betul: Amazon Timestream — keyword 'metrics ikut masa + auto-tier data lama murah' = time-series = Timestream. Redshift = OLAP warehouse untuk aggregate berstruktur berjuta baris, bukan ingest time-series laju + lifecycle auto.

🧠 Cara Mudah Ingat

→Discriminator: paksi data ialah MASA (timestamp setiap rekod) + ingest laju berterusan + query trend ikut masa → Timestream. Kalau cuma "high write throughput" tanpa unsur masa, fikir DynamoDB.
→Auto-tiering = pembeza besar: memory store (data baru, laju) → magnetic store (data lama, murah). Kau set retention tiap tier; Timestream pindah sendiri (tak payah lifecycle manual macam DynamoDB TTL/S3).
→PRICING: serverless, bayar ikut guna. Writes ~$0.50 per 1 juta writes (1KB). Memory store ~$0.036/GB-jam (mahal — sebab itu tempoh memory pendek). Magnetic store ~$0.03/GB-bulan (murah). Query ~$0.01 per GB diimbas (us-east-1).
→PRICING discriminator: kos memory store TINGGI/GB-jam → set tempoh memory pendek (jam, bukan bulan), biar data turun ke magnetic yang murah. Inilah sebab time-series guna tiering, bukan satu storan rata.
→Jangan keliru: ada 2 jenis — Timestream for LiveAnalytics (serverless, AWS-native, default exam) vs Timestream for InfluxDB (managed InfluxDB, instance-based, untuk yang dah guna InfluxDB).

Guna Bila

IoT sensor readings, app/DevOps metrics, apa-apa data yang ada timestamp & masuk berterusan

time-seriesTimestreamIoT telemetrysensor datametrics over timememory storemagnetic storetiered storageserverlesshigh ingesttimestampTimestream pricingpricing

📎 What is Amazon Timestream for LiveAnalytics 📎 Timestream storage architecture (tiering)

D3 · High-Performing

MemoryDB

Amazon MemoryDB (Valkey / Redis OSS compatible)

"Redis yang TAK hilang data — in-memory tapi durable, jadi DB utama"

🎯 Sebab Apa Wujud

MemoryDB wujud sebab orang nak kelajuan Redis TAPI tanpa risiko hilang data. ElastiCache (Redis) itu cache — kalau node mati, data boleh hilang, sebab kau anggap ada DB sebenar (RDS/DynamoDB) di belakang sebagai sumber kebenaran. MemoryDB tulis setiap perubahan ke log merentas Multi-AZ dulu sebelum acknowledge, jadi durable cukup untuk jadi DB utama — kau buang seni bina "cache + DB berasingan" jadi satu lapisan laju + durable.

Apa Dia

In-memory database yang DURABLE — laju macam Redis (microsecond reads, single-digit ms writes) tapi data TAK hilang bila node mati, sebab setiap write disimpan ke Multi-AZ transactional log dulu. Compatible dengan Valkey & Redis OSS (guna command/client sama). Boleh jadi DATABASE UTAMA (primary), bukan sekadar cache.

Anatomy MemoryDB

In-memory data store → semua data dalam RAM → microsecond reads, single-digit ms writes. Valkey/Redis OSS commands.

Multi-AZ transactional log → INI yang bagi durability: setiap write ditulis ke log merentas berbilang AZ SEBELUM di-ack. Node mati → data tak hilang, failover pulih dari log.

Cluster + shards → data dipecah ikut shard (horizontal scale); tiap shard ada primary + replica untuk HA.

Snapshots → backup ke S3 untuk restore / point-in-time.

Analogi — papan tulis vs buku nota tahan air

Rendering diagram…

Analogi: ElastiCache = papan tulis — laju conteng & padam, tapi kalau tertumpah air semua hilang, jadi kau simpan salinan sebenar dalam buku (DB di belakang). MemoryDB = buku nota tahan air dengan karbon kopi — setiap tulisan terus disalin ke log merentas Multi-AZ, jadi walau satu naskhah rosak, data kekal. Sebab itu MemoryDB boleh jadi DB UTAMA, ElastiCache tak. INGAT exam: "durable in-memory / Redis as primary" → MemoryDB.

MemoryDB vs ElastiCache vs DynamoDB+DAX

	MemoryDB	ElastiCache (Redis)	DynamoDB + DAX
Peranan	Primary DB (durable)	Cache (boleh hilang)	DB + cache khusus DynamoDB
Durability	✅ Multi-AZ transactional log	❌ data boleh hilang bila node gagal	✅ DynamoDB durable; DAX cache je
Kelajuan baca	Microsecond	Microsecond	Microsecond (via DAX)
Perlu backing DB?	Tidak — dia sumber kebenaran	Ya — ada DB di belakang	DynamoDB itu sendiri backing
Keyword	durable in-memory, Redis as primary	cache, session store, offload DB	cache di depan DynamoDB

Ingat: "Durable in-memory + primary database (tanpa DB lain di belakang)" → MemoryDB. "Cache di depan DB sedia ada, data boleh hilang" → ElastiCache. "Microsecond cache KHUSUS DynamoDB" → DAX. Pembeza utama MemoryDB = DURABILITY (Multi-AZ log) yang jadikan dia DB, bukan sekadar cache.

⚡ Quick Sifir — hafal ni

▪MemoryDB = in-memory + DURABLE (Multi-AZ transactional log) = boleh jadi primary DB.
▪ElastiCache = cache je (data boleh hilang; kena ada backing DB). MemoryDB = sumber kebenaran sendiri.
▪Microsecond reads, single-digit ms writes; Valkey/Redis OSS compatible.
▪Keyword: "durable in-memory", "Redis as primary database", "microsecond + tak boleh hilang data".

💡 Exam Scenario

"Durable in-memory database as a primary store, microsecond reads, no separate backing DB" → Amazon MemoryDB. "In-memory CACHE in front of an existing DB (data boleh hilang)" → ElastiCache (atau DAX khusus DynamoDB). Keywords: durable in-memory, Redis/Valkey primary database, Multi-AZ transactional log.

🪤 Perangkap Soalan

Q: Microservice perlu microsecond reads & in-memory speed TAPI data tak boleh hilang — nak satu database laju + durable tanpa DB berasingan di belakang. Service?

⚠ Umpan: ElastiCache for Redis — sebab dia in-memory Redis laju, ramai terus pilih bila nampak 'Redis / in-memory'.

✓ Betul: Amazon MemoryDB — keyword 'durable + in-memory + primary database (tanpa backing DB)' = MemoryDB. ElastiCache = cache; data boleh hilang bila node gagal, jadi BUKAN sumber kebenaran. MemoryDB ada Multi-AZ transactional log = durable.

Q: App nak microsecond READ caching di DEPAN DynamoDB sedia ada untuk kurangkan latency. Service?

⚠ Umpan: MemoryDB — sebab dia in-memory microsecond, nampak macam cache laju.

✓ Betul: DAX — keyword 'cache DI DEPAN DynamoDB, microsecond read' = DAX (khusus DynamoDB). MemoryDB ialah DB utama berasingan, bukan cache write-through depan DynamoDB. (Cache depan DB lain → ElastiCache.)

🧠 Cara Mudah Ingat

→Pembeza #1 vs ElastiCache: DURABILITY. MemoryDB tulis ke Multi-AZ transactional log sebelum ack → boleh jadi primary DB. ElastiCache = cache; anggap data boleh hilang, perlu backing DB.
→Pembeza vs DAX: DAX = cache write-through KHUSUS DynamoDB (microsecond reads atas DynamoDB). MemoryDB = DB utama berasingan, bukan cache depan DynamoDB. Jangan tukar ganti.
→Valkey/Redis OSS compatible: client & command sama, jadi app Redis sedia ada boleh guna MemoryDB sebagai primary tanpa tulis semula.
→PRICING: node-based on-demand, cth db.r7g.large ~$0.227/jam (us-east-1) + data written ~$0.20/GB (ke transactional log) + snapshot storage ~$0.021/GB-bulan. Ada juga MemoryDB Serverless (bayar ikut data stored + ECPU). Reserved nodes untuk diskaun.
→PRICING discriminator: MemoryDB lebih mahal dari ElastiCache sebab durability (transactional log) + simpan semua data dalam RAM. Pilih MemoryDB hanya bila kau betul-betul perlukan durable primary; kalau cache je, ElastiCache lebih murah.

Guna Bila

Primary database in-memory: microsecond reads + durability, untuk microservices yang perlu laju TAPI tak boleh hilang data

MemoryDBdurable in-memoryRedisValkeyprimary databasemicrosecond readsMulti-AZ transactional login-memory databasedurabilityElastiCache alternativeMemoryDB pricingpricing

📎 What is Amazon MemoryDB 📎 MemoryDB durability (transactional log)