Các phương pháp hay nhất dành cho Cloud Firestore

Sử dụng các phương pháp hay nhất được liệt kê tại đâ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 bạn tạo thực thể cơ sở dữ liệu, hãy chọn cơ sở dữ liệu vị trí gần nhất với người dùng và tài nguyên điện toán của bạn. Bước mạng sâu rộng dễ gặp 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 của bạn, hãy chọn một vị trí theo nhiều vùng và cần đặt tài nguyên điện toán quan trọng vào ít nhất 2 vùng.

Chọn một địa điểm theo khu vực để có chi phí thấp hơn và dễ ghi hơn độ trễ nếu ứng dụng của bạn nhạy cảm với độ trễ, hoặc để cùng địa điểm với các tài nguyên khác trên Google Cloud Platform.

Mã tài liệu

  • Tránh dùng các mã nhận dạng tài liệu . và ...
  • Tránh sử dụng / dấu gạch chéo lên trong mã tài liệu.

  • Bạn không được 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, ...

    Mã 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 các ký tự sau trong tên trường vì các ký tự này yêu cầu thêm thoát:

    • Hiệp .
    • [ dấu ngoặc đơn trái
    • ] dấu ngoặc đơn phải
    • Dấu hoa thị *
    • ` dấu phẩy ngược

Chỉ số

Giảm độ trễ ghi

Yếu tố chính góp phần tạo ra độ trễ khi viết là lập chỉ mục fanout. Các phương pháp hay nhất để giảm chỉ số fanout là:

  • Đặt trường hợp miễn trừ chỉ mục ở cấp bộ sưu tập. Mặc định dễ dàng là tắt tính năng Giảm dần và Lập chỉ mục mảng. Việc xoá những giá trị được lập chỉ mục không dùng đến cũng sẽ giúp giảm chi phí lưu trữ.

  • Giảm số lượng chứng từ trong một giao dịch. Để viết một số lớn hãy cân nhắc sử dụng một trình ghi hàng loạt thay vì một loạt tài liệu nhà văn.

Trường hợp miễn trừ chỉ mục

Đối với hầu hết ứng dụng, bạn có thể dựa vào tính năng tự động lập chỉ mục cũng như đưa ra bất kỳ thông báo lỗi nào để quản lý chỉ mục của mình. Tuy nhiên, bạn nên thêm trường hợp miễn trừ một trường trong các trường hợp sau:

Cách Mô tả
Trường chuỗi lớn

Nếu bạn có một trường chuỗi thường chứa các giá trị chuỗi dài 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 loại trừ trường này khỏi quá trình lập chỉ mục.
Tốc độ ghi cao vào bộ sưu tập chứa 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 tập hợp, chẳng hạn như dấu thời gian, sau đó là tốc độ ghi tối đa vào là 500 lượt ghi/giây. Nếu không truy vấn dựa trên trường có giá trị tuần tự, thì bạn có thể miễn trừ trường này khỏi lập chỉ mục để bỏ qua giới hạn này.

Trong một trường hợp sử dụng IoT có tốc độ ghi cao, chẳng hạn như một tập hợp chứa tài liệu có trường dấu thời gian có thể đạt tới giới hạn 500 lần ghi/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 phải là dấu thời gian. 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. Phương pháp hay nhất là thêm miễn trừ một trường cho các trường TTL.

Các trường lớn liên quan đến bản đồ hoặc mảng

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 trên mỗi tài liệu. Nếu không truy vấn dựa trên một mảng lớn hoặc trường ánh xạ, bạn không nên lập chỉ mục mảng hoặc trường đó.

Thao tác đọc và ghi

  • Tốc độ 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 phụ thuộc nhiều vào khối lượng công việc. Để biết thêm thông tin, hãy xem phần Cập nhật cho một tài liệu.

  • 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ộ sẽ giảm thiểu tác động đến độ trễ. Ví dụ: hãy xem xét một ứng dụng cần kết quả của quá trình tra cứu tài liệu và kết quả của một truy vấn trước hiển thị một phản hồi. Nếu nội dung tra cứu và truy vấn không có phần phụ thuộc dữ liệu, không cần phải đợi cho đến khi quá trình tra cứu hoàn tất trước khởi tạo truy vấn.

  • Không sử dụng giá trị bù trừ. Thay vào đó, hãy sử dụng con trỏ. Chỉ tránh sử dụng giá trị bù trừ trả lại các tài liệu đã bỏ qua cho đơn đăng ký 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 có ảnh hưởng đến độ trễ của và ứng dụng của bạn sẽ được lập hoá đơn cho các thao tác đọc cần thiết để để truy xuất chúng.

Thử lại giao dịch

SDK và ứng dụng của Cloud Firestore thư viện tự động thử lại không thành công giao dịch để 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 REST hoặc API RPC trực tiếp thay vì thông qua SDK, ứng dụng nên thực hiện 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 Tìm hiểu về các truy vấn theo thời gian thực trên quy mô lớn.

Thiết kế để điều chỉnh quy mô

Các phương pháp hay nhất sau đây mô tả cách tránh những tình huống gây tranh cãi.

Cập nhật một tài liệu

Khi bạn thiết kế ứng dụng, hãy cân nhắc tốc độ mà ứng dụng cập nhật từng tài liệu. 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 tải kiểm thử. Tốc độ 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 phụ thuộc nhiều vào khối lượng công việc. Các yếu tố bao gồm tốc độ 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 quan, và Cloud Firestore áp dụng đồng bộ thao tác ghi trên một số lượng lớn bản sao. Với tốc độ ghi đủ cao, cơ sở dữ liệu sẽ bắt đầu gặp phải 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 trường hợp tỷ lệ đọc hoặc viết cao để đóng tài liệu về mặt từ ngữ hoặc ứng dụng của bạn sẽ gặp lỗi tranh chấp. Vấn đề này được gọi là điểm phát sóng và ứng dụng của bạn có thể gặp phải tình trạng phát sóng nếu ứng dụng đó thực hiện bất kỳ như sau:

  • 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 dần đơn điệu.

    Cloud Firestore phân bổ mã tài liệu bằng thuật toán tán xạ. Bạn sẽ không gặp phải điểm tương tác khi ghi nếu bạn tạo tài liệu mới bằng ID 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, ở tỷ lệ rất cao.

  • Xoá tài liệu trong một bộ sưu tập với tần suất 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 phần 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 trên một số lượng lớn các mục nhập chỉ mục nếu kết quả truy vấn ban đầu gần đây đã bị xoá.

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á: một lệnh cố gắng tìm các mục công việc cũ nhất trong hàng đợi. Cụm từ tìm kiếm 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 qua các mục nhập chỉ mục để Trường created trên mọi tài liệu đã xoá gần đây. Điều này làm chậm tố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 ra giá trị phù hợp 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 trường tăng đơn điệu. Đây là trường hợp chống mẫu cho tốc độ ghi cao.

Tăng lưu lượng truy cập

Bạn nên tăng dần lưu lượng truy cập vào các bộ sưu tập mới hoặc từ điển học đóng tài liệu để Cloud Firestore có đủ thời gian chuẩn bị giúp tăng lưu lượng truy cập. Bạn nên bắt đầu với tối đa 500 hoạt động mỗi giây vào một tập hợp mới và sau đó tăng lưu lượng truy cập lên 50% mỗi 5 phút. Tương tự, bạn cũng có thể tăng lưu lượng truy cập ghi, nhưng xin lưu ý rằng Giới hạn thông thường của Cloud Firestore. Đảm bảo các toán tử được phân bổ tương đối đồng đều trong toàn bộ phạm vi khoá. Chiến dịch này được gọi là "500/50/5" .

Di chuyển lưu lượng truy cập sang một tập hợp mới

Tăng giảm 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ý việc di chuyển này là đọc từ tập hợp báo cáo cũ và nếu tài liệu không tồn tại thì hãy đọc từ bộ sưu tập. Tuy nhiên, điều này có thể khiến lưu lượng truy cập tăng đột ngột tới đóng tài liệu về từ điển trong bộ sưu tập mới. Cloud Firestore có thể không chuẩn bị hiệu quả tập hợp mới cho lưu lượng truy cập tăng, đặc biệt khi chứa ít tài liệu.

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 tập hợp mới phụ thuộc vào dữ liệu của bạn model. Dưới đây là một chiến lược mẫu, còn 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à yếu tố quan trọng cần cân nhắc là tác động về chi phí của các hoạt động song song trong thời gian quá trình di chuyển.

Đọc song song

Để triển khai các lượt đọc song song khi bạn di chuyển lưu lượng truy cập sang một tập hợp mới, hãy đọc từ bộ sưu tập cũ trước tiên. Nếu tài liệu bị thiếu, hãy đọc từ bộ sưu tập mới. Tỷ lệ đọc tài liệu không tồn tại ở mức cao có thể dẫn đến đang tương tác, nên hãy nhớ tăng dần tải lên bộ sưu tập. Chiến lược hay hơn là sao chép tài liệu cũ vào bộ sưu tập mới sau đó xoá tài liệu cũ. Tăng dần số lượng đọc song song để đảm bảo rằng Cloud Firestore có thể xử lý lưu lượng truy cập vào tập hợp mới.

Một chiến lược khả thi để dần tăng số lượt đọc hoặc ghi vào bộ sưu tập mới sử dụng hàm băm xác định của mã nhận dạng người dùng để chọn tỷ lệ phần trăm ngẫu nhiên người dùng cố gắng viết tài liệu mới. Đảm bảo rằng kết quả người dùng Hàm băm của mã nhận dạng không bị sai lệch do hàm của bạn hoặc hành vi của người dùng.

Trong khi đó, hãy chạy một tác vụ 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ũ vào 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 tài liệu tuần tự Mã nhận dạng để ngăn chặn điểm phát sóng. Khi tác vụ hàng loạt kết thúc, bạn chỉ có thể đọc khỏi bộ sưu tập mới.

Việc tinh chỉnh chiến lược này nhằm di chuyển một nhóm nhỏ người dùng cùng một lúc. 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 loạt người dùng cần 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 một công việc hàng loạt để di chuyển tài liệu cho hàng loạt người dùng đó và sử dụng lượt đọc song song cho người dùng trong giữa quá trình di chuyển.

Lưu ý rằng bạn không thể dễ dàng khôi phục trừ phi bạn ghi đồng thời cả hai báo cáo cũ và các thực thể mới trong giai đoạn di chuyển. Điều này sẽ làm tăng Chi phí phát sinh trên Cloud Firestore.

Quyền riêng tư

  • Tránh lưu trữ thông tin nhạy cảm trong mã dự án trên đám mây. Mã dự án trên đám mây có thể được giữ lại sau thời gian hoạt động của dự án.
  • Để tuân thủ quy định về dữ liệu, bạn không nên lưu trữ những thông tin nhạy cảm trong tên tài liệu và tên trường trong tài liệu.

Ngăn chặn truy cập trái phép

Ngăn chặn các hoạt động trái phép trên cơ sở dữ liệu của bạn bằng Các quy tắc bảo mật của Cloud Firestore. Ví dụ: việc sử dụng các quy tắc có thể tránh được trường hợp người dùng độc hại tải xuống lặp đi lặp lại toàn bộ cơ sở dữ liệu của bạn.

Tìm hiểu thêm về cách sử dụng Quy tắc bảo mật của Cloud Firestore.