Wow, great work. Thanks Anthony. On 21 January 2011 16:53, Anthony Watkins <[email protected]> wrote:
> 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]> > <wave-protocol%[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]<wave-protocol%[email protected]> > . > > > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > > > > > > >
