FleetDB Development Roadmap

[Murtaza Husain]

Hi,

First let me appreciate the effort that has gone into this project. Its fills a very obvious void for OLTP applications having regular traffic.

I am considering using it for few our our applications. We are already actively using mongodb and couchdb. I could see use cases for switching from both of them.

My concern here is that though it is an excellent project, however is it being actively developed? Is there a roadmap on where it is progressing?

Also if I am using fleetdb what architecture do I use to account for disater recovery situations. In MongoDB I can replicated nodes, and in Couchdb the DB can similarly replicate to provide me fallback if a server goes down. How would I do that in fleetdb?

I see that fleetdb allows concurrency control through multiple writes, check-write, however consider the scenario where I have a huge map of data which can be modified concurrently. I would like to do something like CouchDB's MVCC, where if I have modified the map and saved it back, and someone tries to modify an older version of the same map and saves if after my save operation, then fleetdb will throw an error. Is that how it behaves right now?

If not then how do I structure the above operation. My understanding of fleetdb is elementary so I may be asking something very obvious.

Thanks,
Murtaza
   

[Mark McGranaghan]

Hi Murtaza,

On Dec 26, 8:46 pm, Murtaza Husain <murtaza.hus...@searce.com> wrote:
> Hi,
>
> First let me appreciate the effort that has gone into this project. Its
> fills a very obvious void for OLTP applications having regular traffic.
>
> I am considering using it for few our our applications. We are already
> actively using mongodb and couchdb. I could see use cases for switching
> from both of them.
>
> My concern here is that though it is an excellent project, however is it
> being actively developed? Is there a roadmap on where it is progressing?

FleetDB is not being actively developed. I still keep an eye on it,
e.g. via this mailing list, but there isn't a particular roadmap for
changes going forward.

> Also if I am using fleetdb what architecture do I use to account for
> disater recovery situations. In MongoDB I can replicated nodes, and in
> Couchdb the DB can similarly replicate to provide me fallback if a server
> goes down. How would I do that in fleetdb?

FleetDB is designed to be easily persisted for disaster recovery
purposes. The single data file produced by a FleetDB server running in
persistent mode can be copied using standard tools like cp, rsync,
curl, etc. You can start a new FleetDB server against one of these
copies to recover a lost machine.

The data file is also designed to be easily backed up in an
incremental/continuous way - the Petrify tool takes advantage of this:
https://github.com/mmcgrana/petrify.

Online replication is possible with some work, but not well documented
or tested, so I would advise against trying it.

> I see that fleetdb allows concurrency control through multiple writes,
> check-write, however consider the scenario where I have a huge map of data
> which can be modified concurrently. I would like to do something like
> CouchDB's MVCC, where if I have modified the map and saved it back, and
> someone tries to modify an older version of the same map and saves if after
> my save operation, then fleetdb will throw an error. Is that how it behaves
> right now?

This is not built-it in the way that it is in CouchDB, but it can be
implemented in userspace. When you create a record, include a (say)
"version" field starting at 0, and then increment it with each write,
using check-write to ensure that the record in the most recent version
of the database has the same version as the one you read and have
updated locally.

> If not then how do I structure the above operation. My understanding of
> fleetdb is elementary so I may be asking something very obvious.
>
> Thanks,
> Murtaza

Thanks for taking the time to write to the list. Good luck with your
datastore explorations!