The company went bakrupt, but the game we made[0] still lives. It uses MongoDB to store user accounts, profiles, inventories, match history and all persistent data.
I was the one who suggested to use MongoDB when we started (instead of SQL) as the game front-end was JS and back-end Node.js, meaning that having a MongoDB database we could easily type, store and retrieve data. Overall I think it was a good decision, it ran pretty well with over 200k MAU, ~2-3k concurrent. We never really had performance issues with the database, but we did have to implement our own locking system to make sure that non-atomic operations are performed correctly. I think there are only 3 VPSs running MongoDB (one master, one replica and one back-up I think), so actually the entire database (a few gigabytes with around 1M accounts) only runs on a single cheap VPS.
Ask HN: Do you still use MongoDB?
211–220 of 243 posts
Re: Ask HN: Do you still use MongoDB?
#212Earlier quoted context omitted.
I don't have a specific book for you, I myself learned about relational databases at school, not sure why is not being taught everywhere. The things that you have problems with aren't really specific to PostgreSQL so if you are looking for a book while one based on PostgreSQL might be easier, there might be better books that talk about relational databases and what you learn will still apply. About migrations, from P…
I studied a different Engineering, not CS, so never really had any course (besides basic C). I've read quite a bit and understand the normalization forms, but it's more from a practical sense. What data should we include, how to structure it so that it's not too complex, but doesn't come back biting me, etc. A good example (but not only!) is login. You can have just user session, or session+token in DB, or session +…
When structuring data you generally want it to be in 3rd normal form or higher. The normal forms the higher you go the less duplication you have in your data, but then the more joins you will do and that could reduce performance.
> A good example (but not only!) is login. You can have just user session, or session+token in DB, or session + devices (1 active token/device), etc. So maybe seeing business problems and how the DB was structured to help would be the best here.
I think you're overthinking it a bit, besides I don't know if you're saying it but in case you are, you don't want to mix login information (like user account, name, login password etc) with a session. Those things are separate and have different requirements.
For example let's say your site became so popular that you have scaling problems. It is perfectly fine to take the session and put it in nosql store, or (maybe even better) in a cache. This data is accessed on key/value basis and also while not great it won't kill you if the data disappears due to some outage (users just get log out). As to what you store there, session + device or session + token in DB is purely based on your need. Frankly I don't know what you mean by token in DB, in fact I'm not sure what do you mean session + device either. Sessions generally is a randomly generated ID that tied to a session, if user connects from a different device they will have another session anyway.
I don't think this particular thing is something that relational database dictates. But you generally wouldn't want to place sessions in user table. Those two things are completely different even when they seem to be related. You should have separate users table and separate session table (most frameworks handle sessions for you, so you might not even need to think too much about it)
> Oh maybe that's the reason I found those so tricky. I don't explicitly care about VCS, but I definitely care about migrations going wrong, and hopefully being able to revert if it goes wrong. Maybe if I get myself comfortable enough with manual migrations this is not such a huge topic though.
In PostgreSQL (it might not be true in other databases) DDL (Data Modification Language) can be inside of a transaction. So you can start a migration with "BEGIN" and then check if what you did worked fine before you say "COMMIT". Note though, when I said developers want to have it version controlled. They do that to avoid any mistakes. Such as forgetting the BEGIN, or accidentally pasting wrong thing to the shell. So if you have a production data you absolutely should use them. But if I were you I would first try to learn it by doing it by hand on a test database. If you understand what is actually done the migrations don't seem that magical.
Re: Ask HN: Do you still use MongoDB?
#213Yes, still using it for storing relatively unstructured blobs of JSON which I only lookup via key but update with various operators ($addToSet, $set, $incr). Also using it as a persistent session store and lately for storing rate-limiting information. I've come to like the MongoDB update operators and features such as the Change Events. However I will eventually be moving off MongoDB as I need horizontal scaling via…
It is just shocking that you would be on mongoDB and move away from it for horizontal sharding. As some one who has never used mongo that seems like the only reason to use it
Re: Ask HN: Do you still use MongoDB?
#214JavaScript is shitty, and JSON is even shittier. Fuck all this trash. I hate all computers, but I hate JavaScript and everything related to it EVEN MORE.
Re: Ask HN: Do you still use MongoDB?
#215Earlier quoted context omitted.
While there are many people here who are sharing their bad experience with MongoDB, just curious if you all find the experience with DynamoDB similar? Since they are both of the NoSQL family.
DynamoDB is a lot more explicit about its tradeoffs. Much of the backlash against Mongo was because it basically claimed to be well-suited to any use case, when its sweet spot was really far narrower. To be successful with Mongo, you need to design the entire app around its limitations, but those limitations were initially downplayed and obscured. People were convinced that Mongo was a good choice as a default, gener…
What are those good use-cases for mongo?
Re: Ask HN: Do you still use MongoDB?
#216I can't help noticing that the majority - not all, but the majority - of "No." responses here summarize identically: someone used MongoDB a long time ago (between 5 and 11 years) and ran into a problem, so they stopped using it and will never try or re-evaluate it again. I'm a bit surprised that developers and systems engineers get burned to the point that they disconnect from the daily reality of their occupation, t…
Life is too short to reevaluate every technology I've had a bad experience with.
You only get one chance to make a first impression - I'll probably stick with it unless I get an excellent reason to change my mind.
How often do you reevaluate technologies that you've had a bad experience with?
Re: Ask HN: Do you still use MongoDB?
#217I've promised myself to never touch MongoDB again. Worked for a valley startup back in 2013 that picked Mongo as primary data store because the CEO liked the simplicity and was too busy with the future to learn anything more complicated. I only implemented a couple of features before I got out of that mess. But from my experience, compared to dozens of SQL and NoSQL databases I've worked with; it was definitely the w…
Whats your opinion on postgres vs nosql like cassandra and aerospike, fundamentally is there any reason that postgres can't scale as well as nosql? If I store key value in postgres and add read replica to scale read and partition to scale write will I not be able to keep up with other nosql solutions? If so what are the reasons?
I would say that by the time you (potentially) have those kinds of problems, you'll most likely have the resources to deal with them.
It's sort of a nice class of problems to have, and a lousy heuristic for choosing solutions before you know what exactly you're dealing with.
Re: Ask HN: Do you still use MongoDB?
#218I can't help noticing that the majority - not all, but the majority - of "No." responses here summarize identically: someone used MongoDB a long time ago (between 5 and 11 years) and ran into a problem, so they stopped using it and will never try or re-evaluate it again. I'm a bit surprised that developers and systems engineers get burned to the point that they disconnect from the daily reality of their occupation, t…
Life is too short to reevaluate every technology I've had a bad experience with. You only get one chance to make a first impression - I'll probably stick with it unless I get an excellent reason to change my mind. How often do you reevaluate technologies that you've had a bad experience with?
How often I re-evaluate applications, you mean? I would say it happens somewhat regularly; if there's something I miss with one I switched from, or if I hear or read something good about an application I stopped using.
Re: Ask HN: Do you still use MongoDB?
#219I had some positive outcomes using Postgres and Mongo as essentially a front end cache. The use case was unique in that all of the spark/etl jobs ran against postgres, which then triggered caching workers to build up a more document oriented cache that the front end talked to. Essentially allowing the front end to get a KV on steroids and documents already prepared well to be rendered and pre joined.
Against a specific use case. I was never burned by Mongo, but I wouldn’t choose it if I had to have one backend only. It lends itself nicely as part of an ecosystem imho
Re: Ask HN: Do you still use MongoDB?
#220No. Every time I've used mongodb we've ended up regretting it for one reason or another. And migrating to a different database after launch is a huge hassle. I've done a couple projects where we kicked off with postgres using JSONB columns for early iteration. Then we gradually migrated to normal SQL columns as the product matured and our design decisions crystallized. That gave us basically all the benefits of mongo…
This. Mongodb sucked.