1) What are your requirements in terms of data durability? If we are talking write failures, then family 1 can have some loss in durability. My caching layer has a write behind cache that already trades a few seconds of durability on node failure for the ability to buffer writes to the backend. And for a rather significant part of the data in certain types of games that is acceptable.
2) Do you have real hardware? Large games mostly yes. Small games no. 3) Do you the capability to use SSDs? Yes 4) What's the size of your total keyspace? What about your working set? For larger games total keyspace would probably range from 10-40 million keys. For a stable game with 10 million keys, I'd say an average might be around 200k active keys. But a number of things can make that number swing up wildly over short periods of time. Launch week, promotions, etc.. Also, it's worth noting that some values will increase in size over time as players collect more and more items. 5) Do you need atomic, multi-key updates? Will always have a small set of stuff that requires this. Chris On Tue, Sep 30, 2014 at 11:53 PM, snacktime <snackt...@gmail.com> wrote: > I'm going to be testing out Riak for use in an open source game server > platform I created, and was looking for some tips on use and configuration. > > Read/write volumes as are normal for many games, is about 50/50. > Consistent response times with low latency is a priority, as is not having > eventually consistent get out of control like with what can happen with > that 'other' nosql db (ya another horror story not worth going into here). > > The data being saved would be a combination of json and binary. It's > protocol buffers and I provide the option to serialize to json or native > protobuf. > > Currently all keys are compound. A scope followed by a delimiter followed > by the actual key. > > Usage patterns basically break down into two groups. One is data that can > change up to several times a second. Local caching is available, but > updates to the database every few seconds would be required. > > The other class of data does not change that often, and in some cases > requires atomic updates. This would be in game trading, etc.. > > > Any tips people have on getting the most out of Riak for this type of > environment would be appreciated. > > Chris >
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
