Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Anh ơi, trong mô hình microservice, ví dụ em có 10 service, thì mỗi service nên dùng riêng 1 DB hay nên dùng chung ạ, nhưng dùng chung thì em đoán là 1 thời điểm nào đó DB sẽ bị sập vì phải phục vụ cùng lúc 10 service, xử lý nặng nề nên dễ bị nghẽn cổ chai ở đây đúng k ạ, vì DB tương tự máy tính, cũng có giới hạn xử lý của nó thôi
Việc thiết kế DB không phải là muốn tách là tách được em ạ, nó còn liên quan đến khả năng truy vấn (đặc biệt là các câu lệnh join) và chi phí vận hành.
Tuy nhiên là ở 1 mức độ nào đó, khi các service hoạt động tương đối độc lập, và có nhiều team hoạt động độc lập thì nên tách database để đẩy nhanh được tốc độ phát triển.
Thế nên đây là câu hỏi không có câu trả lời cụ thể, nó sẽ phụ thuộc vào từng bài toán cũng như mọi hoàn cảnh cụ thể mà quyết định. Ví dụ cả 10 service có 1 mình em làm mà em tách thành 10 DB thì anh nghĩ em sẽ không thể nào maintain nổi đâu.
hãy vui vì lúc DB của bạn sập thì chứng tỏ product của bạn có người dùng rồi đó. HIHI
Đùa chứ mình cũng đang có những kinh nghiệm thương đau về việc tách nhiều DB với khoảng 8 con service. Rất rất cực chuyện sync data giữa các service vì phải duplicate một số table trong DB. Cuối cùng mình gom tất cả lại thành 2 con DB. Nói chung ban đầu, theo kn của mình khi mới bắt đầu build product MVP. Nên chỉ có tối đa 2 con DB. còn lại thì dùng chung vì thời gian đầu nhân lúc chưa có, spec business chưa rõ ràng. Sau này rảnh rỗi thì tách sau.