Luyện thi AWS SAP C01 – Lưu trữ dữ liệu

Đây là memo về lưu trữ dữ liệu (data stores – một trong 2 tính năng quan trọng nhất của cloud computing) trong quá trình học và thi chứng chỉ AWS. Nó là memo nên sẽ ở dạng note nhanh, không trình bày được đầy đủ, văn vẻ. Nội dung memo này dựa trên các thông tin học được, có thể đã outdate. Thông tin mới nhất luôn ở trên trang chủ của AWS

Một số khái niệm

Data Persistence

• Persistent Data Store: Dữ liệu tồn tại mãi mãi, dù khởi động lại, tắt máy hay bất kỳ hành động nào khác. Ví dụ: Glacier, RDS.
• Transient Data Store: Dữ liệu được lưu trữ một cách tạm thời, để chuyển sang các xử lý khác hoặc cách lưu trữ khác. Ví dụ: SQS, SNS
• Ephemeral Data Store: Dữ liệu sẽ mất khi không hoạt động nữa. Ví dụ: EC2 Instance Store, Memcached

IOPS vs Throughput

• IOPS (Input/Output Operations per Second): Giá trị biểu thị mức độ nhanh của việc đọc/ghi dữ liệu vào thiết bị. Tốc độ đọc/ghi cao chưa chắc đã ghi dữ liệu nhanh, vì có thể một lần chỉ đọc/ghi lượng nhỏ dữ liệu.
• Throughput: Giá trị biểu thị bao nhiêu dữ liệu sẽ được đọc/ghi trong 1 lần, giá trị cao nghĩa là một lần đọc/ghi được nhiều dữ liệu, nhưng chưa chắc đã nhanh.

Consistency

“Consistency is far better than rare moments of greatness.” – Scott Ginsberg

Consistency Models

ACID vs BASE (a xít và ba zơ)

• ACID (thường áp dụng trong DB)

  • Atomic: một transaction là “all or nothing” tức là thành công thì cả transaction có giá trị, không thì thôi.
  • Consistent: transaction phải hợp lệ.
  • Isolated: transaction phải tách biệt với nhau
  • Durable: Kết quả của transaction phải tồn tại mãi

• BASE

  • Basic Availability: giá trị có thể truy cập được ngay cả khi nó đã cũ
  • Soft-state: Trạng thái của dữ liệu có thể bị thay đổi mà không có input nào, điều này liên quan đến điều bên dưới
  • Eventual Consistency: consistency sẽ đạt được sau một thời gian nào đó

Không có cái nào tốt hơn cái nào, quan trọng nào mô hình nào phù hợp với bài toán

Một số khái niệm trong AWS

• Strong consistency: khi một đối tượng được tạo mới/thay đổi => sự thay đổi đó ngay lập tức được ghi nhận.
• Eventual consistency: khi một đối tượng được tạo mới/thay đổi => sự thay đổi phải mất một thời gian mới được ghi nhận. Ví dụ: khi update 1 đối tượng sau đó lấy thông tin luôn thì khả năng cao là vẫn nhận được thông tin cũ (nếu may mắn thì sẽ có thông tin mới – không đảm bảo)
• Read-after-write: một hình thức ở giữa 2 loại trên. Nếu một đối tượng được tạo mới thì ngay lập tức được ghi nhận nhưng update thì không.

Amazon S3 (Simple Storage Service)

Khái quát

• Một trong những dịch vụ đầu tiên của AWS (bắt đầu từ năm 2006)
• S3 là lưu trữ dạng object (thực tế sử dụng coi object = file nhưng thực chất không đúng)
• Dễ dàng kết hợp với các dịch vụ khác, trực tiếp và behind-the-scenes
• Kích thước tối đa cho 1 object là 5TB, một lần PUT tối đa 5GB
• Nếu sử dụng multi-parts upload với file lớn (recommend là trên 100MB)

Durability và Availability

Durability:

• Được thiết kế để cung cấp độ bền của object là 99.999999999% (11 số 9), tức là lưu trữ 10 triệu object bằng S3 thì trung bình mỗi 10 nghìn năm sẽ mất 1 đối tượng
• S3 lưu trữ object trên tối thiểu 3 AZ trong 1 region trước khi trả về SUCCESS

