biokoda

24 ms·

211.
by biokoda 13y ago
When you are running in production and something is not right, you can attach to the console and see what is going on. This is of course not something that you should do often, but can be a real life saver. Simulating something that is desi
212.
by biokoda 13y ago
Only JOINs across actors are sacrificed. Most problem sets fit quite well into the actor model and you can keep JOINs where it matters most (inside an actor).
213.
by biokoda 13y ago
It very much depends on your use case. But no you do not split by tables or rows generally. You split your problem into actor types. For instance if you were to create your own news.ycombinator.com you would require 3 types of actors: front
214.
by biokoda 13y ago
Yes but then you're stuck with a KV data and query model. It still being an SQL database is kind of besides the point since you're not using it as a relational database.
215.
by biokoda 13y ago
a) ActorDB is not actually all that complex. b) ad-hoc queries tend to be the first thing out the window once you hit a certain size (query load or dataset size). ActorDB arguably gives you the largest amount of query flexibility out of the
216.
by biokoda 13y ago
encryption of communication is high on the feature priority list. It is erlang and sqlite. Why sqlite and more on how it works is explained in the documentation. Network should be within the same datacenter.
217.
by biokoda 13y ago
There is one master per actor. An actor lives within a cluster. As long as a majority of configured servers are accessible, writes will succeed. All queries (reads and writes) go through the master and are not committed if master does not r
218.
by biokoda 13y ago
You can run queries across actors (even acid transactions), but not actual joins. This is the tradeoff to make it distributed.
219.
by biokoda 13y ago
You can have JOINs, but within individual actors. So for instance if this entire conversation tree was a single actor, you can have a full relational model to make queries with. But you can't do joins on comments over multiple threads.
220.
by biokoda 13y ago
Because it's a truly distributed SQL database. I presume you mean having a master-master setup? ActorDB does not limit you to the capabilities of a single machine. Master-master still means your dataset and query load needs to fit into
221.
by biokoda 13y ago
Yes that is correct. Not a drop-in replacement. You can't go from a traditional RDBMS and magically turn it into a distributed database. Some constraints need to be loosened. ActorDB tries to loose as little as possible to turn it into
222.
by biokoda 13y ago
Because sqlite is an embeddable isolated database. Each individual actor is completely independent. Sqlite naturally fits into this use case. Using postgres or mariadb would be very problematic or even impossible, because they are not desig
223.
by biokoda 13y ago
Author here. With actordb you get: - no single point of failure (redis and likely the rdbms as well) - no need to maintain two very different systems - scalable. As in plug in a new cluster and it will proportionally increase capacity. We a
224.
ActorDB 0.5 released - a distributed SQL database(github.com)
3 points by biokoda 13y ago|0 comments