Những chú ý khi chọn MySQL làm database

(Ngày: 03/02/2020)
Ắt hẳn trong số chúng ta khi lập trình web đều đã từng làm việc với database. Vậy khi nào thì nên dùng MySQL và vận hành MySQL cần chú ý những gì? Cùng tham khảo bài viết sau nhé.

Scaling khá vất vả

Ví dụ: Nếu dùng MySQL vào trong hệ thống chat với dữ liệu message cực lớn (như Facebook Messenger). Khi đó bảng để lưu message sẽ kiểu như thế này:

messages (id, room_id, sender_id, message_body, created_at)

Và không chỉ có mỗi bảng này mà còn rất nhiều bảng khác nữa.

Chẳng hạn như bảng users để lưu thông tin người dùng.

Bảng attachments để quản lý thông tin file được đính kèm khi gửi.

Bảng tags để lưu thông tin tag của người dùng.

Ngoài ra, không chỉ có tính năng chat mà có khi ta cũng sẽ cần phải có thêm tính năng phân tích hành vi của người dùng nữa. Nên lúc đó có thể chúng ta sẽ lưu access_log của người dùng vào MySQL.

Một dãy các luồng xử lí thì khi release xong, với số lượng người dùng ít thì tốc độ query sẽ rất nhanh nên ít ai để ý đến vấn đề scaling sau này.

Vậy vấn đề ở đây là dữ liệu to dần và không thể cache hết lên memory, dẫn đến phải read từ disk và làm tốc độ giảm xuống.

Giai đoạn đầu khi release, lượng dữ liệu sử dụng trên MySQL còn nhỏ, memory cấp phát cho cache có nhỏ đi chăng nữa thì cũng có thể đẩy dữ liệu lên đó được.

Thế nhưng sau 1 thời gian vận hành, lượng dữ liệu tăng gấp bội, số lượng access của người dùng cũng tăng lên. Dẫn đến tỉ lệ cache hit trên MySQL sẽ giảm xuống (vì không đủ memory để cache). Kết quả là phải đọc dữ liệu từ disk thay vì từ cache. Và làm cho tốc độ giảm xuống. (Đọc data trên memory nhanh gấp 200 lần HDD, và gấp 10 lần SSD).

Để giải quyết vấn đề này trong thời gian ngắn thì có 2 cách:

  • Tăng memory lên để có thể cache được nhiều dữ liệu trên memory hơn. Cách này được gọi là scale up.
  • Áp dụng cơ chế master slave vào hệ thống. Master sẽ đảm nhiệm việc ghi. Slave sẽ đảm nhiệm việc đọc. Mỗi khi dữ liệu trên master bị thay đổi thì sẽ replication sang các con slave để đồng bộ dữ liệu. Cách này còn được gọi là scale out.

Cho dù thực hiện cách nào đi chăng nữa thì cost vận hành trên MySQL sẽ càng ngày càng tăng lên. Đến 1 lúc nào đó cost này sẽ tăng đến 1 mức độ mà có khi tiền doanh thu hàng tháng không trả nổi tiền nuôi server.

Với tình trạng như này thì các bạn sẽ suy nghĩ gì?

  • Tốc độ đọc ghi sẽ chậm hơn, làm cho trải nghiệm người dùng bị giảm xuống.
  • Muốn tung ra nhiều campaign để thu hút người dùng. Thế nhưng MySQL bị bottleneck và không thể thực hiện campaign được.
  • Thay đổi sang 1 loại database mới. Thế nhưng do tính chất của nó khác nhau dẫn đến bắt buộc phải sửa logic phía application. Hơn thế nữa việc migration big data từ server này sang server khác có thể mất rất nhiều ngày. (1 ngày application maintain có thể làm doanh thu giảm xuống khá nhiều).

Tính bảo trì, failover khá lớn

Khi MySQL đang được chạy dưới cơ chế master-slave (dữ liệu luôn luôn được đồng bộ từ master sang slave). Chẳng may vì 1 lí do nào đó mà con master bị down. Khi đó MySQL sẽ thực hiện failover (chuyển con master bị down sang 1 con master dự phòng khác). Quá trình này sẽ mất vài phút (với trường hợp RDS của aws).

Với business yêu cầu khắt khe về mặt downtime (ví dụ như game chẳng hạn) thì có lẽ với case mất vài phút để thực hiện failover thì chắc khó có thể chấp nhận được.

Vậy thì ta nên giải quyết vấn đề đó như thế nào?

Chọn database thích hợp hơn?

Để giải quyết được vấn đề này thì có lẽ ta nên chọn loại database khác không phải MySQL. Ví dụ như NoSQL chẳng hạn.

Nhưng khi dữ liệu của hệ thống đã to rồi thì việc chọn 1 database khác không phải là sự lựa chọn đúng đắn lắm vì có thể sẽ phải sửa code khá nhiều, thời gian migration từ database này sang database khác sẽ mất khá nhiều thời gian (có thể mấy ngày đến 1 tuần).

Do đó ngay trong giai đoạn thiết kế thì việc suy nghĩ chọn database nào phù hợp là 1 điều vô cùng quan trọng, đặc biệt cần suy nghĩ xem tương lai dữ liệu sẽ lớn đến mức độ nào.

Với NoSQL thì có vô số loại, ví dụ như Cassandra, DynamoDB.

Cả 2 loại này tính scalable của nó cực lớn, các ông lớn như Facebook, Discord, Instagram hiện tại cũng đang dùng nó.

Một số tính năng của Cassandra và DynamoDB:

Cassandra:

  • Được phát triển bởi Facebook, sau đó tặng cho bên Apache.
  • Cassandra là hệ cơ sở dữ liệu phân tán, kết hợp những gì tinh tuý nhất của Google Bigtable và Amazon DynamoDB. Ngôn ngữ phát triển Cassandra là Java.
  • Dữ liệu được dàn trải sang nhiều node, nên 1 node có chết đi chăng nữa thì vẫn có thể query lấy được dữ liệu trên node khác. Do đó tính chịu lỗi của nó cực lớn.
  • Throughput của nó tăng theo số lượng node. Nếu muốn nó xử lí được nhiều request hơn thì chỉ cần tăng số node lên.
  • Tốc độ write luôn luôn nhanh hơn read. Bởi vì write chỉ cần append vào đít file. Trong khi read cần phải check tính CAP (có thể hiểu đây là tính toàn vẹn dữ liệu) giữa các node nữa nên thời gian sẽ lâu hơn. Mặc dù nói là lâu nhưng mà thời gian của read hay write cũng chỉ tính bằng ms.

DynamoDB:

  • DynamoDB là hệ cơ sở dữ liệu phân tán, được phát triển bởi Amazon.
  • Có thể setting thông số throughput của read và write riêng. Và Amazon sẽ tự động scale để đáp ứng được số throughput đó.
  • Ví dụ như tại thời điểm peak time thì chúng ta setting cho số throughput của read cao hơn chút, ở thời điểm ít access thì setting throughput thấp xuống. Để tiết kiệm cost.

Tóm lại việc chọn database nào đi chăng nữa thì điều quan trọng nhất là nó không làm mất đi tính trải nghiệm của người dùng.

Quay lại bài toán về hệ thống chat như ở bên trên, nếu số lượng người dùng tăng lên mà để trải nghiệm người dùng không bị mất đi thì chúng ta cần thiết kế hệ thống có tính scalable. Đặc biệt với database thì có thể kết hợp cả MySQL lẫn NoSQL lại chẳng hạn, hoặc dùng hẳn NoSQL. Tuỳ vào từng bài toán mà chúng ta cần đưa ra phương án hợp lí.

viblo.asia