Does it tell you when your data is safely committed to disk? WIAB requires this, and as far as I know cassandra doesn't provide such an event.
-J On Sat, Jan 22, 2011 at 3:08 AM, Tad Glines <[email protected]> wrote: > Has anyone taken a look at Casandra? > > I've looked at it a little bit because there is a project called > Lucandra that implements Lucene on top of Casandra. Casandra is a > column order DB that provides configurable (at operation time) levels > of persistence guarantees. The main options are (ONE, QUORUM, and ALL) > where the operation doesn't return until the data has been persisted > at one, a quorum or all Cassandra instances. > > -Tad > > On Thu, Jan 20, 2011 at 10:44 PM, Joseph Gentle <[email protected]> wrote: >> Yeah - great to know. May as well just stick with mongodb then. >> >> Cheers! >> >> -J >> >> >> On Fri, Jan 21, 2011 at 5:21 PM, Alex North <[email protected]> wrote: >>> 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. >>>> > > >>>> > > >>>> >>> >> >
