And before we proceed with our wrap-up, let’s pause for a second to reflect on just how awesome it is to attend a conference like Percona Live. Where even the most casual conversation you overhear is talking about things like optimal page sizes (4k etc) & cache eviction strategies. I. Love. Databases!
We recommended a lot of interesting sessions to attend, but of course we didn’t get to attend all of them (our booth was too busy). However, many if not most of the sessions should be appearing online here in a ‘videos’ section in coming weeks (for example, here’s my presentation on MySQL Scaling Strategies from last year.)
Our own Peter Friedenbach did get a lot of interest in his benchmarking session. Benchmarking is a lot more than pointing sysbench at your server, and good benchmarking deserves a lot more respect (and careful effort) than is commonly perceived. See Peter’s session at Percona.
We did get to meet people like Frédéric Descamps from the MySQL Engineering Team, not only at his session, but walking around the Exhibit Hall.
But the coolest thing was being immersed in the ‘MySQL universe’ for a week and getting a good sense of the current ‘lay of the land.’ For instance:
MySQL Scaling: We met a lot of people and companies with MySQL scale problems, including:
- Large sharded topologies whose ongoing maintenance is costing more than expected… and faced with additional growth are starting to look for other solutions
- Large MySQL deployments right on the cusp of ‘needing’ to shard, but don’t like the prospect of:
- Needing to hire additional DBAs to build it out
- Needing additional redundant hardware to ensure HA
- Needing ongoing shard maintenance and data rebalancing
- SaaS providers with a ‘pod per group of customers’ or ‘pod per large customer’, or ‘pod per database’… but staring at the problem, “what happens when the database (ie, smallest shared resource) gets larger than my biggest MySQL instance?”
Galera Replication: This year I found a lot more common knowledge that Galera Replication (i.e. underpinning MariaDB Cluster & Percona XtraDB) won’t solve your application’s write scale problem. It works for a consolidation workload (each application has its own write-server), but if a single app needs to write to more than 1 server while remaining strongly consistent, Galera isn’t the solution. It works great for HA, which people appreciate; they just want write scale as well.
NoSQL for Scale Misses Important Use Cases: Many people came-by talking about transactional workloads they’d put on Cassandra or Mongo. At first you’d question- “Why?” Well, because both are ‘free’ and scale-out. However, sooner or later they realize:
- There’s lots of redundant hardware, due to multiple copies of the same data across multiple nodes
- The loss of a central RDBMS to guarantee cross-node ACID compliant JOINs, referential integrity, and ad-hoc queries starts to really affect business flexibility
‘Open Source’ (code for ‘free’) plus ‘scale-out’ drove the decision by upper management, but for many, now the Application Devs, DevOps, and DBAs were stuck trying to build-in those transactional ACID guarantees and referential integrity constraints themselves.
‘Bolt-on RDBMS’, indeed.
The Holy Grail: One attendee put it best: “I want what I have on a 1 node MySQL system, just larger”
What We Do: A Quick Pitch for ClustrixDB. We found lots of people interested in ClustrixDB architecture. Whereas some have looked at our technical white papers with raised eyebrows- the recent announcement of Cloud Spanner, leveraging a similar model to ours, got a nod of recognition from many attendees. Now most technical people are familiar with Spanner and realize that 2PL and multi-node consistency guaranteed by Paxos not only is feasible, it’s very performant. (And by the way- with CLX you also get full SQL semantics, online schema changes, ad-hoc queries, & dynamic PK/FK referential integrity as well)
We really enjoyed participating in Percona Live 2017, and are looking forward to next year!