5 ms·

I think you mean Partition Tolerance. I would ask you whether you've actually read the proof, but that question seems redundant.

btilly 17y ago
You're right that I did mean partition tolerance. And yes, I've read the proof, but that was about a year and a half ago.
- jbooth 17y ago
  Whatever, it was obvious what you meant -- if someone has the choice of either figuring what you mean and addressing your question, or changing the subject with defensive pedantry, and chooses the latter, it may say something about their argument.
  - justinsb 17y ago
    Actually, in the distributed database field, 'partitionable on the fly' makes a lot of sense. I used this to infer the poster wasn't really familiar with the CAP theorem (which is only formally expressed in the proof), but it seems this wasn't fair in this case. The big problem with the CAP theorem is trying to decide what on earth C, A and P _really_ mean. Sounds like I need to do a blog post...
moe 17y ago
So, ad hominem attacks aside, which tradeoff did you make for your product, or did you find a way to sidestep the problem altogether? I mean, you're announcing this thing like the 8th world wonder ("The end of NoSQL") and seem to have no problem comparing yourself to Oracle, no less. Do you have anything to show for it? Or At least a date when you will show us something?
- justinsb 17y ago
  The reason why I mentioned Oracle in the demo is precisely because of the whole CAP debacle. So many people talk about CAP as if the SQL database was itself an impossibility, much less Oracle's scalable offering - but you can pick up the phone and an Oracle salesperson will sell you the physical device that you're implying can't exist. So, if somebody misquotes the CAP theorem, it's an indication to me that perhaps the thread isn't going to go anywhere. I'll point them to the place where they can read about it (the proof was where the CAP theorem was formalized, not Eric Brewer's original presentation), and move on. In this case, that wasn't fair to btilly, who just made a typo. So, as I said in the presentation and elsewhere here, if you have a hair-on-fire problem with scaling your database, and are willing to be an early customer of our new database, and would make a good reference customer in a few months, we'd love to work with you today. Otherwise, you'll have to wait till we open it up more widely.
  - moe 17y ago
    but you can pick up the phone and an Oracle salesperson will sell you the physical device that you're implying can't exist. Well, thing is, part of your claim (if I understood it correctly) is that I just throw my data and my queries at your wonder-device and it will magically be fast and scale. You never mention any special care I must take, you even explicitly say it's not partitioning. This is decidedly not the case with what said Oracle salesperson will sell to me. The sale will normally include an expensive support-contract and probably a dedicated DB Admin. Because operating a RAC- or Exadata Cluster is, for all I know, far from trivial. You still have to make a bunch of critical decisions and tradeoffs upfront or it will probably suck. Moreover you're effectively saying that you solved what Amazon and Google either couldn't or didn't bother to solve with their SimpleDB and Appengine Datastore offerings. Still sounds like quite a bold claim to me. But as said elsewhere, I appreciate that you're standing by it and will keep looking forward to what you will unveil. Just one more thing that I really don't understand: If you have this doomsday device at your hands, then why on earth do you bother with MySQL hosting as a secondary product?
    - gfodor 17y ago
      You're misreading his argument or are being deliberately obtuse. The fact that you can scale the relational model using Oracle's software, with or without a support contract or appropriate tuning measures, is sufficient evidence to invalidate the claim that many make that the relational model does not scale. The relational model != ACID. The relational model != SQL. The relational model has nothing in it implicitly that ruins it's ability to obey CAP. You are right, that you will have to make some consistency tradeoffs to get partition tolerance. Again, to repeat, this has nothing to do with the relational model itself, just with the CAP theorem. Just because it is hard to build a RDBMS that loosens ACID but scales and is much easier to build a ad-hoc non-formally-defined model like that seen in Cassandra or BigTable does not mean it is impossible. You simply have to pay for it, in software, hardware, and consulting fees. Nothing is stopping the open source world from making PostgreSQL or MySQL scale out other than time, energy, and perhaps a seminal paper or two out of acadamic that provide foundational models that are necessary to implement it correctly. Odds are, they've done this work at Oracle, but it's not available for obvious reasons.
deleted 17y ago
[deleted]

btilly 17y ago

You're right that I did mean partition tolerance. And yes, I've read the proof, but that was about a year and a half ago.

jbooth 17y ago
Whatever, it was obvious what you meant -- if someone has the choice of either figuring what you mean and addressing your question, or changing the subject with defensive pedantry, and chooses the latter, it may say something about their argument.
- justinsb 17y ago
  Actually, in the distributed database field, 'partitionable on the fly' makes a lot of sense. I used this to infer the poster wasn't really familiar with the CAP theorem (which is only formally expressed in the proof), but it seems this wasn't fair in this case. The big problem with the CAP theorem is trying to decide what on earth C, A and P _really_ mean. Sounds like I need to do a blog post...

moe 17y ago

So, ad hominem attacks aside, which tradeoff did you make for your product, or did you find a way to sidestep the problem altogether? I mean, you're announcing this thing like the 8th world wonder ("The end of NoSQL") and seem to have no problem comparing yourself to Oracle, no less. Do you have anything to show for it? Or At least a date when you will show us something?

justinsb 17y ago
The reason why I mentioned Oracle in the demo is precisely because of the whole CAP debacle. So many people talk about CAP as if the SQL database was itself an impossibility, much less Oracle's scalable offering - but you can pick up the phone and an Oracle salesperson will sell you the physical device that you're implying can't exist. So, if somebody misquotes the CAP theorem, it's an indication to me that perhaps the thread isn't going to go anywhere. I'll point them to the place where they can read about it (the proof was where the CAP theorem was formalized, not Eric Brewer's original presentation), and move on. In this case, that wasn't fair to btilly, who just made a typo. So, as I said in the presentation and elsewhere here, if you have a hair-on-fire problem with scaling your database, and are willing to be an early customer of our new database, and would make a good reference customer in a few months, we'd love to work with you today. Otherwise, you'll have to wait till we open it up more widely.
- moe 17y ago
  but you can pick up the phone and an Oracle salesperson will sell you the physical device that you're implying can't exist. Well, thing is, part of your claim (if I understood it correctly) is that I just throw my data and my queries at your wonder-device and it will magically be fast and scale. You never mention any special care I must take, you even explicitly say it's not partitioning. This is decidedly not the case with what said Oracle salesperson will sell to me. The sale will normally include an expensive support-contract and probably a dedicated DB Admin. Because operating a RAC- or Exadata Cluster is, for all I know, far from trivial. You still have to make a bunch of critical decisions and tradeoffs upfront or it will probably suck. Moreover you're effectively saying that you solved what Amazon and Google either couldn't or didn't bother to solve with their SimpleDB and Appengine Datastore offerings. Still sounds like quite a bold claim to me. But as said elsewhere, I appreciate that you're standing by it and will keep looking forward to what you will unveil. Just one more thing that I really don't understand: If you have this doomsday device at your hands, then why on earth do you bother with MySQL hosting as a secondary product?
  - gfodor 17y ago
    You're misreading his argument or are being deliberately obtuse. The fact that you can scale the relational model using Oracle's software, with or without a support contract or appropriate tuning measures, is sufficient evidence to invalidate the claim that many make that the relational model does not scale. The relational model != ACID. The relational model != SQL. The relational model has nothing in it implicitly that ruins it's ability to obey CAP. You are right, that you will have to make some consistency tradeoffs to get partition tolerance. Again, to repeat, this has nothing to do with the relational model itself, just with the CAP theorem. Just because it is hard to build a RDBMS that loosens ACID but scales and is much easier to build a ad-hoc non-formally-defined model like that seen in Cassandra or BigTable does not mean it is impossible. You simply have to pay for it, in software, hardware, and consulting fees. Nothing is stopping the open source world from making PostgreSQL or MySQL scale out other than time, energy, and perhaps a seminal paper or two out of acadamic that provide foundational models that are necessary to implement it correctly. Odds are, they've done this work at Oracle, but it's not available for obvious reasons.

deleted 17y ago

[deleted]