Availability

• S3 Standard đảo bảo dữ liệu luôn sẵn sàng trong 99.99% thời gian trong năm

S3 Object Store

• S3 lưu trữ dạng object, không phải file
• Mỗi object xác định bởi key (trong giống file path nhưng thực chất không phải)
• Lưu trữ object được S3 triển khai trên cloud, bộ lưu trữ S3 độc lập với máy chủ và truy cập qua Internet
• Object trong S3 có data và metadata
• Object được đặt trong các bucket, và được xác định bởi key: 1 object coi là 1 file, key là đường dẫn (coi như thôi nhé, không phải giống nhau đâu)
• Bucket cấu trúc ngang hàng, không có phân cấp như thư mục, nhưng có thể đặt tên để mô phỏng lại cấu trúc thư mục. Mỗi bucket chứa không giới hạn số lượng object

S3 Consistency

• Read-after-write consistency cho PUT object mới
• HEAD hoặc GET (lấy metadata và data) một key trước khi object tồn tại sẽ là eventual consistency
• PUT hoặc DELETE sẽ là eventual consistency
• Update cùng 1 key là atomic (all or nothing): khi có 2 request update 1 object thì sẽ được xử lý lần lượt theo thời gian

S3 Security

• Resource-based: Object ACL, Bucket Policy
• User-based: IAM Policies
• Multi-factor Authentication trước khi xóa (optional)
• Presigned URL
  • Cung cấp truy cập tạm thời vào object private, có thể sử dụng presigned URL
  • URL này sẽ sử dụng được trong thời gian xác định

S3 Data Protection

Versioning

• Version mới cho mỗi lần write
• Khi bật versioning, mỗi lần xóa thực ra chỉ là gắn delete marker (xóa logic)
• Có thể roll-back về version cũ hoặc un-delete khôi phục lại object
• Các version cũ vẫn được lưu trữ và sẽ tính tiền theo dung lượng bình thường cho đến lúc bị xóa hoàn toàn
• Có thể tích hợp với lifecycle

Multi-factor Authentication

• Bảo vệ khỏi việc xóa nhầm object
• Thay đổi versioning state của bucket

Cross-region Replication

• Security
• Compliance
• Latency
• Tạo bucket ở US region, replicate sang region khác => việc truy cập sẽ dễ dàng và nhanh chóng hơn vì dữ liệu lưu ở vị trí gần hơn

S3 Lifecycle Management

• Việc duy trì bucket có thể rất tốn chi phí
• Lifecycle đặt các rule cho từng object, và có thể chuyển đổi giữa các lớp lưu trữ khác nhau hoặc xóa bỏ
• Rule có thể sử dụng prefix, tags, version
• Lợi ích:
  • Tối ưu chi phí lưu trữ
  • Tuân thủ các chính sách lưu trữ dữ liệu
  • Giữ S3 ở trạng thái well-maintained

S3 Analytics

• Data Lake Concept: Athena, Redshift Spectrum, QuickSight (sẽ tìm hiểu kỹ hơn sau)
• IoT Streaming Data Repository: Kinesis Firehose có thể kết nối và lưu trữ trực tiếp trên S3
• Machine Learning and AI Storage: Rekognition, Lex, MXNet sử dụng dữ liệu trên S3 là dữ liệu training hoặc xử lý
• Storage Class Analysis: S3 Management Analytics công cụ rất tốt nếu lưu trữ nhiều object, báo cáo về các object được sử dụng thường xuyên và không thường xuyên, dựa vào đó để sử dụng lớp lưu trữ hợp lý nhất

S3 Encryption at Rest

• SSE-S3 (Amazon S3-Managed Keys): Sử dụng encryption key có sẵn của S3 (AES-256)
• SSE-C (Customer-Provided Keys): Upload encryption key AES-256, S3 sẽ sử dụng để mã hóa dữ liệu
• SSE-KMS (AWS KMS-Managed Keys): Sử dụng key được tạo và quản lý bởi dịch vụ KMS (Key Management Service) để mã hóa
• Client-side: Encryption object theo cách riêng của người dùng (PGP, GPG, v.v…) trước khi đưa lên S3

