Hãy sử dụng các phương pháp hay nhất được liệt kê ở đây làm tài liệu tham khảo nhanh khi xây dựng một ứng dụng sử dụng Cloud Firestore.
Vị trí cơ sở dữ liệu
Khi tạo thực thể cơ sở dữ liệu, hãy chọn vị trí cơ sở dữ liệu gần nhất với người dùng và tài nguyên tính toán của bạn. Các bước nhảy mạng có phạm vi rộng dễ xảy ra lỗi hơn và làm tăng độ trễ truy vấn.
Để tối đa hoá khả năng sử dụng và độ bền của ứng dụng, hãy chọn một vị trí nhiều khu vực và đặt các tài nguyên tính toán quan trọng ở ít nhất hai khu vực.
Chọn một vị trí theo khu vực để giảm chi phí, giảm độ trễ ghi nếu ứng dụng của bạn nhạy cảm với độ trễ hoặc để cùng vị trí với các tài nguyên GCP khác.
Mã nhận dạng tài liệu
- Tránh mã nhận dạng tài liệu
.và... - Tránh sử dụng
/dấu gạch chéo trong mã nhận dạng tài liệu. Không sử dụng mã nhận dạng tài liệu tăng đơn điệu, chẳng hạn như:
Customer1,Customer2,Customer3, ...Product 1,Product 2,Product 3, ...
Các mã nhận dạng tuần tự như vậy có thể dẫn đến các điểm nóng ảnh hưởng đến độ trễ.
Tên trường
Tránh sử dụng các ký tự sau trong tên trường vì chúng yêu cầu thêm ký tự thoát:
.dấu chấm[dấu mở ngoặc vuông]dấu đóng ngoặc vuông*dấu hoa thị`dấu phẩy ngược
Chỉ mục
Giảm độ trễ ghi
Yếu tố chính gây ra độ trễ ghi là hệ số phân nhánh chỉ mục. Các phương pháp hay nhất để giảm hệ số phân nhánh chỉ mục là:
Đặt các trường hợp miễn trừ chỉ mục ở cấp bộ sưu tập. Một giá trị mặc định dễ dàng là tắt tính năng lập chỉ mục Mảng và Giảm dần. Việc xoá các giá trị được lập chỉ mục không dùng đến cũng sẽ làm giảm chi phí lưu trữ.
Giảm số lượng tài liệu trong một giao dịch. Để ghi một số lượng lớn tài liệu, hãy cân nhắc sử dụng trình ghi hàng loạt thay vì trình ghi hàng loạt nguyên tử.
Các trường hợp miễn trừ chỉ mục
Đối với hầu hết các ứng dụng, bạn có thể dựa vào tính năng lập chỉ mục tự động cũng như mọi đường liên kết thông báo lỗi để quản lý chỉ mục. Tuy nhiên, bạn có thể muốn thêm các trường hợp miễn trừ một trường trong các trường hợp sau:
| Hộp | Mô tả |
|---|---|
| Trường chuỗi lớn | Nếu có một trường chuỗi thường chứa các giá trị chuỗi dài mà bạn không dùng để truy vấn, bạn có thể cắt giảm chi phí lưu trữ bằng cách miễn trừ trường đó khỏi việc lập chỉ mục. |
| Tỷ lệ ghi cao vào một bộ sưu tập chứa các tài liệu có giá trị tuần tự | Nếu bạn lập chỉ mục một trường tăng hoặc giảm tuần tự giữa tài liệu trong một bộ sưu tập, chẳng hạn như dấu thời gian, thì tỷ lệ ghi tối đa vào bộ sưu tập là 500 lần ghi mỗi giây. Nếu không truy vấn dựa trên trường có giá trị tuần tự, bạn có thể miễn trừ trường đó khỏi việc lập chỉ mục để bỏ qua giới hạn này. Trong trường hợp sử dụng IoT có tỷ lệ ghi cao, chẳng hạn như một bộ sưu tập chứa các tài liệu có trường dấu thời gian có thể đạt đến giới hạn 500 lần ghi mỗi giây. |
| Trường TTL |
Nếu bạn sử dụng chính sách TTL (thời gian tồn tại), hãy lưu ý rằng trường TTL phải là dấu thời gian. Tính năng lập chỉ mục trên các trường TTL được bật theo mặc định và có thể ảnh hưởng đến hiệu suất ở tỷ lệ lưu lượng truy cập cao hơn. Tốt nhất là bạn nên thêm các trường hợp miễn trừ lập chỉ mục tự động cho các trường TTL. |
| Trường mảng hoặc bản đồ lớn | Các trường mảng hoặc bản đồ lớn có thể đạt đến giới hạn 40.000 mục nhập chỉ mục cho mỗi tài liệu. Nếu không truy vấn dựa trên trường mảng hoặc bản đồ lớn, bạn nên miễn trừ trường đó khỏi việc lập chỉ mục. |
Thao tác đọc và ghi
Tỷ lệ tối đa chính xác mà một ứng dụng có thể cập nhật một tài liệu duy nhất phụ thuộc rất nhiều vào khối lượng công việc. Để biết thêm thông tin, hãy xem Cập nhật một tài liệu duy nhất.
Sử dụng lệnh gọi không đồng bộ (nếu có) thay vì lệnh gọi đồng bộ. Lệnh gọi không đồng bộ giúp giảm thiểu tác động của độ trễ. Ví dụ: hãy cân nhắc một ứng dụng cần kết quả tra cứu tài liệu và kết quả của một truy vấn trước khi kết xuất phản hồi. Nếu tra cứu và truy vấn không có sự phụ thuộc dữ liệu, thì không cần phải đợi đồng bộ cho đến khi tra cứu hoàn tất trước khi bắt đầu truy vấn.
Không sử dụng độ lệch. Thay vào đó, hãy sử dụng con trỏ. Việc sử dụng độ lệch chỉ giúp tránh trả về các tài liệu bị bỏ qua cho ứng dụng của bạn, nhưng các tài liệu này vẫn được truy xuất nội bộ. Các tài liệu bị bỏ qua ảnh hưởng đến độ trễ của truy vấn và ứng dụng của bạn sẽ bị tính phí cho các thao tác đọc cần thiết để truy xuất các tài liệu đó.
Thử lại giao dịch
Các Cloud Firestore SDK và thư viện ứng dụng Cloud Firestore tự động thử lại các giao dịch không thành công để xử lý các lỗi tạm thời. Nếu ứng dụng của bạn truy cập Cloud Firestore thông qua các API REST hoặc RPC trực tiếp thay vì thông qua SDK, thì ứng dụng của bạn nên triển khai tính năng thử lại giao dịch để tăng độ tin cậy.
Thông tin cập nhật theo thời gian thực
Để biết các phương pháp hay nhất liên quan đến thông tin cập nhật theo thời gian thực, hãy xem bài viết Tìm hiểu các truy vấn theo thời gian thực ở quy mô lớn.
Thiết kế để chuyển tỷ lệ
Các phương pháp hay nhất sau đây mô tả cách tránh các tình huống tạo ra vấn đề về tranh chấp.
Cập nhật một tài liệu duy nhất
Khi thiết kế ứng dụng, hãy cân nhắc tốc độ cập nhật tài liệu duy nhất của ứng dụng. Cách tốt nhất để mô tả hiệu suất của khối lượng công việc là thực hiện kiểm thử tải. Tỷ lệ tối đa chính xác mà một ứng dụng có thể cập nhật một tài liệu duy nhất phụ thuộc rất nhiều vào khối lượng công việc. Các yếu tố bao gồm tỷ lệ ghi, tranh chấp giữa các yêu cầu và số lượng chỉ mục bị ảnh hưởng.
Thao tác ghi tài liệu sẽ cập nhật tài liệu và mọi chỉ mục được liên kết, và Cloud Firestore áp dụng đồng bộ thao tác ghi trên một số lượng bản sao đủ để đạt được sự đồng thuận. Ở tỷ lệ ghi đủ cao, cơ sở dữ liệu sẽ bắt đầu gặp phải tình trạng tranh chấp, độ trễ cao hơn hoặc các lỗi khác.
Tỷ lệ đọc, ghi và xoá cao đối với một phạm vi tài liệu hẹp
Tránh tỷ lệ đọc hoặc ghi cao đối với các tài liệu gần nhau theo thứ tự từ vựng, nếu không, ứng dụng của bạn sẽ gặp phải lỗi tranh chấp. Vấn đề này được gọi là điểm nóng và ứng dụng của bạn có thể gặp phải tình trạng điểm nóng nếu thực hiện bất kỳ thao tác nào sau đây:
Tạo tài liệu mới với tốc độ rất cao và phân bổ mã nhận dạng tăng đơn điệu của riêng mình.
Cloud Firestore phân bổ mã nhận dạng tài liệu bằng thuật toán phân tán. Bạn không nên gặp phải tình trạng điểm nóng khi ghi nếu tạo tài liệu mới bằng mã nhận dạng tài liệu tự động.
Tạo tài liệu mới với tốc độ cao trong một bộ sưu tập có ít tài liệu.
Tạo tài liệu mới có trường tăng đơn điệu, chẳng hạn như dấu thời gian, với tốc độ rất cao.
Xoá tài liệu trong một bộ sưu tập với tốc độ cao.
Ghi vào cơ sở dữ liệu với tốc độ rất cao mà không tăng dần lưu lượng truy cập.
Tránh bỏ qua dữ liệu đã xoá
Tránh các truy vấn bỏ qua dữ liệu đã xoá gần đây. Một truy vấn có thể phải bỏ qua một số lượng lớn mục nhập chỉ mục nếu kết quả truy vấn ban đầu đã bị xoá gần đây.
Ví dụ về một khối lượng công việc có thể phải bỏ qua nhiều dữ liệu đã xoá là khối lượng công việc cố gắng tìm các mục công việc được xếp hàng đợi lâu nhất. Truy vấn có thể có dạng như sau:
docs = db.collection('WorkItems').order_by('created').limit(100)
delete_batch = db.batch()
for doc in docs.stream():
finish_work(doc)
delete_batch.delete(doc.reference)
delete_batch.commit()
Mỗi khi truy vấn này chạy, nó sẽ quét các mục nhập chỉ mục cho trường created trên mọi tài liệu đã xoá gần đây. Điều này làm chậm các truy vấn.
Để cải thiện hiệu suất, hãy sử dụng phương thức start_at để tìm vị trí tốt nhất để bắt đầu. Ví dụ:
completed_items = db.collection('CompletionStats').document('all stats').get()
docs = db.collection('WorkItems').start_at(
{'created': completed_items.get('last_completed')}).order_by(
'created').limit(100)
delete_batch = db.batch()
last_completed = None
for doc in docs.stream():
finish_work(doc)
delete_batch.delete(doc.reference)
last_completed = doc.get('created')
if last_completed:
delete_batch.update(completed_items.reference,
{'last_completed': last_completed})
delete_batch.commit()
LƯU Ý: Ví dụ trên sử dụng một trường tăng đơn điệu, đây là một mẫu chống lại tỷ lệ ghi cao.
Tăng dần lưu lượng truy cập
Bạn nên tăng dần lưu lượng truy cập đến các bộ sưu tập mới hoặc các tài liệu gần nhau theo thứ tự từ vựng để Cloud Firestore có đủ thời gian chuẩn bị tài liệu cho lưu lượng truy cập tăng lên. Bạn nên bắt đầu với tối đa 500 thao tác mỗi giây cho một bộ sưu tập mới, sau đó tăng lưu lượng truy cập thêm 50% sau mỗi 5 phút. Bạn cũng có thể tăng dần lưu lượng truy cập ghi, nhưng hãy lưu ý đến Cloud Firestore Giới hạn tiêu chuẩn. Đảm bảo rằng các thao tác được phân bổ tương đối đồng đều trong phạm vi khoá. Đây được gọi là quy tắc "500/50/5".
Di chuyển lưu lượng truy cập sang một bộ sưu tập mới
Việc tăng dần là đặc biệt quan trọng nếu bạn di chuyển lưu lượng truy cập ứng dụng từ một bộ sưu tập sang một bộ sưu tập khác. Một cách đơn giản để xử lý quá trình di chuyển này là đọc từ bộ sưu tập cũ và nếu tài liệu không tồn tại, thì hãy đọc từ bộ sưu tập mới. Tuy nhiên, điều này có thể khiến lưu lượng truy cập tăng đột ngột đối với các tài liệu gần nhau theo thứ tự từ vựng trong bộ sưu tập mới. Cloud Firestore có thể không chuẩn bị hiệu quả bộ sưu tập mới cho lưu lượng truy cập tăng lên, đặc biệt là khi bộ sưu tập đó chứa ít tài liệu.
Một vấn đề tương tự có thể xảy ra nếu bạn thay đổi mã nhận dạng tài liệu của nhiều tài liệu trong cùng một bộ sưu tập.
Chiến lược tốt nhất để di chuyển lưu lượng truy cập sang một bộ sưu tập mới phụ thuộc vào mô hình dữ liệu của bạn. Dưới đây là một ví dụ về chiến lược được gọi là đọc song song. Bạn sẽ cần xác định xem chiến lược này có hiệu quả đối với dữ liệu của bạn hay không và một yếu tố quan trọng cần cân nhắc là tác động chi phí của các thao tác song song trong quá trình di chuyển.
Đọc song song
Để triển khai tính năng đọc song song khi di chuyển lưu lượng truy cập sang một bộ sưu tập mới, hãy đọc từ bộ sưu tập cũ trước. Nếu tài liệu bị thiếu, hãy đọc từ bộ sưu tập mới. Tỷ lệ đọc cao đối với các tài liệu không tồn tại có thể dẫn đến tình trạng điểm nóng, vì vậy, hãy nhớ tăng dần tải cho bộ sưu tập mới. Một chiến lược tốt hơn là sao chép tài liệu cũ sang bộ sưu tập mới, sau đó xoá tài liệu cũ. Tăng dần số lần đọc song song để đảm bảo rằng Cloud Firestore có thể xử lý lưu lượng truy cập đến bộ sưu tập mới.
Một chiến lược có thể để tăng dần số lần đọc hoặc ghi vào một bộ sưu tập mới là sử dụng hàm băm xác định của mã nhận dạng người dùng để chọn một tỷ lệ phần trăm ngẫu nhiên của người dùng đang cố gắng ghi tài liệu mới. Đảm bảo rằng kết quả của hàm băm mã nhận dạng người dùng không bị lệch do hàm của bạn hoặc do hành vi của người dùng.
Trong khi đó, hãy chạy một công việc hàng loạt sao chép tất cả dữ liệu của bạn từ các tài liệu cũ sang bộ sưu tập mới. Công việc hàng loạt của bạn nên tránh ghi vào mã nhận dạng tài liệu tuần tự để ngăn chặn các điểm nóng. Khi công việc hàng loạt hoàn tất, bạn chỉ có thể đọc từ bộ sưu tập mới.
Một cách tinh chỉnh chiến lược này là di chuyển các đợt nhỏ người dùng tại một thời điểm. Thêm một trường vào tài liệu người dùng để theo dõi trạng thái di chuyển của người dùng đó. Chọn một đợt người dùng để di chuyển dựa trên hàm băm của mã nhận dạng người dùng. Sử dụng công việc hàng loạt để di chuyển tài liệu cho đợt người dùng đó và sử dụng tính năng đọc song song cho những người dùng đang trong quá trình di chuyển.
Xin lưu ý rằng bạn không thể dễ dàng khôi phục trừ phi bạn thực hiện ghi kép cả thực thể cũ và mới trong giai đoạn di chuyển. Điều này sẽ làm tăng Cloud Firestore chi phí phát sinh.
Quyền riêng tư
- Tránh lưu trữ thông tin nhạy cảm trong Mã dự án trên Google Cloud. Mã dự án trên Google Cloud có thể được giữ lại sau khi dự án của bạn kết thúc.
- Theo phương pháp hay nhất về tuân thủ dữ liệu, bạn không nên lưu trữ thông tin nhạy cảm trong tên tài liệu và tên trường tài liệu.
Ngăn chặn hành vi truy cập trái phép
Ngăn chặn các thao tác trái phép trên cơ sở dữ liệu của bạn bằng Cloud Firestore Security Rules. Ví dụ: việc sử dụng quy tắc có thể tránh được trường hợp người dùng độc hại liên tục tải xuống toàn bộ cơ sở dữ liệu của bạn.
Tìm hiểu thêm về cách sử dụng Cloud Firestore Security Rules.