Closed kulshekhar closed 8 years ago
ActorDB was designed so that it is as much hands off as possible. We use it as a part of our products and our clients expect things to just work. They often do not have any specialized database administrators and often have very little tech knowledge because they are not a tech company. The more complex or hard to manage something is, the less appealing our products are.
We are a small team ourselves.
Thanks the super quick response!
Regarding the second point - I imagine that the solution to servers getting overloaded or disks filling up could be to (a) expand vertically and/or (b) add more node(s). Is that correct?
Yes. Keep in mind as with every other distributed database, the point at which you decide to start adding nodes should never be once you hit max capacity. Resharding requires resources to complete.
Thank you for answering my questions. This issue can now be closed.
As I mentioned, I'll be testing ActorDB out and in the process, I'll likely be documenting some stuff for referring to later. If there's any particular kind of documentation that could be useful here, let me know. If there's an overlap, I'll try to create the docs in a way that could be used on this repo (or on your site)
Well it is good to get an outsiders point of view on what docs are missing and could be improved. So any input is very welcome.
I came across ActorDB and it seems like a very useful alternative to the existing options. I'm planning on playing a bit with it and testing it out.
I've gone through the documentation and one thing that's not clear is what kind of effort will be required to manage and administer an installation of ActorDB that has, let's say, 5 clusters with 5 nodes each.
It would be great if these questions could be answered from the perspective of a very small team (< 5) of developers.