Nifty S3 Tricks

• Transfer Acceleration: Tăng tốc quá trình upload bằng cách dùng CloudFront ngược. Bình thường CloudFrond dùng như CDN để phân phối nội dung, giờ có thể dùng ngược lại để tăng tốc upload
• Requester Pay: Người request object sẽ trả tiền chứ không phải chủ của bucket
• Tags: Tag được dùng cho rất nhiều dịch vụ của AWS và là một cách dễ dàng để quản lý. Có thể gắn tag cho object để quản lý, billing, security, v.v…
• Events: S3 support event như tạo, sửa, xóa object và có thể dùng nó để trigger SNS, SQS, Lambda cho các xử lý tiếp theo
• Static Web Hosting: Host một trang web tĩnh (html tĩnh) dễ dàng và dễ mở rộng
• BitTorrent: Sử dụng giao thức BitTorrent, tự sinh .torrent file, giảm chi phí do sử dụng peer-to-peer protocol

Amazon Glacier

Khái quát

• Glacier là dịch vụ chuyên dùng để lưu trữ kiểu archived, tức là lưu trữ lâu dài nhưng nhu cầu sử dụng lại không cao (nhưng cũng không muốn xóa)
• Giá rẻ, phản hồi chậm, truy cập ít
• Còn gọi là “cold storage”, “orphan storage”
• Được sử dụng bởi AWS Storage Gateway Virtual Tape Library
• Tích hợp với S3 thông qua Lifecycle Management
• Có thể truy cập nhanh hơn nếu trả nhiều tiền. Nhanh ở đây là so với phương thức archive, thời gian trả lời có thể là vài phút. Chứ không thể so tốc độ với S3 được
• Trên console của S3 cũng nhìn thấy Glacier nên nhiều người nhầm tưởng Glacier là một lớp lưu trữ của S3 nhưng thực ra Glacier là một dịch vụ độc lập
• Glacier có API riêng, không cần phải sử dụng S3 mới làm việc được với Glacier

Một số điểm khác biệt giữa S3 và Glacier

• Glacier hỗ trợ lưu trữ object lên tới 40TB thay vì 5TB trong S3
• Việc lưu trữ của Glacier được mã hóa theo mặc định
• Key trên S3 có thể đọc được, ID Glacier do máy tạo
• Thời gian lấy object là khác biệt lớn nhất: Glacier có thể mất vài giờ, trong khi S3 thì gần như ngay lập tức
• Glacier thích hợp lưu trữ dài hạn, không đòi hỏi truy xuất nhanh
• Các đối tượng lưu trữ thường là document, video, tar, zip file

Một số khái niệm chính

Archive

• Các đối tượng lưu trữ của Glacier gọi là archive (không phải object)
• Một archive có kích thước tối đa 40TB, số lượng và tổng dung lượng archive là không giới hạn
• Archive được gán 1 ID khi tạo và là immutable, tức là đã archive thì không thể thay đổi được nữa (xóa thì được nhưng không xóa được trên console)
  • Nếu đối tượng lưu trữ được chuyển từ S3 sang Glacier thông qua console hoặc Lifecycle thì trên console của S3 vẫn nhìn thấy đối tượng và vẫn có thể xóa được

Vault

• Glacier Vault là nơi lưu trữ dài hạn các archive tương tự như bucket của S3
• Mỗi account có thể có tối đa 1000 vaults

Vault Lock và Access Control

