4 ms·

what objections are true? (i've not seen them raised anywhere?)

by pquerna 17y ago

justinsb 17y ago
I meant this comment in a positive way: I genuinely think this is smart marketing. I think the real objections would be things like (and I'm not necessarily saying these are true/false, just that they're the ones that people should really be thinking about): * Are NoSQL databases the object databases of the modern era? * Is our pain big enough that we're willing to be a guinea pig for any new technology? * How will making this technology choice impact our future ability to hire and to work with future technologies? * Is this the right time to adopt a new database, or will the world be so different in 3 months that we should limp along until then? From my viewpoint (@ FathomDB), that last point is the most interesting. We're seeing the start of NoSQL convergence; I expect both rapid development and serious teething issues. We see FathomDB & VoltDB announcing early availability of scalable relational databases. Rackspace hired the core of the Drizzle team, so this project will likely start to bear more fruit. To borrow from the wife-selection problem, it feels like immediately getting married to the first attractive person you meet on your first day at college, when there's a freshman mixer that evening.
- skorgu 17y ago
  None of these can be definitively affirmed or rejected by facts. They're interesting questions but they're either unanswerable (time, oodb) or entirely application dependent (pain, hiring).
  - justinsb 17y ago
    Perhaps not, but this doesn't make them unimportant, and again this is why it's clever marketing. Frame the discussion in terms of things that you do well, even if they're not the most important considerations (e.g. "one keyspace per install"). It's a good sales technique: "Do you like holidays?" "Yes" "Well, now that I know you can say yes, do you want to buy this product?"
  - Semiapies 17y ago
    Nor are they "objections".
    - justinsb 17y ago
      They're certainly fairly big reasons not to use Cassandra, and as such I'd put them in the objections bucket. If you're objecting to the fact that I phrased them as questions, just pretend we're on Jeopardy :-)
      - jbooth 17y ago
        No they're not, a "big reason not to use Cassandra" would be "it has critical bug X" or "it's missing critical feature Y".
- jbellis 17y ago
  I agree that evaluating whether to switch to a solution now, or wait for something even better, is always a question you should ask. But the term "vaporware" exists for a reason. Waiting for something that may or may not be everything it's promised is risky too. The Maglev ruby VM is a good example; they were demo-ing close to 10x performance a couple years ago, but when they finished implementing the fully ruby spec it was something like... 20% faster. A lot can change when you go from demo-ware to a real production ready product. Neither Fathom nor Volt is going to be at Cassandra levels of stability in 3 months. More like a year... if things go well.
  - justinsb 17y ago
    It's you that pointed out that we're on the cusp on NoSQL convergence. I'm sure the end result of that will be better than NoSQL today, but any project merge or convergence of this kind is going to be pretty painful for those using the product along the way. In the meantime, there's at least 3 promising projects that have announced (FathomDB, VoltDB, Drizzle), and I know of a few more as well that aren't public. My decision would be to wait, others may decide to place their bets now. I meant it as a sincere complement - it's good marketing to draw attention to your strengths.
    - jbellis 17y ago
      "any project merge or convergence of this kind is going to be pretty painful for those using the product along the way" Only if you're using one of the non-viable products. So don't do that. :) "there's at least 3 promising projects that have announced (FathomDB, VoltDB, Drizzle)" Drizzle's idea of scale-out is writing a Cassandra backend, fwiw. http://drizzle.org/wiki/CassandraEngine http://drizzle.org/wiki/CassandraEngine
      - justinsb 17y ago
        But last year, CouchDB was the future. Today it's Cassandra. In a few months, it could well be MongoDB or Redis. Even if Cassandra ends up the NoSQL winner, I'm pointing out that you'll have your hands full dealing with 'must have' feature contributions from the 'losing' NoSQL store users, and that this will be painful for existing Cassandra users. As for the Drizzle thing, you've crossed the line into misleading marketing there. There is a plugin to integrate Cassandra as a Drizzle engine, just like there's a plug-in that logs MySQL error messages to Twitter. That doesn't make it the official strategy, nor does it automatically make it a good idea. (Edit: fixed my MongoDB/CouchDB confusion!)
- jbooth 17y ago
  Those aren't criticisms, at least not in a technical sense, they're broad philosophical concerns that apply just about equally to any technology you want to adopt, ever.

