On Sun, Jun 27, 2010 at 1:36 PM, Gaetano Giunta <[email protected]> wrote: > Bertrand Dunogier 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). > > Are you suggesting to use a key/pair for file metadata, or the reverse > (keeping file metadata in a db and file data "chunks" in the kv)? > Would the second solution be completely crazy (ie. no advantages in speed / > simplicity of setup / other domains) or not? >
I think I was suggesting it for the meta data tables(but those are more then simple key / value pairs), and files on nfs or something like gridfs as used by mongodb maybe. And I was not suggesting a cache layer, but an persistant kv store so you don't need to layer it.
-- Sdk-public mailing list [email protected] http://lists.ez.no/mailman/listinfo/sdk-public
