Sau khi làm theo Phần 1 của loạt bài này, các máy chủ của bạn giờ đã có thể mở rộng theo chiều ngang và bạn có thể xử lý hàng nghìn yêu cầu đồng thời. Nhưng rồi, theo thời gian, ứng dụng của bạn ngày càng chậm lại và cuối cùng là sụp đổ. Nguyên nhân: cơ sở dữ liệu của bạn. Là MySQL, phải không?
Lúc này, các thay đổi cần thiết sẽ cấp tiến hơn nhiều so với việc chỉ thêm các máy chủ bản sao, và có thể đòi hỏi cả một chút liều lĩnh. Cuối cùng, bạn sẽ đứng trước hai con đường:
Con đường số 1 là tiếp tục dùng MySQL và cố gắng duy trì “quái vật” đó. Thuê một quản trị viên cơ sở dữ liệu (DBA), yêu cầu họ thiết lập hệ thống master-slave replication (đọc từ slave, ghi vào master) và nâng cấp máy chủ master bằng cách thêm RAM, RAM và thêm thật nhiều RAM. Vài tháng sau, DBA của bạn sẽ bắt đầu nói đến những khái niệm như “sharding”, “phi chuẩn hóa dữ liệu” và “tối ưu truy vấn SQL”, đồng thời sẽ tỏ ra lo lắng vì những tuần làm việc ngoài giờ sắp tới. Đến lúc đó, mỗi hành động tiếp theo để duy trì cơ sở dữ liệu sẽ ngày càng tốn kém và mất thời gian hơn. Có thể bạn đã sáng suốt hơn nếu chọn con đường số 2 ngay từ khi dữ liệu còn nhỏ và dễ di chuyển.
Con đường số 2 là phi chuẩn hóa dữ liệu (denormalize) ngay từ đầu và không còn sử dụng bất kỳ JOIN nào trong các truy vấn cơ sở dữ liệu. Bạn vẫn có thể dùng MySQL, nhưng hãy sử dụng nó như một cơ sở dữ liệu NoSQL, hoặc chuyển hẳn sang một hệ quản trị NoSQL có khả năng mở rộng dễ hơn như MongoDB hoặc CouchDB. Các thao tác JOIN lúc này sẽ phải được thực hiện trong mã ứng dụng của bạn. Bạn càng thực hiện bước này sớm thì sau này càng ít phải sửa đổi mã. Nhưng ngay cả khi bạn đã chuyển đổi thành công sang hệ NoSQL tối tân nhất và để ứng dụng xử lý việc ghép dữ liệu (join), thì chẳng bao lâu sau, các truy vấn cơ sở dữ liệu của bạn cũng lại bắt đầu chậm dần.
Lúc đó, bạn sẽ cần triển khai một hệ thống cache.
Dẫn nguồn: https://www.lecloud.net/post/7994751381/scalability-for-dummies-part-2-database
