Я нахожусь в процессе обновления / выбора ресурсов для приложения, работающего на базе данных MySQL, работающей на Amazon RDS. Я рассматриваю возможность внедрения реплик чтения и некоторых других стратегий для повышения доступности при возрастающих нагрузках. (Самая старая история в книге.) Таким образом, я наблюдал за своим сервером БД и пытался понять, где находятся узкие места и тому подобное, и я получаю очень противоречивую информацию о том, что соотношение чтения / записи:
Во-первых, я скажу, что мое приложение относительно тяжело писать по сравнению со многими другими типами приложений. Я это знаю.
Используя облачные часы в панели управления AWS RSD, я обычно вижу следующие показатели:
Соотношение операций чтения и записи: 1:20 (1 чтение на каждые 20 записей)
Соотношения чтения и записи для пропускной способности и задержки обычно соответствуют этому соотношению.
Мне это кажется совершенно абсурдным. Я не могу представить, как и почему мое приложение будет делать намного больше операций записи, чем чтения.
Таким образом, я искал второе мнение в виде мониторинга своей БД в реальном времени с помощью панели управления MySQL Work Bench Administration Dashboard. Там доказательства другие. В среднем я наблюдаю следующее:
Прочтите выполнение запроса, чтобы написать выполнение запроса: 6: 1 (6 запросов чтения, выполняемых на каждый выполненный 1 запрос записи)
Либо один из этих инструментов мониторинга сильно неточен, либо у меня есть фундаментальное недопонимание данных.
По вопросам:
Почему эти два инструмента показывают такие совершенно разные результаты?
Есть ли для меня лучший способ точно определить эффективное соотношение чтения / записи моей базы данных, чтобы я мог принимать разумные решения о масштабировании?
Читай пиши операции ! = читать / писать запросы.
Один запрос на "запись" может привести к нескольким операциям записи ввода-вывода на диск в зависимости от характера вашего запроса, того, какой движок вы используете, какие у вас есть индексы и т. Д.