Regarding compatibility, don't we already support NDB clusters for the whole DB anyway? I'm thinking that that is used the most and generally has the highest number of rows (apart from the ezsession table); and since NDB is an in-memory engine, it might provide an easy kill for improving performance without much negative as far as trying to do all joins across the clustered nodes on the (relatively slow) network.
-- Luc. On 27 June 2010 12:37, Gaetano Giunta <[email protected]> wrote: > Luc Chase wrote: > > Another possible option for easily improving both read and write > > performance.... > > Has anyone ever tried using MySQL NDB engine (within a cluster) *just > > for the ezcontentobject_attribute table*? Perhaps also with some > > partitioning of that table? > > Sounds interesting - but quite a few queries are done on that table. We > should find out if all of them are compatible with the ndb restrictions. > > The ezdb tables otoh could also be interesting candidates... > > > -- > > Luc. > > > > On 25 June 2010 20:04, Bertrand Dunogier <[email protected] <mailto:[email protected]>> > wrote: > > > > > > > > 2010/6/25 André Rømcke <[email protected] <mailto:[email protected]>> > > > > On Fri, Jun 25, 2010 at 4:56 PM, André Rømcke <[email protected] > > <mailto:[email protected]>> wrote: > > > > Key Value store on the other hand can be used for other > > things, memory variants for caching, and persistent variants > > for instance as an alternative nfs cluster handler for > > instance (Cluster handler can already use different DB as > > Bertrand mentioned on today eZ Conference talk, and the > > tables have a simple key / value structure). > > > > > > Ignore, mixed with ezdbfile_data, ezdfsfile is more complex so > > will probably not be possible in a pure KV, but maybe using any > > of the hybrids (Cassandra? but probably issue with it's > > eventually consistence nature though). > > > > Nope, ezdfsfile table has the exact same structure as the ezdbfile > > one. So a key/pair based cache would work here. We just have a few > > sync issues that /have/ to be considered (TTL of items, expiry > > delay, etc). > > > > There is an 'oops' from me here though, I have to confess: I > > probably read the initial email too late at night (okay, 21:03. I > > was drunk, I guess), and checked too quickly what KV Stores was > > exactly. But in any case, it has triggered an interesting discussion > > about both topics :-) > > > > -- > > Bertrand > > > > > > -- > > Sdk-public mailing list > > [email protected] <mailto:[email protected]> > > http://lists.ez.no/mailman/listinfo/sdk-public > > > > > > > > > > -- > > Luc. > > M. +44.7939 00 29 32 > > T. +44.2071939840 / +44.7040901582 > > Writing can be either readable or precise, but not at the same time. > > - Betrand Russell > > > > -- > Sdk-public mailing list > [email protected] > http://lists.ez.no/mailman/listinfo/sdk-public > -- Luc. M. +44.7939 00 29 32 T. +44.2071939840 / +44.7040901582 Writing can be either readable or precise, but not at the same time. - Betrand Russell
-- Sdk-public mailing list [email protected] http://lists.ez.no/mailman/listinfo/sdk-public
