Trang này được dịch bởi Cloud Translation API.

Sử dụng Cloud Firestore với Cơ sở dữ liệu theo thời gian thực của Firebase

Bạn có thể sử dụng cả Firebase Realtime Database và Cloud Firestore trong ứng dụng của mình, và tận dụng các lợi ích của từng giải pháp cơ sở dữ liệu để phù hợp với nhu cầu của bạn. Ví dụ: bạn có thể muốn tận dụng sự hỗ trợ của Realtime Database cho việc hiện diện, như đã nêu trong Xây dựng sự hiện diện trong Cloud Firestore.

Tìm hiểu thêm về điểm khác biệt giữa các cơ sở dữ liệu.

Đang di chuyển dữ liệu sang Cloud Firestore

Nếu bạn quyết định di chuyển một số dữ liệu của mình từ Realtime Database sang Cloud Firestore, hãy cân nhắc quy trình sau. Vì mỗi cơ sở dữ liệu đều có các nhu cầu riêng biệt và các cân nhắc về cấu trúc, không có khả năng đường dẫn di chuyển tự động. Thay vào đó, bạn có thể tuân theo tiến trình chung sau:

Ánh xạ cấu trúc dữ liệu và các quy tắc bảo mật từ Realtime Database đến Cloud Firestore. Cả Realtime Database và Cloud Firestore đều dựa vào tính năng Xác thực Firebase, do đó, bạn không cần thay đổi phương thức xác thực người dùng cho ứng dụng. Tuy nhiên, có sự khác biệt giữa các quy tắc bảo mật và mô hình dữ liệu và điều quan trọng là phải cẩn thận tính đến những khác biệt đó trước khi bắt đầu di chuyển dữ liệu sang Đám mây Firestore.
Di chuyển dữ liệu trong quá khứ. Khi thiết lập cấu trúc dữ liệu mới trong Cloud Firestore, bạn có thể liên kết và di chuyển dữ liệu hiện có từ Realtime Database sang Cloud Firestore mới thực thể. Tuy nhiên, nếu đang sử dụng cả hai cơ sở dữ liệu trong ứng dụng của mình, bạn không cần di chuyển dữ liệu trong quá khứ ra khỏi Realtime Database.
Phản chiếu dữ liệu mới lên Firestore theo thời gian thực. Sử dụng Cloud Functions để ghi dữ liệu mới vào Cloud Firestore mới khi được thêm vào Realtime Database.
Đặt Cloud Firestore làm cơ sở dữ liệu chính cho dữ liệu được di chuyển. Sau khi bạn đã di chuyển một số dữ liệu, hãy sử dụng Cloud Firestore làm cơ sở dữ liệu chính và giảm mức sử dụng Realtime Database cho dữ liệu đã di chuyển . Xem xét các phiên bản ứng dụng vẫn gắn liền với Realtime Database đối với dữ liệu đó và cách bạn dự định tiếp tục hỗ trợ loại dữ liệu đó.

Đảm bảo bạn tính đến chi phí thanh toán cho cả Realtime Database và Cloud Firestore.

Lập bản đồ dữ liệu của bạn

Dữ liệu trong Realtime Database có cấu trúc dưới dạng một cây duy nhất, trong khi Cloud Firestore hỗ trợ các hệ phân cấp dữ liệu rõ ràng hơn thông qua các tài liệu, bộ sưu tập và tập hợp con. Nếu bạn chuyển một số dữ liệu từ Realtime Database sang Cloud Firestore, bạn nên cân nhắc một cấu trúc khác cho dữ liệu của bạn.

Những điểm khác biệt chính cần lưu ý

Nếu bạn di chuyển dữ liệu từ cây Realtime Database hiện có sang Cloud Firestore tài liệu và bộ sưu tập, hãy lưu ý những điểm khác biệt chính sau đây giữa những cơ sở dữ liệu có thể ảnh hưởng đến cách bạn sắp xếp dữ liệu trong Cloud Firestore:

Truy vấn nông giúp bạn linh hoạt hơn trong cấu trúc dữ liệu phân cấp.
Truy vấn phức tạp có độ chi tiết cao hơn và giảm bớt nhu cầu trùng lặp .
Con trỏ truy vấn cung cấp tính năng phân trang mạnh mẽ hơn.
Giao dịch không còn đòi hỏi một gốc chung cho tất cả dữ liệu của bạn nữa và thường một cách hiệu quả.
Chi phí thanh toán khác nhau giữa Realtime Database và Cloud Firestore. Trong nhiều trường hợp, Cloud Firestore có thể đắt hơn Realtime Database, đặc biệt nếu bạn phụ thuộc vào nhiều thao tác nhỏ. Cân nhắc giảm số lượng thao tác trên cơ sở dữ liệu và tránh ghi không cần thiết. Tìm hiểu thêm về sự khác biệt trong thanh toán trong khoảng thời gian từ Realtime Database và Cloud Firestore.

