Тестовый запрос вставки с использованием mysqlslap - PullRequest
Новая
       11

Тестовый запрос вставки с использованием mysqlslap

0 голосов
/ 14 февраля 2019

Во-первых, я новичок в mysqlslap. Я хочу протестировать запрос вставки с использованием mysqlslap в моей существующей базе данных.Таблица, которую я хочу протестировать, имеет основной и составной уникальные данные.

Итак, как выполнить тест производительности для этой таблицы, используя mysqlslap одновременно?

Я не должен сталкиваться с ошибкой дублирования ключа mysql

Ниже приведен скелет для моего стола: 

CREATE TABLE data (
  id bigint(20) NOT NULL,
  column1 bigint(20) DEFAULT NULL,
  column2 varchar(255) NOT NULL DEFAULT '0',
  datacolumn1 VARCHAR(255) NOT NULL DEFAULT '',
  datacolumn2 VARCHAR(2048) NOT NULL DEFAULT '',
  PRIMARY KEY (id),
  UNIQUE KEY profiles_UNIQUE (column1,column2),
  INDEX id_idx (id),
  INDEX unq_id_idx (column1, column2) USING BTREE
) ENGINE=innodb DEFAULT CHARSET=latin1;

Пожалуйста, помогите мне в этом

1 Ответ

0 голосов
/ 16 февраля 2019

Есть несколько проблем с бенчмаркингом INSERTs.Скорость будет меняться по мере того, как вы будете вставлять все больше и больше, но это не будет легко предсказуемым образом.

Вставка выполняет (примерно) этот путь:

  1. Проверка на наличие дублированного ключа.У вас есть два уникальных ключа (ПК и УНИКАЛЬНЫЙ).Каждый BTree будет развернут для проверки на дублирование.Предполагая, что нет дублирования ...
  2. Строка будет вставлена ​​в данные (BTree, назначенный PK)
  3. "Строка" будет вставлена ​​в BTree каждого Уникального.В вашем случае есть BTree, эффективно упорядоченный по (column1, column2) и содержащий (id).
  4. Материал помещается в «буфер изменений» для каждого неуникального индекса.

Если у вас был AUTO_INCREMENT или UUID или ..., будет больше обсуждений.

Буфер изменений по сути является «отложенной записью» в неуникальные индексы.Эта задержка должна быть устранена в конце концов.То есть в какой-то момент все замедлится, если фоновый процесс не поспевает за изменениями.То есть, если вы вставите 1 миллион строк, вы не сможете достичь этого замедления;если вы вставите 10 миллионов строк, вы можете нажать на нее.

Другая переменная: VARCHAR(2048) (и другие TEXT и BLOB столбцы) может или может не хранится "вне записи".Это зависит от размера строки, размера этого столбца и «формата строки».Большая строка может получить дополнительный удар по диску, тем самым замедляя тест, вероятно, на заметную величину.То есть, если вы проводите тестирование только с небольшими строками и определенными форматами строк, вы получите более быстрое время вставки, чем в противном случае.

И вам необходимо понять, как работает программа сравнения - по сравнению с тем, как будет работать ваше приложение:

  • Вставка строк по одной в один поток, каждая из которых является транзакцией.
  • Вставка строк по одной в один поток - партии, объединенные в транзакцию.
  • Вставка 100 строк за раз в одном потоке в одной транзакции.
  • ЗАГРУЗКА ДАННЫХ.
  • Несколько потоков с каждым из перечисленных выше.
  • Различные настройки изоляции транзакций.
  • И т. Д.

(я не фанат тестов из-за того, сколько у них недостатков.) «Лучший» тест для сравнения оборудования или ограниченной схемыИзменения / app: захватить «общий журнал» из запущенного приложения;захватить базу данных в начале этого;время повторного применения этого журнала.

Разработка таблицы / вставки для вставленных строк по 50 КБ / с

  • Минимизация индексов.В вашем случае все, что вам нужно, это PRIMARY KEY(col1, col2);брось остальное;бросить id.Пожалуйста, объясните, что такое col1 и col2;здесь могут быть и другие советы.
  • Избавьтесь от стола.Серьезно, рассмотрите возможность суммирования 50К строк каждую секунду и сохраняйте только суммирование.Если это практично, это значительно ускорит процесс.Или, может быть, стоит минута.
  • Пакетная вставка строк каким-то образом.Детали здесь зависят от того, есть ли у вас один или несколько клиентов, выполняющих вставки, нужно ли обрабатывать данные по мере их поступления, и т. Д. Дополнительные обсуждения: http://mysql.rjweb.org/doc.php/staging_table
  • Что находится в этих строках?Можно / нужно ли их «нормализовать»?
  • Давайте обсудим математику.Будете ли вы загружать около 10 петабайт в год?У тебя так много места на диске?Что вы будете делать с данными?Сколько времени займет чтение даже небольшой части этих данных?Или это будет база данных «только для записи»?
  • Больше математики.50K строк * 0.5KB = 25 МБ записи на диск в секунду.Какое устройство у вас есть?Может ли он справиться, скажем, в 2 раза?(С вашей исходной схемой это было бы больше как 60 МБ / с из-за всех индексов.)

После комментариев

Ладно, так больше похоже на 3 ТБ, прежде чем бросить данные и начать все сначала (через 2 часа)?Для этого я бы предложил PARTITION BY RANGE и использовал бы некоторую функцию времени, которая дает вам 5 минут в каждом разделе.Это даст вам разумное количество разделов (около 25), а DROP PARTITION будет отбрасывать только около 100 ГБ, что может не перегружать файловую систему.Дополнительные обсуждения: http://mysql.rjweb.org/doc.php/partitionmaint

Что касается строк ... Вы предлагаете 25 КБ, но объявления не позволяют так много ???

...