• Glacier sử dụng IAM để quản lý truy cập dữ liệu Glacier
• Có thể tạo user mới, gán credential và IAM Policy cho từng Vault để quản lý việc truy cập của user
• Vault Lock cho phép dễ dàng triển khai và compliance với từng vault thông qua policy. Chúng ta có thể dễ dàng quản lý thao tác với vault như “Write Once Read Many (WORM)” để phòng tránh việc thay đổi vault trong tương lai. Một khi lock, policy là immutable tức là không thể thay đổi được
• Vault Lock thường dùng liên quan đến compliance trong khi Access Control thì không, cả hai nên được dùng phối hợp với nhau
• Vault Lock cần 2 bước để thực thi:
  1. Initiate: Gắn 1 vault lock policy vào vault, quá trình lock ở trạng thái in-progress và trả về lock ID. Trong quá trình này, chúng ta có 24h để xác nhận vault lock policy. Nếu không xác nhận thì mặc định sẽ abort quá trình lock.
  2. Trong 24h nếu cảm thấy OK thì dùng lock ID để complete vault lock. Nếu policy chưa đúng như mong muốn thì Abort để làm lại từ đầu. Một khi đã lock xong, thì không thể thay đổi được nữa.

Amazon EBS (Elastic Block Storage)

Khái quát

• Có thể coi là “ổ cứng ảo”
• Chỉ có thể sử dụng với EC2 (cần xem lại?? RDS cũng sử dụng)
• Gắn với 1 AZ
• Có nhiều lựa chọn cho IOPS, Throughput và chi phí
• Snapshot rất tuyệt vời
• Kết nối qua mạng nên tốc độ không cao bằng ổ cứng có sẵn
• Có thể attach và detach

EBS vs Instance Storage

• Instance Storage là ổ cứng gắn với EC2 host có tính tạm thời
  • Instance Storage có tốc độ cao hơn do EBS truy cập qua mạng
• Instance Storage tốt nhất là dùng cho cache, buffer, khu vực làm việc
  • Dữ liệu muốn lưu trữ lâu dài nên dùng EBS
• Dữ liệu Instance Storage sẽ mất khi EC2 bị stopped hoặc terminated
  • Dữ liệu EBS thì vẫn còn

EBS Snapshot

• Chiến lược backup rất dễ dàng với chi phí hợp lý
• Chia sẻ dữ liệu với user hoặc account khác
• Migrate hệ thống sang AZ khác hoặc region khác
• Convert unencrypted volume thành encrypted
  1. Tạo snapshot unencrypted
  2. Tạo volume mới encrypted
  3. Attach vào EC2 instance
• Snapshot là incremental snapshot
• Snapshot sau sẽ tham chiếu đến snapshot trước và chỉ lưu những gì thay đổi
• Cách làm tối ưu chi phí và dung lượng lưu trữ snapshot
• Xóa 1 snapshot thì những dữ liệu được tham chiếu bởi snapshot khác vẫn được giữ => vẫn recover bình thường (không recover được thời điểm snapshot đã xóa)
• Tuy nhiên xóa snapshot không giúp tiết kiệm chi phí lưu trữ

Amazon EFS (Elastic File Service)

• Network File System
  • Có lịch sử từ Sun Microsystem (giờ đã bị mua lại với Oracle)
  • Sun Microsystem giới thiệu Sun OS trong đó sử dụng hệ thống tệp phân tán NFS (Network File System)
  • NFS là một giao thức cho phép file system của một hệ thống có thể được sử dụng bởi 1 hệ thống khác thông qua network.
  • NFS hoạt động trên mô hình server/client với server là nơi chia sẻ tài nguyên còn client là nơi sử dụng tài nguyên.
• Elastic File Service (EFS)
  • Cài đặt NSF file share
  • Dung lượng lưu trữ mềm dẻo, chỉ phải trả tiền cho lượng sử dụng (trái ngược với EBS phải mua volume trước)
    • Tuy nhiên giá EFS đắt gấp 3 EBS và gấp 20 lần S3
  • Lưu trữ metadata và data multi-AZ => dữ liệu rất an toàn
  • Có thể cấu hình mount-points (AWS gọi là mount target) trong 1 hoặc nhiều AZ (chính xác là trong subnet) => gọi EC2 instance ở tất cả AZ có thể mount EFS
  • Có thể mount từ hệ thống on-premise thông qua Direct Connect, các hình thức kết nối khác không mount được do trải nghiệm người dùng kém
  • Một cách thay thế là sử dụng EFS File Sync

