Christian,
Sincere thanks for that very concise explanation. The portion regarding secondary indexes as partition storage is especially enlightening. This is very useful information. I highly recommend it being included in the 'Start Here' guide. So again, considering the benefit of natural key selection, It would be handy if one could add many named counters per buket/key to more closely handle a shopping cart scenario J -m From: Christian Dahlqvist [mailto:christ...@basho.com] Sent: Saturday, November 09, 2013 6:10 AM To: Mark A. Basil, Jr. Cc: 'Dave Rusek'; riak-users@lists.basho.com Subject: Re: Multiple named counters per key Hi Mark, Riak is at its core a key-value store, and accessing objects directly through the key is therefore the by far the most efficient and scalable method. For each query, Riak can through consistent hashing determine exactly where the data should live and GET/PUT/DELETE it very efficiently, giving near-linerar scalability. It is generally recommended that you use semantic keys that will allow you to query directly based on key, rather that e.g. always use a UUID. Some of the other features in Riak, e.g. secondary index queries and mapreduce, are often referred to as 'coverage queries'. As objects having a secondary index that matches the query can be stored in any partition, Riak needs to access a covering set of partitions in order to find all objects. A covering set of partitions is generally at least 'ring_size / n_val' rounded up. As these kind of queries require Riak to do significantly more work compared to direct key access, they generally result in higher and less predictable latencies. As the number of partitions that need to be queried increases with ring size, they do not scale linearly either. For this reason it is generally recommended that you use secondary index queries and mapreduce when you can control the level of concurrency and the thereby the load of the system. When you are considering using secondary indexes, it makes sense to first consider whether your application will be read or write heavy or perhaps even balanced. As described in http://basho.com/index-for-fun-and-for-profit/ , it does in some scenarios make sense to create and maintain your own indexes rather than automatically relying on secondary indexes. Link walking is behind the scenes based on mapreduce and suffers from the same limitation and performance characteristic. Best regards, Christian On 8 Nov 2013, at 20:28, "Mark A. Basil, Jr." <m...@badarmadillo.com> wrote: Yes that would certainly work. My experience up until recently has been limited to RDBMS, so I'm still trying to wrap my head around ideas of relating data when done this way. How does one choose the "best" of 2i vs. links vs. deterministic key names? What makes this hard to adopt is that there isn't much background info on use-case, and the impact that a particular method had on that case. I don't know what resource to turn to that is a starting point for "when you need to do this, then these are the options and here are the pros/cons". I just don't have time to watch 96 Vimeo videos that are all 30-60 minutes long. Counters seem like a good idea, but in order to use one we must solve another problem. My mindset is use the built-in counter because that's what they are meant to do; however, when that brings about a more complex problem of determining how to relate the data, it just doesn't make sense. Again, I'm very new to "NoSQL". So if I'm missing some fundamental thing that should be obvious please forgive me. -m From: Dave Rusek [mailto:dru...@basho.com] Sent: Friday, November 08, 2013 2:53 PM To: Mark A. Basil, Jr.; riak-users@lists.basho.com Subject: Re: Multiple named counters per key Could you accomplish this with a bucket which is a map of counters? The counter name would be the map key. -- Dave Rusek Sent with <http://airmailapp.com/tracking> Airmail On November 8, 2013 at 12:50:23 PM, Mark A. Basil, Jr. ( <mailto://m...@badarmadillo.com> m...@badarmadillo.com) wrote: Just a thought. It would be handy if one could add many named counters per buket/key to more closely handle a shopping cart scenario. Otherwise, unless I'm mistaken, one would have to have a bucket that would be the "cart" and keys which are the "items". That doesn't make a lot of sense to me. _______________________________________________ riak-users mailing list <mailto:riak-users@lists.basho.com> riak-users@lists.basho.com <http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
