Re: How to increase Riak write performance for sequential alpha-numeric keys

I failed to mention these links that give additional details concerning the timed grooming feature: discussion of the timed grooming feature is here: https://github.com/basho/leveldb/wiki/mv-timed-grooming discussion of the timed grooming fix and disable is here: https://github.com/bas

Re: How to increase Riak write performance for sequential alpha-numeric keys

Alex, I am making a guess. I would be better able to support this guess with data from leveldb LOG files of one server. The performance difference between the sequential keys and the reverse of the sequential keys is informative. The reverse ordered keys essentially become more like "random

Riak TS is now available as open source

Basho Riak® TS , a distributed NoSQL database architected to aggregate and analyze massive amounts of sequenced, unstructured time series data, is now available as an Open Source database. See the blog

Re: How to increase Riak write performance for sequential alpha-numeric keys

Hello, Leveldb is a sorted backend by key name (and bucket.) I don't know the details on exactly how it does the sort but there may be considerations there. Another question is why is your ring size 128 on a 3 node cluster? Ring size determines the number of virtual nodes in the cluster which are

Re: How to increase Riak write performance for sequential alpha-numeric keys

Alex, This is why I was requesting you run "riak-debug" on one server. I would like to look at the leveldb LOG files before guessing and/or offering other solutions. I have a guess but would like to confirm it with supporting evidence from the LOG file. Matthew > On May 5, 2016, at 10:11 A

Re: How to increase Riak write performance for sequential alpha-numeric keys

On 5 May 2016, at 15:11, alexc155 wrote: > Hi, > > Thanks for your reply. > > I don't think that write_once is going to work for us as we have to > periodically update the data (although if we remove the data before > re-inserting it, would that work?) > > Why does read-before-write slow down

Re: How to increase Riak write performance for sequential alpha-numeric keys

It's version 2.1.3 -- View this message in context: http://riak-users.197444.n3.nabble.com/How-to-increase-Riak-write-performance-for-sequential-alpha-numeric-keys-tp4034219p4034227.html Sent from the Riak Users mailing list archive at Nabble.com. __

Re: How to increase Riak write performance for sequential alpha-numeric keys

Hi, Thanks for your reply. I don't think that write_once is going to work for us as we have to periodically update the data (although if we remove the data before re-inserting it, would that work?) Why does read-before-write slow down new writes so much? Some new information we've found - it se

Re: How to increase Riak write performance for sequential alpha-numeric keys

On 5 May 2016, at 14:42, Sanket Agrawal wrote: > > On Thu, May 5, 2016 at 9:28 AM, Russell Brown wrote: > CRDTs are all about mutation, why would you use a CRDT for immutable data? I > think write-once is what you need. > > No particular reason - most likely ignorance on my part, I think :)

Re: How to increase Riak write performance for sequential alpha-numeric keys

On Thu, May 5, 2016 at 9:28 AM, Russell Brown wrote: > CRDTs are all about mutation, why would you use a CRDT for immutable data? > I think write-once is what you need. No particular reason - most likely ignorance on my part, I think :) Basho documentation mentioned modeling the data as CRDT if

Re: How to increase Riak write performance for sequential alpha-numeric keys

CRDTs are all about mutation, why would you use a CRDT for immutable data? I think write-once is what you need. On 5 May 2016, at 14:14, Sanket Agrawal wrote: > Two questions about write-once bucket: > - is it useful from performance-perspective for immutable CRDTs as well? > - If the objects

Re: How to increase Riak write performance for sequential alpha-numeric keys

Two questions about write-once bucket: - is it useful from performance-perspective for immutable CRDTs as well? - If the objects are immutable, is map CRDT generally performant, compared to equivalent JSON with write-once property? Let us say map has 1-9 registers with about 2KB size total in strin

Re: How to increase Riak write performance for sequential alpha-numeric keys

Alex, The successor to "last_write_wins" is the "write_once" bucket type. You can read about its characteristics and limitations here: http://docs.basho.com/riak/kv/2.1.4/developing/app-guide/write-once/ This bucket typ

How to increase Riak write performance for sequential alpha-numeric keys

We're using Riak as a simple key value store and we're having write performance problems which we think is due to the format of our keys which we can't easily change because they're tied into different parts of the business and systems. We're not trying to do anything complicated with Riak: No solr