4 ms·

I have a mobile game API that does ~415rps and about 2100qps. (About 1500qps are in MySQL, more below.) We do that with one DB server with 122m RAM. While we ca

I have a mobile game API that does ~415rps and about 2100qps. (About 1500qps are in MySQL, more below.) We do that with one DB server with 122m RAM. While we can continue to scale RAM, we can see the handwriting on the wall - indexes will continue to grow, and we won't be able to scale vertically forever. BTW - CPU usage on a SQL server is usually low - as long as indexes are in RAM, lookups should be CPU-light. In any case, SQL considers the oldest record with equal importance as the newest, and so index sizes can (and likely will) eventually be larger than data in some cases (two-column relation-tables with 20m records for instance). The options are basically 1. shard, or 2. consider a different approach. We use NoSQL to store certain types of info, just as SO does - Redis, Elasticsearch, and so on. The more data we store and the more we use it in new ways, the more types of non-relational DBs we use. I don't think we'll ever have a situation where MySQL goes away entirely, but it stops being the singular solution pretty quickly as you scale up.

y0ghur7_xxx 12y ago
> I have a mobile game API that does ~415rps and about 2100qps. (About 1500qps are in MySQL, more below.) We do that with one DB server with 122m RAM. While we can continue to scale RAM, we can see the handwriting on the wall - indexes will continue to grow, and we won't be able to scale vertically forever. I don't know how many users you have now and how quick you grow, but you can buy a server with more than 10x as much RAM as you have now. You may not "be able to scale vertically forever", but if you hit that spot you reached at least 5x Stack Overflow level. Congrats! > We use NoSQL to store certain types of info, just as SO does - Redis, Elasticsearch, and so on. The more data we store and the more we use it in new ways, the more types of non-relational DBs we use. > I don't think we'll ever have a situation where MySQL goes away entirely, but it stops being the singular solution pretty quickly as you scale up. Sure why not. Use what fits your needs. But I guess you used Redis and Elasticsearch for it's features, not because it scales better - for that, some more RAM would have done it.
jlgaddis 12y ago
> 122m RAM Huh? I assume you're not referring to 122 MB of RAM. What's the "m"?
- themartorana 12y ago
  * facepalm * 122GB. That's still an abnormal amount, but it's in AWS RDS, on a db.r3.4xlarge instance. http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.DBInstanceClass.html http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concep...
- deleted 12y ago
  [deleted]

y0ghur7_xxx 12y ago

> I have a mobile game API that does ~415rps and about 2100qps. (About 1500qps are in MySQL, more below.) We do that with one DB server with 122m RAM. While we can continue to scale RAM, we can see the handwriting on the wall - indexes will continue to grow, and we won't be able to scale vertically forever. I don't know how many users you have now and how quick you grow, but you can buy a server with more than 10x as much RAM as you have now. You may not "be able to scale vertically forever", but if you hit that spot you reached at least 5x Stack Overflow level. Congrats! > We use NoSQL to store certain types of info, just as SO does - Redis, Elasticsearch, and so on. The more data we store and the more we use it in new ways, the more types of non-relational DBs we use. > I don't think we'll ever have a situation where MySQL goes away entirely, but it stops being the singular solution pretty quickly as you scale up. Sure why not. Use what fits your needs. But I guess you used Redis and Elasticsearch for it's features, not because it scales better - for that, some more RAM would have done it.

jlgaddis 12y ago

> 122m RAM Huh? I assume you're not referring to 122 MB of RAM. What's the "m"?

themartorana 12y ago
* facepalm * 122GB. That's still an abnormal amount, but it's in AWS RDS, on a db.r3.4xlarge instance. http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.DBInstanceClass.html http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concep...
deleted 12y ago
[deleted]