issues with bucket types and corrugatediron

Paige Thompson erratic at yourstruly.sx
Wed Dec 10 10:43:24 EST 2014


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





More information about the riak-users mailing list