Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About piojo

  • Rank

Personal Information

  • Interests
  1. Wow, this has really turned into a rabbit hole! I've been reading a lot more than I expected to in the last couple days. What I understand is: I'm not going to be able to scale MongoDB for performance without losing data consistency. The only really safe scaling is sharding. And Postgres can also store/manipulate similar JSONB documents--the API is different, but it seems like it can do the same things. Postgres has the potential to move to relational storage as designs solidify or optimization is needed. Plus, Postgres can run on Aurora, which as @hplus0603 mentioned, will probably be a performance boost and might simplify scaling. Is there any additional benefit of Postgres or disadvantage of MongoDB, other than the fact that I'm not using it for its strongest use case (massively multiplied/available data)? In other words, why bring up Postgres and MySQL? Is it only because relational is faster than nosql, or are these technologies better in another way?
  2. Oh, wow. That's a lot to think about (and read). The reason I chose nosql over relational is that we may want to change schemas quickly (due to either inexperience or changing requirements). Also, omitting schemas is just nice, because game data can take so many shapes. From reading about JSONB, I gather it's far slower to query than Postgres as a relational DB. Is a common workflow to start with heavy use of JSONB, but eventually migrate a lot of that data to other columns or tables? I don't want to slow development too much, but I really don't want to choose a tool that will turn out to be unsuitable and hard to replace.
  3. Thank you @Kylotan, that's very helpful! We don't want to read stale data, but I believe we can make it less likely by using the appropriate MongoDB options. We don't have a database expert on the team, but it seems like our general experience is in nosql and mysql. Is there any other choice that sticks out as an obvious candidate? (We're moving away from Parse.com, because development, debugging, and performance are all too slow.) Sharding is a great idea, either if I can't get our DB writes to be fast enough for one DB, or if we use the scheme I first described but find it's still not fast enough and needs to be multiplied.
  4. This is a mobile game, and while we don't know how all the popular mobile games work internally, it seems like a lot of them run this way. They aren't multiplayer so the client can have most of the game logic, but the players can interact in a very limited way and the server must manage player progress/stats (and may manage inventory). Think Puzzle and Dragons or Ingress. Are you at all familiar with that type of architecture (which offloads most of the logic to the client, but has the server keep an eye on things to make sure it's a-okay)? That's what we're going for.
  5. I'm part of a small team which is adapting an old game to use a client/server architecture, so game logic/state can be more centrally controlled. The game server currently uses MongoDB, but it's still early enough to switch. I have a plan to avoid server performance problems if we need to scale to support a lot of users. Can you tell me if it seems reasonable? (We don't actually plan to do this stuff until it's needed, but we don't want to develop ourselves into a hole we can't get out of.) The server is stateless (responding to each message based on what's in the database), so we can have more than one server talking to the same DB. The server is hosted on Amazon Web Services. So the first scaling step will be to use one or more instances/VMs running their own copies of the server, but all connecting to the same database. This assumes the server CPU power will be maxed out before the database. A load balancer will spread the requests to all the servers. The next step is to change the single database to a MongoDB replication set, so the many servers can talk to many databases. My understanding is that we can read from any database, but must write to the "master". This will require slight changes to the server, but in the real world, do we need to minimize writes or somehow batch them? What does this entail? Hearing your feedback/knowledge/experience would be appreciated.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!