计费示例

您可以使用这个真实的基本聊天应用示例来衡量 Firestore 使用量和费用。此为估算并不准确，但可以帮助您更好地了解如何对自己的 Firestore 使用量进行计费。

概览：按使用量级别划分费用

为了说明典型的费用案例，我们假设一个示例聊天应用，用户可以在此应用中发起与两位或多位参与者的聊天。用户可以在列表中查看他们的活跃聊天，阅读消息和发送消息。在此示例中，我们使用的是北美多区域（具体来说就是 nam5）的价格。

前提

假设此应用的使用量和数据存储情况如下所示：

• 日活跃用户数 (DAU) 占应用安装总数的 10%。您可以使用日活跃用户数 (DAU) 的粗略估计值来估算您的每日费用。此数值对应的是某一天主动打开并使用应用的用户数，通常只占应用安装总数的一小部分。在下面的计算中，我们估计日活跃用户数为应用安装总数的 10%。
• 文档大小相对较小。如需了解按类型分列的文档大小统计，请参阅下表。
• 数据仅存储三个月。示例聊天应用中消息的存储时间仅为三个月。为了计入删除操作，下面的计算显示每个日写入操作对应一个日删除操作。
• 这些费用估算值反映了示例应用的大部分费用，但并非所有费用。我们通过计算本指南中述及的最常见用户任务的操作、用户和消息存储以及出站流量，考虑了应用的大部分费用。您可能还需要考虑其他费用，具体取决于您的应用结构和数据需求。此示例只为指导您如何计算费用，如需 Firestore 费用的更全面说明，请参阅价格页面。

如需了解按用户任务分列的操作统计，请参阅细分：按用户任务划分的计费使用量部分。

Firestore 计费模式的一项优点就在于，您只需为实际使用量付费。因此，您的费用可能会随着 DAU 数量的变化而上下浮动。

细分：按用户任务划分的计费用量

以示例聊天应用为例，其数据结构如下：

• users/{userId} - 用户记录
• groups/{groupId} - 两位或更多位用户之间的聊天
  • messages/{messageId} - 聊天中的每条消息。

数据存储

为了计算用于存储应用数据的存储费用，请使用以下文档大小假设：

* 此文档大小计算包括消息字段的索引，但假定对消息内容停用索引。

为降低存储费用，该应用存储消息的最长时间也仅为三个月。

如需详细了解如何计算存储费用，请参阅了解存储空间使用量计算。

操作

用户在应用中通常完成以下常见任务：

• 查看聊天列表：用户打开应用主屏幕，并查看按最新发布的消息顺序排序的聊天列表（包括群聊和私聊）。
• 阅读聊天中的消息：用户从主屏幕选择聊天并阅读聊天中的最新消息。
• 向聊天发送消息：用户向聊天（群聊或私聊）发送消息。

该示例应用在 Firestore 中针对上述三个典型用户任务的估计操作总次数如下：

• 读取：(5 * 10) + (30) = 80 次读取 / 用户 / 天
• 写入：(10 * 2) = 20 次写入 / 用户 / 天
• 网络出站流量：(50 * 0.25 KB) + (30 * 0.25 KB) = 20 KB / 用户 / 天
• 存储：(20 * 0.75 KB) = 15 KB / 用户 / 天

按用户任务统计的总使用量

选择每项用户任务以查看应用中的操作、存储和网络费用的完整说明和细分。

db.collection('groups')
  .where('participants', 'array-contains', 'user123')
  .where('lastUpdated', '>', lastFetchTimestamp)
  .orderBy('lastUpdated', 'desc')
  .limit(25)

db.collection('groups')
  .doc('group234')
  .collection('messages')
  .where('sentTime', '>', lastFetchTimestamp)
  .orderBy('sentTime', 'desc')
  .limit(50)

管理员任务的计费使用量

作为应用所有者或管理员，您可能需要基于应用数据生成报告。例如，您可能希望记录用户每天发送的消息数。为此，您可以对 messages 合集组进行 count() 聚合。

使用 count() 等聚合查询时，对于查询所匹配的每批索引条目（不超过 1,000 个），系统都会收取相当于一次文档读取的费用。运行这种每日聚合会增加以下月度费用：