I've recently looked into Redis for a different project and I don't
think it will meet the needs of the wave server, mostly because of the
amount of memory it requires and its deficiencies with persistence.

Here are some of the articles I came across during my investigation:
http://blog.mjrusso.com/2010/10/17/redis-from-the-ground-up.html#heading_toc_j_9
http://blog.kennejima.com/post/1226487020/thoughts-on-redis
http://antirez.com/post/a-few-key-problems-in-redis-persistence.html

All of the authors are fans of Redis, but come to the same overall
conclusion: "In short: the strength is the data model, and the
deficiency is the persistence."

A few highlights from these articles:

- "Redis requires that the whole dataset be loaded into main memory at
all times. (Redis Virtual Memory, which we’ll discuss later, relaxes
this requirement, but still needs all keys to always be in memory.).
Guaranteed in-memory access to most of the dataset is Redis' main
performance driver — and is also responsible for creating its main
limitations."

- "The amount of RAM that Redis needs is proportional to the size of
the dataset. Large datasets in Redis are going to be fast, but
expensive."

- "Redis persistence is highly configurable but the implementation
makes extremely heavy use of I/O resources. Furthermore, most save
operations require additional memory to complete successfully, and, in
some cases, asynchronous saves can block the server for lengthy
periods of time."

- "my recommended setup is: Use Redis for small datasets that don’t
grow fast (stay far less than 1GB). Have at least 2x memory than the
dataset. Use default snapshotting and disable AOF."

On a related note mongodb will have single server durability in
version 1.8, the release candidate of which is scheduled for January
28th. I imagine by the time we implement any other non file based
persistence solution for wave, mongodb will have satisfied its biggest
negative for use in wave.

I am fully in favor of multiple persistence solutions being available
to the community, so I am not trying to be discouraging.  Just sharing
what I've recently encountered.

R,

Anthony

On Thu, Jan 20, 2011 at 7:37 PM, Joseph Gentle <[email protected]> wrote:
>
> If we want to stick to nosql databases, redis might be worth a look.
> Redis supports transactions and it has a synchronous save operation.
>
> -J
>
>
> On Tue, Jan 11, 2011 at 1:59 PM, Michael MacFadden
> <[email protected]> wrote:
> > This has come up several times.  Tad Glines and I have talked about this a 
> > few times on the forum.  I the idea would be to implement a SQL DB 
> > persistence layer via JPA and/or apache JDO.  Tad has a bit of a schema 
> > design worked up, which I am sure he could re-post if necessary.  I think 
> > we were hoping the the file based implementation would stabilize a bit 
> > before starting on the SQL DB implementation, since as Alex mentions they 
> > are working out some core issues.  Also we would likely step on each others 
> > toes.
> >
> > ~Michael
> >
> > On Jan 10, 2011, at 5:17 PM, Alex North wrote:
> >
> >> Soren and I are currently working on file-based persistence. The final
> >> hookup is currently held up behind bugs it exposed in other parts of the
> >> system, which I'm fixing now.
> >>
> >> The filesystem based persistence demonstrates what would be required of
> >> another datastore implementation. There's been some talk about hooking up 
> >> an
> >> SQL layer but I don't believe anyone's designing it yet.
> >>
> >> That talk may have been on the [email protected] list, which is
> >> where all future discussion should occur.
> >>
> >> Alex
> >>
> >> On 11 January 2011 02:20, faisalbhagat <[email protected]> wrote:
> >>
> >>> Is there anyone actively working on waves persistence using some db?
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups
> >>> "Wave Protocol" group.
> >>> To post to this group, send email to [email protected].
> >>> To unsubscribe from this group, send email to
> >>> [email protected]<wave-protocol%[email protected]>
> >>> .
> >>> For more options, visit this group at
> >>> http://groups.google.com/group/wave-protocol?hl=en.
> >>>
> >>>
> >
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Wave Protocol" group.
> > To post to this group, send email to [email protected].
> > To unsubscribe from this group, send email to 
> > [email protected].
> > For more options, visit this group at 
> > http://groups.google.com/group/wave-protocol?hl=en.
> >
> >

Reply via email to