Planet MySQL Planet MySQL: Meta Deutsch Español Français Italiano 日本語 Русский Português 中文
10 Newer Entries Showing entries 91 to 100 of 744 10 Older Entries

Displaying posts with tag: performance (reset)

Why Unique Indexes are Bad
+1 Vote Up -0Vote Down

Before creating a unique index in TokuMX or TokuDB, ask yourself, “does my application really depend on the database enforcing uniqueness of this key?” If the answer is ANYTHING other than yes, do not declare the index to be unique. Why? Because unique indexes may kill your write performance. In this post, I’ll explain why.

Unique indexes are a strange beast: they have no impact on standard databases that use B-Trees, such as MongoDB and MySQL, but may be horribly painful for databases that use write optimized data structures, like TokuMX’s Fractal Tree(R) indexes. How? They

  [Read more...]
What the Mean Really Means
+0 Vote Up -0Vote Down

When analyzing response time, or latency, you need much more information than an average provides. The average, commonly the arithmetic mean, shows the index of central tendency. But, as I found in earlier posts, the tendency is often not central, but may be skewed by outliers, or split by multiple modes. How often these factors occur was determined quantitatively, using tests and a survey of hundreds of production servers and different types of latency: over 95% had six-sigma outliers, and

  [Read more...]
Scalability Tips & Greatest Hits
+0 Vote Up -0Vote Down

Join 8000 others and follow Sean Hull on twitter @hullsean. In the past two years we’ve written a ton of material on scalability. Here’s the greatest hits… Why Generalists Are Better at Scaling the Web The internet stack is a complex infrastructure of interlocking components. An scalability engineer must be adept at Linux, plus webservers, […]

The post Scalability Tips & Greatest Hits appeared first on Scalable Startups.

Modes and Modality
+1 Vote Up -0Vote Down

It is a truth universally acknowledged that the average is the index of central tendency. But what if the tendency isn’t central?

I’ve worked many performance issues where the latency or response time was multimodal, and higher-latency modes turned out to be the cause of the problem. Their existence isn’t shown by the average – the arithmetic mean; it could only be seen by examining the distribution as a histogram, density plot, heat map, or frequency trail. Once you know that more than

  [Read more...]
OurSQL Episode 145: Biblical Tools, part 3
+3 Vote Up -0Vote Down

This week we finish up talking about the Openark Kit for MySQL. Ear Candy is using both --master-data and --tab with mysqldump, and At the Movies features Robert Hodges of Continuent presenting Scalable MySQL Operation in the Cloud with Continuent Tungsten.

Openark Kit series:
Part 1
Part 2

Openark Kit
oak-purge-master-logs
PURGE BINARY LOGS at the MySQL manual page.

read more

OurSQL Episode 144: Biblical Tools, part 2
+2 Vote Up -0Vote Down

This week we continue talking about the Openark Kit. Ear candy is the Percona Configuration Wizard, and At the Movies is a keynote from the SkySQL and MariaDB Solutions Day about the SkySQL and MariaDB merger and the MariaDB Foundation.

Openark Kit series:
Part 1
Part 3

Events
DB Hangops - every other Wednesay at noon Pacific time

Upcoming MySQL events (http://www.mysql.com/news-and-events/events/)

Training
SkySQL Trainings

read more

TokuMX Fractal Tree(R) indexes, what are they?
+1 Vote Up -0Vote Down

With our recent release of TokuMX 1.0, we’ve made some bold claims about how fast TokuMX can run MongoDB workloads. In this post, I want to dig into one of the big areas of improvement, write performance and reduced I/O.

One of the innovations of TokuMX is that it eliminates a long-held rule of databases: to get good write performance, the working set of your indexes should fit in memory. The standard reasoning goes along the lines of: if your indexes’ working set does not fit in memory, then your writes will induce I/O, you will become I/O bound, and performance will suffer. So, either make sure

  [Read more...]
Detecting Outliers
+1 Vote Up -0Vote Down

In computer performance, we’re especially concerned about latency outliers: very slow database queries, application requests, disk I/O, etc. The term “outlier” is subjective: there is no rigid mathematical definition. From [Grubbs 69]:

An outlying observation, or “outlier,” is one that appears to deviate markedly from other members of the sample in which it occurs.

Outliers are commonly detected by comparing the maximum value in a data set to a custom threshold, such as 50 or 100 ms for disk I/O. This requires the metric to be well understood beforehand, as is usually the case for

  [Read more...]
Fun with Bugs #14 - InnoDB in MySQL 5.6
+2 Vote Up -1Vote Down
InnoDB improvements in MySQL 5.6 are well known. One of the key reasons to upgrade to MySQL 5.6 for most users is to get the benefits of improved performance, scalability, new monitoring features and fulltext indexes support in InnoDB.

Is there anything to double check before assuming that InnoDB in MySQL 5.6 is just better than any older version for any practical purposes? Let's review known public InnoDB-specific bug reports. Here is my "Top 10" list, as of MySQL 5.6.12, starting with most recent reports:

  • Bug #69424  - maybe I miss something (I am not the only one though), but I see no way to continue using raw devices (on Linux at least) to store InnoDB data. You had working raw device in 5.5.32, then you upgrade to 5.6.12 and just can not start MySQL any more.




  •   [Read more...]
    Benchmarking the Performance Impact of Foreign Keys in MySQL Cluster 7.3 GA
    +2 Vote Up -0Vote Down



    FOREIGN KEYs in MySQL Cluster is a big step forward. It is now possible to run enterprise software with NDB Cluster as the storage backend. Over the years, the lack of FOREIGN KEYs have been one of the most limiting pieces of functionality. Who wants to fiddle with TRIGGERs or recode applications to enforce data integrity?
    But finally, it is here. It is implemented natively at the Data Node level, where NDB stores its data. It is well known that FOREIGN KEYs come with an overhead. E.g., when writing a record into a child table, the existence must be checked in the parent table. Since data is distributed across multiple Data Nodes, the child record and parent record may be on different nodes or shards (Node Groups). Hence there is extra work to be done in terms of internal triggers and network communication, the



      [Read more...]
    10 Newer Entries Showing entries 91 to 100 of 744 10 Older Entries

    Planet MySQL © 1995, 2014, Oracle Corporation and/or its affiliates   Legal Policies | Your Privacy Rights | Terms of Use

    Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.