It was simply amazing for me as an ex-MySQL AB to be at the conference today. I felt really emotional seeing so much people, most of whom I know, all together again. The spirit was again the right one, with the will to say WE ARE HERE! It was more than impressive, and I am happy to say once more: “I was there”. I am not going to comment the keynote speeches, but I do want to share the Baron message. We are here to share, and to help each other become better and go beyond our current limit.
I have only one world: AMAZING.
Topic: Measuring Scalability and Performance with TCP
What if you had all the data you needed to measure system performance and scalability at any tier, discover performance and stability
problems before they happen, and plan for capacity and performance by modeling the system’s behavior at greater load than you currently have?
Now it is as easy as running tcpdump and processing the result with a tool. In this two-part talk, you will first learn how to do black-box performance analysis to discover hidden problems in your systems. In the second part, you will learn about mathematical performance and scalability models, how the inputs can be computed from TCP packet headers, and how to derive and interpret the results with free tools from Percona Toolkit.
The talk was good, as we are now used to get from Baron. Baron has reviewed and refined the slides, which are now much more clear. The proposed method for the quick performance analysis using TCP dump is simple and efficient. Honestly, we do use it already. However, Baron added the scientific notations that makes an empiric measurement more objective, especially in regards to the immediate issue identification and the concurrency calculation. On this specific topic, I still need to digest/elaborate.
Like the formula for the concurrency:
Neil J. Gunther’s book
? Guerrilla Capacity Planning
Topic: Hibernate and Connector/J Tuning
Many Java developers using MySQL as a data backend rely on Hibernate to bridge their OO designs with the relational database world.
This talk will review Hibernate and some of its related projects, with a focus on performance. We will also cover performance-related considerations about Connector/J, discussing settings and usage scenarios that will be useful even for Java developers not using Hibernate.
I attended this talk, expecting more and less. I expected more focus on possible Hibernate problems that we find every day because customers have no idea how to use Hibernate. I also expected less because the presentation was giving too many details of few Select and was too fast in describing the solutions.
Anyhow, given my huge background in programming, I was not really enlightened by the information and was able to follow the flow of the information. The info was based on good sense in using the standard feature and definitions in Hibernate, regarding the Lazy load of the collections, and the way SELECT … JOIN(s) needs to be done.
Finally, it provided a good review of what the MySQL JDBC can really do.
Topic: Build Simple and Complex Replication Clusters with Tungsten Replicator
Tired of the intricacies of circular replication? Dreaming of real multiple masters solutions for MySQL replication? Dream no more. Tungsten Replicator, a free and open source replacement for MySQL replication, can build clusters of asynchronous nodes in a matter of minutes. This workshop will explain the basics of Tungsten Replicator, and it will show how to start your multiple master cluster in a few minutes. There will be examples of several topologies: from the simplest bi-directional replication to the ambitious all-to-all (every node is a master), fan-in (multiple masters to a single slave), the star (a central hub connected to several bi-directional masters).
Mysql 5.6 is going to be GA soon, probably at the end of September. By then, most products that use customized replication solutions will be obsolete, but not the replicator. Continuent has developed a good solution for the multi master/multi master single slave solution that will remain valid in the time. Also, replicator offers MySQL -> Oracle replication and Oracle -> MySQL replication.
It is going to be the perfect solution for many customers who need to have a scalable replication solution and/or relation with Oracle databases.
The parallel replication is and will remain by schema, with no real mechanism to guarantee the data integrity between masters/slave given the checksum will be calculated on the command and not on the data. Plus, the installation was facilitated a lot with the replicator installer.
Topic: MySQL Optimizer Standoff MySQL 5.6 and MariaDB 5.3
Both MySQL 5.6 and MariaDB 5.3 introduced advanced game changing optimizer features. In this presentation, we will look in detail and comparison on these changes as well as perform benchmarks to show which version is able to handle complex queries better.
If you’re working with applications using complex queries with MySQL this presentation is for you.
This speech was somehow a little strange. From one side, Peter presented his results on the evolution on the optimizer; on the other side, a few developers from MariaDB team discussed most of the results.
The most important point is and remains that the MySQL Optimizer, one of the most important elements of the MySQL DB platform, is finally revisited from both sides (MariaDB and Oracle MySQL). Optimizer was revisited in full to be included in MySQL 6.0. This MySQL version was never released, and in consequence, all the improvements done so far on the Optimizer were forgotten and left aside the release delivery.
Optimizer is the core of any DB platform. It mainly decides how to physically access the data, reads the SQL statements, and translates it into an action plan against Indexes and table reads. The optimizer goes for lower cost and not for execution time. To do so, the optimizer uses statistics; if a DBA does not collect accurate statistics, the optimizer will not be able to identify an efficient action plan. It is a fact that changes to the optimizer are always scary, giving that they can overturn successful SQL statements in very bad SQL statements.
The MySQL optimizer still has serious limitations like not using prepared statement to execute the queries, so any query will invoke/involve the optimizer. From the many improvements done on both sides, Maria DB and MySQL 5.6 are much more efficient than 5.5, of an order of 5.5. 900 sec 5.6 maria 180 sec. MariaDB is much more efficient than MySQL 5.6 in many cases.
Speaker: Peter Zaitsev