Jordon,

I used the ETS backend with success while working @ AOL.  In my case I was
using it to cache ~100K, short lived (hours), largish objects.

I'm confused because you said you don't care if you lose data, but one of
Riak's main strengths is to do everything possible to avoid data loss.
 Perhaps something like memcached is more suitable?

-Ryan

On Thu, Jun 2, 2011 at 1:20 PM, Jordan West <jw...@makingfun.com> wrote:

> Mark,
>
> Thanks for the reply. I saw couple other postings related to the ETS
> backend on the list so I decided to start prototyping a bit with it but I
> haven't decided if its the solution I'm looking for yet. I'll see you
> tuesday at the IGN offices for the meetup.
>
> Jordan
>
>
> On Thu, Jun 2, 2011 at 9:58 AM, Mark Phillips <m...@basho.com> wrote:
>
>> Hey Jordan,
>>
>> To address a few of your questions:
>>
>> While it's not the most optimal memory-only backend, ETS is certainly
>> usable in production.  That said, if it runs out of gas on you at
>> larger scales, it wouldn't be that hard to write a better one using
>> the NIF interface.
>>
>> Hope that helps.
>>
>> Mark
>>
>> On Thu, May 26, 2011 at 11:15 AM, Jordan West <jw...@makingfun.com>
>> wrote:
>> > Hi all,
>> > I'm posting to the list for the first time after talking with Mark
>> > (ironically, at MongoSF the other day), about a use-case I'm considering
>> > Riak for. Quickly, I should probably say I've only played with Riak on a
>> > side project or two, and dabbled with Riak Core thanks to the new GitHub
>> > blog. Part of the reason I'm writing the list is to determine if for my
>> > use-case its worth investing significant time learning and prototyping
>> some
>> > possible implementations with Riak(-Core). Anyways, on to the question:
>> > Is the ETS Backend in the riak_kv repo something maintained and endorsed
>> for
>> > use by the Basho team? I have a dataset which is well suited for a k/v
>> store
>> > and needs to be eventually consistent across a cluster of Erlang
>> nodes. Riak
>> > crossed my mind because of those reasons. Also, being able to embed it
>> into
>> > my application like Mnesia is a plus. However, I could care less in this
>> > case about losing data. The data is ephemeral anyways as its a map of a
>> > string assigned per connection to a couple erlang process ids, and hence
>> I
>> > want to store it in-memory (also want it in memory for performance
>> reasons).
>> > This data is very read-heavy, but must be available for writes or new
>> > connections will begin to fail. I know this is not a typical use for
>> Riak,
>> > since one of its most touted benefits is not losing data but would it be
>> too
>> > far of a stretch to use Riak as an eventually consistent, in-memory
>> > key-value store embedded into an Erlang application? If not, I figure
>> this
>> > is something I could build with Riak Core. Does anyone know if there
>> already
>> > is a OSS project I could contribute to instead of starting from scratch
>> in
>> > that case?
>> > Thanks for your help,
>> > Jordan West
>> >
>> >
>> > _______________________________________________
>> > 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

Reply via email to