Anti-patterns
The data models that work badly in TeselaDB and what to do instead.
Some data models work badly in any document database. Others only fail in a database that spreads data by ranges, such as TeselaDB. This list says which ones and what to do instead.
How it works
Each case says what goes wrong and what to do instead. The first ones apply to any document database, because they are about the size of documents and the cost of indexes, and the last one belongs to a database that spreads each collection in ranges across the nodes.
Unbounded arrays
An array that grows with every event ends up in a huge document. Store each event as a document.
Very many collections
One collection per customer multiplies indexes and ranges. Use one collection with a customer field, or tenants.
Unused indexes
Every index is written on every insert. Look at $indexStats and drop the ones nobody uses.
Bloated documents
Fetching fields the query does not need costs network and memory. Use projections.
$lookup on every read
If you always join two collections to read, every query pays for the join even when the data hardly ever changes separately, so embed in one document what you read together.
A key that always grows in a collection with many writes
It concentrates the load on one range. Read Keys and hotspots.
What it means for your application
Check your model against these cases before taking it to production. Start with the queries that touch the most ranges or read
more documents than they return, which are the ones explain and the profiler point out to you.
Limits
No anti-pattern breaks the application at first. The problems show up when the data and the traffic grow, and by then changing the model means rewriting documents that are already in production.