Firestore：如何保持在Firebase的新数据库免费套餐的限制内

I recently started a personal project where I wanted to use a database in the cloud. There are quite a few to choose from. My main criteria was that it be something low or no cost.

我最近开始了一个个人项目 ，想在云中使用数据库。 有很多可供选择。 我的主要标准是成本低或无成本。

Eventually I decided on Firestore, using the Spark Plan. This plan gives me 5Gb of storage, with 50K reads and 20K writes per day for free, which at the time seemed like plenty. I soon learned that a little carelessness can blow past those transaction limits pretty fast.

最终，我决定使用Spark计划选择 Firestore 。 这个计划为我提供了5Gb的存储空间，每天免费提供5万次读取和2万次写入操作，这在当时看来是足够的。 我很快了解到，一些粗心大意会很快超过交易限额。

Firestore is a NoSQL document store database. Each NoSQL database is different and my a learning curve was steeper than expected. As you know, the best teacher is adversity, and I made my share of mistakes early on. One too many, though, and I’d hit the read or write limit of the plan, which sometimes could happen within an hour or two. Then it was time to call it a day.

Firestore是NoSQL文档存储数据库。 每个NoSQL数据库都是不同的，而且我的学习曲线比预期的还要陡峭。 如您所知，最好的老师是逆境，我很早就犯了很多错误。 但是，太多了，我达到了计划的读写限制，有时可能在一两个小时之内发生。 然后是时候打电话给它了。

Things are better now, so I offer these lessons learned:

现在情况变好了，所以我提供了这些经验教训：

*做*从免费计划开始 (*Do* start with the free plan)

Yes, it is easy to overshoot the plan’s limits, but those occurrences will force you to learn to be efficient with your reads and writes. You will become more cost-conscious of sequencing multiple database operations in an efficient way.

是的，很容易超出计划的限制，但是这些情况会迫使您学习读写效率。 您将更加有效率地意识到以有效的方式对多个数据库操作进行排序的方式。

从一个小的数据集开始 (Start with a small dataset)

This may seem obvious, but by small I mean less than 100 documents total. On my project, I first created a collection with 10K documents. I later realized that I made a mistake in the data I loaded, fixed that, found another, went to fix that, but… TRANSACTION_RESOURCE_LIMIT_EXCEEDED. Welp, done for the day.

这似乎是显而易见的，但小我的意思是低于100个文件总数。 在我的项目中，我首先创建了一个包含1万个文档的集合。 后来，我意识到我在加载的数据中犯了一个错误，修复了该错误，找到了另一个错误，然后去修复它，但是……TRANSACTION_RESOURCE_LIMIT_EXCEEDED。 哭了，做了一天。

花时间设计数据模型 (Take time in the design of your data model)

Like the carpenter’s axiom: “Measure twice, cut once”, you don’t want to be adjusting your JSON document fields and structure piecemeal. Oh, you will of course, but you’ll save yourself some transactions by practicing a little foresight. Write out a schematic of documents, their fields, and their relationships first. Visualization is the key to happiness.

就像木匠的公理：“两次测量，一次剪切”一样，您不想调整JSON文档字段和零散的结构。 哦，您当然会的，但是通过稍加预见，您可以节省一些交易。 首先写出文档，它们的字段和它们之间的关系的示意图。 可视化是幸福的关键。

测试并验证您的数据加载脚本 (Test and verify your data loading scripts)

You’ll need scripts to populate the database from some other source. That is the time to:

您将需要脚本来从其他来源填充​​数据库。 到时候了：

• verify what you loaded is what you expected
  验证您加载的是您期望的
• correctly handle the no-data case for fields
  正确处理字段的无数据情况

I made mistakes in both cases. First, when I loaded some string data into a document field, I hadn’t immediately noticed that those strings had quotes already, so the stored strings had embedded quotes. It didn’t seem that serious an issue, but it became a pain later when writing and testing searches on that field. Because there were a lot of documents, I spent a sizable portion of my daily write quota to clean that up.

在这两种情况下我都犯了错误。 首先，当我将一些字符串数据加载到文档字段中时，我没有立即注意到这些字符串已经带有引号，因此存储的字符串具有嵌入式引号。 似乎没有那么严重的问题，但是后来在该领域编写和测试搜索时变得很痛苦。 因为有很多文档，所以我花了每天写配额中的很大一部分来清理它。

In the second case, I discovered that Firestore has no mechanism for determining the existence of a property in a document (there is no undefined check). There is an exists test for documents, but not for document fields. The best practice is to populate missing data fields with null, and then do null equivalence tests in a where clause to find documents with “missing” properties.

