6 ms·

Sad to see. We were one of their early paying customers in 2009/2010 (we got a great deal). Performance was fantastic over very large datasets, but the bugs, st

Sad to see. We were one of their early paying customers in 2009/2010 (we got a great deal). Performance was fantastic over very large datasets, but the bugs, storage requirements (very expensive SANs) and query limitations became big problems for us. We moved away after a year. Just recently one of our team has been looking at them again (following a strong benchmark being posted at mysqlperformanceblog). So I went and checked out the forums and saw it was pretty much in a similar state to when I last used it four years ago. Sad to see they couldn't make it work. The team was always really friendly and quick to help with issues - good luck in the future.

imaginenore 12y ago
There are so many scalable (and often free) databases out there. What do you that can't be done in Cassandra or Mongo or Vertica?
- trhway 12y ago
  is where a good way of doing MPP SQL in Cassandra or Mongo? and Vertica is really far from being free, isn't it?
  - imaginenore 12y ago
    Postgres-XL can do that. There's also Shard-Query and (not free) Amazon Redshift. Or you could just shard your regular community Postgre or MySQL.
    - bsg75 12y ago
      See also https://github.com/citusdata/cstore_fdw https://github.com/citusdata/cstore_fdw
  - bsg75 12y ago
    Vertica has a community tier, free up to 1TB of source data, and a 3 node limit. SQL is not part of the Cassandra or Mongo feature sets. They have certain analytic possibilities, but not if you want to use SQL (window functions for example), or most of the BI client tools associated with data warehousing.
  - electrum 12y ago
    Presto is a fully distributed (MPP) SQL query engine that supports Cassandra: http://prestodb.io/docs/current/connector/cassandra.html http://prestodb.io/docs/current/connector/cassandra.html You can even join together data from Hive, Cassandra, MySQL, PostgreSQL, Kafka, etc., all in one query. We don't have a connector for Mongo yet, but contributions are welcome! The Cassandra connector was actually an external contribution. We don't use it at Facebook.
- samcrawford 12y ago
  Of course, you're right, but we didn't know that at the time. It turns out there's nothing we were doing that really warranted using a data warehouse (for that is what InfiniDB was really suited for). We were collecting a lot of numerical, time-series data, bulk loading it and then performing summarised queries periodically. Mongo, Cassandra, etc are not good fits for this. Vertica was very expensive. In the end we went with a sharded and partitioned MySQL setup (partitioning really is great if you use it well). It's worked very well.
  - imaginenore 12y ago
    Yeah, that's exactly what I suggested in the other comment. If you can get away with sharding, it's the easiest solution, and the developers/DBAs are relatively easy to find. Glad it worked out for you guys.
  - jwegan 12y ago
    FYI, for people using less than 1 TB of data, Vertica does have a free community edition. I used Vertica at my last job and it was blazingly fast compared to Hive (like 5x to 10x faster).
    - michaelcampbell 12y ago
      Is that 1TB compressed or "raw"?
  - zenogais 12y ago
    This actually sounds like a great fit for Cassandra and Hadoop. You could use Cassandra's built in TimeUUID as the primary key and have your data pre-sorted on disk in time-series. This would make big queries, using something like Hadoop, very efficient.
    - jhh 12y ago
      That's not necessary though, if it works fast enough on a relational database in my opinion. I think this article has some valuable insight on the topic: http://www.chrisstucchio.com/blog/2013/hadoop_hatred.html http://www.chrisstucchio.com/blog/2013/hadoop_hatred.html
- swartkrans 12y ago
  Honest question, is MongoDB actually scalable? I keep reading about how it is not for serious business[1][2][3][4]. Who is using Mongo at scale and what sort of loads are they seeing and are the level of problems on par with other solutions? As a developer I like Mongo's API, but I would worry about using it given what has been written about it. [1] http://aphyr.com/posts/284-call-me-maybe-mongodb http://aphyr.com/posts/284-call-me-maybe-mongodb [2] http://svs.io/post/31724990463/why-i-migrated-away-from-mongodb http://svs.io/post/31724990463/why-i-migrated-away-from-mong... [3] http://use-the-index-luke.com/blog/2013-10/mysql-is-to-sql-like-mongodb-to-nosql http://use-the-index-luke.com/blog/2013-10/mysql-is-to-sql-l... [4] https://news.ycombinator.com/item?id=8353228 https://news.ycombinator.com/item?id=8353228
  - x0x0 12y ago
    No, and even modest write loads will cause immense pain -- there was a single lock per db when I last used them. Plus lots of the standard tricks for getting performance out of dbs don't work for them. I'd recommend staying away unless your performance needs are very moderate and you must have unstructured tables.
    - mcot2 12y ago
      Check out tokumx, it fixes a lot of the problems with mongo.
      - cheald 12y ago
        Seconded; we've had a very positive experience with it so far. We're running around 1.5TB in it (and growing) and it's working pretty decently. Our biggest problems with it have been CPU saturation due to compression (solvable with sharding) and oplog size (due to supporting ACID; supposedly much better in the upcoming release), but both of those are surmountable. In exchange we get massively better disk usage characteristics, no global locks, ACID compliance, transactions, and generally better performance. It's not perfect, but it solved a lot of our problems.
    - rogerbinns 12y ago
