Nền tảng·5 phút đọc·Le Cloud Blog - Scalability for Dummies, Part 2

Khả năng mở rộng cho người mới - Phần 2: Cơ sở dữ liệu (Database)

Nút thắt cổ chai mới

Sau khi làm theo Phần 1, các server của bạn giờ đã mở rộng theo chiều ngang (horizontally scale) được, và bạn đã phục vụ được hàng nghìn request đồng thời.

Nhưng rồi đến một lúc nào đó, ứng dụng của bạn cứ chậm dần, chậm dần, rồi sập hẳn. Nguyên nhân: database của bạn. Là MySQL đúng không?

Lúc này, những thay đổi cần làm đã triệt để hơn nhiều so với việc chỉ thêm vài server nhân bản, và thậm chí còn đòi hỏi một chút gan dạ. Rốt cuộc, bạn có hai con đường để chọn.

Con đường 1: Bám lấy MySQL

Con đường thứ nhất là ở lại với MySQL và cố giữ cho "con quái vật" đó chạy tiếp.

Thuê một quản trị viên cơ sở dữ liệu (DBA - database administrator), bảo anh ta làm master-slave replication (đọc từ slave, ghi vào master), rồi nâng cấp server master bằng cách thêm RAM, RAM và thêm RAM nữa.

Vài tháng sau, DBA của bạn sẽ bắt đầu nhắc đến những từ như "sharding", "denormalization" và "SQL tuning", và trông đầy lo lắng về đống giờ làm thêm sắp tới trong những tuần kế tiếp.

Đến lúc đó, mỗi hành động mới để giữ database sống sót đều sẽ đắt đỏ và tốn thời gian hơn hành động trước đó. Có lẽ bạn đã khá hơn nhiều nếu chọn Con đường 2 ngay từ khi tập dữ liệu còn nhỏ và còn dễ di chuyển.

Con đường 2: Phi chuẩn hóa ngay từ đầu

Con đường thứ hai nghĩa là denormalize (phi chuẩn hóa) ngay từ đầu, và không dùng thêm bất kỳ phép Join nào trong mọi câu truy vấn database.

Bạn có thể vẫn ở lại với MySQL nhưng dùng nó như một database NoSQL, hoặc chuyển sang một database NoSQL tốt hơn và dễ mở rộng hơn như MongoDB hay CouchDB.

Việc Join giờ sẽ phải làm trong code ứng dụng của bạn. Bạn làm bước này càng sớm thì sau này càng phải sửa ít code.

Nhưng vẫn chưa đủ

Nhưng kể cả khi bạn đã chuyển thành công sang database NoSQL mới nhất và xịn nhất, rồi để ứng dụng tự lo việc join dữ liệu, thì chẳng bao lâu các request tới database lại sẽ chậm dần, chậm dần.

Bạn sẽ cần đưa vào một cache.