Why is it impossible to run a slow Query on Cloud Firestore ?
It’s not just a boast. It’s true that It’s impossible to run a slow query on Cloud Firestore. But how ?
Quite simple: Index every field, query only indexes
There are a few trade-offs with this strategy. But time has proven that these are all valid and feasible moves. Cloud Firestore can assure you that, querying 10 documents from a collection of 1000 documents will always perform the same with running the same query on a collection of 1 000 000 000 documents.
There are 2 main trade-offs in this. First of them , is the widely accepted trade off “ Sacrificing write speed for Read speed” or “Prioritizing READs over WRITEs”. Indexing every field and every sub-field till hitting 20-level depth means a huge amount of index updates for every WRITE operation . And these are only the default indexes. Beside them , as you design your product , you will be creating Composite Indexes for your custom needs of querying and sorting at many occasions and adding more indexes for enabling Collection Group Query of sorts. So yes , It’s a lot of index updates.
And the second part is sacrificing some functional abilities which can be cumbersome in execution , all of which can be implemented or built with other well-thought functionalities. So what are those functionalities which are omitted ?
Note : I will be listing what’s omitted but I will leave the details about how you can still get things done in another blog
Below is an example document that I will use to help demonstrate what I’m saying.
NOT EQUALS
You cannot query as “age != 45” or “name != Muhammad Li” . Why ? Because such query would not hit an index. Thus , omitted.
CALCULATION
You cannot query on the result of a calculation based on values of fields , like “weight_kg / height_cm > 0.55” . Why ? Because such query would not hit an index. You would need to read a document to do the calculation on the fields. Thus , omitted.
REGEX STRING SEARCH or WILDCARD START Search
You cannot use Regex or WILDCARD Search . Why ? Well , this doesn’t need much explanation. No Index hit. Thus, omitted.
OR OPERATOR
You cannot use the OR operation on multiple queries like “age > 45 OR weight_kg >60” . Why ? Because Cloud Firestore needs to hit ONLY ONE POINT on index and bring the desired amount of documents that are adjacent to that point , moving backwards or forwards. Thus , omitted.
FIELD EXISTS OPERATOR
You cannot query for the documents that miss a field like mongoDB “{‘height_cm’:{‘$exists’:false}}” . Why ? Because if the document does not contain that field, there would be no index pointing to such document. Thus , omitted.
COMBINING 2 INEQUALITY COMPARISONS
You cannot do 2 inequality comparisons at once like “ age > 40 AND height_cm > 180” . Why ? because , even with Composite Indexes , It’s not possible to guarantee an adjacent block of Index Points. Thus , omitted.
I believe I’m done with the incomplete set of what I happen to know and remember of such examples but I would like to hear from you what kind of queries you needed to run on Cloud Firestore to no avail. And what you think about the shrinking of set of functionality ?
I’m hoping to write about the suggested solutions and design approaches around these limitations soon
