我目前正在使用firestore构建一个应用程序。Google一直宣传firestore具有可扩展性,但我不认为每秒10,000次写入的限制符合这一承诺。如果你在firestore中存储用户喜欢、通知等内容,你很容易超过这个限制。我是否有什么遗漏?这个限制只适用于新文档还是文档更新也适用?提前致谢。
Firestore适用于高度可扩展的读操作。具体而言,它最著名的特点是运行特定查询将需要固定的数量时间,无论您查询的集合中有多少数据。因此,如果您从包含10K个文档的集合中读取10个文档,并花费1秒钟,那么当该集合中有10M或10B个文档时,在相同的客户端条件下进行相同的读取,保证也将花费1秒钟。Cloud Firestore的写吞吐量限制主要由物理限制决定,其中包括10K个文档/秒,但您更可能遇到能够每秒钟向每个文档写入一次的限制。这些限制的原因在于Firestore的其他保证。例如:Firestore保证立即一致性以完成写操作,因此一旦写操作完成,没有客户端将从服务器获取旧数据。为了实现这一点,它必须在确认写入之前更新多个数据中心中的所有数据索引,这仅需要一定的时间,这反过来又导致了它对写吞吐量的限制。同样,还有其他限制源于这些选择。如果您需要更高的写吞吐量并愿意接受不同的性能保证,则可以寻找满足这些需求的其他数据库。
我对GCP的服务不熟悉,但是我在其他云平台上的经验告诉我你可以做以下几件事情: 确保选择正确的数据库。从描述来看,您需要具备自动分区和最终一致性的NoSQL数据库。 文档中提到“标准限制”,这意味着您可以联系技术支持以扩展限制。至少Azure就是这样操作的。 云供应商提供咨询服务,以确保客户成功使用技术。您是否有此类渠道?您是否与首席技术官进行了交流? 如果GCP的服务不能满足您的需求,您可以查看其他数据库引擎,可以在GKE中进行托管。初始设置和操作成本较高,但长期来看会得到回报。例如,我采用了这个想法,在Azure中托管ElasticSearch,这被证明是与可用替代方案相比最佳的决策。 这些提示可能并不完全回答您的问题,但我希望分享我的经验可以帮助找到整体解决方案。