On Feb 28, 2014, at 4:31 AM, Benoit Chesneau <bchesn...@gmail.com> wrote:
> Looking at the code of mem3 it seems that all databases are oblgatory > fragmented (sharded). I understand that you can have only 1 shard / > database but then it will be still stored at > `<database_dir>/shard/<dbname>`. > > Is there any plan of having non fragmented databases stored in their > own place ie `<database_dir>/<dbname>` ? Would be interesting when > you want to manage different policies of backup depending on the type > of database (fragmented or not). Which place should I look to make it > happen? > > - benoit I'm not entirely certain I understand what you're looking for there Benoit. I classify databases in two categories: "clustered" and "local". A clustered database is available via the clustered HTTP interface and has its data stored in files inside <database_dir>/shards/<range>/<dbname>. This is true even for a Q=1,N=1 database where this is only one file for the database in the entire cluster. On the other hand, a local database exists on a specific node in the cluster, and is not accessible via the clustered HTTP interface. The data for this database is stored at <database_dir>/<dbname>. What exactly did you mean by a non-fragmented database? It sort of sounds like you're wanting to conflate a Q=1,N=1 clustered database with a local database, but those are very different concepts (not least because multiple nodes in a cluster can have a local database with the same name but different content). I can honestly say we've never considered storing the files for Q=1 or Q=1,N=1 databases somewhere different than other clustered databases. Can you say more about your motivations here? You talked about backup policies; while I could absolutely see wanting to implement a different backup policy for N=1 databases it's not obvious to me why you'd want to treat Q=1 and Q>1 databases separately. Adam
