5 ms·

The long tail of startups will rarely need something other than a relational database because they won't get to a scale anywhere near Reddit's. It's not that ot

by diego 13y ago

The long tail of startups will rarely need something other than a relational database because they won't get to a scale anywhere near Reddit's. It's not that others don't "feel" the same way; there's a reason all those technologies exist. If you want to know, go work for Google, Twitter, Facebook, LinkedIn, etc.

j_baker 13y ago
I would argue the exact opposite. The average startup is likely using MySQL as a glorified key-value store already anyway, and they're likely using it in lieu of a more appropriate datastore because people tell them they don't need a NoSQL database until they get to Google-size. The lesson is: match your database to your use-case, not the other way around. Need advanced querying/reporting options? Get a warm, fuzzy feeling from a SQL prompt? Use MySQL. Want a plain jane key-value store? Use Voldemort/Kyoto Cabinet. Want flexible schemas? Use MongoDB. Want a Key-value store with secondary indexes and lots of scaling capabilities? Use Cassandra/HBase. Want a powerful datastore that's supported by a BigCo? Use DynamoDB or Cloud Datastore.
- diego 13y ago
  That's not the exact opposite. Because most people are familiar with SQL databases, that's usually what they use. That's the case with the grandparent post. "Use what you know, and works for your case" is better for a startup than learning a trendy technology because you believe it might be better for your use case. Three years ago at IndexTank we were looking for a SimpleDB replacement because it just didn't work as advertised. We explored a bunch of options, and we paid a significant cost to find out that deploying Cassandra would not be worth it for us. If you have never used Cassandra and choose it because you "want a Key-value store with secondary indexes and lots of scaling capabilities" then you're in for a world of hurt.
  - j_baker 13y ago
    For some reason, you seem to be reducing my argument to "Use the shiniest technology possible!". Please don't strawman me. If MySQL works for your use-case, and it's the option you're the most familiar with, use it. You'd be doing yourself a disservice by not at least evaluating other options though. And Cassandra is a key-value store with secondary indexes and lots of scaling capabilities (such as multi-datacenter deployments, multi-master replication deployment)[1], and some companies who aren't Google or Facebook do need these things. It sounds to me like IndexTank wasn't one of those companies. I reiterate my point: choose what's best for your company, and don't settle at MySQL just because it's "good enough". [1] I'd also add that it's particularly suited for large, insert-heavy datasets.
- asdasf 13y ago
  There is literally zero appropriate use cases for mysql. If you need a relational database, use one. If you need a network hash table, use one. Don't use mysql at all.
  - falcolas 13y ago
    This is a very common (at least on HN), and very misdirected view of MySQL. MySQL is a high performing, highly scalable, ACID compliant relational database, when configured correctly. The "MySQL is not production ready" meme was perpetuated by some well meaning, if ill-informed, fans of other RDBMS platforms.
    - asdasf 13y ago
      >MySQL is a high performing, highly scalable, ACID compliant relational database, when configured correctly. You forgot the "with tons of brokenness, misfeatures, mistakes, problems and otherwise NOTABUG bugs that will never be fixed and cause immense amounts of pain". Literally every other RDBMS is a better option, thus there is no reason to use mysql.
      - bcoates 13y ago
        Reason to use MySQL: It's easy to find people comfortable with it that won't accidentally shoot off a toe doing simple things. The "Don't use MySQL" argument smells like the "don't use bcrypt" argument to me. You're letting the perfect be the enemy of the good, for 95% of the usecases where you're doing something dumb like using MongoDB or homebrewing something, MySQL is a better choice--even if it isn't often the best choice.
        asdasf 13y ago
        I've never seen a single mysql database where there was no toe shooting happening. People just don't seem to miss their toes. In 100% of the cases where you used mysql, postgresql was a better option in every way. It isn't letting perfect be the enemy of good, it is saying "don't use bad software when there's good software available".
falcolas 13y ago
As a differing example of scaling - Facebook works very well using MySQL at a very large scale; implying that you don't need to move to key/value stores to scale. Both technologies have their place and reasons to exist, but it's not solely for the ability to scale.
- mh- 13y ago
  I don't necessarily disagree with your point, but that is a poor example. Facebook uses MySQL, largely, as a key-value store.
  - falcolas 13y ago
    Do you have a citation for this? The closest I could find is a mention in a gigaom article[1] that mentions that they have some data better suited for a document store tool, but saying "there likely are unstructured or semistructured data currently in MySQL that are better suited for HBase" doesn't imply that the majority of their data is key/value based. If you'd like another example at slightly less than Facebook size - RightNow (recently acquired by Oracle). They manage customer service for many (1,000+) different clients at huge scale: more than 300 MySQL databases spread throughout the world. If a website has a knowledge base, there's a good chance it's being managed on the backend by RightNow. [1] http://gigaom.com/2011/12/06/facebook-shares-some-secrets-on-making-mysql-scale/ http://gigaom.com/2011/12/06/facebook-shares-some-secrets-on...

