issues with bucket types and corrugatediron

Paige Thompson erratic at yourstruly.sx
Wed Dec 10 12:49:48 EST 2014


Just a heads up, we figured out I had some consistency/misconfiguration
issues with my riak.conf and the names I had specified for the backends:

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

#was: multi_backend.leveldb_mult.storage_backend = memory
multi_backend.memory_mult.storage_backend = memory

multi_backend.default = bitcask_mult


Also the names of the storage backends in the bucket type definitions
were inconsistent with the riak.conf (were: memory, leveldb, and
bitcask) (changed to memory_mult, leveldb_mult, and bitcask_mult) now it
works fine.


On 12/10/14 15:43, Paige Thompson wrote:
> 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
> riak-users at lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com





More information about the riak-users mailing list