Сегодня я решил провести еще один абсурдный тест на Amazon Aurora, на этот раз играя с разными движками MySQL.

Маленький абсурдный эксперимент с MySQL и Aurora

Amazon RDS и Amazon Aurora полностью поддерживают ИнноБД механизм хранения для экземпляров БД MySQL. Существуют функции, такие как восстановление моментальных снимков, которые поддерживаются только для механизма хранения InnoDB. Но InnoDB — не единственный движок, доступный в RDS для MySQL или Aurora MySQL.

Вы можете увидеть все включенные движки, работающие на простом:

MySQL> show engines;

+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| Engine             | Support | Comment                                                        | Transactions | XA   | Savepoints |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| FEDERATED          | NO      | Federated MySQL storage engine                                 | NULL         | NULL | NULL       |
| MEMORY             | YES     | Hash based, stored in memory, useful for temporary tables      | NO           | NO   | NO         |
| InnoDB             | DEFAULT | Supports transactions, row-level locking, and foreign keys     | YES          | YES  | YES        |
| PERFORMANCE_SCHEMA | YES     | Performance Schema                                             | NO           | NO   | NO         |
| MyISAM             | YES     | MyISAM storage engine                                          | NO           | NO   | NO         |
| MRG_MYISAM         | YES     | Collection of identical MyISAM tables                          | NO           | NO   | NO         |
| BLACKHOLE          | YES     | /dev/null storage engine (anything you write to it disappears) | NO           | NO   | NO         |
| CSV                | YES     | CSV storage engine                                             | NO           | NO   | NO         |
| ARCHIVE            | YES     | Archive storage engine                                         | NO           | NO   | NO         |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
Войти в полноэкранный режим

Выйти из полноэкранного режима

InnoDB — это дефолт engine и тот, который вы должны использовать для (почти) каждой таблицы, которая у вас есть. Если только вы не заботитесь о данных, хранящихся в таблице.

Но InnoDB не самый быстрый и легкий механизм хранения на RDS. Нет, я не говорю о MyISAM, я говорю о мусорном баке, ЧЕРНАЯ ДЫРА механизм хранения:

Механизм хранения BLACKHOLE действует как «черная дыра», которая принимает данные, но отбрасывает их и не сохраняет. Извлечение всегда возвращает пустой результат.

Какая?

Лучший способ оптимизировать IOPS и уменьшить количество проблем с данными — не хранить данные в первую очередь. Хорошо, мы будем хранить меньше данных, но действительно ли у нас есть преимущества в использовании ЦП?

Каково влияние на DBLoad почти все на DBLoadNonCPU? Сколько на самом деле стоит хранение (бесполезных) данных?

Любая реальная разница?

Мы проведем небольшой эксперимент с экземпляром Aurora Serverless с фиксированным размером 4 ACU (примерно 8 ГБ).

Давайте создадим простую таблицу и процедуру для ее заполнения несколькими (миллионами и бесполезными) записями. Здесь нет ничего особенного, просто несколько случайных чисел и 5 миллионов записей для каждого звонка.


CREATE TABLE data
(id bigint(20) NOT NULL AUTO_INCREMENT,
datetime TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP,
value float DEFAULT NULL,
PRIMARY KEY (id)) ENGINE=InnoDB;

DELIMITER $$
CREATE PROCEDURE generate_data()
BEGIN
  DECLARE i INT DEFAULT 0;
  WHILE i < 5000000 DO
    INSERT INTO data (datetime,value) VALUES (
      FROM_UNIXTIME(UNIX_TIMESTAMP('2022-01-01 01:00:00')+FLOOR(RAND()*31536000)),
      ROUND(RAND()*100,2));
    SET i = i + 1;
  END WHILE;
END$$
DELIMITER ;
Войти в полноэкранный режим

Выйти из полноэкранного режима

Теперь мы можем вызвать нашу простую процедуру (дважды, чтобы убедиться, что результаты не являются случайными и воспроизводимыми) и сравнить показатели базы данных с движками InnoDB и BLACKHOLE. Мы немного спим (200 секунд) между выполнениями, чтобы иметь более четкие метрики:

CALL generate_data();
SELECT sleep(200);
CALL generate_data();

SELECT sleep(200);
ALTER TABLE data ENGINE=BLACKHOLE;

CALL generate_data();
SELECT sleep(200);
CALL generate_data();

Войти в полноэкранный режим

Выйти из полноэкранного режима

И победителем становится…

Как и ожидалось, разница в загрузке процессора базы данных огромна, хранение (бесполезных) данных недешево.

ЦП: InnoDB против BLACKHOLE

Пропускная способность вставки увеличивается, что сокращает время, необходимое для выполнения процедуры.

Вставка пропускной способности: InnoDB против BLACKHOLE

Ты шутишь, да?

Нет, есть некоторые угловые случаи, когда выполняется простой:

ALTER TABLE myUselessTable ENGINE=BLACKHOLE;

не совсем сумасшедший. Среди сценариев:

  1. Тревожная кнопка. Хорошо, ваша база данных действительно исчерпала IOPS, у вас нет логического сегментирования для разделения трафика на отдельные экземпляры. И вертикальное масштабирование не поможет. Если у вас есть какие-то данные, которые вы можете потерять, запуск таблицы на BLACKHOLE может быть выходом из тюрьмы.

  2. Ускорить изменения приложения. Хорошо, эта крутая функция в вашем продукте уже не такая крутая, вы решили прекратить сбор данных и удалить ее, но у вас не будет исправления/новой версии в течение нескольких дней или недель. Возможно, вам повезет, и вы тем временем сможете сбросить записи.

3 Тест влияние вашей новой интересной функции сильно на скорость записи в секунду при сложной рабочей нагрузке. Попробуйте с черной дырой и без нее, как в этих фиктивных тестах. Вы можете получить некоторые полезные и страшные цифры.

Устойчивость?

Поскольку все говорят об устойчивости, давайте добавим последнее замечание. В прошлом месяце я присутствовал на выступлении Sheen Brisals об устойчивости бессерверных технологий в Конференция по бессерверной архитектуре в Берлине. Одним из ключевых идей Шина было избавление от бесполезных данных: если данные вам не нужны, не храните их.

Если вам не нужны данные, не сохраняйте их

Герт Линдерс недавно поделился схожей точкой зрения:

В петабайтном озере данных нет никакой ценности без доступа к данным.

Я полностью согласен, т. лучший способ иметь меньше проблем с данными — не иметь данных. И цена бесполезных данных — это не только хранение.

Не храните данные, которые вам не нужны. Вы не только берете хранилище, которое вам не нужно. Вы сжигаете циклы процессора. Вы согреваете планету. Вы истощаете свою кредитную карту. Вы замедляете свое приложение.

Возможно, вам даже не потребуется менять продукт, чтобы воспользоваться некоторыми преимуществами. Продолжайте с этой простой ALTER TABLE.

Или удалите всю базу данных и остановите этот экземпляр RDS/Aurora. Ладно, может быть, я просто шучу.