what objections are true? (i've not seen them raised anywhere?)

by pquerna 17y ago

what objections are true? (i've not seen them raised anywhere?)

I meant this comment in a positive way: I genuinely think this is smart marketing. I think the real objections would be things like (and I'm not necessarily saying these are true/false, just that they're the ones that people should really be thinking about): * Are NoSQL databases the object databases of the modern era? * Is our pain big enough that we're willing to be a guinea pig for any new technology? * How will making this technology choice impact our future ability to hire and to work with future technologies? * Is this the right time to adopt a new database, or will the world be so different in 3 months that we should limp along until then? From my viewpoint (@ FathomDB), that last point is the most interesting. We're seeing the start of NoSQL convergence; I expect both rapid development and serious teething issues. We see FathomDB & VoltDB announcing early availability of scalable relational databases. Rackspace hired the core of the Drizzle team, so this project will likely start to bear more fruit. To borrow from the wife-selection problem, it feels like immediately getting married to the first attractive person you meet on your first day at college, when there's a freshman mixer that evening.

skorgu 17y ago
None of these can be definitively affirmed or rejected by facts. They're interesting questions but they're either unanswerable (time, oodb) or entirely application dependent (pain, hiring).
- justinsb 17y ago
  Perhaps not, but this doesn't make them unimportant, and again this is why it's clever marketing. Frame the discussion in terms of things that you do well, even if they're not the most important considerations (e.g. "one keyspace per install"). It's a good sales technique: "Do you like holidays?" "Yes" "Well, now that I know you can say yes, do you want to buy this product?"
- Semiapies 17y ago
  Nor are they "objections".
  - justinsb 17y ago
    They're certainly fairly big reasons not to use Cassandra, and as such I'd put them in the objections bucket. If you're objecting to the fact that I phrased them as questions, just pretend we're on Jeopardy :-)
    - jbooth 17y ago
      No they're not, a "big reason not to use Cassandra" would be "it has critical bug X" or "it's missing critical feature Y".
jbellis 17y ago
I agree that evaluating whether to switch to a solution now, or wait for something even better, is always a question you should ask. But the term "vaporware" exists for a reason. Waiting for something that may or may not be everything it's promised is risky too. The Maglev ruby VM is a good example; they were demo-ing close to 10x performance a couple years ago, but when they finished implementing the fully ruby spec it was something like... 20% faster. A lot can change when you go from demo-ware to a real production ready product. Neither Fathom nor Volt is going to be at Cassandra levels of stability in 3 months. More like a year... if things go well.
- justinsb 17y ago
  It's you that pointed out that we're on the cusp on NoSQL convergence. I'm sure the end result of that will be better than NoSQL today, but any project merge or convergence of this kind is going to be pretty painful for those using the product along the way. In the meantime, there's at least 3 promising projects that have announced (FathomDB, VoltDB, Drizzle), and I know of a few more as well that aren't public. My decision would be to wait, others may decide to place their bets now. I meant it as a sincere complement - it's good marketing to draw attention to your strengths.
  - jbellis 17y ago
    "any project merge or convergence of this kind is going to be pretty painful for those using the product along the way" Only if you're using one of the non-viable products. So don't do that. :) "there's at least 3 promising projects that have announced (FathomDB, VoltDB, Drizzle)" Drizzle's idea of scale-out is writing a Cassandra backend, fwiw. http://drizzle.org/wiki/CassandraEngine http://drizzle.org/wiki/CassandraEngine
    - justinsb 17y ago
      But last year, CouchDB was the future. Today it's Cassandra. In a few months, it could well be MongoDB or Redis. Even if Cassandra ends up the NoSQL winner, I'm pointing out that you'll have your hands full dealing with 'must have' feature contributions from the 'losing' NoSQL store users, and that this will be painful for existing Cassandra users. As for the Drizzle thing, you've crossed the line into misleading marketing there. There is a plugin to integrate Cassandra as a Drizzle engine, just like there's a plug-in that logs MySQL error messages to Twitter. That doesn't make it the official strategy, nor does it automatically make it a good idea. (Edit: fixed my MongoDB/CouchDB confusion!)
jbooth 17y ago
Those aren't criticisms, at least not in a technical sense, they're broad philosophical concerns that apply just about equally to any technology you want to adopt, ever.