- rubinelli 12y ago
  My bet is what really took the wind out of InfiniDB's sails was Amazon's Redshift. It's new, shiny, ridiculously easy to use, has a strong pedigree and a fairly low initial capital outlay.
  - mhoglan 12y ago
    Not really. Redshift is nice don't get me wrong, but we did not run into many people that were choosing Redshift over InfiniDB. The major players out there still run everything on premise and behind their firewall. btw, InfiniDB was originally going to be the backend to Redshift. Lets just say the previous executive team 'screwed that up'

imaginenore 12y ago

There are so many scalable (and often free) databases out there. What do you that can't be done in Cassandra or Mongo or Vertica?

trhway 12y ago
is where a good way of doing MPP SQL in Cassandra or Mongo? and Vertica is really far from being free, isn't it?
- imaginenore 12y ago
  Postgres-XL can do that. There's also Shard-Query and (not free) Amazon Redshift. Or you could just shard your regular community Postgre or MySQL.
  - bsg75 12y ago
    See also https://github.com/citusdata/cstore_fdw https://github.com/citusdata/cstore_fdw
- bsg75 12y ago
  Vertica has a community tier, free up to 1TB of source data, and a 3 node limit. SQL is not part of the Cassandra or Mongo feature sets. They have certain analytic possibilities, but not if you want to use SQL (window functions for example), or most of the BI client tools associated with data warehousing.
- electrum 12y ago
  Presto is a fully distributed (MPP) SQL query engine that supports Cassandra: http://prestodb.io/docs/current/connector/cassandra.html http://prestodb.io/docs/current/connector/cassandra.html You can even join together data from Hive, Cassandra, MySQL, PostgreSQL, Kafka, etc., all in one query. We don't have a connector for Mongo yet, but contributions are welcome! The Cassandra connector was actually an external contribution. We don't use it at Facebook.
samcrawford 12y ago
Of course, you're right, but we didn't know that at the time. It turns out there's nothing we were doing that really warranted using a data warehouse (for that is what InfiniDB was really suited for). We were collecting a lot of numerical, time-series data, bulk loading it and then performing summarised queries periodically. Mongo, Cassandra, etc are not good fits for this. Vertica was very expensive. In the end we went with a sharded and partitioned MySQL setup (partitioning really is great if you use it well). It's worked very well.
- imaginenore 12y ago
  Yeah, that's exactly what I suggested in the other comment. If you can get away with sharding, it's the easiest solution, and the developers/DBAs are relatively easy to find. Glad it worked out for you guys.
- jwegan 12y ago
  FYI, for people using less than 1 TB of data, Vertica does have a free community edition. I used Vertica at my last job and it was blazingly fast compared to Hive (like 5x to 10x faster).
  - michaelcampbell 12y ago
    Is that 1TB compressed or "raw"?
- zenogais 12y ago
  This actually sounds like a great fit for Cassandra and Hadoop. You could use Cassandra's built in TimeUUID as the primary key and have your data pre-sorted on disk in time-series. This would make big queries, using something like Hadoop, very efficient.
  - jhh 12y ago
    That's not necessary though, if it works fast enough on a relational database in my opinion. I think this article has some valuable insight on the topic: http://www.chrisstucchio.com/blog/2013/hadoop_hatred.html http://www.chrisstucchio.com/blog/2013/hadoop_hatred.html
swartkrans 12y ago
Honest question, is MongoDB actually scalable? I keep reading about how it is not for serious business[1][2][3][4]. Who is using Mongo at scale and what sort of loads are they seeing and are the level of problems on par with other solutions? As a developer I like Mongo's API, but I would worry about using it given what has been written about it. [1] http://aphyr.com/posts/284-call-me-maybe-mongodb http://aphyr.com/posts/284-call-me-maybe-mongodb [2] http://svs.io/post/31724990463/why-i-migrated-away-from-mongodb http://svs.io/post/31724990463/why-i-migrated-away-from-mong... [3] http://use-the-index-luke.com/blog/2013-10/mysql-is-to-sql-like-mongodb-to-nosql http://use-the-index-luke.com/blog/2013-10/mysql-is-to-sql-l... [4] https://news.ycombinator.com/item?id=8353228 https://news.ycombinator.com/item?id=8353228
- x0x0 12y ago
  No, and even modest write loads will cause immense pain -- there was a single lock per db when I last used them. Plus lots of the standard tricks for getting performance out of dbs don't work for them. I'd recommend staying away unless your performance needs are very moderate and you must have unstructured tables.
  - mcot2 12y ago
    Check out tokumx, it fixes a lot of the problems with mongo.
    - cheald 12y ago
      Seconded; we've had a very positive experience with it so far. We're running around 1.5TB in it (and growing) and it's working pretty decently. Our biggest problems with it have been CPU saturation due to compression (solvable with sharding) and oplog size (due to supporting ACID; supposedly much better in the upcoming release), but both of those are surmountable. In exchange we get massively better disk usage characteristics, no global locks, ACID compliance, transactions, and generally better performance. It's not perfect, but it solved a lot of our problems.
  - rogerbinns 12y ago
rubinelli 12y ago
My bet is what really took the wind out of InfiniDB's sails was Amazon's Redshift. It's new, shiny, ridiculously easy to use, has a strong pedigree and a fairly low initial capital outlay.
- mhoglan 12y ago
  Not really. Redshift is nice don't get me wrong, but we did not run into many people that were choosing Redshift over InfiniDB. The major players out there still run everything on premise and behind their firewall. btw, InfiniDB was originally going to be the backend to Redshift. Lets just say the previous executive team 'screwed that up'