On Dec 13, 2012, at 5:06 PM, Benoit Chesneau <[email protected]> wrote:
> Hi all, > > > This morning I was back reading a lot of fundamentals about databases and > such and was asking myself how we could increase the number of concurrent > writes. > > These days the theory is that it will be solved by sharding the databases > in multiples database files and merging results of the queries. Since the > databases will be shareded then the writes on the same db will be > concurrents. A map of the shards willl be kept aside. All of this thanks to > the introduction of bigcouch. > > The question I have is why don't we already do that? Ie balancing datas on > different files on one db? for example the db folder could be > > database/XY.couch > > where XY are the first letters of an id or content hash or any consistent > hashing method. > > I am currently asking myself such question because I am wondering how will > the backup works when couchdb will be used as a single node. How to backup > only one db without having to query for the mapping and such? How to keep > it it simple. > > Related to that why did bigcouch used that design? Why mapping shards in a > db database instead of having some kind of natural balancing on the fs and > having a consistent hashing algorithm used to balance on different > machines/vms as well ? > > > - benoît Hi, That's like "horizontal partitioning" in conventional databases and I think its a great idea. Having a writer process for each partition will make it scale. Does Bigcouch have anything for the view files too or are they just sharding the backing files? - Hans
