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

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 ứng dụng sử dụng Cloud Firestore.

Vị trí cơ sở dữ liệu

Khi bạn tạo phiên bản cơ sở dữ liệu, hãy chọn vị trí cơ sở dữ liệu gần người dùng nhất và tính toán tài nguyên. Các bước nhảy mạng sâu rộng dễ xảy ra lỗi hơn và tăng độ trễ truy vấn.

Để tối đa hóa tính khả dụng và độ bền của ứng dụng, hãy chọn một vị trí đa vùng và đặt các tài nguyên điện toán quan trọng ở ít nhất hai vùng.

Chọn vị trí trong khu vực để có chi phí thấp hơn, độ trễ ghi thấp hơn 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 .

ID tài liệu

  • Tránh các ID tài liệu ... .
  • Tránh sử dụng dấu gạch chéo / chuyển tiếp trong ID tài liệu.
  • Không sử dụng ID tài liệu tăng dần một cách đơn điệu như:

    • Customer1 , Customer2 , Customer3 , ...
    • Product 1 , Product 2 , Product 3 , ...

    ID 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ì chúng yêu cầu thoát thêm:

    • . Giai đoạn
    • [ dấu ngoặc trái
    • ] dấu ngoặc phải
    • * dấu hoa thị
    • ` đánh dấu ngược

Chỉ mục

Giảm độ trễ ghi

Yếu tố chính gây ra độ trễ ghi là phân bổ chỉ mục. Các phương pháp hay nhất để giảm lượng fanout chỉ mục là:

  • Đặt miễn trừ chỉ mục cấp bộ sưu tập . Một mặc định dễ dàng là tắt tính năng lập chỉ mục Giảm dần & Mảng. Việc loại bỏ các giá trị được lập chỉ mục không sử dụng 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. Để viết một số lượng lớn tài liệu, hãy cân nhắc sử dụng máy ghi số lượng lớn thay vì máy ghi hàng loạt nguyên tử.

Miễn trừ chỉ số

Đố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 liên kết thông báo lỗi để quản lý chỉ mục của mình. Tuy nhiên, bạn có thể muốn thêm miễn trừ một trường trong các trường hợp sau:

Trường hợp Sự miêu 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 mà bạn không sử dụng để truy vấn, bạn có thể cắt giảm chi phí lưu trữ bằng cách miễn lập chỉ mục cho trường đó.

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

Ví dụ: trong trường hợp sử dụng IoT có tốc độ ghi cao, 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. 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ốc độ lưu lượng truy cập cao hơn. Cách tốt nhất là thêm các miễn trừ một trường cho các trường TTL của bạn.

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

Hoạt động đọ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 các cuộc gọi không đồng bộ nếu có thay vì các cuộc gọi đồng bộ. Cuộc gọi không đồng bộ giảm thiểu tác động về độ trễ. Ví dụ: hãy xem xét một ứng dụng cần kết quả tra cứu tài liệu và kết quả của truy vấn trước khi đưa ra phản hồi. Nếu việc 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 quá trình tra cứu hoàn tất trước khi bắt đầu truy vấn.

  • Không sử dụng offset. Thay vào đó, hãy sử dụng con trỏ . Việc sử dụng phần bù chỉ tránh việc trả lại các tài liệu bị bỏ qua cho ứng dụng của bạn nhưng những tài liệu này vẫn được truy xuất nội bộ. Các tài liệu bị bỏ qua sẽ ả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 chúng.

Thử lại giao dịch

SDK Cloud Firestore và thư viện máy khách 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 trực tiếp vào Cloud Firestore thông qua API REST hoặc RPC thay vì thông qua SDK, thì ứng dụng của bạn nên triển khai thử lại giao dịch để tăng độ tin cậy.

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 cập nhật theo thời gian thực, hãy xem Tìm hiểu các truy vấn thời gian thực trên quy mô lớn .

Thiết kế theo quy mô

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 đề tranh chấp.

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

Khi bạn thiết kế ứng dụng của mình, hãy xem xét ứng dụng của bạn cập nhật từng tài liệu nhanh như thế nào. Cách tốt nhất để mô tả hiệu suất khối lượng công việc của bạn là thực hiện kiểm tra tải. 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, sự 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 liên quan, đồng thời Cloud Firestore áp dụng đồng bộ thao tác ghi trên một số lượng bản sao. Ở tốc độ ghi đủ cao, cơ sở dữ liệu sẽ bắt đầu gặp phải xung đột, độ trễ cao hơn hoặc các lỗi khác.

Tỷ lệ đọc, ghi và xóa cao đối với phạm vi tài liệu hẹp

Tránh tốc độ đọc hoặc ghi cao đối với các tài liệu đóng theo từ điển, nếu không ứng dụng của bạn sẽ gặp phải lỗi tranh chấp. Sự cố 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 sự cố phát sóng nếu thực hiện bất kỳ điều nào sau đây:

  • Tạo tài liệu mới với tốc độ rất cao và phân bổ ID tăng dần đều đặn của chính nó.

    Cloud Firestore phân bổ ID tài liệu bằng thuật toán phân tán. Bạn sẽ không gặp phải tình trạng điểm nóng 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 bộ sưu tập có ít tài liệu.

  • Tạo tài liệu mới với trường tăng dần đều, như dấu thời gian, ở tốc độ rất cao.

  • Xóa tài liệu trong bộ sưu tập ở 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 đã xóa

Tránh các truy vấn bỏ qua dữ liệu đã xóa gần đây. Một truy vấn có thể phải bỏ qua một số lượng lớn các mục chỉ mục nếu các kết quả truy vấn ban đầu gần đây đã bị xóa.

Một ví dụ về khối lượng công việc có thể phải bỏ qua nhiều dữ liệu đã xóa là khối lượng công việc cố gắng tìm các mục công việc cũ nhất được xếp hàng đợi. Truy vấn có thể trông giống như:

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 lần truy vấn này chạy, nó sẽ quét qua các mục nhập chỉ mục cho trường created trên bất kỳ tài liệu nào đã bị xóa 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 nơi 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 trường tăng đơn điệu, chống mẫu cho tốc độ ghi cao.

Tăng cường giao thông

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 đóng tài liệu theo từ điển để 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. Chúng tôi khuyên bạn nên bắt đầu với tối đa 500 thao tác mỗi giây cho bộ sưu tập mới và sau đó tăng lưu lượng truy cập lên 50% sau mỗi 5 phút. Tương tự, bạn có thể tăng lưu lượng ghi của mình, nhưng hãy nhớ Giới hạn tiêu chuẩn của Cloud Firestore . Hãy đảm bảo rằng các thao tác được phân bổ tương đối đồng đều trên toàn bộ phạm vi phím. Đây được gọi là quy tắc "500/50/5".

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

Việc tăng dần dần đặc biệt quan trọng nếu bạn di chuyển lưu lượng truy cập ứng dụng từ bộ sưu tập này sang 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ừ 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 đóng các tài liệu trong bộ sưu tập mới về mặt từ điển tăng đột ngột. Cloud Firestore có thể không chuẩn bị hiệu quả bộ sưu tập mới để tăng lưu lượng truy cập, đặc biệt khi nó chứa ít tài liệu.

Sự cố tương tự có thể xảy ra nếu bạn thay đổi ID 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 bộ sưu tập mới tùy thuộc vào mô hình dữ liệu của bạn. Dưới đây là một chiến lược ví dụ đượ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 mình hay không và điều quan trọng cần cân nhắc là tác động chi phí của các hoạt động song song trong quá trình di chuyển.

Đọc song song

Để triển khai tính năng đọc song song khi bạn di chuyển lưu lượng truy cập sang bộ sưu tập mới, trước tiên hãy đọc từ bộ sưu tập cũ. Nếu tài liệu bị thiếu, hãy đọc từ bộ sưu tập mới. Tỷ lệ đọc các tài liệu không tồn tại cao có thể dẫn đến điểm nóng, vì vậy hãy đảm bảo tăng dần tải cho bộ sưu tập mới. 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 rồi xóa tài liệu cũ. Tăng cường đọc song song dần dần để đảm bảo rằng Cloud Firestore có thể xử lý lưu lượng truy cập vào bộ sưu tập mới.

Một chiến lược khả thi để tăng dần khả năng đọc hoặc ghi vào bộ sưu tập mới là sử dụng hàm băm xác định của ID người dùng để chọn một tỷ lệ phần trăm ngẫu nhiên người dùng đang cố gắng viết tài liệu mới. Hãy đảm bảo rằng kết quả băm ID người dùng không bị sai lệch bởi chức năng của bạn hoặc bởi 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ừ 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 ID 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 kết thúc, bạn chỉ có thể đọc từ bộ sưu tập mới.

Một cải tiến của chiến lược này là di chuyển từng nhóm nhỏ người dùng cùng một lúc. Thêm 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 nhóm người dùng để di chuyển dựa trên hàm băm của ID người dùng. Sử dụng tác vụ hàng loạt để di chuyển tài liệu cho nhóm người dùng đó và sử dụng chức năng đọc song song cho người dùng ở 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ừ khi bạn ghi kép cả thực thể cũ và 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 của Cloud Firestore.

Sự riêng tư

  • Tránh lưu trữ thông tin nhạy cảm trong ID dự án đám mây. ID dự án trên đám mây có thể được giữ lại trong suốt thời gian dự án của bạn.
  • Theo phương pháp hay nhất về tuân thủ dữ liệu, chúng tôi khuyên 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 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 với Quy tắc bảo mật Cloud Firestore. Ví dụ: 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 Quy tắc bảo mật của Cloud Firestore .