# Manticore Search Re-indexing with mysqldump

Discover how Marius Matilionis, a senior developer and Manticore Search expert at Ivinco, leverages mysqldump to optimize large-scale search table re-indexing, achieving a 6x speedup in performance.

*Эта статья написана **Мариусом Матилионисом**, старшим разработчиком и экспертом по Manticore Search в [Ivinco](https://ivinco.com/). Ivinco специализируется на предоставлении передовых решений для поиска, оптимизации баз данных, управлении инцидентами и настройках наблюдаемости, помогая компаниям достигать более быстрых, эффективных и масштабируемых операций.*

---

### Понимание задачи
Полная переиндексация больших таблиц Manticore Search может быть трудоёмкой и требовать значительных ресурсов. При существенных изменениях конфигурации таблицы, таких как изменение исключений или модификация структур данных, часто требуется полная переиндексация для обеспечения точных результатов поиска.

### Традиционный подход: переиндексация с помощью скриптов
Традиционный метод подразумевает написание пользовательских скриптов для перебора документов, их парсинга и отправки в таблицу. Хотя такой подход обеспечивает гибкость, он может быть медленным, особенно для больших наборов данных. Узким местом часто является итеративный характер процесса, что приводит к значительным накладным расходам.

### Более эффективный подход: использование mysqldump
`mysqldump` — мощный инструмент для резервного копирования и восстановления баз данных MySQL, который можно эффективно использовать для упрощения процесса переиндексации. Путём прямого дампа и восстановления данных таблицы мы можем значительно сократить требуемое время.

#### Ключевые шаги:
- **Подготовить таблицу:**
   - **Хранить текстово‑индексируемые столбцы:** Убедитесь, что все текстово‑индексируемые столбцы `stored` как текст, чтобы оптимизировать процесс дампа и восстановления. Этот формат более эффективен для передачи данных и минимизирует потенциальные проблемы во время переиндексации.
   - **Создать новую таблицу:** Создайте новую таблицу с нужной конфигурацией, чтобы учесть изменения.

- **Выполнить mysqldump:**
   - Используйте следующую команду `mysqldump` для дампа данных таблицы:
     ```bash
     mysqldump -etc --replace -P7103 -h0 manticore rt_index_2 | mysql -P7103 -h0
     ```

- **Оптимизировать таблицу (НЕОБЯЗАТЕЛЬНО. Не требуется, если включён `auto_optimize`, что является настройкой по умолчанию):**
   - **Запустить Optimize (`optimize table rt_index_2 option sync=1`):** После процесса переиндексации размер таблицы составлял 8,9 ГБ. Процесс Optimize помогает освободить дисковое пространство (после оптимизации размер таблицы стал 4,4 ГБ) и оптимизировать структуру таблицы. Этот шаг важен для обеспечения оптимальной производительности и снижения нагрузки на хранилище.

### Анализ производительности и соображения
Наши тесты показали значительное улучшение производительности при использовании `mysqldump`:

| Тип таблицы            | Начальный размер (ГБ) |
|-----------------------|-----------------------|
| Текстовый индекс          | 3.5               |
| Текстовый индекс (хранимый)   | 4.4               |

| Тип переиндексации         | Время переиндексации (минуты) |
|-----------------------|------------------------------|
| Переиндексация на основе скриптов | 94                          |
| mysqldump             | 17                           |

Как видите, хранение текстово‑индексируемых столбцов в виде stored увеличивает начальный размер таблицы на 25 % (с 3,5 ГБ до 4,4 ГБ), но значительно сокращает время переиндексации с 94 минут до 17 минут, что дает ускорение в 6 раз.

#### Ключевые соображения:
- **Дисковое пространство:** Хотя `mysqldump` требует дополнительного дискового пространства во время процесса переиндексации, окончательный размер таблицы остаётся тем же после оптимизации. В нашем случае начальный размер таблицы был 4,4 ГБ, а после процесса переиндексации размер увеличился до 8,9 ГБ. Однако после отладки сжатия размер был уменьшен обратно до 4,4 ГБ.
- **Структура таблицы:** Конкретная структура таблицы может влиять на производительность обоих методов. Может потребоваться экспериментировать, чтобы определить оптимальный подход для вашего конкретного случая.
- **Согласованность данных:** Обеспечьте согласованность данных и избегайте конфликтов во время процесса переиндексации, особенно если таблица активно обновляется. Это может потребовать использования таких техник, как блокировка или асинхронные обновления.
- **Аппаратная и программная конфигурация:** Производительность процесса переиндексации может зависеть от таких факторов, как аппаратные ресурсы (CPU, память, дисковый ввод‑вывод), конфигурация базы данных и сетевая задержка.

### Заключение
Используя `mysqldump` для переиндексации, мы можем значительно сократить время и ресурсы, необходимые для этой критической задачи. Такая оптимизация особенно полезна для больших таблиц поиска, где производительность и эффективность имеют первостепенное значение. При выборе стратегии переиндексации тщательно оценивайте конкретные потребности вашего приложения и инфраструктуры, чтобы определить наиболее подходящий подход.

---

*Мариус Матилионис — старший разработчик и эксперт по Manticore Search в [Ivinco](https://ivinco.com/), компании, специализирующейся на решениях для поиска, оптимизации баз данных, управлении инцидентами и настройках наблюдаемости. Эта статья отражает его экспертизу в оптимизации Manticore Search для крупномасштабных приложений.*