41–50 of 57 posts
MVCC does not provide serializability of transactions without a bit more work. Since when can you get away without giving guaranties about what you support?
I agree that MVCC does not itself guarantee transaction isolation, but FoundationDB does indeed do the "bit more work" to guarantee all of the ACID properties.
Does it use locking? Does it use something like PostgreSQL's new SSI? Does it write the read timestamps to the database on reads? Something else?
First:
"FoundationDB Beta 1 is ready for production use."
Then:
"The community edition will include the full capabilities of FoundationDB and will allow production deployment."
Finally:
"FoundationDB grants you a...revocable license...for test purposes only in a non-production environment"
Earlier quoted context omitted.
FoundationDB founder here. We think that it's awesome that RavenDB also supports multi-node ACID transactions. However, on page 9 of https://s3.amazonaws.com/daily-builds/RavenDBMythology-11.pd... they warn against relying on this capability: "RavenDB supports multi document (and multi node) transactions, but even so, it isn’t recommended for common use, because of the potential for issues when using distributed tran…
That remark seems a bit unfair. That document is two years old, from long before version 1.0. RavenDB is now at version 2.0. It was also built with transaction support from the start. The default setting for TransactionMode is Safe ( http://ravendb.net/docs/server/administration/configuration ) so most users will use that, if there were any issues with it that would certainly be known by now.
I see C, node, ruby, and Java support...any plans for a .NET API as well? This seems like something that would be nice to mess around with there. Would also be nice to understand what the intended pricing model will be (if any). If the plans are to keep this free, that would be pretty great.
"We will offer FoundationDB as both a free community edition and a licensed version with support and larger cluster capability. The community edition will include the full capabilities of FoundationDB and will allow production deployment. FoundationDB licenses will have reasonable and linear pricing. The license cost for a cluster, including support, will be similar to the operational cost of the commodity hardware i…
@Dave_Rosenthal can you address the licensing? I'd consider porting a nontrivial application if the terms were agreeable. I'm a little confused, though. First: "FoundationDB Beta 1 is ready for production use." Then: "The community edition will include the full capabilities of FoundationDB and will allow production deployment." Finally: "FoundationDB grants you a...revocable license...for test purposes only in a non-…
If you are interested in using FoundationDB Beta in production today (as some of our customers are) you should give us a call. We can get you a license for production use and support at a very reasonable cost.
For better or worse, after being in this industry for a long time now all I can say about a new database launch is: cool, I'd love to talk to you in 3-5 years when you've had time to work out the hinks and people have figured out what your strengths and weaknesses are and where the real gotchas will getcha.
Until then: good luck. A distributed, linearly scalable, easy-to-admin NoSQL database with transaction support and full ACID would be delicious indeed.
Earlier quoted context omitted.
That remark seems a bit unfair. That document is two years old, from long before version 1.0. RavenDB is now at version 2.0. It was also built with transaction support from the start. The default setting for TransactionMode is Safe ( http://ravendb.net/docs/server/administration/configuration ) so most users will use that, if there were any issues with it that would certainly be known by now.
The current RavenDB documentation still warns against using "system transactions" because of performance reasons ( http://ravendb.net/docs/client-api/advanced/transaction-supp... ), so I think it is still fair to say that RavenDB was not designed for applications requiring high performance cross node transactions.
The Flow language they implemented for this is interesting. http://www.foundationdb.com/white-papers/flow/ I think we are going to see eventual consistency deflate as people relearn to love transactions. SQL also makes users of a database a lot more productive. The bottom line is you don't want your devs spending time and effort reasoning about database behavior, you want them focusing on business logic. In 5 years h…
FoundationDB founder here. Flow sounds crazy. What hubris to think that you need a new programming language for your project? Three years later: Best decision we ever made. We knew this was going to be a long project so we invested heavily in tools at the beginning. The first two weeks of FoundationDB were building this new programming language to give us the speed of C++ with high level tools for actor-model concurr…
Is Debian 6 supported?
I really want to be excited by this. For better or worse, after being in this industry for a long time now all I can say about a new database launch is: cool, I'd love to talk to you in 3-5 years when you've had time to work out the hinks and people have figured out what your strengths and weaknesses are and where the real gotchas will getcha. Until then: good luck. A distributed, linearly scalable, easy-to-admin NoS…
- Known limitations (http://foundationdb.com/documentation/beta1/known-limitation...)
- Anti-features (http://foundationdb.com/white-papers/anti-features/)
- Performance considerations (http://foundationdb.com/documentation/beta1/developer-guide....)
Talk to you in a few years :)