2010/6/23 Luc Chase <[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. >
Well, everything's relative, including performances... there is no such thing as pure performances as far as the database's concerned. Non-SQL DBs will definitely be faster when it comes to listing using search criterias, for instance. That is actually why we recommend replacing heavy content requests by solr searches ;) But it doesn't mean such a DB would be faster for everything. I for one thing it might be slower when inserting / updating content; such operations are very commonly asynchronous, and this might also be an issue. All of this is perfectly manageable. With time... 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. But yes, when it comes to extracting & rendering content, such a no-SQL DB would probably be much more efficient. Not that much for UGC & social stuff though... right ? -- Bertrand
-- Sdk-public mailing list [email protected] http://lists.ez.no/mailman/listinfo/sdk-public
