I am not looking for a perfect solution here, just wondering what you are planning for the project.
An embedded database implies you want to build the HA logic in the application layer, as opposed to re-use the database capabilities. Is that the case?
Note: I am in no way familiar with RocksDB, maybe there is something very obvious I don’t understand.
“TBD” sort of covers my plans right now. I’ve heard RocksDB has something internal which can be massaged into a replication stream but I’m not deep enough to grok it yet.
Faktory goes further and provides the same job persistence, state management and monitoring Web UI that Sidekiq does. It uses Facebook’s high-performance RocksDB embedded datastore internally to persist all job data, queues, error state, etc.
I couldn’t find information on how you plan to handle job persistence. What happens to the jobs if the server fails?
TBD. This is the public unveiling of a new project. No one ships with a perfect HA solution on day one.
I am not looking for a perfect solution here, just wondering what you are planning for the project.
An embedded database implies you want to build the HA logic in the application layer, as opposed to re-use the database capabilities. Is that the case?
Note: I am in no way familiar with RocksDB, maybe there is something very obvious I don’t understand.
“TBD” sort of covers my plans right now. I’ve heard RocksDB has something internal which can be massaged into a replication stream but I’m not deep enough to grok it yet.
Okay, I’ll look into it as well, thanks.
from the article itself:
I think he meant if the rocksdb server goes down, implying it has no fault tolerance.
It’s no worse a problem than relying on Postgres, minus the fact that RocksDB doesn’t have an obvious replication strategy.
So, to recap: fine for a hobby app, requires more effort for anything critcal.
rocksdb has no server, it’s an embedded database. It’s a fork of LevelDB.
Exactly, we were talking about the server hosting Faktory and in turn RocksDb.