|
|
|
|
|
by Meai
2771 days ago
|
|
To me it's several things:
1.
I don't know how stable foundationdb actually is. You say it's tested and very performant but simply starting fdbmonitor on localhost with two processes and then starting fdbcli, it takes 5.6 seconds to get a connection. Typing 'status' takes even longer (before I have a database configured). Why does it take so long for me to get back an error? What could possibly justify that kind of delay? I know I'm saying the word 'should' a lot of times but in my mind it should be practically instant, especially if there is no network trip involved and you know all the servers that I configured.
Secondly, the errors are scary to me. "The coordinator(s) have no record of this database. Either the coordinator
addresses are incorrect, the coordination state on those machines is missing, or
no database has been created."
The error "The database is unavailable" is equally scary. I don't even have a database yet but sometimes I feel like I did create one and then I imagine myself getting that error in production because of some simple or not so simple mistake and I think: What would I even be doing if the coordinator state is missing? That sounds like a critical internal issue to me, is this really something I need to find out and if it is, why does the error not tell me how to check this or repair it? Another thing: Right after I create a database with 'configure new single memory', I get in 'status':
"
Moving data - unknown (initializing)
Sum of key-value sizes - unknown
"
Is this really such an edge case that the database cannot give me meaningful information on what is going on with my data right now? That is very scary to me. It should be able to tell me what is going on with the data, this is the simplest possible moment. I just created a database 5 seconds earlier and I run a status command. Now the database is apparently in an unknown state. What I would like to get is a realtime progress bar of where data is moving and why, with percentage numbers indicating the progress and if there is any error it should actually tell me the location of the log file. The other big question mark is:
I dont know if I can truly configure everything correctly so I actually get the performance that is advertised, there seem to be a lot of things I need to consider and configure exactly the right way in order to get the correct performance as I've read on the forums, from the number of processes to start, to all kinds of other configuration issues. Somebody actually made a guide and I'm thankful for this but in my opinion I should not need to worry about any of this, foundationdb should scan what CPUs/disks I have and suggest the optimal solution/configuration. These are simple rules, shouldnt they be automatically done? Imagine how many people are running foundationdb suboptimally just because they didnt know that the default naive way of starting a few processes and letting them do some work is horribly wrong. The third issue is:
What matters is how the performance will look after I did all my fancy custom layers on top and when I had to emulate all the stuff that was builtin by mongodb and whether this thing is actually as reliable and performant as it says it is.
When I look at the issues I enumerated in the beginning, it really doesn't feel good to me. |
|