Luc Chase wrote: > Regarding compatibility, don't we already support NDB clusters for the > whole DB anyway?
Unfortunately not. http://dev.mysql.com/doc/refman/5.0/en/mysql-cluster-limitations.html Just browse to section 17.1.5.1, and you will see that NDB storage engine does not support many features eZP uses, such as temp tables indexes on bit/text fields, etc... > 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] <mailto:[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]> <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > > > > > 2010/6/25 André Rømcke <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> > > > > On Fri, Jun 25, 2010 at 4:56 PM, André Rømcke <[email protected] > <mailto:[email protected]> > > <mailto:[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]> > <mailto:[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] <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
