For database, the motivation is increased disk i/o and IOPS beyond what current solutions allow. In addition to the Violin device, we're looking at other flash, ram and SSD technologies, but these are admittedly bleeding edge. We've already done all the other stuff to get better performance out of our db, and if we could get the dbs running on this super-fast storage, we think it's worth examining.
For memcache, it's examining how to scale a large memcache farm. Our current needs are for 512Gb-1Tb of memcache. Right now that looks like 8-16U of servers, vs 3U for the Violin. The Violin people say that when you factor in the operational costs (space, power, etc) their solution saves money. Why do you think I would lose my disk blocks randomly on a fast block device? According to their specs, it's got a RAID5-like design so you can lose memory boards without dropping data. Lest anyone think this is an ad for the device, it's not. I have yet to see one, but I'm sure someone here has looked at it before? Thanks. Dan On Sat, Oct 25, 2008 at 11:28 PM, Brad Fitzpatrick <[EMAIL PROTECTED]> wrote: > That sounds like a terrible idea. > I was going to leave it at that, but I'll elaborate: > > * memcached is a cache. do you want to lose your disk blocks randomly? > > * if you just want fast database slave replicas and don't care about > reliability, there are already in-kernel memory filesystems and memory block > devices. you'll get much more memory efficiency over those, as there won't > be per-item overhead and internal fragmentation. (admittedly you could tune > memcached's slab sizes to the size of your blocks, but you'd still have > per-item overhead, both memory and CPU wise maintaining the LRUs, etc) > > So uh, yeah.... I don't get your motivation. > > > On Sat, Oct 25, 2008 at 8:08 PM, Dan Simoes <[EMAIL PROTECTED]> wrote: > >> I'm curious as to what results people have had with the block device >> driver that is in the community branch (or so I've been told). We're >> looking at the Violin Memory device, primarily for DB storage, but it may >> have interesting applications for memcache as well. >> >> Thanks. >> >> Dan >> > >