Một ví dụ về việc sử dụng EFS

Amazon Storage Gateway

Khái quát

• Một phương thức để sử dụng cloud computing dạng hybrid (vừa sử dụng cloud computing vừa on-premise)
• Máy ảo chạy on-premise với VMWare hoặc HyperV
• Cung cấp tài nguyên lưu trữ cục bộ được hỗ trợ bởi AWS S3 và Glacier => mount vùng lưu trữ vào data center của mình, vùng lưu trữ đó được Storage Gateway sync lên S3 hoặc Glacier
• Thường được sử dụng như một sự chuẩn bị phục hồi thảm họa
• Rất hữu ích khi cần migrate lên cloud

Mode lưu trữ

• File Gateway: sử dụng NFS, SMB cho phép EC2 instance hoặc on premise lưu trữ dữ liệu trên S3 sử dụng NFS hoặc SMB mount point
• Volume Gateway Stored Mode (tên cũ Gateway stored volume): sử dụng iSCSI sao chép dữ liệu bất đồng bộ lên S3
• Volume Gateway Cached Mode (tên cũ Gateway cached volume): sử dụng iSCSI, dữ liệu chính được lưu trên S3, on premise đóng vai trò như cache, chỉ lưu những dữ liệu được sử dụng thường xuyên
• Tape Gateway (tên cũ Gateway virtual tape library): sử dụng iSCSI, là tape library ảo sử dụng với những phần mềm backup có sẵn (backup lên Glacier)

Để migrate lên cloud có thể sử dụng kết hợp các mode

• Lúc đầu sử dụng Stored Mode: sao chép dữ liệu lên cloud nhưng dữ liệu chính vẫn lưu on premise
• Sau khi sử dụng đã sao chép hơn chuyển sang Cached Mode: chỉ giữ lại những dữ liệu được sử dụng thường xuyên nhất
• Migrate phần còn lại lên cloud

Bandwidth throttling

• Một tính năng khá hay của Storage Gateway là Bandwidth Throttling
• Tính năng nay sẽ hữu ích trong trường hợp chúng ta không có một kết nối mạng mạnh
• Giới hạn băng thông upload hoặc download dữ liệu

Amazon WorkDocs

• Coi như là Amazon version của Dropbox hoặc Google Drive
• Dịch vụ cộng tác, lưu trữ và tạo nội dung bảo mật, fully managed
• Có thể tích hợp với AD để sử dụng SSO
• Có web, mobile và native client (cho Windows và MacOS, không có Linux)
• Tuân thủ các tiêu chuẩn HIPPA, PCI DSS và ISO
• Có SDK để tạo các app bổ trợ

Database on EC2

• Chạy bất kỳ database nào, toàn quyền kiểm soát và có tinh hoạt cao nhất (tương tự như on premise)
• Phải quản lý mọi thứ backup, redundancy, patching, scale
• Là một lựa chọn tốt nếu database không được support bởi RDS, ví dụ IBM DB2 hoặc SAP HANA
• Là lựa chọn tốt nếu việc migrate lên dịch vụ database của AWS là không khả thi

Một ví dụ đơn giản về việc sử dụng SAP HANA trên EC2

Amazon RDS

Khái quát

• Dịch vụ database được quản lý (người dùng không cần quản lý infra) cho các DB MySQL, Maria, PostgreSQL, Microsoft SQL Server, Oracle, Aurora (tương thích với MySQL, PostgreSQL)
• Là dịch vụ tốt nhất cho nhu cầu lưu trữ dữ liệu có cấu trúc, có quan hệ
• Mục tiêu là để thay thế các instance DB on premise bằng DB tương ứng trên AWS
• Tự động backup, patching trong maintenance windows thiết lập bởi người dùng
• Scaling, replication, redundancy rất đơn giản

Anti pattern

• Lưu trữ một lượng lớn object binary (BLOB) => dùng S3
• Cần khả năng mở rộng tự động => Dùng DynamoDB
• Dữ liệu có cấu trúc Name/Value => Dùng DynamoDB (NoSQL)
• Dữ liệu không có cấu trúc tốt hoặc không dự đoán trước được => Dùng DynamoDB (NoSQL)
• Các platform DB như IBM DB2 hoặc SAP HANA => Dùng EC2
• Muốn kiểm soát hoàn toàn DB => Dùng EC2

