Hi Ioana,
In meantime if you are interested these are the
results I've got some time ago doing the volume test
for scenario 1 with sequoia 1,2 and 3 backends and
without sequoia. If you are looking at the tests 5
(131 TPS) and 7 (132 TPS) they are almost the same.
When running the same tests (tests 6 and 8) without FK
constraints in the database the difference is big 144
and 681...
Do you know why this is happening?
Yes, this is easy to understand. Sequoia overhead is pretty much
constant on all queries (a good baseline is around 8ms but it can vary
according to the setup). When you have slower queries (which is the case
when you enforce referential integrity), Sequoia overhead becomes almost
negligible. When you have fast queries (this is the case without
referential integrity), Sequoia overhead becomes more substantial.
If you have write intensive workloads, you may want to look at other
alternatives than full replication that will never scale writes (at best
it will go at the speed of 1 database but with group communication and
synchronization it will usually be slower). Shared disk architectures
might be a little better at scaling write workloads but it is expensive
and require specific database extensions.
Sequoia only offers read scalability (like any other replication
technology), you would need partitioning to scale writes.
Hope this clarifies things a bit,
Emmanuel
--
Emmanuel Cecchet
Chief Architect, Continuent
Blog: http://emanux.blogspot.com/
Open source: http://www.continuent.org
Corporate: http://www.continuent.com
Skype: emmanuel_cecchet
Cell: +33 687 342 685
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
