Oh, man. What about using indexing?

What if I was to use something for storage then use a bona-fide programming language or something faster for Map/Reduce? The worst case of hell is to just build JSON on a file then execute. There are other NoSQL databases available as well. Couch is built on Erlang. Perhaps that is faster.

Edit to add: well, duh, CouchDB uses JavaScript as well..

Anything anywhere can be scaled horizontally - I can write a database server in about 3 days that is extremely easy to scale out horizontally from the developer's perspective, but would be completely unusable for solving problems at scale. That's the real question - is the product effective at scale? Or does it have performance characteristics or reliability issues that make it less than ideal? Your users don't care how you achieve high request throughput and low latency.

This seems like a good summary of issues, both the original pastebin and an ex MongoDB engineer's explanations:

http://www.quora.com/MongoDB/How-muc...B-have?share=1

Btw, I completely agree that MongoDB is easy to use and features in MongoDB including sharding/clustering are easy to use. But by the time you need to scale horizontally, you usually have the budget not to care about a few extra developer hours. For prototypes, ease of use matters; for serious scalability issues, ease of use may simply mean the developer's lulled into thinking something works when it doesn't, or that some setups have been battle-tested when no one's done it successfully in production.

No disagreement on LOL Oracle prices. Or just LOL Oracle. Talking to MongoDB sales folks, I thought it was interesting how they try to make everything about Oracle versus them and handwave away all other open-source competition. Don't forget that MongoDB Enterprise is $7,500 a year per server.

Maybe it works differently in the US but I get the craziest lowball offers. I think a couple of days ago I could have gotten 3 Euro for selling back the absolute edition of Sandman (#1). Maybe it's just meant for textbooks but I think I got some dumb offers for CSy books as well.

---

While we're talking about DBs...one of the things that really blows my mind in the global IT landscape is that companies would get MSSQL or Oracle databases. I'm obviously a huge supporter of open source but PostgreSQL (and probably MySQL/MariaDB) is such an amazing piece of software with a well run community and good for pay support available if you want it. In my mind it's just superior to these other RDBMs in all ways.
It most certainly isn't because it's a joy to work with. Oracle is basically the nut low of strange "yeah but I did it this way, deal with it" situations. (a company I know may or may not charge 50% more if a client insists on Oracle vs. one of their recommended DBs)

I mean I get that some applications don't run on anything else (like SAP...which begs the question why it doesn't) but if you have a choice it seems like such an easy decision.

Then again...I don't get why anyone would run Windows on servers (once again other than they have to i.e. Active Directory infrastructure or Outlook maybe)

Candybar, trying to argue that Mongo isn't built to scale is just lol. Almost as lol as your claim that the traditional DBs have a long history of horizontal scaling or that you could do it yourself in 3 days.

Oracle has the "Nobody ever got fired for choosing Oracle" advantage. But other than that I don't understand how people choose to use it for new projects at all.

Dave,
Elasticsearch can act as a plain old document store too so you could in theory use it as a stand alone DB to store hands that can be retrieved.

It's kind of a lot to take in but the API and docs are really clean. Lots of drivers for many different languages too if you don't want to deal with HTTP calls directly but I would recommend fooling with the direct API to get familiar with it.

There's an excellent Chrome extension called "Sense" which makes working with elasticsearch directly really pleasant:
https://chrome.google.com/webstore/d...okbbfpbo?hl=en

I agree with this but this is almost entirely due to how solid Postgres is - in a world with just Oracle and MongoDB, there are good reasons why you'd use Oracle.

I'm not exactly sure what you want to do, but my guess is that any non-trivial hand simulations will take too long to do on the fly. Although some of the people that have more experience with poker apps probably know better.

In a world without Postgres I still would almost never use Oracle.

Obviously. They're not built to solve the same use cases.

That's not what I'm saying though.

The point I'm trying to get across is that scales easily (easy for developer to set up horizontal scaling) != scales well (works well at scale) and the latter is what you care about. I can code "scales easily DB" in 3 days but I can't code "scales well DB" in 3 years. You're saying that MongoDB scales easily - I agree. I don't know if it scales as well as MySQL/Postgres/Oracle. People have been developing applications at huge scale for years with these technologies - Skype with Postgres, Facebook with MySQL and Palantir and Salesforce with Oracle. MongoDB hasn't even been around that long. Meanwhile here on Quora, the biggest MongoDB deployment mentioned in the most upvoted answer is Foursquare running 6 instances (3 master-slave pairs), who btw had an infamous MongoDB-related outage.

http://www.quora.com/MongoDB/What-is...ne-use?share=1

MongoDB is super-nice to use and for most uses, its reliability and performance issues probably don't matter but I don't think there's much evidence for choosing it for any reason other than simple data model, ease of use and some nice features. History suggests that most feature-rich database management systems take a long time to mature - Postgres, MySQL and SQL Server all had reputation for being unreliable early in their respective lifecycle.

