Most database problems are fixable. A slow query gets an index. A hot table gets partitioned. A node runs out of memory and you add another. The feedback loop is tight enough that you can experiment your way to a better configuration without touching application code or migrating data.
One thing that can really wreck your performance in Cassandra and the similar YugabyteDB YCQL is large partitions due to an imbalanced key. Without the robust nodetool commands of Cassandra, it can be challenging to find these large partitions in YugabyteDB.
Today’s global and distributed applications often need to serve user requests from a single data source across different regions. While providing data scaling and protection against network outages, ensuring low-latency access to data is critical for providing a seamless user experience. YugabyteDB, a distributed SQL database, is designed to handle global data workloads efficiently. In this blog post, I’ll share some techniques to optimize read and write latency in a multi-region YugabyteDB cluster.
Modern distributed databases split large tables into tablets to enable parallel processing and efficient data distribution. Finding the right tablet size impacts everything from query performance to operational overhead. Let’s explore how to approach tablet sizing systematically to achieve optimal performance.
Timing of seasonal demand depends on the industry, but a cyclical increase in traffic applies to all industries. Maybe your cycle is shorter than a full year. Or maybe it’s related to things like weather patterns or fashion.
A distributed database is designed to withstand outages to a good degree. However, you should also maintain backups in case of “oops” scenarios like a dropped table.
Memory configuration in YugabyteDB for YSQL workloads involves partitioning among the tserver, master, and postgres processes, each with default ratios. Adjusting these ratios based on workload characteristics helps avoid out-of-memory events. Monitoring memory usage is crucial, and tuning parameters like max_connections, work_mem, and temp_file_limit can optimize both performance and resource utilization.
At DSS 2021, I provided a comprehensive orientation to monitoring YugabyteDB, focusing on how to interpret and leverage built-in metrics for operational visibility.
Migrating Oracle workloads to Google Cloud’s Bare Metal Solution (BMS) offers benefits like reduced rewrites, familiar hardware, and simplified licensing. Challenges include server sizing, OS changes, and database upgrades. Careful planning and consolidation are key for large databases, and BMS is well-suited for organizations aiming to minimize downtime and risk during migration.
PostgreSQL offers multiple backup options, including logical backups with pg_dump and pg_dumpall, and physical backups with pg_basebackup. Regular backups and testing restore procedures are essential for disaster recovery. Continuous archiving and point-in-time recovery provide additional protection and flexibility for critical database environments.