by diego 13y ago

j_baker 13y ago

I would argue the exact opposite. The average startup is likely using MySQL as a glorified key-value store already anyway, and they're likely using it in lieu of a more appropriate datastore because people tell them they don't need a NoSQL database until they get to Google-size. The lesson is: match your database to your use-case, not the other way around. Need advanced querying/reporting options? Get a warm, fuzzy feeling from a SQL prompt? Use MySQL. Want a plain jane key-value store? Use Voldemort/Kyoto Cabinet. Want flexible schemas? Use MongoDB. Want a Key-value store with secondary indexes and lots of scaling capabilities? Use Cassandra/HBase. Want a powerful datastore that's supported by a BigCo? Use DynamoDB or Cloud Datastore.

diego 13y ago
That's not the exact opposite. Because most people are familiar with SQL databases, that's usually what they use. That's the case with the grandparent post. "Use what you know, and works for your case" is better for a startup than learning a trendy technology because you believe it might be better for your use case. Three years ago at IndexTank we were looking for a SimpleDB replacement because it just didn't work as advertised. We explored a bunch of options, and we paid a significant cost to find out that deploying Cassandra would not be worth it for us. If you have never used Cassandra and choose it because you "want a Key-value store with secondary indexes and lots of scaling capabilities" then you're in for a world of hurt.
- j_baker 13y ago
  For some reason, you seem to be reducing my argument to "Use the shiniest technology possible!". Please don't strawman me. If MySQL works for your use-case, and it's the option you're the most familiar with, use it. You'd be doing yourself a disservice by not at least evaluating other options though. And Cassandra is a key-value store with secondary indexes and lots of scaling capabilities (such as multi-datacenter deployments, multi-master replication deployment)[1], and some companies who aren't Google or Facebook do need these things. It sounds to me like IndexTank wasn't one of those companies. I reiterate my point: choose what's best for your company, and don't settle at MySQL just because it's "good enough". [1] I'd also add that it's particularly suited for large, insert-heavy datasets.
asdasf 13y ago
There is literally zero appropriate use cases for mysql. If you need a relational database, use one. If you need a network hash table, use one. Don't use mysql at all.
- falcolas 13y ago
  This is a very common (at least on HN), and very misdirected view of MySQL. MySQL is a high performing, highly scalable, ACID compliant relational database, when configured correctly. The "MySQL is not production ready" meme was perpetuated by some well meaning, if ill-informed, fans of other RDBMS platforms.
  - asdasf 13y ago
    >MySQL is a high performing, highly scalable, ACID compliant relational database, when configured correctly. You forgot the "with tons of brokenness, misfeatures, mistakes, problems and otherwise NOTABUG bugs that will never be fixed and cause immense amounts of pain". Literally every other RDBMS is a better option, thus there is no reason to use mysql.
    - bcoates 13y ago
      Reason to use MySQL: It's easy to find people comfortable with it that won't accidentally shoot off a toe doing simple things. The "Don't use MySQL" argument smells like the "don't use bcrypt" argument to me. You're letting the perfect be the enemy of the good, for 95% of the usecases where you're doing something dumb like using MongoDB or homebrewing something, MySQL is a better choice--even if it isn't often the best choice.
      - asdasf 13y ago
        I've never seen a single mysql database where there was no toe shooting happening. People just don't seem to miss their toes. In 100% of the cases where you used mysql, postgresql was a better option in every way. It isn't letting perfect be the enemy of good, it is saying "don't use bad software when there's good software available".

falcolas 13y ago

As a differing example of scaling - Facebook works very well using MySQL at a very large scale; implying that you don't need to move to key/value stores to scale. Both technologies have their place and reasons to exist, but it's not solely for the ability to scale.

mh- 13y ago
I don't necessarily disagree with your point, but that is a poor example. Facebook uses MySQL, largely, as a key-value store.
- falcolas 13y ago
  Do you have a citation for this? The closest I could find is a mention in a gigaom article[1] that mentions that they have some data better suited for a document store tool, but saying "there likely are unstructured or semistructured data currently in MySQL that are better suited for HBase" doesn't imply that the majority of their data is key/value based. If you'd like another example at slightly less than Facebook size - RightNow (recently acquired by Oracle). They manage customer service for many (1,000+) different clients at huge scale: more than 300 MySQL databases spread throughout the world. If a website has a knowledge base, there's a good chance it's being managed on the backend by RightNow. [1] http://gigaom.com/2011/12/06/facebook-shares-some-secrets-on-making-mysql-scale/ http://gigaom.com/2011/12/06/facebook-shares-some-secrets-on...