New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
https://objectrocket.com/ (rackspace)
https://www.compose.io/
https://mongolab.com/
Mongolab and Compose.io are both great, MMS also provides automatic deployment of mongodb instances but is not managed.
You should probably reconsider your use of MongoDB - it performs poorly, scales poorly, loses data, and causes hard-to-maintain applications.
Further reading:
There are pretty much no usecases where MongoDB is the optimal choice. If you absolutely need a document store (and you almost certainly do not), then there are better options like CouchDB or RethinkDB (although the latter suffers from overhead problems).
EDIT: Oh, and if you need JSON for some reason - PostgreSQL has that too.
Those are $18 and $19 per GB. @jmginer what do you mean by "LowEnd"?
And as many people who say its bad, there are as many who say its great.
We've used MongoDB for 3+ years, we've had zero data loss, fantastic performance. Our Mongo cluster has close to 50TB of data.
A lot of the people whining about it try to use it for the wrong purpose. Its a glorified document store, don't try to use it as an SQL database.
Honestly, most people who say it's great are developers who don't want to take the time to learn SQL.
Shrug. I have nothing against Mongo and there is certainly a very valid role for NoSQL in the world. I can't comment on scalability or integrity as I haven't used Mongo beyond play, but I also didn't find anything in Mongo that was all that impressive. Their free book was full of "Mongo doesn't support this" and "Mongo doesn't allow that".
But if you want to store documents with arbitrary attributes and retrieve primarily by key, sure, why not. Anything beyond that use case is not a good idea as you observe. I think @joepie91's point is that you can do the exact same thing storing JSON or XML or whatever inside Pg or MySQL (or any SQL DB).
But of course, then devs have to learn the basics of SQL :-)
Basics? It's just a few keywords
Mongo was the first big player on the field, there are much better NoSQL solutions now. I agree that one needs to understand when to use a relational database or a schema-less database.
We are working on a project that colects many informations, around 1000 regs/minute and then it generate stats with this regs. Tested with MySQL and MariaDB with very high CPU overloads. Looking other solutions...
@jmginer - consider buffering with Redis and also look at Couchbase. We funnel CDRs into our datastore using a combination of those.
mongodb is right for this job because you can actually write a script and check the performance, duplication etc ... if we talk about 100K/minute then you may need memory stores like redis as a buffer.
@MarkTurner beat me to the redis part
>
Here's a pick of the mongodb customers.
sql is a must for complex rational dbs like those rely heavily on joins and other datasources, mongodb shines as a document store with enough aggravation quires to get common jobs done. SQL is still needed for analysis.
If you're considering other options, be sure to give Cassandra a look as well.
And I have asked those people repeatedly to come up with rational arguments and actual, real-world benchmarks. For years. I have gotten none. And in the meantime, more and more evidence to the contrary is being published.
Great. Can you show me your benchmarks against other implementations for the same workload? Or are you just reclassifying "good enough" as "fantastic"? And how are you verifying that you're not losing any data? Do you keep a separate non-MongoDB store that you verify your data integrity against?
That is a problem with document stores in general. The problem is that, on top of that, MongoDB is objectively bad from a data integrity and performance point of view. I've provided some sources showing this - to date, I have seen none that contradict those sources. Feel free to provide sources that show otherwise, with hard metrics.
CouchDB was there before MongoDB. In enterprise settings, other solutions have been in common use before that. MongoDB was by no means "the first big player".
No, SQL isn't a must. Schemas and relations are a must. SQL is just one of the languages you can use for interfacing with your database - it would be perfectly possible to use a different language or API, and still have proper schemas and relations.
I also haven't seen MongoDB "shine" at anything when compared to other commonly available document store solutions. This is not a personal opinion, this is a simple lack of hard metrics.
And while on that topic, I want to clear up some of the issues with common terminology on these topics:
While all of these properties can exist together, they are not interchangeable terms. They all mean distinctly different things, and none of them requires any of the others to be true (or false).
when i said "shines" i meant mongodb solved problems i came across storing / duplication of json objects in real time. you can have excel or some script/xpath/api etc... to get results but sql is a must for those standard rational schema based languages.
If you have used other nosql tools please tell me i am always looking.
RethinkDB has been gaining steam lately, and is apparently working rather well - it has significant overhead, though. Small objects will take a minimum of a few kilobytes of space, which can be a problem. CouchDB has been around for a long time, and has a lot of interesting features. Somebody else mentioned Cassandra, and there are plenty more - they're just a Google search away.
And no, you don't need SQL. As I said, SQL is just the query language - it says nothing about whether a database is relational, schemaful, etc.
EDIT: I haven't used RethinkDB myself. I'm going off what I've heard from others regarding the overhead.
EDIT2: The specifics: "if your document is > 256 bytes, it uses full 4kb block to store it"