Replication

• Có 2 loại: Read Replica và multi-AZ RDS (Standby)
  • Standby DB cùng region (khác AZ) với Master
  • Read Replica có thể khác region (Cross-Region Read Replica)
  • Auro chỉ có Aurora Replica
  • Engine lưu trữ MyISAM (MySQL) dạng non-transactional không support replica => phải sử dụng InnoDB (MySQL) hoặc XtraDB (MariaDB)
• Standby DB sẽ sao chép đồng bộ, read replica sao chép bất đồng bộ
  • Đều có độ trễ, nhưng sao chép đồng bộ có độ trễ thấp hơn
• Khi 1 AZ có vấn đề, Master không hoạt động => Standby DB ở AZ khác sẽ trả thành primary, các read replica hoạt đồng bình thường
• Khi cả region có vấn đề, Master, Standby đều không hoạt động => Promote Read Replica thành Stand-Alone (Single AZ) sau đó cấu hình lại multi-AZ
  • Read Replica có thể được promote thành Master nhưng bình thường không ai làm vậy do sao chép bất đồng bộ nên độ trễ cao, có thể mất nhiều dữ liệu => chỉ khi thảm họa không cần Standby mới dùng cách này

NoSQL

Khái quát

• NoSQL: Not only SQL, Non-Relational Database
• Đáp ứng yêu cầu hàng chục nghìn truy vấn mỗi giây
• Dữ liệu dạng multi structured
• Tổ chức dữ liệu:
  • Schemaless
  • Dữ liệu lưu trong collection
  • Collection gồm nhiều item
  • Mỗi item sẽ gồm nhiều attribute là các cặp key-value
  • Không yêu cầu item có cùng attribute (chỉ yêu cầu cùng primary key attribute)
  • Các attribute độc lập và không liên quan đến nhau
  • NoSQL không chia bảng (có thể dẫn tới dư thừa dữ liệu)
• Các loại NoSQL
  • Key-value: mọi NoSQL DB
  • Document-oriented: Phân tích tài liệu, lưu trữ metadata
  • Graph Dabatabase: phân tích mỗi quan hệ giữa các item (kể cả khác cấu trúc)

DynamoDB

Đặc điểm

• NoSQL được quản lý, multi-AZ có Cross-Region Replication
• Có thể đọc eventual consistency (default) hoặc strongly consistent
• Tính tiền theo throughput, không phải theo tính toán
• Các cách tính tiền:
  • Provisioned Capacity:
    • Tự chọn provision read/write capacity theo nhu cầu
    • Autoscale có thể điều chính cầu hình
  • On-demand Capacity:
    • mềm dẻo hơn nhưng giá cho từng thao tác cao hơn
  • Reserved Capacity:
    • Mua trước capacity để dữ liệu
    • Mua theo từng block 100 RCU, 100 WCU
• Có thể sử dụng DynamoDB Transaction tuân thủ ACID (không bắt buộc)

Primary key

• Partition key (hash key): đơn giản, 1 thuộc tính, unique
• Composite key: partition key + sort key, có thể trùng partition key nhưng sort key phải khác nhau

Secondary Indexes

• Cho phép truy vấn với các attribute khác primary key
• Global Secondary Index:
  • Partition key và sort key khác với base table
  • Luôn luôn là eventual consistent
  • Sử dụng khi cần truy vấn nhanh các attribute khác primary key mà không cần sử dụng scan
• Local Secondary Index:
  • Phải dùng partition key của base table nhưng có thể dùng sort key khác
  • Phải tạo cùng với base table và không xóa được
  • Consistency: strongly hoặc eventual
  • Khi biết trước partition key và muốn truy vấn các thuộc tính khác nữa
• Max 5 local, 5 global secondary indexes
• Max 20 attribute cho mọi index
• Index sẽ tiêu tốn dung lượng lưu trữ

