Three Things That Differentiate Amazon Aurora From MySQL
January 27, 2017 |
It's not always obvious what makes one database type distinct from another. What are the most significant ways Amazon Aurora is different from MySQL? Clear separators aren't always featured or widely known, but even slight variables between two databases can prove valuable in choosing which one is right for you and your organization.
In the case of Aurora, at least three interesting things make it unique and present opportunities for particular uses. (Thanks in advance to @saileshkrish for helping us stay in-the-know on what Aurora can do.)
Adaptive Thread Pool
Aurora's thread pool doesn't look quite like MySQL's. With features like multiplexed connections and the ability to handle over 5,000 concurrent sessions, Aurora's thread pool means you don't have to use connection pooling. It's more scalable than MySQL's thread pooling, and when you use it, you have one fewer thing you need to worry about on the database. Overall, Aurora's thread pool is a more "modern" system. It's what you would expect to see from a database created today.
DDL refers to operations like ALTERs. It's not just transactional, but online too. This is the benefit of using log-structured storage.
This isn't actually documented anywhere we've seen, but it's a definite benefit to know about.
A Rewritten Query Cache
Aurora's rewritten query cache could represent a major difference in how it should be run vs. MySQL. MySQL's query cache is frequently the cause of server stalls, as we've seen with our Adaptive Fault Detection. It can cause more harm than good, and there's a reason why it's been disabled by default in MySQL for more than four years.
Aurora's brand new query cache makes the feature worth revisiting. This comes with the caveat that we haven't yet investigated Aurora's query cache--if you choose to use it, you should still benchmark it both enabled/disabled with your workload, then act according to the results you see.