在第二种情况下，我发现Firestore没有确定文档中属性存在的机制(没有未定义的检查)。 有一个存在的文档测试 ，但不适用于文档字段。 最佳实践是使用null填充缺少的数据字段，然后在where子句中进行null等效测试以查找具有“ missing”属性的文档。

小型数据集不会教您什么 (What a small dataset won’t teach you)

Once you worked out kinks on the small dataset, it is time to graduate to a larger one. With more documents to process, things like query efficiency, pagination and batch requests become important.

一旦确定了小型数据集的纽结，就可以逐步升级到较大的数据集了。 随着更多文档的处理，诸如查询效率，分页和批处理请求之类的事情变得很重要。

读取大块，写入大块 (Read in chunks, write in chunks)

Batch operations allow for multiple read/writes on the database in a single transaction. This means that if any write operation fails, then all writes fail, and the database data retains its original state. Each operation in a batch counts toward the total read/write quotas, so as such it doesn’t help usage quotas. Also, when writing via batch operations, be aware there’s a 500 operation limit per batch.

批处理操作允许在单个事务中对数据库进行多次读/写。 这意味着，如果任何写操作失败，则所有写操作都会失败，并且数据库数据将保留其原始状态。 批处理中的每个操作都计入总的读/写配额，因此这样对使用配额没有帮助。 另外，通过批处理操作进行写入时，请注意每个批处理有500个操作限制。

Be careful when correlating two documents (i.e., for every A document, there is an association by reference to a B document). Don’t fetch all of one first, then iterate through the other. That’s a good way to chew up the transaction quota when debugging.

在关联两个文档时要小心(即，对于每个A文档，通过引用B文档都存在关联)。 不要先获取所有内容，然后再遍历另一个。 这是调试时减少事务配额的好方法。

It is better to fetch a subset of the first collection, then iterate through it document by document. Associate these documents with document in the second collection by fetching one that matches criteria. Continue to do this until the entire first collection has been fetched. When debugging, you can verify everything looks like it is working correctly and, if not, kill the process before a lot of transactions are run.

最好先获取第一个集合的一个子集，然后逐个文档对其进行遍历。 通过获取一个符合标准的关联这些文件与第二集合中的文件。 继续执行此操作，直到获取完第一个集合为止。 调试时，您可以验证一切看起来是否正常，如果没有，请在运行大量事务之前终止该进程。

如何限制查询结果 (How to limit query results)

Firestore’s query language isn’t as richly expressive as SQL is, but there are still a number of ways to restrict your queries so that you don’t overfetch data. Although technically there is no size limit for a POST response body, in practical terms there is.

Firestore的查询语言不像SQL那样富有表现力，但是仍然有很多方法可以限制查询，以免数据超量获取。 尽管从技术上讲，POST响应正文没有大小限制，但实际上是有限制的。

Some mechanisms for limiting query results:

限制查询结果的一些机制：

where and compound where

在哪里和在哪里

You can chain multiple where clauses together, similar to adding conditional expressions to a single where clause in SQL.

您可以将多个where子句链接在一起，类似于将条件表达式添加到SQL中的单个where子句中。

citiesRef.where('state', '==', 'CO').where('name', '==', 'Denver');

limit and ranges

极限和范围

You can limit the number of documents returned by a query by using chaining a limit clause at the end of the query object.

您可以通过在查询对象的末尾使用链接limit子句来限制查询返回的文档数。

let biggest = citiesRef.where('population', '>', 2500000)  .orderBy('population').limit(2);

You can also specify a range of records to retrieve via startAt/endAt or startBefore/endBefore constraints, which allows you to do cursor-based pagination.

您还可以通过startAt / endAt或startBefore / endBefore约束指定要检索的记录范围，这允许您执行基于游标的分页。

let docRef = db.collection('cities').doc('SF');

return docRef.get().then(snapshot => {  let startAtSnapshot = db.collection('cities')    .orderBy('population')    .startAt(snapshot);  return startAtSnapshot.limit(10).get();});

in array query

在数组查询

You can look for specific matches in an array. This is good for enumerated values.

您可以在数组中查找特定的匹配项。 这对于枚举值很有用。

const usaOrJapan = citiesRef.where('country', 'in', ['USA', 'Japan']);

As demonstrated, it is possible to work within the limitations of the Spark Plan as you learn about Firestore. It’s free, which is always a good place to start.

如所演示的，当您了解Firestore时，可以在Spark计划的限制内工作。 它是免费的，始终是一个不错的起点。

翻译自: https://www.freecodecamp.org/news/firestoreliving/