Розмір транзакції MySQL - наскільки великий занадто великий?

У мене є процес імпорту, який запускається так часто, і я хочу, щоб це була угода "все або нічого", так само: транзакція.

Є багато аспектів, і імпорт може давати десь між 100 000-1 мільйонів записів. Це прирівнюється до корисного навантаження, що становить від декількох МБ до кількох сотень МБ даних.

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

Чи є якісь застереження, які слід знати про подібну практику, коли велика кількість маніпулювання даними між комітетами? (Поза типовим вибухом завантаження / індексування навантаження, коли воно здійснено)

— толстянка
джерело

Особисто мені подобається мати баланс. Я імпортую в 1 к або 10 к транзакцій, тому що я просто знаю, що він досяг приблизно 900k рядків, а потім зазнає краху через розмір буфера або щось інше смішне. Вибирати з цього досить просто, і не так багато вводу / виводу.

— Гіпертекст капітана

Одне вузьке місце, про яке слід пам’ятати, є буфер журналу InnoDB. Розмір встановлюється innodb_log_buffer_size . Ось що говорить про це Документація MySQL:

Розмір у байтах буфера, який InnoDB використовує для запису до журнальних файлів на диску. Значення за замовчуванням - 8 МБ. Великий буфер журналу дозволяє виконувати великі транзакції без необхідності записувати журнал на диск до здійснення транзакцій. Таким чином, якщо у вас великі транзакції, збільшення буфера журналу збільшує збереження дискового вводу / виводу.

Буфер журналу InnoDB не слід плутати з пулом InnoDB Buffer. Основна різниця між ними - їх призначення. Буфер журналу InnoDB в основному запише короткочасні зміни, які записуються до повторних журналів (ib_logfile0, ib_logfile1). Пул буфера InnoDB (розміром з innodb_buffer_pool_size ) кешує дані та індексні сторінки, які мають бути скоєні (якщо сторінки забруднені) та зрештою записані) на диск. Після їх внесення сторінки змін залишаються в оперативній пам'яті до тих пір, поки не будуть видалені за допомогою правил LRU.

Великі транзакції повинні проходити через буфер журналу. Як було сказано, більший буфер журналу зменшить введення / виведення диска. Лише велика комісія представляла б вузьке місце.

Ви можете переглянути інші параметри InnoDB для налаштування.

innodb_flush_method : Це диктує, як обробляється флеш і чи дозволяти ОС кешувати записи в InnoDB ( Ви повинні експериментувати між O_DSYNC та O_DIRECT )
innodb_read_io_threads (Використовуйте максимальний: 64)
innodb_write_io_threads (Використовуйте максимальний: 64)
innodb_io_capacity (використовуйте більш високі значення на зразок 5000 або 10000, але апаратне забезпечення допоможе вам це зробити. Іншими словами, дозвольте апаратурі визначити ємність IO, коли ви призначите величезну кількість)
innodb_thread_concurrency : Значення за замовчуванням дорівнює 0. Я навчився з перших рук від Рональда Бредфорда в Percona NYC 2011, щоб залишити це число на 0. Це дозволяє InnoDB визначити найкращу кількість білетів на одночасну валюту, з якими він міг би працювати)

У мене є інші повідомлення про оптимізацію InnoDB для подальших досліджень

— RolandoMySQLDBA
джерело

якось я знав, що ти будеш на цьому. Дякую за ґрунтовні відповіді, які, здається, ви завжди даєте. Побічне запитання: Чи є у вас ресурси щодо використання innodb_io_capacity? Коли в документації передбачено, що споживач SATA для 5400 / 7200RPM має значення 100, чи пропонується ваша стратегія просто "зняти ліміт", встановивши це значення настільки високим?

— thinice

Зазвичай я встановлюю innodb_io_capacity вище і дозволяю апаратному забезпечити його. Я зараз додам це до своєї відповіді.

— RolandoMySQLDBA