https://github.com/basho-labs/CorrugatedIron/issues/212
I may not be understanding this correctly but I'm about to test this in a sec, maybe I can create the bucket with a shell script to make sure its created with the specified bucket type, but thats assuming that it won't maintain two different buckets with the same name "Sessions" when I try to put objects (IE if I don't put objects and specify the bucket type in Corrugated Iron.) As for the rest of the config stuff: Konsole output storage_backend = multi multi_backend.bitcask_mult.storage_backend = bitcask multi_backend.bitcask_mult.bitcask.data_root = ../data/riak/bitcask_mult multi_backend.leveldb_mult.storage_backend = leveldb multi_backend.leveldb_mult.leveldb.data_root = ../data/riak/leveldb_mult multi_backend.leveldb_mult.storage_backend = memory multi_backend.default = bitcask_mult Because of the amount of trouble I had to go through to get that configuration figured out in the first place, I want to say it's probably better if I just have 3 different riak servers, one for memory, one for bitcask, and one for leveldb. This way I wouldn't even have to mess with bucket types, but I can't even begin to tell you how unacceptable that is for someone trying to setup riak for development purposes; - yeah ok sure just start 3 docker instances because docker totally doesn't have problems either. - I guess I could also just have 3 instances of riak running all of which use different listening ports but thats... fughhhhgly. I'm having logistical hangups about this in terms of what I have to support in order to facilitate development efforts led by other people. I could use some advice as maybe just reading the documentation isn't doing me any favors? I do have a purpose in in wanting to use all 3 of these backends, let me describe why I want these things, feel free to tell me where I'm wrong: Memory: session: self expiring objects, fast. Object footprint is predictably measurable (has a sane maximum size, small) Bitcask: user account: no secondary indexes required, items are always retrieved by the same key, object footprint is predictably measurable (has a sane maximum size, only needs to be accessed once and the name and location of the user's data bucket is cached in the session object.) Since keys are in memory this would mean that authentication should be pretty fast, and the overhead on the server should be pretty minimal since it's only needed once every time the user logs in. leveldb: user account data buckets: each user has it's own bucket, may have secondary indexes for searching, bucket/data size is somewhat invariable; I'm also planning to index each bucket (as per the documentation for solr, indexing can be done on bucket types and I would like to set up solr so that it finds all user data buckets by bucket type.) I've established creating a bucket per user is an ok way to manage stuff, though I'm wondering what sort of implications this will have in how partitioning works/doesn't work; will each buckets data be "partitioned" (seems like in the context of replicas partitioning just means that each node is responsible for queries to specific items in the bucket vs specific items only exist in those parititons.) Any advice appreciated, -Paige _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
