我有一个应用程序，每个Collection包含数百万个文档。我的应用程序是使用AndroidJava与Fi恢复数据库创建的。问题是Fi恢复的批量写入最多只能更新500个文档。如果我需要更新超过500个文档怎么办？我不能仅仅为了解决我的问题而创建多个批量写入，因为我使用的是带有Java的Android，Java中没有Promise或AsyncTask之类的东西。因此，创建多个批处理写入不会返回Promise。所以我无法保证我的数据与批处理写入的一致性。
我读到Firebase实时数据库的多路径更新，它确实可以解决我的问题，因为它没有文档限制。但是实时数据库的问题是它不支持对多个where子句的查询，例如FiRecovery数据库中的子句。
在我想要支持多个where子句并更新多达数百万个数据的情况下，我应该使用哪个数据库？
请帮助我，因为我现在很困惑，如果我的Firebase问题无法解决，我计划迁移到SQL。
我不能创建多个批处理写入只是为了解决我的问题，因为我使用Android与Java和没有这样的东西作为promise或AsyncTask在Java。
Java中没有Promise的概念。但是，AsyncTask是存在的，但是正如您所见，即使从30级开始，它也API弃用。
因此，创建多个批处理写入不会返回Promise。
它不能返回Promise，它将返回一个Task。当您调用WriteBatch#提交（）时，返回的对象类型是Task
如果您不想使用这种非常简单的方法，那么您应该考虑使用RxJava库。
如果你想提高你在Android开发方面的技能，我强烈建议你学习静态编程语言。所以当谈到静态编程语言时，我认为最好的特性之一是静态编程语言Coroutines。
对于简单的Fi恢复读取，我建议您阅读以下资源：
当涉及到更新数百万个文档时，在你的Android应用程序的代码中这样做听起来并不是一个好的解决方案。在我看来，你最好的选择是使用Firebase的云函数。因此，你将能够使用多个来创建一个查询，其中EqualTo（）调用，一切都将在服务器上执行。
您仍然可以创建多个批次并单独运行每个批次。Promise. all（）本质上同时运行所有这些Promise，但每个批次最终都会返回一个单独的Promise。如果您不想在应用程序端处理此问题，那么您可以使用Cloud Functions并在服务器端运行它，以防出现任何错误，您可以根据需要恢复添加的任何文档。
我读到了Firebase实时数据库的多路径更新，它确实可以解决我的问题，因为它没有记录的限制
限制记录在留档中。对于REST API，每个写操作中的总数据应小于256MB，对于SDK，应小于16MB
在我想要支持多个where子句并更新多达数百万个数据的情况下，我应该使用哪个数据库？
这完全取决于您需要什么查询。读操作比写操作更频繁吗？Fi恢复可能是一个更好的选择，因为它可以支持具有多个约束的查询，就像您的问题一样。
