4 ms·
This is exactly what I'm looking for. One small database per entity, with the option of distributed transactions across the databases. It sounds wonderful. How
by continuational 11y ago
This is exactly what I'm looking for. One small database per entity, with the option of distributed transactions across the databases. It sounds wonderful. How mature is it?
- biokoda 11y agoWe eat our own dog food and use ActorDB for everything we do. Things that are critical for the company. Multiple products are using it without issue.
- continuational 11y agoThank you. What do you do about secondary indexes? Say, if you want to search for users by name? To elaborate: I imagine sharding my data per user, so that I have one actor per user. But I still want a search bar on my page where I can type in a name and find the user in question. A multi-actor query would probably be too inefficient in this case. Did you have a similar problem, and if so, how did you solve it?
- biokoda 11y agoActorDB can have multiple actor types, each with a completely different schema. I would create a new actor type for this purpose and have a single actor in it. This would just contain the names of users. It would be easy to query and manage. Another option is to create a new KV type and have the names there. This is much more scalable bit a bit more difficult to query. Needed if you really need many thousands of queries per second. On the other hand if your scale is such that search by name is a big load, it is probably better to complement the DB with elasticsearch and move text search to it. This is how the big boys do it.
- continuational 11y agoThat makes sense. Thank you for the explanation.