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 <jose...@gmail.com> 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 <ano...@google.com> wrote: >> Wow, great work. Thanks Anthony. >> >> On 21 January 2011 16:53, Anthony Watkins <awatkin...@gmail.com> 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 <jose...@gmail.com> 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 >>> > <michael.macfad...@gmail.com> 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 wave-dev@incubator.apache.org list, >>> which is >>> > >> where all future discussion should occur. >>> > >> >>> > >> Alex >>> > >> >>> > >> On 11 January 2011 02:20, faisalbhagat <faisalbha...@gmail.com> >>> 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 wave-proto...@googlegroups.com. >>> > >>> To unsubscribe from this group, send email to >>> > >>> wave-protocol+unsubscr...@googlegroups.com<wave-protocol%2bunsubscr...@googlegroups.com> >>> <wave-protocol%2bunsubscr...@googlegroups.com<wave-protocol%252bunsubscr...@googlegroups.com> >>> > >>> > >>> . >>> > >>> 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 wave-proto...@googlegroups.com. >>> > > To unsubscribe from this group, send email to >>> wave-protocol+unsubscr...@googlegroups.com<wave-protocol%2bunsubscr...@googlegroups.com> >>> . >>> > > For more options, visit this group at >>> http://groups.google.com/group/wave-protocol?hl=en. >>> > > >>> > > >>> >> >