Amazon Neptune

• Fully-managed graph database (một dạng NoSQL)
• Hỗ trợ open graph API cho cả Gremlin và SPARQL
• High availability, read replica, point-in-time recovery, continuous backup, multi-AZ replication

Amazon DocumentDB

• Tương thích với MongoDB
• Nhanh, scalable, high availability, fully managed
• Dữ liệu xử lý chủ yếu ở dạng JSON

Amazon Redshift

Khái quát

• Tên bắt nguồn từ hiện tượng vật lý
  • Ánh sáng phát ra từ các vật chuyển động ra xa sẽ đỏ hơn (bước sóng dài hơn) tương tự hiệu ứng Doppler
  • Thường dùng trong thiên văn, vũ trụ phát hiện các thiên xa đang chuyển động ra xa nhau
• Data warehouse được quản lý hoàn toàn, chia cluster, scale hàng petabyte
• Cực kỳ hợp lý về chi phí khi so sánh với các platform data warehouse on premise khác
• Tương thích với PostgreSQL với driver JDBC, ODBC, tương thích với hầu hết các công cụ BI
• Tính năng xử lý song song và lưu trữ dữ liệu columnar tối ưu cho truy vấn phức tạp
• Có thể truy vấn trực tiếp từ data file trên S3 thông qua Redshift Spectrum

Data Lake

• Kho lưu trữ tập trung cho phép lưu mọi dữ liệu có và không có cấu trúc
• Lưu trữ dữ liệu thô, không cần xử lý trước
• Có thể thực hiện mọi thao tác phân tích

Ví dụ sử dụng S3 làm data lake

Amazon ElastiCache

Khái quát

• Fully managed
• Cài đặt 2 loại lưu trữ dữ liệu in-memory phổ biến nhất: Redis và Memcached
• Dễ dàng mở rộng về bộ nhớ, write, read
• Cơ chế lưu dữ liệu key/value in-memory
  • Tốc độ đọc ghi nhanh (nhanh hơn DynamoBD)
  • Dữ liệu không được duy trì (tắt là mất)
• Tính tiền theo node size và số giờ sử dụng

Use case

• Lưu web session: Trong trường hợp cân bằng tải, lưu session trong Redis khi server có sự cố thông tin session vẫn không mất và có thể được sử dụng bởi server khác
• Database caching: Sử dụng Memcached trước AWS RDS để cache các query phổ biến nhằm giảm tải công việc RDS và trả về kết quả nhanh hơn
• Leaderboards: Sử dụng Redis cung cấp leaderboard cho hàng triệu user của mobile app
• Streaming Data Dashboard: Cung cấp dashboard thời gian thực về thông tin streaming

Memcached vs Redis

Memcached

• Đơn giản, không rườm rà
• Cần scale out và thay đổi theo yêu cầu
• Cần nhiều CPU và threads
• Cần cache object (ví dụ database query)

Redis

• Cần mã hóa
• Cần tuân thu HIPPA
• Hỗ trợ clustering
• Cần kiểu dữ liệu phức tạp
• Cần high availability (replication)
• Khả năng pub/sub
• Index không gian địa lý
• Backup và restore

So sánh các DB option

• Database on EC2
  • Kiểm soát cao nhất DB
  • DB muốn sử dụng không hỗ trợ bởi RDS
• Amazon RDS
  • Cần cơ sở dữ liệu quan hệ truyền thống cho OLTP
  • Dữ liệu có cấu trúc tốt
• Amazon DynamoDB
  • Dữ liệu có cấu trúc cặp Name/value hoặc cấu trúc không đoán trước
  • Hiệu năng tương tự in-memory nhưng có tính duy trì (dữ liệu được lưu lâu dài)
• Amazon Redshift
  • Một lượng lớn dữ liệu
  • Workload cơ bản là OLAP
• Amazon Neptune
  • Mối quan hệ giữa các đối tượng là giá trị lớn nhất của dữ liệu
• Amazon ElastiCache
  • Bộ nhớ nhanh tạm thời cho lượng nhỏ dữ liệu
  • Dữ liệu biến động mạnh