Nit picking, but can we please distinguish between KV (memcached, redis, dynamo, cassandra..) and Document storage (couch, mongo..)?
They have slightly different use cases, document store is a good match for our content engine and with it's schema less nature we can 'solve' the schema update issue on lots of content by ignoring obsolete attributes on reads, use default values for missing attributes and update to correct schema on writes. 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). On Thu, Jun 24, 2010 at 10:49 AM, Gaetano Giunta <[email protected]> wrote: > Bertrand Dunogier wrote: > > 2010/6/23 Luc Chase <[email protected] <mailto:[email protected]>> > > > > > Disadvantages > > > 1) slow > > I would expect a huge improvement on current performance and I very > > much doubt it would be slower. But if it is then, I would say do not > > do it. > I think this comment was about basex, not no-sql implementations in general. Personally I would prefer some document store and search enginge for retrival where you can't lookup the document by it's key (filters, drill downs, lists..). But we also need to identify the other types of data we use and where to best place them, like preferences, polices, roles, users.. > > In any case, about replacing the current "content DB" (we should first > > identify which parts of the DB are part of the content engine and which > > are not...), yes, there is an abstraction layer. But unfortunately, we > > live in a world where database / query abstraction is far from perfect, > > especially back a few years ago. Refactoring all of this is planned, > > but parallel work on such an integration will (or would) severely > > increase developement time. And will also add up again when the public > > API is refactored. > > What do you mean exactly with 'parallel work'? Parallel to what? > > 'Add up again' - I think on the contrary that when the public API is/will > be redesigned, it will need to take into account this possible change in its > underlying data-storage layer to avoid being obsoleted fast. So it would be > better to have a working prototype of a different storage engine now, to > check that > the new public api is compatible with it... > As for the prototype, that is being worked on as well in the Archive story. (As presented by Paul yesterday at the conference) But new PHP API is really crucial to be able to switch data store in the future. Our current API is way to tied into relational databases to be possible to hack it into using other stores without major breaks beyond the point of even be funny. So new API, hopefully in a eZ Publish version soon, and maybe as an extension so early extension addaptors can support some older eZ Publish versions as well? :)
-- Sdk-public mailing list [email protected] http://lists.ez.no/mailman/listinfo/sdk-public
