[ANN] Yokozuna 0.11.0

[Ryan Zezeski]

Riak Users,

Today I'm happy to announce the 0.11.0 release of Yokozuna.

This release brings Riak Java Client support as well as
authentication and security for the HTTP and protocol buffer
transports. An access control list (ACL) may be created to
control administration and access to indexes. All official Riak
clients should now have full support for Yokozuna's
administration and search API. Stored boolean fields and tagging
support were fixed for the protocol buffer transport. And
finally, documentation was added. The new CONCEPTS document [1]
goes over various important concepts in Yokozuna and the
RESOURCES document [2] has links to other resources for
learning. There isn't much documentation on specifically how to
use the new security features besides in the pull request itself
but I will rectify that soon with a security specific doc page.

This release may confuse some people given that the Riak 2.0 Tech
Preview (2.0.0pre5) [3] was just released last week. Why continue
with separate Yokozuna releases? What is the difference? These
questions are answered in the INSTALL document [4], but the short
story is that Yokozuna runs on a monthly release cycle and
therefore out paces official Riak releases. These monthly releases
allow you to try the latest Yokozuna features and bug fixes
without waiting for the next Riak release. These releases should
never be used for production. See the INSTALL document for more
information.

In summary: If you need to test the latest features then use the
Riak-Yokozuna source package. Otherwise just stick to the tech
preview until the final Riak 2.0 package drops.

Finally, the only feature in Riak-Yokozuna 0.11.0 not found in
Riak 2.0.0pre5 is the security feature. See the release notes and
install document for more details.

https://github.com/basho/yokozuna/blob/develop/docs/RELEASE_NOTES.md#0110

https://github.com/basho/yokozuna/blob/develop/docs/INSTALL.md

-Z

[1]: https://github.com/basho/yokozuna/blob/develop/docs/CONCEPTS.md

[2]: https://github.com/basho/yokozuna/blob/develop/docs/RESOURCES.md

[3]: http://docs.basho.com/riak/2.0.0pre5/downloads/

[4]: https://github.com/basho/yokozuna/blob/develop/docs/INSTALL.md
___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: LevelDB tuning questions.

[kzhang]

I am reading through
http://docs.basho.com/riak/latest/ops/advanced/backends/leveldb/

I am a little confused when I read 'cache size' section, where the
calculation of cache size is based on 50% of physical memory and the
sentence here also seems to indicate to allocate 50% of memory to block
cache alone:You might ask yourself, 'why only 50% of available RAM?'


But in the 'Parameter Planning' section, it seems to say to allocate 50% of
physical memory to leveldb overall, including cache_size plus
average_write_buffer_size, open_file_memory and 20 MB (for management
files). 

Which of the above should I follow? BTW, we are on riak 1.4. 



--
View this message in context: 
http://riak-users.197444.n3.nabble.com/LevelDB-tuning-questions-tp4029246p4029715.html
Sent from the Riak Users mailing list archive at Nabble.com.

___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: LevelDB tuning questions.

[Matthew Von-Maszewski]

The 50% recommendation is to ensure there is memory available if this node has 
to take over vnodes from a failing node.  leveldb in Riak 1.4 has a static 
memory allocation for each vnode.  If you suddenly add a bunch of vnodes in a 
failure scenario, this machine could run out of memory and also fail as each 
added vnode grabs another same sized slice of memory … cascading failure could 
result and bring down the entire cluster.

