</>Học Dev
Bài học

Tuần 5 - Ngày 5: OpenSearch và Lựa chọn Data Store theo Use Case

Tuần 5 – Ngày 5

Mục tiêu học tập

  • Hiểu OpenSearch Service/Serverless: search, log analytics, dashboards
  • Ôn vị trí RDS/Aurora trong bức tranh data
  • Tổng hợp decision matrix chọn data store — kỹ năng ăn điểm Domain 2
  • Luyện phản xạ ghép use case → store

1. Amazon OpenSearch Service

Khái niệm

Managed OpenSearch (fork Elasticsearch): full-text search, log analytics, visualization (OpenSearch Dashboards — fork Kibana).

  • Domain gồm data nodes (+ dedicated master, UltraWarm/cold storage cho log cũ rẻ hơn)
  • OpenSearch Serverless: collection (search / time series / vector), OCU tự scale — không quản node
  • Ingest: Firehose → OpenSearch (chuẩn), OpenSearch Ingestion (pipeline managed), Lambda, zero-ETL từ DynamoDB/S3 query trực tiếp
  • Use case: tìm kiếm sản phẩm/tài liệu, log/APM realtime, security analytics, vector search

Không phải: warehouse SQL (JOIN/aggregate BI phức tạp → Redshift), nguồn sự thật (không thay S3/DB).

Index lifecycle cho log

Hot (SSD data nodes) → UltraWarm (S3-backed, đọc) → Cold → Delete
     ISM (Index State Management) policy tự chuyển

"Log 7 ngày realtime, 90 ngày thi thoảng đọc, chi phí thấp" → hot + UltraWarm + ISM.

2. RDS/Aurora trong bức tranh data engineering

  • OLTP (giao dịch, row-based) — nguồn dữ liệu cho pipeline, không phải nơi chạy analytics nặng
  • Analytics trên dữ liệu OLTP: read replica (nhẹ), zero-ETL → Redshift (chuẩn hiện nay), DMS CDC → lake
  • Chạy report nặng trực tiếp trên production RDS = anti-pattern kinh điển trong đề

3. Decision matrix — chọn data store

Yêu cầu trong đềStore
Object/data lake, mọi định dạng, rẻ, nhiều engine đọcS3
SQL warehouse, BI concurrency cao, aggregate lặp lạiRedshift
Ad-hoc SQL trên S3, không hạ tầng, trả theo scanAthena
Key-value latency ms, scale lớn, serving layerDynamoDB
OLTP quan hệ, transactions, app truyền thốngRDS/Aurora
Full-text search, log analytics + dashboardsOpenSearch
Cache sub-msElastiCache (Redis/Valkey)
Time series chuyên dụngTimestream (nhận biết)
Graph quan hệ nhiều tầngNeptune (nhận biết)

Câu thần chú phân biệt nhanh

  • "search / log analytics / dashboards Kibana-style" → OpenSearch
  • "single-digit millisecond key-value" → DynamoDB
  • "complex SQL joins across large datasets / BI" → Redshift
  • "occasional SQL on S3" → Athena
  • "store everything cheaply, schema-on-read" → S3
  • "ACID transactions cho app" → RDS/Aurora

4. Kiến trúc nhiều store phối hợp (poly-store)

┌─►Redshift(BI,aggregate)Sources─►S3datalake─┼─►Athena(ad-hoc)│(sourceof└─►SageMaker(ML)│truth)├─►DynamoDB(servingAPIrealtime)└─►OpenSearch(search+logdashboards)

Nguyên tắc: S3 là nguồn sự thật, mỗi store phục vụ đúng access pattern của nó — đề DEA thích kiến trúc "right tool for the job" hơn "một store làm tất cả".

Câu hỏi ôn tập

  1. Team vận hành cần tìm kiếm full-text trên application logs và dashboard realtime. Store nào, và đường ingest ít vận hành nhất?

    Xem đáp án

    OpenSearch Service (hoặc Serverless) + OpenSearch Dashboards. Ingest ít vận hành: Amazon Data Firehose destination OpenSearch (kèm Lambda transform parse log nếu cần), backup S3 cho bản gốc. CloudWatch Logs cũng subscription được sang OpenSearch qua Firehose/subscription filter.

  2. Log giữ 7 ngày truy vấn nóng, 90 ngày thỉnh thoảng đọc, sau đó xóa — giảm chi phí OpenSearch thế nào?

    Xem đáp án

    ISM policy: index 7 ngày ở hot (data nodes SSD) → chuyển UltraWarm (S3-backed, rẻ hơn nhiều, vẫn query được) tới 90 ngày → delete (hoặc cold storage nếu cần giữ lâu). Tự động hoàn toàn, không thao tác tay.

  3. Ghép store cho từng yêu cầu: (a) giỏ hàng latency <10ms; (b) báo cáo doanh thu đa chiều cho 200 analyst; (c) lưu toàn bộ raw event vĩnh viễn; (d) tìm sản phẩm theo từ khóa có typo.

    Xem đáp án

    (a) DynamoDB — key-value ms; (b) Redshift — BI concurrency cao, SQL phức tạp; (c) S3 — rẻ, bền, schema-on-read; (d) OpenSearch — full-text, fuzzy matching. Mỗi access pattern một công cụ — poly-store là đáp án chuẩn của đề chọn store.

  4. Báo cáo tháng đang chạy trực tiếp trên RDS production làm app chậm. Hai hướng xử lý theo mức đầu tư?

    Xem đáp án

    Nhẹ: read replica — trỏ query báo cáo sang replica, tách tải đọc (vẫn là engine OLTP, đủ cho report vừa). Chuẩn dài hạn: đưa dữ liệu sang analytics store — zero-ETL Aurora/RDS → Redshift (ít vận hành) hoặc DMS/CDC → S3 + Athena. Nguyên tắc: OLTP không gánh analytics nặng.

  5. Khi nào OpenSearch Serverless hợp hơn OpenSearch domain?

    Xem đáp án

    Serverless khi workload biến động/không dự đoán, không muốn size node/shard, dev nhanh — trả theo OCU tự scale. Domain (provisioned) khi workload lớn ổn định (tối ưu chi phí bằng instance/reserved), hoặc cần tính năng/cấu hình chi tiết (UltraWarm, một số plugin, fine-grained tuning). Logic giống Redshift Serverless vs provisioned.

Bài tập thực hành

  • Vẽ lại kiến trúc poly-store mục 4 và chú thích lý do từng nhánh
  • Làm 10 flashcard "use case → store" từ decision matrix
  • Tạo pipeline thử: Firehose → OpenSearch Serverless collection, gửi vài log JSON, xem trên Dashboards
  • Ôn lại tuần 5 chuẩn bị quiz

Tài liệu tham khảo chính thức

Tiếp theo: Quiz Tuần 5