Những phương pháp hay nhất trong thực tế

Ví dụ sau đây phản ánh một số yếu tố mà bạn có thể cân nhắc khi sử dụng chuyển dữ liệu giữa các cơ sở dữ liệu. Bạn có thể tận dụng các chỉ số đọc nông và khả năng truy vấn nhiều cấu trúc dữ liệu tự nhiên hơn so với khả năng bạn có thể đã sử dụng cùng với Realtime Database.

Cân nhắc việc cung cấp một ứng dụng hướng dẫn trong thành phố giúp người dùng tìm thấy các địa danh nổi bật trong thành phố trên khắp thế giới. Vì Realtime Database thiếu số lượt đọc nội dung, nên bạn có thể phải cấu trúc dữ liệu trong hai nút cấp cao nhất như sau:

// /cities/$CITY_KEY
{
  name: "New York",
  population: 8000000,
  capital: False
}

// /city-landmark/$CITY_KEY/$LANDMARK_KEY
{
  name: "Empire State Building",
  category: "Architecture"
}

Cloud Firestore có số lượt đọc không đáng kể, vì vậy, việc truy vấn các tài liệu trong một tập hợp sẽ không lấy dữ liệu từ các tập hợp con. Do đó, bạn có thể lưu trữ trong bộ sưu tập con:

// /cities/$CITY_ID
{
  name: "New York",
  population: 8000000,
  capital: False,
  landmarks: [... subcollection ...]
}

Tài liệu có kích thước tối đa là 1MB, đây là một lý do khác để lưu trữ địa danh dưới dạng một bộ sưu tập con, giữ cho từng tài liệu về thành phố ở dạng nhỏ, thay vì tăng kích thước tài liệu với các danh sách lồng nhau.

Khả năng truy vấn nâng cao của Cloud Firestore giảm nhu cầu dữ liệu trùng lặp cho các mẫu truy cập phổ biến. Ví dụ: hãy xem xét một màn hình trong ứng dụng hướng dẫn thành phố hiển thị tất cả các thành phố thủ đô theo dân số. Trong Realtime Database, cách hiệu quả nhất để làm việc này là duy trì một danh sách các thành phố thủ đô sao chép dữ liệu từ danh sách cities như sau:

{
   cities: {
    // ...
   },

   capital-cities: {
     // ...
   }
}

Trong Cloud Firestore, bạn có thể trình bày danh sách các thành phố thủ đô theo dưới dạng một truy vấn đơn:

db.collection('cities')
    .where('capital', '==', true)
    .orderBy('population')

Đọc thêm về mô hình dữ liệu Cloud Firestore và thực hiện hãy xem Giải pháp của chúng tôi để có thêm ý tưởng về cách cấu trúc Cơ sở dữ liệu Cloud Firestore.

Bảo mật dữ liệu của bạn

Bạn có đang sử dụng Cloud Firestore Security Rules cho Ứng dụng web, Apple, Android hoặc Quản lý quyền truy cập danh tính (IAM) cho máy chủ, hãy đảm bảo bạn đang bảo mật dữ liệu của mình trong Cloud Firestore dưới tên Realtime Database. Việc xác thực người dùng được xử lý bằng Xác thực cho cả hai cơ sở dữ liệu, nên bạn không cần thay đổi cách triển khai Xác thực khi bắt đầu đang sử dụng Cloud Firestore.

Những điểm khác biệt chính cần lưu ý

SDK dành cho thiết bị di động và web sử dụng Cloud Firestore Security Rules, trong khi máy chủ SDK sử dụng giải pháp Quản lý quyền truy cập danh tính (IAM) để bảo mật dữ liệu.
Cloud Firestore Security Rules không phân tầng trừ phi bạn dùng ký tự đại diện. Tài liệu và tập hợp không kế thừa các quy tắc.
Bạn không cần xác thực riêng dữ liệu nữa (như bạn đã làm trong Realtime Database).
Cloud Firestore kiểm tra các quy tắc trước khi thực thi truy vấn để đảm bảo người dùng có quyền truy cập phù hợp vào tất cả dữ liệu mà truy vấn trả về.

Di chuyển dữ liệu trong quá khứ sang Cloud Firestore

Sau khi bạn liên kết dữ liệu và cấu trúc bảo mật của mình vớiCloud Firestore dữ liệu và mô hình bảo mật, bạn có thể bắt đầu thêm dữ liệu của mình. Nếu bạn định truy vấn dữ liệu trong quá khứ sau khi chuyển ứng dụng từ Realtime Database vào Cloud Firestore, hãy thêm một tệp xuất dữ liệu cũ vào dữ liệu mới Cơ sở dữ liệu Cloud Firestore. Nếu bạn định sử dụng cả Realtime Database và Cloud Firestore trong ứng dụng của mình, thì bạn có thể bỏ qua bước này.

