Indexed relations.
Stephane Le Dorze
Joao Cachopo
> How can I start using them?
> Which code version should we use? what is the status (feature and
> behavior including the usage patterns)?
Would it be OK for you if you had already a version of the
fenix-framework that allowed specifying indexed relations at the DML
level, but that, instead of using the new btrees for the relations was
still using the old sets and generating the code to iterate over those
sets.
This way, you would not have the performance benefits yet, but at least
your code would be using already the new API. Once the new btrees are
fully tested and operational, you would get the performance benefits
without having to change your code. But you will have to migrate your
database, nevertheless...
Best regards,
--
João Cachopo
Stephane Le Dorze
Joao Cachopo
> If it is in the main trunk; yes!
OK, I think that we may manage to that shortly, but I'll have to check.
> (Just a matter of performance guessing) I wonder; are these BTrees
> implemented at the DB level; or would they rely on the underlying
> Btree implementation of their backend?
They are implemented as fenix-framework entities, i.e., persistent
objects backed up by the fenix-framework. So, they will use whatever
backend is being used for the remaining of the persistent entities.
Actually, currently they are not programmed in the DML themselves, but I
guess that they should, even though there may be some bootstrapping
issues there...
> Speaking about that; we're now wondering about fail-over and wonder
> what do you use in production with MySQL? (master - master)?
I believe that MySQL is configured in a (master - slave) arrangement.
That is, all application servers talk with the same MySQL server that is
then responsible for pushing the changes down to a replica (via binlogs,
if I'm not mistaken). The failover (in case of failure of the master)
is not automatic, though.
> About the next backend? Have commited to a choice? (Berkeley?)
Well, I've not discussed this further yet with the rest of the team, and
we haven't started doing it (even though the majority of the work has
already been done for the HBase backend), but I'm almost certain that we
would want to have a Berkeley DB backend, yes.
Stephane Le Dorze
> If it is in the main trunk; yes!OK, I think that we may manage to that shortly, but I'll have to check.
They are implemented as fenix-framework entities, i.e., persistent
> (Just a matter of performance guessing) I wonder; are these BTrees
> implemented at the DB level; or would they rely on the underlying
> Btree implementation of their backend?
objects backed up by the fenix-framework. So, they will use whatever
backend is being used for the remaining of the persistent entities.
Actually, currently they are not programmed in the DML themselves, but I
guess that they should, even though there may be some bootstrapping
issues there...
> Speaking about that; we're now wondering about fail-over and wonderI believe that MySQL is configured in a (master - slave) arrangement.
> what do you use in production with MySQL? (master - master)?
That is, all application servers talk with the same MySQL server that is
then responsible for pushing the changes down to a replica (via binlogs,
if I'm not mistaken). The failover (in case of failure of the master)
is not automatic, though.
Well, I've not discussed this further yet with the rest of the team, and
> About the next backend? Have commited to a choice? (Berkeley?)
we haven't started doing it (even though the majority of the work has
already been done for the HBase backend), but I'm almost certain that we
would want to have a Berkeley DB backend, yes.