Who's "I" here? Minus Postgres, if you need a relational DBMS, you're left with a choice between something like MySQL, SQL Server, DB2 and Oracle. You're not sure why anyone would choose Oracle out of that lineup? Don't forget that for some applications, Oracle's license fees are pocket change.

Candybar, I honestly don't know what your point is but you come off as not really knowing what you're talking about.

I made a comment about horizontal scaling which you then responded to by implying that Mongo wasn't designed with that in mind (it was, what do you think the joke is in the web scale cartoon?) and implying that MySQL/Postgres/Oracle had a long history of supporting it.

Now you're trying to say that nobody is using it for heavy applications? Check out: http://www.mongodb.org/about/production-deployments/. They've also just raised a **** ton of money which is more proof that people are using them for serious applications.

"I" is jjshabado. Who else would it be?

I (again, that is "jjshabado") think that there is "almost never" a use case in which Oracle is the best choice in terms of cost/benefit. Even if you're in an organization with lots of resources there are better things you can spend that money on. And don't forget that your Oracle licensing fees scale with your usage. So even if you're a big company you're still going to be paying significant licensing fees. I know lots of reasons why people choose it and I think they're almost always making a non-optimal choice.

It's not necessarily a matter of saying "Which one other option would you chooose?" either. It could be something like saying you use MySQL for your real time transactional needs, and you use Vertica/RedShift/Whatever for your reporting needs, etc.

Holy crap, did you watch the video? What do you think the joke was?

http://www.mongodb-is-web-scale.com/

It certainly wasn't that MongoDB was built without the intention of being web scale.

Edit: Hell, the joke isn't even that MongoDB isn't scalable.

Here's what you said:

So were you not implying that Mongo wasn't built for horizontal scalability from day 1? And, once again, I'd point out that the write locks are not relevant to horizontal scaling.

I should also make it clear: Mongo (like most things) is built for particular use cases. If you have a use case that isn't compatible with its strengths then obviously it won't scale well. If your use case is compatible - then it'll scale fine.

The same usage can correspond to a completely different level of revenue. There are a lot of applications where a single DB server can be responsible for 8-10 figure revenue - do you want to take a chance with MySQL if you know Oracle is more reliable and feature-complete when losing data or any kind of screw-up can cost you 7 figures, missing features can cost you mid-6 figures in development costs or represent existential risk for your company if they cause you to lag your competitors? The license fee in this context is negligible. If you're hosting lolcat blogs or creating a free social picture-sharing site, you need to figure out a way to scale as cheaply as possible. If you're charging 5-figures per user, you have a completely different perspective as to what kinds of costs matter and what kinds of costs don't.

I tell you what, why don't we play the game where you give evidence to back up any of these beliefs about how significantly better Oracle is than all of its competitors?

I'm also not sure your single DB server generating 8-10 figures of revenue scenario gets out of the "almost never" territory.

So what was the joke and why did you bring this up?

Candybar, taking a step back, what was your original point?

Was it just that Mongo doesn't scale well? If so, cool, I'm quite sure there are many cases it doesn't scale well.

Edit: Bah, whatever. This is getting old. I'll just leave it at the above.

I don't think Oracle is that much better than Postgres, SQL Server or DB2. And I'm certainly not a database expert. But only one of those is open source, SQL Server is Windows-only, etc. But I've talked to plenty of people who are much better versed in database internals, all the relevant features for various business use cases and every single one of them thinks MySQL is completely unusable for a wide range of use cases that Oracle/SQL-Server/Postgres/etc support.

No, a huge part of the enterprise software sector is priced at this level and nearly all internal software written for small companies has implicit pricing at or close to this level. If you pay a single developer $150,000 a year to write and maintain some CRUD app that 100 people use, you're implicitly paying close to $2,000 per person per year in labor costs alone, if not more. And tons of enterprise apps have less than 100 users and/or require a large team to maintain. If a single Oracle server can support 5000 users, each of which is paying $2,000 a year, you're in the 8-figure revenue per server territory.

Cool. I'd be happy to continue this discussion with them, but otherwise this doesn't seem productive.

The original point was that Cassandra and MongoDB don't belong in the same sentence when it comes to being designed for scalability. For Cassandra, it's the raison d'etre, for MongoDB, it's an oft-claimed benefit that doesn't seem to have much basis in reality.

Because some NoSQL technologies were designed explicitly for high availability (Cassandra, DynamoDB) and others were designed for Big Data (HBase, BigTable) I've seen an increasingly lazy tendency to associate these benefits with NoSQL in general, allowing NoSQL technologies whose design doesn't have much to do with high-availability or big-data or anything to do with scale to reap marketing benefits.