Another email thread recently pointed out that static allocation / static 
sizing of leveldb is mostly stupid.  However, that is how the leveldb code 
originated from Google.  Riak 2.0 implements dynamic leveldb cache sizing.  You 
will get to configure 90% ram to leveldb (the default) and that memory will 
dynamically split across the vnodes even as vnodes move to and from the server. 
 No more fancy formulas or hard thinking:  one number and done.  (but only with 
Basho's leveldb  :-)  )

Matthew



On Nov 7, 2013, at 10:59 AM, kzhang  wrote:

> I am reading through
> http://docs.basho.com/riak/latest/ops/advanced/backends/leveldb/
> 
> I am a little confused when I read 'cache size' section, where the
> calculation of cache size is based on 50% of physical memory and the
> sentence here also seems to indicate to allocate 50% of memory to block
> cache alone:You might ask yourself, 'why only 50% of available RAM?'
> 
> 
> But in the 'Parameter Planning' section, it seems to say to allocate 50% of
> physical memory to leveldb overall, including cache_size plus
> average_write_buffer_size, open_file_memory and 20 MB (for management
> files). 
> 
> Which of the above should I follow? BTW, we are on riak 1.4. 
> 
> 
> 
> --
> View this message in context: 
> http://riak-users.197444.n3.nabble.com/LevelDB-tuning-questions-tp4029246p4029715.html
> Sent from the Riak Users mailing list archive at Nabble.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

Re: LevelDB tuning questions.

[Matthew Von-Maszewski]

Hmm, no.

I double checked the link.  It has the spreadsheet for 1.2 (bad basho, bad bad 
basho).  Attached is the 1.4 spreadsheet.

Note there is a secondary column that computes sizing when anti_entropy is on 
(default).

Matthew



leveldb_sizing_1.4.xls
Description: Binary data


On Nov 7, 2013, at 12:00 PM, kzhang  wrote:

> Thanks for the reply!
> 
> So to properly size leveldb memory for riak 1.4, should I just use the
> 'memory model spreadsheet' attached in the article
> (http://docs.basho.com/riak/latest/ops/advanced/backends/leveldb/)? 
> 
> 
> 
> --
> View this message in context: 
> http://riak-users.197444.n3.nabble.com/LevelDB-tuning-questions-tp4029246p4029717.html
> Sent from the Riak Users mailing list archive at Nabble.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

Re: LevelDB tuning questions.

[kzhang]

Thanks for the reply!

So to properly size leveldb memory for riak 1.4, should I just use the
'memory model spreadsheet' attached in the article
(http://docs.basho.com/riak/latest/ops/advanced/backends/leveldb/)? 



--
View this message in context: 
http://riak-users.197444.n3.nabble.com/LevelDB-tuning-questions-tp4029246p4029717.html
Sent from the Riak Users mailing list archive at Nabble.com.

___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: LevelDB tuning questions.

[kzhang]

Thanks again!

I have a few questions regarding the new spreadsheet.

'percent reserved', in the spreadsheet, it is set at 10%, we should really
use 50%?

'vnode count', it is 'vnode count per server'?

E11 (max_open_file, with AAE), shows as a static value '10*4*1024*1024',
whereas D11(max_open_file calculations) is calculated as
(c11-10)*4*1024*1024, E11 looks a bit odd to me, should I use D11 instead?

I noticed 'avg value size' and 'avg key size' are missing from the new
compared to 1.2, is it intentional?

Is the end goal to make:
working per vnode = ave for 2 write bufs + cache_size + max_open_files+20M
for LOG and for MANIFEST?

Thanks,

Kathleen











--
View this message in context: 
http://riak-users.197444.n3.nabble.com/LevelDB-tuning-questions-tp4029246p4029719.html
Sent from the Riak Users mailing list archive at Nabble.com.

___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: LevelDB tuning questions.

[Matthew Von-Maszewski]

inserting replies in original text

On Nov 7, 2013, at 12:49 PM, kzhang  wrote:

> Thanks again!
> 
> I have a few questions regarding the new spreadsheet.
> 
> 'percent reserved', in the spreadsheet, it is set at 10%, we should really
> use 50%?
> 
> 'vnode count', it is 'vnode count per server'?
> 
percent reserved and vnode count:  there are two ways to populate the fields

 - set percent reserved in range of 50 to 75% (50 for small number of nodes 
<10, 75 for >10), 
   and set vnode count to your ring size divided by total number of nodes

 - set percent reserved to 10% 
   and set vnode count to your ring size divided by your worst case count of 
nodes after multiple server failures

The first way is the documented method.  The second is what I have been using 
more recently.


> E11 (max_open_file, with AAE), shows as a static value '10*4*1024*1024',
> whereas D11(max_open_file calculations) is calculated as
> (c11-10)*4*1024*1024, E11 looks a bit odd to me, should I use D11 instead?
> 
No.  AAE does not use your max_open_file count.  It has a static allocation of 
10 to minimize impact.

> I noticed 'avg value size' and 'avg key size' are missing from the new
> compared to 1.2, is it intentional?
Yes.  The two values in 1.2 were used to estimate overhead for bloom filters.  
Bloom filter sizes and accounting completely changed in 1.3.  Made my life 
simpler.

> 
> Is the end goal to make:
> working per vnode = ave for 2 write bufs + cache_size + max_open_files+20M
> for LOG and for MANIFEST?
> 
Yes.  

Side note:  never mess with the write buffer min and max size … unless 
something is really, really wrong … or you have almost no RAM.  There are 
several internal tunings based upon those assumed sizes.

> Thanks,
> 
> Kathleen
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://riak-users.197444.n3.nabble.com/LevelDB-tuning-questions-tp4029246p4029719.html
> Sent from the Riak Users mailing list archive at Nabble.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

Re: LevelDB tuning questions.

[kzhang]

I am attaching my calculation based on our environment. Since I am getting
negative remainders, so my best bet is to change the number of
max_open_file? should I tweak cache_size at all?


Copy_of_leveldb_sizing_1_4_(2).xls

  



--
View this message in context: 
http://riak-users.197444.n3.nabble.com/LevelDB-tuning-questions-tp4029246p4029721.html
Sent from the Riak Users mailing list archive at Nabble.com.

___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: LevelDB tuning questions.

[Matthew Von-Maszewski]

Kathleen,

This is a tricky question.  On a new database, the cache_size will help 
performance.  As your database grows, the file cache (max_open_files) becomes 
more important than the cache_size because a miss in the file cache is much 
more expensive (disk activity) than a miss in the block cache (cache_size).

My thought at this time is to leave you cache_size as is (50Mbytes), and reduce 
your max_open_files from 150 to 138.


Once your database is in production, go find a LOG file in the leveldb data 
directory every two weeks or so.  Look for a line like this:

2013/11/06-16:32:06.853818 7f972437a700 compacted to: files[ 0 0 29 51 50 0 0 ]

Add the seven numbers between the '[' and ']'.  When those total larger than 
138, it will be time to start rethinking the setting.  

Matthew



On Nov 7, 2013, at 2:05 PM, kzhang  wrote:

> I am attaching my calculation based on our environment. Since I am getting
> negative remainders, so my best bet is to change the number of
> max_open_file? should I tweak cache_size at all?
> 
> 
> Copy_of_leveldb_sizing_1_4_(2).xls
> 
>   
> 
> 
> 
> --
> View this message in context: 
> http://riak-users.197444.n3.nabble.com/LevelDB-tuning-questions-tp4029246p4029721.html
> Sent from the Riak Users mailing list archive at Nabble.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

IRiakClient and fetchMeta

[JohnP]

Hi -

I am using the java client library for Riak and trying to determine if there
is an equivalent way to query only for metadata with IRiakClient in the same
manner one can with the older RiakClient? 

RiakClient has the following method: fetchMeta(String bucket, String key)

Thanks in advance!

- John



--
View this message in context: 
http://riak-users.197444.n3.nabble.com/IRiakClient-and-fetchMeta-tp4029723.html
Sent from the Riak Users mailing list archive at Nabble.com.

___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: IRiakClient and fetchMeta

[Brian Roach]

Hi John -

You're looking for headOnly() in the FetchObject. Simplest example:

bucket.fetch("key").headOnly().execute();

Thanks,
-Roach

On Thu, Nov 7, 2013 at 5:05 PM, JohnP  wrote:
> Hi -
>
> I am using the java client library for Riak and trying to determine if there
> is an equivalent way to query only for metadata with IRiakClient in the same
> manner one can with the older RiakClient?
>
> RiakClient has the following method: fetchMeta(String bucket, String key)
>
> Thanks in advance!
>
> - John
>
>
>
> --
> View this message in context: 
> http://riak-users.197444.n3.nabble.com/IRiakClient-and-fetchMeta-tp4029723.html
> Sent from the Riak Users mailing list archive at Nabble.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

Re: LevelDB tuning questions.

[kzhang]

Thanks!

The cluster has been in production for 4 months. I found this in leveldb log
file:
013/10/25-12:43:10.678239 7fb895781700 compacted to: files[ 0 1 5 31 51 0 0
]
2013/10/29-16:57:26.280633 7fb895781700 compacted to: files[ 0 2 5 31 51 0 0
]
2013/11/03-11:46:15.935006 7fb895781700 compacted to: files[ 0 3 5 31 51 0 0
]
2013/11/07-12:04:18.308733 7fb895781700 compacted to: files[ 0 4 5 31 51 0 0
]
2013/11/07-12:04:29.921077 7fb8958bf700 compacted to: files[ 0 0 20 31 51 0
0 ]
2013/11/07-12:04:31.629970 7fb8958bf700 compacted to: files[ 0 0 19 31 51 0
0 ]
2013/11/07-12:04:34.008481 7fb8958bf700 compacted to: files[ 0 0 18 31 51 0
0 ]
2013/11/07-12:04:38.480066 7fb8958bf700 compacted to: files[ 0 0 17 32 51 0
0 ]
2013/11/07-12:04:39.197229 7fb8958bf700 compacted to: files[ 0 0 15 35 51 0
0 ]
2013/11/07-12:04:41.440583 7fb8958bf700 compacted to: files[ 0 0 14 35 51 0
0 ]
2013/11/07-12:04:44.895349 7fb8958bf700 compacted to: files[ 0 0 13 35 51 0
0 ]
2013/11/07-12:04:47.098208 7fb8958bf700 compacted to: files[ 0 0 12 36 51 0
0 ]
2013/11/07-12:04:51.675148 7fb8958bf700 compacted to: files[ 0 0 11 39 51 0
0 ]
2013/11/07-12:04:53.454434 7fb8958bf700 compacted to: files[ 0 0 10 41 51 0
0 ]
2013/11/07-12:04:58.335885 7fb8958bf700 compacted to: files[ 0 0 9 44 51 0 0
]
2013/11/07-12:05:02.312521 7fb8958bf700 compacted to: files[ 0 0 8 44 51 0 0
]
2013/11/07-12:05:06.239789 7fb8958bf700 compacted to: files[ 0 0 7 44 51 0 0
]
2013/11/07-12:05:09.034111 7fb8958bf700 compacted to: files[ 0 0 6 45 51 0 0
]
2013/11/07-12:05:11.293695 7fb8958bf700 compacted to: files[ 0 0 6 44 51 0 0
]
2013/11/07-12:05:12.762098 7fb8958bf700 compacted to: files[ 0 0 6 43 51 0 0
]
2013/11/07-12:05:15.484027 7fb8958bf700 compacted to: files[ 0 0 6 42 51 0 0
]
2013/11/07-12:05:18.960306 7fb8958bf700 compacted to: files[ 0 0 6 41 51 0 0
]

looks like the sum never exceeded 110. I guess I should go ahead change the
max open file to 138?

Thanks,

Kathleen




--
View this message in context: 
http://riak-users.197444.n3.nabble.com/LevelDB-tuning-questions-tp4029246p4029725.html
Sent from the Riak Users mailing list archive at Nabble.com.

___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: LevelDB tuning questions.

[Matthew Von-Maszewski]

Agreed

Matthew Von-Maszewski


On Nov 7, 2013, at 19:44, kzhang  wrote:

> Thanks!
> 
> The cluster has been in production for 4 months. I found this in leveldb log
> file:
> 013/10/25-12:43:10.678239 7fb895781700 compacted to: files[ 0 1 5 31 51 0 0
> ]
> 2013/10/29-16:57:26.280633 7fb895781700 compacted to: files[ 0 2 5 31 51 0 0
> ]
> 2013/11/03-11:46:15.935006 7fb895781700 compacted to: files[ 0 3 5 31 51 0 0
> ]
> 2013/11/07-12:04:18.308733 7fb895781700 compacted to: files[ 0 4 5 31 51 0 0
> ]
> 2013/11/07-12:04:29.921077 7fb8958bf700 compacted to: files[ 0 0 20 31 51 0
> 0 ]
> 2013/11/07-12:04:31.629970 7fb8958bf700 compacted to: files[ 0 0 19 31 51 0
> 0 ]
> 2013/11/07-12:04:34.008481 7fb8958bf700 compacted to: files[ 0 0 18 31 51 0
> 0 ]
> 2013/11/07-12:04:38.480066 7fb8958bf700 compacted to: files[ 0 0 17 32 51 0
> 0 ]
> 2013/11/07-12:04:39.197229 7fb8958bf700 compacted to: files[ 0 0 15 35 51 0
> 0 ]
> 2013/11/07-12:04:41.440583 7fb8958bf700 compacted to: files[ 0 0 14 35 51 0
> 0 ]
> 2013/11/07-12:04:44.895349 7fb8958bf700 compacted to: files[ 0 0 13 35 51 0
> 0 ]
> 2013/11/07-12:04:47.098208 7fb8958bf700 compacted to: files[ 0 0 12 36 51 0
> 0 ]
> 2013/11/07-12:04:51.675148 7fb8958bf700 compacted to: files[ 0 0 11 39 51 0
> 0 ]
> 2013/11/07-12:04:53.454434 7fb8958bf700 compacted to: files[ 0 0 10 41 51 0
> 0 ]
> 2013/11/07-12:04:58.335885 7fb8958bf700 compacted to: files[ 0 0 9 44 51 0 0
> ]
> 2013/11/07-12:05:02.312521 7fb8958bf700 compacted to: files[ 0 0 8 44 51 0 0
> ]
> 2013/11/07-12:05:06.239789 7fb8958bf700 compacted to: files[ 0 0 7 44 51 0 0
> ]
> 2013/11/07-12:05:09.034111 7fb8958bf700 compacted to: files[ 0 0 6 45 51 0 0
> ]
> 2013/11/07-12:05:11.293695 7fb8958bf700 compacted to: files[ 0 0 6 44 51 0 0
> ]
> 2013/11/07-12:05:12.762098 7fb8958bf700 compacted to: files[ 0 0 6 43 51 0 0
> ]
> 2013/11/07-12:05:15.484027 7fb8958bf700 compacted to: files[ 0 0 6 42 51 0 0
> ]
> 2013/11/07-12:05:18.960306 7fb8958bf700 compacted to: files[ 0 0 6 41 51 0 0
> ]
> 
> looks like the sum never exceeded 110. I guess I should go ahead change the
> max open file to 138?
> 
> Thanks,
> 
> Kathleen
> 
> 
> 
> 
> --
> View this message in context: 
> http://riak-users.197444.n3.nabble.com/LevelDB-tuning-questions-tp4029246p4029725.html
> Sent from the Riak Users mailing list archive at Nabble.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

Re: LevelDB tuning questions.

[Matt Black]

Interesting thread!

I had used the old 1.2 spreadsheet to calculate cache_size and max_files -
and having used the 1.4 spreadsheet, it looks like I should change my
config :)

However, I'm not seeing anything like the below in my log files. Which log
file should I be looking in?

Cheers
Matt


On 8 November 2013 11:50, Matthew Von-Maszewski  wrote:

> Agreed
>
> Matthew Von-Maszewski
>
>
> On Nov 7, 2013, at 19:44, kzhang  wrote:
>
> > Thanks!
> >
> > The cluster has been in production for 4 months. I found this in leveldb
> log
> > file:
> > 013/10/25-12:43:10.678239 7fb895781700 compacted to: files[ 0 1 5 31 51
> 0 0
> > ]
> > 2013/10/29-16:57:26.280633 7fb895781700 compacted to: files[ 0 2 5 31 51
> 0 0
> > ]
> > 2013/11/03-11:46:15.935006 7fb895781700 compacted to: files[ 0 3 5 31 51
> 0 0
> > ]
> > 2013/11/07-12:04:18.308733 7fb895781700 compacted to: files[ 0 4 5 31 51
> 0 0
> > ]
> > 2013/11/07-12:04:29.921077 7fb8958bf700 compacted to: files[ 0 0 20 31
> 51 0
> > 0 ]
> > 2013/11/07-12:04:31.629970 7fb8958bf700 compacted to: files[ 0 0 19 31
> 51 0
> > 0 ]
> > 2013/11/07-12:04:34.008481 7fb8958bf700 compacted to: files[ 0 0 18 31
> 51 0
> > 0 ]
> > 2013/11/07-12:04:38.480066 7fb8958bf700 compacted to: files[ 0 0 17 32
> 51 0
> > 0 ]
> > 2013/11/07-12:04:39.197229 7fb8958bf700 compacted to: files[ 0 0 15 35
> 51 0
> > 0 ]
> > 2013/11/07-12:04:41.440583 7fb8958bf700 compacted to: files[ 0 0 14 35
> 51 0
> > 0 ]
> > 2013/11/07-12:04:44.895349 7fb8958bf700 compacted to: files[ 0 0 13 35
> 51 0
> > 0 ]
> > 2013/11/07-12:04:47.098208 7fb8958bf700 compacted to: files[ 0 0 12 36
> 51 0
> > 0 ]
> > 2013/11/07-12:04:51.675148 7fb8958bf700 compacted to: files[ 0 0 11 39
> 51 0
> > 0 ]
> > 2013/11/07-12:04:53.454434 7fb8958bf700 compacted to: files[ 0 0 10 41
> 51 0
> > 0 ]
> > 2013/11/07-12:04:58.335885 7fb8958bf700 compacted to: files[ 0 0 9 44 51
> 0 0
> > ]
> > 2013/11/07-12:05:02.312521 7fb8958bf700 compacted to: files[ 0 0 8 44 51
> 0 0
> > ]
> > 2013/11/07-12:05:06.239789 7fb8958bf700 compacted to: files[ 0 0 7 44 51
> 0 0
> > ]
> > 2013/11/07-12:05:09.034111 7fb8958bf700 compacted to: files[ 0 0 6 45 51
> 0 0
> > ]
> > 2013/11/07-12:05:11.293695 7fb8958bf700 compacted to: files[ 0 0 6 44 51
> 0 0
> > ]
> > 2013/11/07-12:05:12.762098 7fb8958bf700 compacted to: files[ 0 0 6 43 51
> 0 0
> > ]
> > 2013/11/07-12:05:15.484027 7fb8958bf700 compacted to: files[ 0 0 6 42 51
> 0 0
> > ]
> > 2013/11/07-12:05:18.960306 7fb8958bf700 compacted to: files[ 0 0 6 41 51
> 0 0
> > ]
> >
> > looks like the sum never exceeded 110. I guess I should go ahead change
> the
> > max open file to 138?
> >
> > Thanks,
> >
> > Kathleen
> >
> >
> >
> >
> > --
> > View this message in context:
> http://riak-users.197444.n3.nabble.com/LevelDB-tuning-questions-tp4029246p4029725.html
> > Sent from the Riak Users mailing list archive at Nabble.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
>
___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Yokozuna Search On Counters

[Weston Jossey]

Evening Everyone,
I’m curious if it’s possible operate against values in distributed counters via 
Yokozuna.  Here’s an example result I get from performing a query, but I don’t 
see what field the value is getting set to.  The value should be 80840.

curl 
'http://localhost:8098/search/stats?rows=10&q=_yz_id:this_is_a_test*&wt=json&indent=true&face=true&stats=on&stats.field=_yz_id'

  "response":{"numFound":1,"start":0,"maxScore":1.0,"docs":[
  {
"_yz_id":"this_is_a_test_30",
"_yz_rk":"this_is_a_test",
"_yz_rb":"stats"}]
  },
  "stats":{
"stats_fields":{
  "_yz_id":{
"min":"this_is_a_test_30",
"max":"this_is_a_test_30",
"count":1,
"missing":0,
"facets":{}
___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: Yokozuna Search On Counters

[Sam Elliott]

Weston,

We don't yet have an extractor written for Yokozuna to support Riak 1.4's 
Counter Data Type. We hope (but obviously can't guarantee) to have extractors 
for all the Data Types we release with Riak 2.0.

Sam

--  
Sam Elliott
Engineer
sam.elli...@basho.com
--


On Thursday, 7 November 2013 at 10:33PM, Weston Jossey wrote:

> Evening Everyone,
> I’m curious if it’s possible operate against values in distributed counters 
> via Yokozuna. Here’s an example result I get from performing a query, but I 
> don’t see what field the value is getting set to. The value should be 80840.
>  
> curl 
> 'http://localhost:8098/search/stats?rows=10&q=_yz_id:this_is_a_test*&wt=json&indent=true&face=true&stats=on&stats.field=_yz_id'
>  
> "response":{"numFound":1,"start":0,"maxScore":1.0,"docs":[
> {
> "_yz_id":"this_is_a_test_30",
> "_yz_rk":"this_is_a_test",
> "_yz_rb":"stats"}]
> },
> "stats":{
> "stats_fields":{
> "_yz_id":{
> "min":"this_is_a_test_30",
> "max":"this_is_a_test_30",
> "count":1,
> "missing":0,
> "facets":{}
> ___
> riak-users mailing list
> riak-users@lists.basho.com (mailto: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

Re: Yokozuna Search On Counters

[Weston Jossey]

Thanks Sam (and Eric who PM’d me).

Well, I’ll put in my 2cents that I’d love that feature.  We’re already using 
counters, and adding yokozuna on top of it would be really useful.

-Wes

On Nov 7, 2013, at 10:47 PM, Sam Elliott  wrote:

> Weston,
> 
> We don't yet have an extractor written for Yokozuna to support Riak 1.4's 
> Counter Data Type. We hope (but obviously can't guarantee) to have extractors 
> for all the Data Types we release with Riak 2.0.
> 
> Sam
> 
> --  
> Sam Elliott
> Engineer
> sam.elli...@basho.com
> --
> 
> 
> On Thursday, 7 November 2013 at 10:33PM, Weston Jossey wrote:
> 
>> Evening Everyone,
>> I’m curious if it’s possible operate against values in distributed counters 
>> via Yokozuna. Here’s an example result I get from performing a query, but I 
>> don’t see what field the value is getting set to. The value should be 80840.
>> 
>> curl 
>> 'http://localhost:8098/search/stats?rows=10&q=_yz_id:this_is_a_test*&wt=json&indent=true&face=true&stats=on&stats.field=_yz_id'
>> 
>> "response":{"numFound":1,"start":0,"maxScore":1.0,"docs":[
>> {
>> "_yz_id":"this_is_a_test_30",
>> "_yz_rk":"this_is_a_test",
>> "_yz_rb":"stats"}]
>> },
>> "stats":{
>> "stats_fields":{
>> "_yz_id":{
>> "min":"this_is_a_test_30",
>> "max":"this_is_a_test_30",
>> "count":1,
>> "missing":0,
>> "facets":{}
>> ___
>> riak-users mailing list
>> riak-users@lists.basho.com (mailto: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

Re: Yokozuna Search On Counters

[Mark Phillips]

Hi Wes,


On Thu, Nov 7, 2013 at 7:50 PM, Weston Jossey wrote:

> Thanks Sam (and Eric who PM’d me).
>
> Well, I’ll put in my 2cents that I’d love that feature.  We’re already
> using counters, and adding yokozuna on top of it would be really useful.
>
>
Can you elaborate on what you're doing with counters?  I'm mainly curious
(and we're pretty excited about people using them so any use case details
you could spare would be interesting and helpful).

Mark



> -Wes
>
> On Nov 7, 2013, at 10:47 PM, Sam Elliott  wrote:
>
> > Weston,
> >
> > We don't yet have an extractor written for Yokozuna to support Riak
> 1.4's Counter Data Type. We hope (but obviously can't guarantee) to have
> extractors for all the Data Types we release with Riak 2.0.
> >
> > Sam
> >
> > --
> > Sam Elliott
> > Engineer
> > sam.elli...@basho.com
> > --
> >
> >
> > On Thursday, 7 November 2013 at 10:33PM, Weston Jossey wrote:
> >
> >> Evening Everyone,
> >> I’m curious if it’s possible operate against values in distributed
> counters via Yokozuna. Here’s an example result I get from performing a
> query, but I don’t see what field the value is getting set to. The value
> should be 80840.
> >>
> >> curl '
> http://localhost:8098/search/stats?rows=10&q=_yz_id:this_is_a_test*&wt=json&indent=true&face=true&stats=on&stats.field=_yz_id
> '
> >>
> >> "response":{"numFound":1,"start":0,"maxScore":1.0,"docs":[
> >> {
> >> "_yz_id":"this_is_a_test_30",
> >> "_yz_rk":"this_is_a_test",
> >> "_yz_rb":"stats"}]
> >> },
> >> "stats":{
> >> "stats_fields":{
> >> "_yz_id":{
> >> "min":"this_is_a_test_30",
> >> "max":"this_is_a_test_30",
> >> "count":1,
> >> "missing":0,
> >> "facets":{}
> >> ___
> >> riak-users mailing list
> >> riak-users@lists.basho.com (mailto: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

Advice on commit hooks

[Mark A. Basil, Jr.]

Good morning.

 

First I would like to introduce myself as the FNG.  Hi there.

 

In attempting to solve a problem with a particular relational database, I
realized that the solution was simply to avoid the problem.  Long story
short, research led me to Riak, and I'm quite glad that it did.  I have a
question regarding Links and Link Traversal.  Can Links span buckets?  

 

Is the following possible?  If so, are cross-bucket links the best method
for these relationships?

 

/riak/dishes/saucer_a   -- with
; "member_of"

/riak/dishes/dish_a-- with
; "member_of"

/riak/dishes/bowl_a   -- with
; "member_of"

 

/riak/combos/dish_set_a-- with
;
"member_of"

/riak/combos/place_setting_a -- with
; "includes"

 

If the above is both possible and appropriate -- how might one implement a
commit hook that, when a link is added to an item that defines an "includes"
relationship, the "member_of" relationship is automatically added?

 

-m

___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com