2010/6/23 Luc Chase <[email protected]> > ez is based on an EAV data-model (allowing us to store any new > content-class without changing the DB schema). But it results in the the > DBMS we currently use (e.g. MySQL, etc.) which is designed for more > conventional relational database designs, having to work very hard to > execute fetches. KV stores are designed for systems such as eZ and are able > to execute the same types of queries but more efficiently than a system > which would have expected different content classes to be in different > tables. The current situation is convenient and very good for a system that > allows new classes at any time. But in terms of efficiency on the DBMS, it's > like creating a dbms on a dbms. So, using a KV store I would expect a > performance improvement for fetches of maybe hundreds or thousands of > percent. And scalability issues would be fully resolved. > To be fully honest, as a member of the eZ engineering team, i'm quite aware of how eZ Publish is structured :-)
It is still a work-in-progress, but we are investing serious resources into a more advanced content engine that would be able to use no-SQL databases (sorry for the buzzword). We haven't investigated KV at all, but are studying (and working on/with) CouchDB, MongoDB and more specifically Solr. KV looks interesting though, but I confirm we haven't explicitely mentionned it so far. -- Bertrand
-- Sdk-public mailing list [email protected] http://lists.ez.no/mailman/listinfo/sdk-public
