Re: Running riak from launchd?

2012-05-26 Thread Will Moss
That doesn't seem like it solves the problem. launchd (and other tools like it) don't want processes to daemonize themselves (which is what riak start does). Is there a blessed way to run Riak not daemonized? Will On Sat, May 26, 2012 at 11:34 AM, Kelly McLaughlin wrote: > Hi Izzy. Use riak st

Re: Geospatial advice?

2012-05-01 Thread Will Moss
I remember someone once going on a rant about how there's no silver bullet database (If you have not read this, do so), so I'm, of course, going to agree Sean. If you're going to need to run this on more than one machine then go

Re: is there easy way to transfer mongo collections to riak?

2012-02-23 Thread Will Moss
Hey Dominik, To answer the question in your subject line, no. To quote one of the guys I work with, "You're the bitch of data." That said, I'm extremely happy we did it. Riak does what it says it's going to do when it says it will and doesn't seem to really ever go down. I can't say the same for M

Re: load balancing protocol buffers clients

2012-02-01 Thread Will Moss
We've used haproxy and have no complaints. On Feb 1, 2012 9:12 AM, "Marc Campbell" wrote: > Hi everyone, > > I'm looking to put a load balancer in front of my riak cluster but not > sure which one will work. I'm using both the HTTP interface and the > protocol buffers client. My connections fro

Re: SSDs instead of SAS.

2012-01-09 Thread Will Moss
I don't have any exact statistics, but I'm willing to personally guarantee you will not be disappointed. Both Riak back ends are essentially doing random IO, and in practice we've found our disks to be entirely bounded by seek time. Will On Mon, Jan 9, 2012 at 3:05 PM, David McNicholl wrote: >

Re: best practices for testing eventual consistency?

2011-11-15 Thread Will Moss
Hey Jesse, You should do all of those things, more testing of a database is always good! To answer your specific question though, one of the easiest ways to produce conflicts is just to create multiple new values (i.e. values with no vector clocks). In that case, Riak can't possible resolve them

Re: Map Reduce Requirements

2011-08-22 Thread Will Moss
Hey Bill, If you write an Erlang MR, you are just given the raw bucket data, so there's no reason you shouldn't be able to do it. That said, I've never done it, but would be really interested if you figure it out. Will On Mon, Aug 22, 2011 at 11:51 AM, bill robertson wrote: > In order to run a

Re: GET vs map reduce

2011-08-19 Thread Will Moss
It seems like this is a problem that can be solved without too much headache by the client library. If you're working in an asynchronous environment then forking off n green threads for each get and collecting the results is no problem (this is what we do with great results). In a traditionally thr

Re: NoSQL combinations - what works best?

2011-08-09 Thread Will Moss
Apparently Antirez is currently working on a cluster solution to Redis, but in the meantime, he's written a good blog post about how to get around the issues: http://antirez.com/post/redis-presharding.html TL;DR: Redis is light-weight, so just run a bunch of instances on one machine and ring hash

Re: NoSQL combinations - what works best?

2011-08-09 Thread Will Moss
g.com - <http://www.loomlearning.com/> > www.loomlearning.com - Skype: intel352 > * > > > On Tue, Aug 9, 2011 at 12:59 PM, Will Moss < wm...@bu.mp>wrote: > >> We've used Redis for many things, including as a cache in front of S3 and >> Riak. Redis allow

Re: NoSQL combinations - what works best?

2011-08-09 Thread Will Moss
We've used Redis for many things, including as a cache in front of S3 and Riak. Redis allows you to set it's maximum memory and various eviction schemes (including LRU, which works great for a cache). In our application code we try to fetch from Redis, if it's missing, we restore from Riak (or S3)

Re: How much memory for 20GB of data?

2011-07-14 Thread Will Moss
In that case, Riak adds a minimum of around 500 bytes of overhead per record, but that can grow as the size of the vector clock grows. As Justin mentioned, if N = 3 you'll be storing three copies of the data, so you need at least 60G, but probably closer to 90G. On Thu, Jul 14, 2011 at 4:13 PM, M

Re: How much memory for 20GB of data?

2011-07-14 Thread Will Moss
If you're planning on using bitcask, this site should be helpful: http://wiki.basho.com/Bitcask-Capacity-Planning.html Innostore and LevelDB store the keys on disk, so the minimum overhead would be quite small. On Thu, Jul 14, 2011 at 3:02 PM, Maria Neise wrote: > Hey, > I would like to store 2

Re: LevelDB driver

2011-07-11 Thread Will Moss
Hey Justin/Dave, I know you guys are busy working on various new features, is this going to make it into the next production release? Is there a date for that? Is there somewhere to look at your road map so I don't have to spam the list? Thanks, Will On Mon, Jul 4, 2011 at 7:41 AM, Justin Sheeh

Re: LevelDB driver

2011-07-01 Thread Will Moss
Hey Dave, This is very cool--glad you guys decided to bundle this in. The linked post and the Google Code page both suggest that it will have a much more efficient on-disk representation than InnoDB, do you have an specific numbers on overhead per key? Thanks, Will On Fri, Jul 1, 2011 at 9:03 A

Re: Pros/Cons to not storing JSON

2011-06-14 Thread Will Moss
ype is BSON? Does the js engine > already have BSON support included? > > - Jon Langevin -- sent from my Android phone > On Jun 14, 2011 12:47 PM, "Will Moss" wrote: > > I still haven't had a chance to try out using BSON for a map-reduce, but > in > > genera

Re: Pros/Cons to not storing JSON

2011-06-14 Thread Will Moss
arning.com/> > * Jonathan Langevin > Systems Administrator > Loom Inc. > Wilmington, NC: (910) 241-0433 - jlange...@loomlearning.com - > www.loomlearning.com - Skype: intel352 * > > > > On Thu, Jun 9, 2011 at 5:26 PM, Will Moss wrote: > >> Hey Andrew, >> >

Re: Pros/Cons to not storing JSON

2011-06-09 Thread Will Moss
Hey Andrew, We're using BSON (bsonspec.org), because it stores binary (and other) data types better than JSON and is also faster and more wire efficient (sounds like about the same reasons you're considering leaving JSON). There are also libraries to parse BSON it in just about every language. I