Well, I was away for a few days, my wife had a baby – great times! Sorry if there were any site problems, I noticed there were a few when I got back today.
The predictions should start working any minute now (Tuesday @ 1:30pm EST). The reason was all to do with MongoDB, some records disappeared on me. I suppose that is what you get for using bleeding edge systems. I will be converting everything over to Mysql as Mongo is way too young to be used in a production environment with things related to money (I am actually making trades with these predictions).
Speaking of Mongo… here area a few things I do not like about Mongo besides the lack of stability, and why I am going back to Mysql
- Lack of Transactions – there is simply no way to create a transaction as of yet, this is my biggest need.
- Missing Records – I lose probably about 5-10 records a week, I can sometimes get most of them back if I take the site down, and run a db.repair.
- No means to do any joins, though I must agree, it ends up much quicker this way.
- Schema-less, although this is the main reason I moved from Mysql, it is the same reason I am moving away from it. I always (usually) test my code, however, sometimes small things get missed. I noticed that some of my data was incorrect… it turned out that I had a typo in my table selector, and it automatically created another table with my typo. (More descriptive: I had two tables: Balances and Balancse). I had to create a migration program to move data from ‘balancse’ and merge it into ‘balances’ Perhaps there is a way of stopping this, but I just didn’t like the fact that it would just create anything on the fly. I am simply not perfect, and I will make mistakes, therefore, I’d rather see an error when the table, or field doesn’t already exist.
- Unstable Replication – I have had nothing but problems with the replication, however, I should admit- they do get fixed and pushed into the latest ‘stable’ version all the time.
- Not stable… after using MongoDB for a few months, I have come to the realization (which I already knew) that Mongo is new, bleeding edge, and is nowhere near stable. I am doing a server reboot every few days as there are still memory leaks on the process.
In Mongo’s defense- I really like it, and hope to use it in the future when it becomes stable. I’d also prefer an option to not allow Table or field additions unless there was another step or explicit command. The table and field creates should follow suit to at least the update/insert data rules. INSERT NEW FIELD into Collection, or INSERT NEW TABLE into Database X, etc.
My response to Mongo’s FAQ:
“When should I use Mongo?” – Always…
Whenever you don’t care if records go missing, don’t need replication, you’re a seasoned beta tester, like on the fly table/record creation, or simply like to use bleeding edge software.
Although I sound like a hater, this is just my advice to you. I will use it, when it becomes stable, but it is not currently stable in my opinion. My advice – stick with something that works, or wait until Mongo is not releasing a new version every couple weeks.
Back to the grind…
baby · mongo · nyse · predictions · problems
Mike Dirolf · June 22, 2010 at 2:59 pm
Sorry to hear that you ran into issues w/ MongoDB. From the sounds of it transactions were a requirement for you, unfortunately MongoDB just isn’t a good fit if complex, multi-document (row) transactions are required. We try to do a good job of noting / explaining that, so if you remember places where we could improve the docs on that I’d love to do so.
As for missing documents / memory leaks, both of those are *very* unexpected, and I have *never* heard reports of either on a production MongoDB release. Would love to get some more info so we can try and debug whatever the issue you ran into is.
Anyway, thanks for the writeup, and good luck w/ the changes!
Admin comment by admin · June 22, 2010 at 4:20 pm
Thanks for the reply, I will submit my findings via bug reports.
Glenn Gillen · June 22, 2010 at 5:15 pm
Curious to know what your setup was re replication, slaves, etc.
Riyad Kalla · June 22, 2010 at 11:32 pm
I’m curious about the replication setup as well — the master/slave setup seems to be preferred until sets are ready, and replica pairs seems to be a mess from what I’ve read.
I have seen a few folks with master/slave setups that still run into hickups, but it seems to be the smoothest sailing at the moment until 1.6 comes out with replica sets — but then those will need to stabilize.
Also curious when you said you were restarting every few days, was this due to out of memory explicitly and the DB dumping core or were you just being precautious with the lost records and running repairs preemptively?
– I’m coming from the perspective as a potential mongo-er and would rather avoid problems that someone else has run into if possible.
Links #8 « Otaku, Cedric's weblog · June 23, 2010 at 1:20 am
[...] We’re Back… so long MongoDB!A well needed reality check to emphasize that NoSQL solutions come with drawbacks [...]
Esen Sagynov · June 23, 2010 at 1:52 am
Consider using CUBRID database. At least you can try it, and if you don’t like it you can always can back to MySQL. Since you want to handle you website, CUBRID would be very handy to you. It is an open source database highly optimized for web applications. In my company we have run several benchmark analyses comparing Oracle, MS SQL, MySQL, and CUBRID. So, guess what. Oracle is, I think, really the positive result of hundreds of millions of investment – it showed the highest performance. CUBRID, in its turn, overpassed both MS SQL and MySQL in performance like 2x~6x times. More details can be found at http://www.cubrid.org/benchmark_result.
People got used to MySQL. It’s widely available and common. Few people even heard about CUBRID. it’s very young but gaining its pace. Try it out, I bet your records won’t ever be lost and you can easily move your data back and forth, in addition to your site will be highly available.
Matt Good · June 23, 2010 at 1:57 pm
Having run MongoDB in production for several months, I have to disagree with your assertion that MongoDB is unstable. It does require rethinking things a bit, but MongoDB makes for much quicker development, and we spend much less time administering it than the MySQL server used by our other smaller site.
First of all, I was also initially surprised by MongoDB’s memory usage, but if you’re seeing MongoDB using a lot of memory, it’s probably a good thing, not a memory leak. MongoDB’s memory usage looks very high because it’s caching a lot of your data. Since MongoDB uses memmapped files, almost all of that memory is a direct cache of your data files and managed by the OS’s virtual memory system. If another process needs some of that memory, the OS will write the data back to disk and free up a page of memory. It is best if you can put MongoDB on a box by itself, but that high memory usage is just an indication of how much more of your data is cached & ready for blazingly fast access.
As for transactions & joins, yes they’re not available, but for many applications, you can structure your data in a way that does not require them. Since you are dealing with financial transactions, you may actually need them, though for many typical web applications, MongoDB’s ability to do atomic updates to a single document are sufficient to keep the data consistent. It does require thinking about your updates a little differently, but as many people find, when using MySQL at a large scale you often have to abandon long transactions and joins for performance reasons.
Yes, MongoDB is not perfect for every application, but I’ve been extremely satisfied and would strongly recommend it over MySQL for many applications.
Matt Good · June 23, 2010 at 2:32 pm
@Riyad I’ve been using replica pairs in production & it’s working fine. I started hearing the recommendation to use master/slave after I’d already put the replica pair in production, so I asked about this at the MongoSF conference. I didn’t get the impression that replica pairs were a “mess”, but just that since replica sets would replace it there wouldn’t be much development effort going into replica pairs anymore. The word from the man-in-charge was to just leave it alone & switch to replica sets when they’re ready.
Mike Dirolf · June 23, 2010 at 4:49 pm
@Riyad What Matt Good said
. They aren’t a mess, just not much effort going into them as they will soon be deprecated in favor of replica sets.
Random Links #215 | YASDW - yet another software developer weblog · June 23, 2010 at 5:50 pm
[...] We’re Back… so long MongoDB! a MongoDB – NonSuccess Story – back to Mysql [...]
Gates VP · June 23, 2010 at 11:01 pm
I’m a production MongoDB User running a DB with well over 100M entries and slaving.
We have not had the “lost data” problem, however, we have experienced the occasional “very delayed” write. The type of weird thing where Mongo will “succeed” an operation, but then will take a hour before a query on that item will successfully return the new data. (thanks to “eventual consistency”)
Of course, we’re also writing to the DB hundreds of times / second with great speed.
However, if you’re experiencing issues requiring regular reboots or DB repairs, please do share with the community. Mongo is definitely still a young project, but the Mongo team works ridiculous hours and they fix a lot of bugs. So the more you can give them, the more you’re helping us all out.
Joe · June 24, 2010 at 11:09 am
I tried using MongoDB for a few months and made the same choice you did — move back to MySQL.
I have plenty of datapoints to back up my decision, and we can argue the merits of Mongo all day long, but perception == reality. Given the number of problems people have had with Mongo and users who have reverted their mongo projects, they have an uphill battle now.
Stuart · June 25, 2010 at 6:32 am
“I was also initially surprised by MongoDB’s memory usage”
This is a good point. Mongo deliberately uses a lot of memory by default, and newbies may falsely assume it’s a memory leak. Mongo on my server using about 80% of available memory. MySQL users would naturally freak out at that.
Stuart · June 25, 2010 at 9:04 am
Just as an after thought, if the server is being restarted every few days on suspicion of memory leaks, could it be mongo is not being cleanly closed down for whatever reason, and that’s how records are being lost? Without using safe document inserts, it can take a while for data to reach the disk.
+1 for lack of transactions.
Jennifer Davis · August 1, 2010 at 9:51 pm
I’m very curious about your and other’s experience.
1) It seems like there are different ideas about what eventual consistency means. I work on a project that isn’t open source (yet), but our understanding of eventual consistency isn’t “an hour later”. Is this in an alternate region or the local region that this “successful” write doesn’t return up to date information?
2) MySQL administrators in general wouldn’t freak out about memory usage because in general you want to size and prime your buffer pools and memory allocation as needed for the application running. A memory leak in general is the steady climb of memory use, and not a static number. If the Mongo system doesn’t allow you to configure how much cache you want at the start so that you can plan for OS requirements then that is definitely a problem. So is this problem a memory leak, a cache configuration you can’t tune, or long running static memory use?
3) What is great speed? For a system that writes hundreds a time a second, what is the expected latency?
Thanks, and I appreciate the understanding!
Scalable RDBMS | Labs@Leaseweb · July 22, 2011 at 11:03 am
[...] & stability unless there are some real users (I keep seeing post from users running into issues, or annoyance ) For example, the guys at Twitter were trying to move on with MySQL and Cassandra [...]