Let’s look at some of the most popular Percona Database Performance Blog posts in 2018.
The closing of a year lends itself to looking back. And making lists. With the Percona Database Performance Blog, Percona staff and leadership work hard to provide the open source community with insights, technical support, predictions and metrics around multiple open source database software technologies. We’ve had nearly 4 million visits to the blog in 2018: thank you! We look forward to providing you with even better articles, news and information in 2019.
As 2018 moves into 2019, let’s take a quick look back at some of the most popular posts on the blog this year.
Top 10 Most Read
These posts had the most number of views (working down from the highest):
When Should I Use Amazon Aurora and When Should I use RDS MySQL?
Now that Database-as-a-service (DBaaS) is in high demand, there is one question regarding AWS services that cannot always be answered easily : When should I use Aurora and when RDS MySQL?
ZFS has many very interesting features, but I am a bit tired of hearing negative statements on ZFS performance. It feels a bit like people are telling me “Why do you use InnoDB? I have read that MyISAM is faster.” I found the comparison of InnoDB vs. MyISAM quite interesting, and I’ll use it in this post.
Linux OS Tuning for MySQL Database Performance
In this post we will review the most important Linux settings to adjust for performance tuning and optimization of a MySQL database server. We’ll note how some of the Linux parameter settings used OS tuning may vary according to different system types: physical, virtual or cloud.
As the MyRocks storage engine (based on the RocksDB key-value store http://rocksdb.org ) is now available as part of Percona Server for MySQL 5.7, I wanted to take a look at how it performs on a relatively high-end server and SSD storage.
How to Restore MySQL Logical Backup at Maximum Speed
The ability to restore MySQL logical backups is a significant part of disaster recovery procedures. It’s a last line of defense.
Why MySQL Stored Procedures, Functions and Triggers Are Bad For Performance
MySQL stored procedures, functions and triggers are tempting constructs for application developers. However, as I discovered, there can be an impact on database performance when using MySQL stored routines. Not being entirely sure of what I was seeing during a customer visit, I set out to create some simple tests to measure the impact of triggers on database performance. The outcome might surprise you.
AMD EPYC Performance Testing… or Don’t get on the wrong side of SystemD
Ever since AMD released their EPYC CPU for servers I wanted to test it, but I did not have the opportunity until recently, when Packet.net started offering bare metal servers for a reasonable price. So I started a couple of instances to test Percona Server for MySQL under this CPU. In this benchmark, I discovered some interesting discrepancies in performance between AMD and Intel CPUs when running under systemd.
Tuning PostgreSQL Database Parameters to Optimize Performance
Out of the box, the default PostgreSQL configuration is not tuned for any particular workload. Default values are set to ensure that PostgreSQL runs everywhere, with the least resources it can consume and so that it doesn’t cause any vulnerabilities. It is primarily the responsibility of the database administrator or developer to tune PostgreSQL according to their system’s workload. In this blog, we will establish basic guidelines for setting PostgreSQL database parameters to improve database performance according to workload.
Using AWS EC2 instance store vs EBS for MySQL: how to increase performance and decrease cost
If you are using large EBS GP2 volumes for MySQL (i.e. 10TB+) on AWS EC2, you can increase performance and save a significant amount of money by moving to local SSD (NVMe) instance storage. Interested? Then read on for a more detailed examination of how to achieve cost-benefits and increase performance from this implementation.
Why You Should Avoid Using “CREATE TABLE AS SELECT” Statement
In this blog post, I’ll provide an explanation why you should avoid using the CREATE TABLE AS SELECT statement. The SQL statement “create table <table_name> as select …” is used to create a normal or temporary table and materialize the result of the select. Some applications use this construct to create a copy of the table. This is one statement that will do all the work, so you do not need to create a table structure or use another statement to copy the structure.
Honorable Mention:
Is Serverless Just a New Word for Cloud-Based?
Top 10 Most Commented
These posts generated some healthy discussions (not surprisingly, this list overlaps with the first):
- A Look at MyRocks Performance
- Tuning InnoDB Primary Keys
- Tuning Autovacuum in PostgreSQL and Autovacuum Internals
- About ZFS Performance
- How to Speed Up Pattern Matching Queries
- Using AWS EC2 instance store vs EBS for MySQL: how to increase performance and decrease cost
- 40 million tables in MySQL 8.0 with ZFS
- Tune Linux Kernel Parameters For PostgreSQL Optimization
- Fsync Performance on Storage Devices
- One Billion Tables in MySQL 8.0 with ZFS
Posts Worth Revisiting
Don’t miss these great posts that have excellent information on important topics:
- Scaling PostgreSQL with PgBouncer: You May Need a Connection Pooler Sooner Than You Expect
- Percona Monitoring and Management: Look After Your pmm-data Container
- Comparing Data At-Rest Encryption Features for MariaDB, MySQL and Percona Server for MySQL
- Running Percona XtraDB Cluster in Kubernetes/OpenShift
- Installing MySQL 8.0 on Ubuntu 16.04 LTS in Five Minutes
- Setting up PMM on Google Compute Engine in 15 minutes or less
Have a great end of the year celebration, and we look forward to providing more great blog posts in 2019.
