Skip to main content

Timeline for MySQL- reducing memory footprint

Current License: CC BY-SA 4.0

10 events
when toggle format what by license comment
Jul 22, 2018 at 18:10 vote accept Slawomir
Jul 21, 2018 at 16:58 comment added Slawomir Noted re. "big data" comment.
Jul 21, 2018 at 16:28 comment added Rick James "Big data" smells of brute force full data scans; as opposed to careful coding that can run faster by not needing big scans. Check your IOPs budget.
Jul 21, 2018 at 15:34 comment added Slawomir In the future we plan on going away from mysql as the reporting source and use more "big data"-friendly engine. We prefer something AWS agnostic so the evaluations are still ongoing.
Jul 21, 2018 at 15:31 comment added Slawomir Yes we use BIGINT. Our PK are like "uuid_short" but generated but the app nodes themselves (not the DB), guaranteed unique across distributed network of compute nodes - they reside closer to customers, at the edges, then forward to the master DB. We don't have a single autoincrement column.
Jul 21, 2018 at 2:18 comment added Rick James @Debriter - Do you need BIGINT; it is usually overkill. CPU:10%; what about I/O? "Reports" beg for "Summary tables".
Jul 21, 2018 at 2:16 comment added Rick James @Debriter - I added to my Answer to address your PK concern. Some other questions...
Jul 21, 2018 at 2:16 history edited Rick James CC BY-SA 4.0
respond to Comment
Jul 21, 2018 at 1:58 comment added Slawomir Most of our tables already have up to 2 indexes: one PK, one related to access pattern (like account_id + timestamp). I always thought that PK should be as small as possible (in our case it's a bigint) but you're suggesting to add the account_id for better clustering. As of now, we haven't observed any problems with writes. Our write-instance DB has about 1/4th the memory of the slave instance. CPU is mostly below 10% on the master. The slowdowns are definitely in the reads (reports) run by the slaves. We will shard accesses and see where this gets us.
Jul 20, 2018 at 19:20 history answered Rick James CC BY-SA 4.0