Тест MySQL с пакетной вставкой в ​​несколько потоков в одной таблице - PullRequest
Новая
       34

Тест MySQL с пакетной вставкой в ​​несколько потоков в одной таблице

2 голосов
/ 02 июля 2019

Я хочу протестировать интенсивную запись между InnoDB и движком MyRock базы данных MySQL.Для этой цели я использую sysbench для тестирования.Мои требования:

  • параллельная запись нескольких потоков в одну и ту же таблицу.
  • поддержка пакетной вставки (каждая транзакция вставки будет вставлять большую часть записей)

Я проверяю все готовые тесты sysbench и не вижу тестов, удовлетворяющих моим требованиям.

  • oltp_write_only: поддерживает несколько потоков, которые записывают в одну таблицу.Но в этом тесте нет опции массовой вставки.
  • bulk_insert: поддержка нескольких потоков, но каждый поток записывает в разные таблицы.

Есть ли какие-либо готовые sysbenchтесты удовлетворили мое требование?Если нет, могу ли я где-нибудь найти пользовательские сценарии Lua, которые уже сделали это?

(из Комментарий:) 

CREATE TABLE IF NOT EXISTS `tableA` (
    `id` BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT, 
    `user_id` VARCHAR(63) NOT NULL DEFAULT '', 
    `data` JSON NOT NULL DEFAULT '{}', 
    PRIMARY KEY (`id`), 
    UNIQUE INDEX `user_id_UNIQUE` (`user_id` ASC)
) ENGINE = InnoDB;

1 Ответ

0 голосов
/ 05 июля 2019

(С точки зрения MySQL ...)

  • Бросок id и PK - экономит 8 байтов на строку.
  • Повышение UNIQUE(user_id) до PRIMARY KEY(user_id) - может сэкономить 40 байт на строку (зависит от LENGTH(user_id)).

Выполнение этих действий

  • Сокращение необходимого дискового ввода-вывода (обеспечивая некоторое ускорение)
  • Устранить один из индексов (вероятно, значительную часть обработки после загрузки)

Запустить инструменты мониторинга ОС, чтобы увидеть, какой процент ввода-вывода используется. То, что может быть ограничивающим фактором.

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

Еще одна мысль ...

Как выглядит JSON?Если JSON имеет простую структуру (непротиворечивый набор пар ключ: значение), тогда занимаемая площадь диска может быть вдвое меньше (следовательно, удвоение скорости), если вы создали отдельные столбцы.Обработка для перехода от JSON к отдельным столбцам будет выполняться на клиенте, что может (или не может) отменить предсказываемую мной экономию.

Если JSON более сложный, все равно может быть экономия, если потянутьout "столбцы", которые всегда присутствуют.

Если JSON "большой", то сжать его в клиенте, а затем записать в BLOB.Это может уменьшить занимаемую площадь диска и пропускную способность сети в 3 раза.

Вы упомянули 250 ГБ для 250M строк?Это 1000 байт / строка.Что означает, что в среднем JSON составляет 700 байт?(Примечание: это накладные расходы.) Сжатие столбца JSON в BLOB сократится до, возможно, 400 байт / строка в целом, следовательно, только 100 ГБ для 250M строк.

{"b": 100} занимает около 10 байтов.Если b можно сохранить в 2-байтовом столбце SMALLINT, это значительно сократит запись.

Другое дело: если вы повышаете user_id до PK, тогда стоит подумать: используйте сортировку файловотсортировать таблицу по user_id перед загрузкой.Это вероятно быстрее, чем INSERTing строк "случайно".(Если данные уже отсортированы, то дополнительная сортировка будет потрачена впустую.)

...