Дієта для фотостолу Сільван Мюлеман; s блогу
Наші засоби спостереження підтверджують ситуацію: Нагіос стріляє у мій мобільний телефон за допомогою SMS, як із автомата. Сіра крива, яка описує навантаження сервера в гангліях, значно вище червоної лінії. Мореті, наш інструмент для вимірювання часу відгуку, повідомляє кілька секунд, щоб доставити сторінку фіксації.
Загальновідома ситуація, з якою ми стикаємося знову і знову, як і в останні шість років нашого існування. Існує два шляхи вирішення цієї ситуації: додаткова оптимізація апаратного чи програмного забезпечення.
Додавання обладнання - це швидке і просте рішення.
ВСТАВКИ потрібно пришвидшити
У цьому випадку ситуація інша: це страждають фотографи, які хочуть додати фотографії на веб-сайт. І менше відвідувачів, які просять лише фотографії. Функція "Додати фотографії" працює повільно. Отже, це оператори INSERT, а не запити SELECT. Додано нові фотографії. Тож нові рядки бази даних
додається:
Оскільки ми працюємо з реплікацією, ці рядки повинні бути скопійовані до всіх підлеглих. Один INSERT на підлеглого. Якщо ми додамо більше серверів до кластера, це не вирішить проблему, оскільки ці рядки також повинні бути додані до цих нових серверів. Більша кількість серверів не зменшує кількість INSERT на кластері. У цьому випадку апаратне забезпечення не допоможе.
Ми продовжуємо шукати: ВСТАВКИ викликають проблеми. ВСТАВКИ занадто повільні. Що робить ВСТАВКИ повільними? Що дорого з INSERT? Не додавання даних, а запис індексів. Індекси - це складні структури даних, B-дерева, двійкові дерева, які необхідно перевіряти на вагомість кожного разу, коли вставляється рядок. Індекси дорогі.
У випадку з нашою таблицею фотографій індекси складають навіть більше байтів, ніж дані (хоча наша структура даних є аматорською та повною надмірності)
Непотрібні стовпці та індекси!
Отже, ми почали з індексів таблиці зображень. Боже мій, які показники ми встановили у своїй юнацькій безрозсудності? Практично кожен стовпець має індекс, хоча він ніколи не використовується у запиті (перевірка за допомогою EXPLAIN SELECT). Там все ще є стовпці, які ніколи не запитуються. злий!
Прочешіть 60 000 рядків коду
Отже: ми зі Стефаном переходимо до дієти таблиці зображень: За допомогою grep по всьому коду tilllate, я перевіряю всі дзвінки до таблиці зображень. Які індекси ми можемо видалити? Які стовпці більше не потрібні?
Результат: Ми маємо три стовпці та п’ять індексів, які не використовуються. Особливо жирний повнотекстовий покажчик можна вигнати в окрему таблицю вертикальним розділенням. Це причина для задоволення, оскільки ми знайшли стільки місця для вдосконалення? Або ми повинні сердитися через нашу затяжку в системі?
Неважливо: у суботу вранці о 01:00 Стефан виконує заяви ALTER TABLE. Через дві години тривалості запиту блискавична дієта закінчена. Результат:
Зменшення файлу даних на 22%. Зменшення файлу індексу на 70%. Це призводить до швидшого ВСТАВЛЕННЯ, швидшого резервного копіювання та швидшого РЕМОНТНОГО СТОЛУ (що часто є проблемою для таблиць MyISAM).
Цей вечір покаже, чи буде фотографам легше додавати фотографії. мені цікаво.