Để tránh ghi đè dữ liệu mới bằng dữ liệu cũ, bạn có thể muốn thêm dữ liệu trong quá khứ trước tiên. Nếu bạn thêm dữ liệu mới vào cả hai cơ sở dữ liệu cùng lúc, như thảo luận trong bước tiếp theo, hãy đảm bảo bạn ưu tiên dữ liệu mới được thêm vào Cloud Firestore của Cloud Functions.

Để di chuyển dữ liệu trong quá khứ sang Cloud Firestore, hãy làm theo các bước sau:

Xuất dữ liệu từ Realtime Database hoặc sử dụng bản sao lưu gần đây.
1. Chuyển đến Mục Realtime Database trong bảng điều khiển Firebase.
2. Trong thẻ Data (Dữ liệu), hãy chọn nút cấp cơ sở của cơ sở dữ liệu rồi chọn Xuất JSON từ trình đơn.
Tạo cơ sở dữ liệu mới trong Cloud Firestore và thêm dữ liệu của bạn.

Hãy xem xét các chiến lược sau đây khi bạn di chuyển một số dữ liệu sang Cloud Firestore:
- Viết một tập lệnh tuỳ chỉnh để chuyển dữ liệu cho bạn. Mặc dù chúng tôi không thể một mẫu cho tập lệnh này, vì mỗi cơ sở dữ liệu sẽ có những nhu cầu riêng, Các chuyên gia Cloud Firestore trên kênh Slack của chúng tôi hoặc trên Stack Overflow có thể xem lại kịch bản hoặc đưa ra lời khuyên cho tình huống cụ thể của bạn.
- Sử dụng SDK máy chủ (Node.js, Java, Python hoặc Go) để ghi dữ liệu trực tiếp thành Cloud Firestore. Để biết hướng dẫn về cách thiết lập SDK máy chủ, hãy xem Bắt đầu.
- Để đẩy nhanh quá trình di chuyển dữ liệu lớn, hãy sử dụng ghi theo lô và gửi tối đa 500 thao tác trong một yêu cầu mạng.
- Để không vượt quá giới hạn số lượng yêu cầu của Cloud Firestore, giới hạn thao tác ở 500 lượt ghi/giây cho mỗi tập hợp.

Thêm dữ liệu mới vào Cloud Firestore

Để đảm bảo tính đồng nhất giữa các cơ sở dữ liệu, hãy thêm dữ liệu mới vào cả hai cơ sở dữ liệu trong thời gian thực. Dùng Cloud Functions để kích hoạt hoạt động ghi vào Cloud Firestore bất cứ khi nào một ứng dụng ghi vào Realtime Database. Đảm bảo rằng Cloud Firestore sẽ ưu tiên dữ liệu mới đến từ Cloud Functions so với mọi lượt ghi mà bạn đang thực hiện từ quá trình di chuyển dữ liệu trong quá khứ.

Tạo một hàm để ghi dữ liệu mới hoặc dữ liệu thay đổi vào Cloud Firestore mỗi khi ứng dụng ghi dữ liệu vào Realtime Database. Tìm hiểu thêm về Điều kiện kích hoạt Realtime Database cho Cloud Functions.

Đặt Cloud Firestore làm cơ sở dữ liệu chính cho dữ liệu đã di chuyển

Nếu bạn quyết định sử dụng Cloud Firestore làm cơ sở dữ liệu chính cho một số dữ liệu của bạn, hãy nhớ tính đến mọi chức năng phản chiếu dữ liệu mà bạn thiết lập và xác thực Cloud Firestore Security Rules của bạn.

Nếu bạn đã sử dụng Cloud Functions để duy trì sự đồng nhất giữa các cơ sở dữ liệu, đảm bảo bạn không lặp lại thao tác ghi trên cả hai cơ sở dữ liệu trong một vòng lặp. Chuyển đổi hàm của bạn để ghi vào một cơ sở dữ liệu hoặc xoá hoàn toàn và bắt đầu ngừng sử dụng chức năng ghi cho dữ liệu được di chuyển trong các ứng dụng vẫn được liên kết với Realtime Database. Cách bạn xử lý vấn đề này đối với ứng dụng của bạn tuỳ thuộc vào nhu cầu cụ thể và người dùng của bạn.
Xác minh rằng dữ liệu của bạn được bảo mật đúng cách. Xác thực Cloud Firestore Security Rules của bạn hoặc thiết lập IAM.