My main use case for Percona Server was for an e-commerce platform, operating as a webshop. The customer had a migration underway where they wanted to move from a certain service provider to managing things themselves. They previously used MariaDB, which did not work, so we needed to move to MySQL, and Percona has a MySQL derivative that worked for us. The use case also involved running this within a Kubernetes cluster. A specific example of how Percona Server was used in that e-commerce platform is that the state was managed through the database, and the entire hydration process occurred there as well. We had server-side rendering happening, and the client-side renders were hydrated through whatever lived in Percona Server database, which resulted in a huge amount of read operations. For redundancy and performance reasons, we worked with about three instances of Percona Server running to ensure that we got the read performance we needed. One issue was the contention and locking that occurred during write operations, and this is where I think Percona showcased that their system was better than other MySQL derivatives. We used Kubernetes installed on VPS in Hetzner for that project, and it was very important for us to have a platform that was MySQL compliant, along with all the CRDs, the custom resource definitions, required to use it properly in Kubernetes. We also needed support in managing the service, so having a specialist to tweak those parameters for good database performance was really good to have. My experience with the Kubernetes-native features was that getting it into Kubernetes was really easy. It is just a Helm chart that you throw in there, and it kind of works. Of course, Helm charts have many intricacies, so parameterizing it correctly was essential, but it provided an out-of-the-box experience for getting it into our cluster. A cool thing to call out is that they have an observability dashboard for Grafana to see what is going on, which works seamlessly. It is not just about getting everything in there, but also having visibility into how it works, and we had lots of interesting metrics available to use.
My main use case for Percona Server is deploying the community version without support to MongoDB servers in Kubernetes, and I also use Percona Server Exporter tools. Using Percona Server for deploying MongoDB servers in Kubernetes helps my team day-to-day by allowing us to quickly deploy small replica sets of MongoDB and configure it in YAML files. I use Percona MongoDB Exporter to export all metrics to Grafana.
Percona Server is my main solution for electronic information systems, and I use Percona XtraDB Cluster for this purpose. Percona Server has facilitated the configuration of clusters compared to using a large cluster setup. Percona Server helps me maintain consistency in my systems.
For the system SEI, Sistema Eletrônico de Informações, I use Percona Server XtraDB Cluster for the migration and replication of the database for this system. More material would be helpful for understanding how to further optimize the implementation.
I'm in the process of running a POC. Initially, I've been working on the vendor side and we can only suggest to the vendor how to use Percona Server as opposed to MySQL's community version. I was just working on MySQL Server to see the difference between the community version and this and how the performance goes. I'm doing the R&D on my side.
Percona Server is a MySQL alternative offering improved performance and scalability for databases used in demanding environments. It is tailored for companies requiring reliable data management, ensuring efficiency and flexibility in operations.Percona Server enhances MySQL with numerous features that boost database performance, making it suitable for large-scale deployments. Known for its ability to handle heavy workloads, users count on Percona Server to maintain operational consistency...
My main use case for Percona Server was for an e-commerce platform, operating as a webshop. The customer had a migration underway where they wanted to move from a certain service provider to managing things themselves. They previously used MariaDB, which did not work, so we needed to move to MySQL, and Percona has a MySQL derivative that worked for us. The use case also involved running this within a Kubernetes cluster. A specific example of how Percona Server was used in that e-commerce platform is that the state was managed through the database, and the entire hydration process occurred there as well. We had server-side rendering happening, and the client-side renders were hydrated through whatever lived in Percona Server database, which resulted in a huge amount of read operations. For redundancy and performance reasons, we worked with about three instances of Percona Server running to ensure that we got the read performance we needed. One issue was the contention and locking that occurred during write operations, and this is where I think Percona showcased that their system was better than other MySQL derivatives. We used Kubernetes installed on VPS in Hetzner for that project, and it was very important for us to have a platform that was MySQL compliant, along with all the CRDs, the custom resource definitions, required to use it properly in Kubernetes. We also needed support in managing the service, so having a specialist to tweak those parameters for good database performance was really good to have. My experience with the Kubernetes-native features was that getting it into Kubernetes was really easy. It is just a Helm chart that you throw in there, and it kind of works. Of course, Helm charts have many intricacies, so parameterizing it correctly was essential, but it provided an out-of-the-box experience for getting it into our cluster. A cool thing to call out is that they have an observability dashboard for Grafana to see what is going on, which works seamlessly. It is not just about getting everything in there, but also having visibility into how it works, and we had lots of interesting metrics available to use.
My main use case for Percona Server is deploying the community version without support to MongoDB servers in Kubernetes, and I also use Percona Server Exporter tools. Using Percona Server for deploying MongoDB servers in Kubernetes helps my team day-to-day by allowing us to quickly deploy small replica sets of MongoDB and configure it in YAML files. I use Percona MongoDB Exporter to export all metrics to Grafana.
Percona Server is my main solution for electronic information systems, and I use Percona XtraDB Cluster for this purpose. Percona Server has facilitated the configuration of clusters compared to using a large cluster setup. Percona Server helps me maintain consistency in my systems.
For the system SEI, Sistema Eletrônico de Informações, I use Percona Server XtraDB Cluster for the migration and replication of the database for this system. More material would be helpful for understanding how to further optimize the implementation.
I'm in the process of running a POC. Initially, I've been working on the vendor side and we can only suggest to the vendor how to use Percona Server as opposed to MySQL's community version. I was just working on MySQL Server to see the difference between the community version and this and how the performance goes. I'm doing the R&D on my side.