Миграция с Apache Tika
Apache Tika — де-факто JVM-библиотека для извлечения текста из огромного числа форматов, включая DOCX, XLSX, PPTX и устаревшие DOC, XLS, PPT. Если ваш пайплайн работает исключительно с Office-документами, Office Oxide — подходящая замена: те же шесть форматов, никакой JVM, нативная скорость, более простое развёртывание.
Когда стоит мигрировать
Переходите, если хотя бы один из пунктов вам близок:
- Инжест-пайплайн работает только с Office-документами (PDF, EPUB, RTF, ODT и прочее, что умеет Tika, вам не нужно)
- Вы не хотите тащить и настраивать JVM в контейнер / Lambda / настольное приложение
- Нужны нативные привязки для Python, Node.js, Go, C#, Rust — а не только Java-JAR
- Важна задержка на файл; старт JVM и прогрев Tika ощутимо бьют по короткоживущим воркерам
- Нужен структурированный вывод Markdown / IR для LLM- и RAG-пайплайнов
Оставайтесь на Tika, если:
- Вы обрабатываете длинный хвост форматов, которые Office Oxide не поддерживает (Tika охватывает около 1 400 типов файлов)
- У вас уже есть JVM-сервис инжеста, и архитектурные изменения ради нативных привязок нецелесообразны
- Вы полагаетесь на MIME-детекцию Tika для этого длинного хвоста
Распространённый компромисс: оставить Tika для редких форматов, а .docx / .xlsx / .pptx / .doc / .xls / .ppt (которые составляют основной объём в большинстве корпоративных корпусов) передать Office Oxide.
Установка
Python
pip install office-oxide
(Заменяет Python-обёртки tika или apache-tika вместе с самой JVM, на которой они работали.)
Rust
[dependencies]
office_oxide = "0.1.0"
Java
Если вы остаётесь на JVM, используйте Office Oxide через его C FFI вместе с JNA / JNR-FFI. Как вариант, запускайте office_oxide_cli как sidecar-процесс через stdio — тот же движок, без JVM-мостового кода.
Сравнительная шпаргалка — Python
Обычный текст
Tika (REST-режим)
import tika
from tika import parser
tika.initVM() # JVM startup; ~1-2s on first call
parsed = parser.from_file("report.docx")
text = parsed["content"]
metadata = parsed["metadata"]
office_oxide
from office_oxide import Document
with Document.open("report.docx") as doc:
text = doc.plain_text()
props = doc.as_docx().core_properties() # author, modified, etc.
Ни запуска JVM, ни REST-раундтрипа — извлечение за доли миллисекунды.
Байтовый ввод (без временного файла)
Tika
import io, requests
from tika import parser
data = requests.get(url).content
parsed = parser.from_buffer(io.BytesIO(data))
office_oxide
import requests
from office_oxide import Document
data = requests.get(url).content
with Document.from_bytes(data, "docx") as doc:
print(doc.plain_text())
Сервер / пакетная обработка
Tika — обычно запускается в режиме tika-server за HTTP.
java -jar tika-server.jar -h 0.0.0.0 -p 9998
import requests
text = requests.put("http://localhost:9998/tika",
data=open("report.docx", "rb"),
headers={"Accept": "text/plain"}).text
office_oxide — забудьте о JVM и сервере, просто вызывайте библиотеку напрямую. Если нужна sidecar-архитектура (клиенты на разных языках), используйте MCP-сервер или CLI через stdio.
Сравнение для пользователей JVM
Если у вас Java/Kotlin/Scala-пайплайн и отказываться от JVM вы не собираетесь:
- Оставьте Tika для всего, что выходит за рамки Office.
- Для Office-форматов вызывайте
office-oxide. Два варианта:- JNA / JNR-FFI поверх
liboffice_oxideи C-заголовкаinclude/office_oxide_c/office_oxide.h. Тот же C API, что используют привязки Go и C#. - Sidecar
office_oxide_cliчерезProcessBuilder. Стримите ввод через stdin, читайте вывод из stdout. Легко перезапускается, изолирует сбои.
- JNA / JNR-FFI поверх
Оба варианта быстрее, чем запускать Tika на Office-форматах, — и избавляют от причуд «JVM внутри JVM».
Что вы получаете по сравнению с Tika
| Tika | Office Oxide | |
|---|---|---|
| DOCX, XLSX, PPTX | ✓ | ✓ |
| Устаревшие DOC, XLS, PPT | ✓ | ✓ |
| PDF, EPUB, RTF, ODT и т. д. | ✓ | ✗ (для PDF — pdf_oxide) |
| Извлечение обычного текста | ✓ | ✓ |
| Вывод в Markdown | частично | ✓ (встроенный to_markdown) |
| Структурированный IR / JSON | XHTML SAX-события | ✓ (типизированный DocumentIR) |
| Поиск-и-замена для шаблонов | ✗ | ✓ (EditableDocument) |
| Запись ячеек (XLSX) | ✗ | ✓ (set_cell) |
| Конвертация legacy → modern | ✗ | ✓ (save_as) |
| Требуется JVM | ✓ | ✗ |
| Нативная скорость | накладные расходы JVM | <1 мс на файл |
Производительность (только Office-форматы)
Инжест миллиона Office-документов (смесь DOCX, XLSX, PPTX, DOC, XLS, PPT), измеренный против tika-server:
| Пайплайн | Реальное время | Примечания |
|---|---|---|
| tika-server (REST), 8 воркеров | ~3 ч 40 мин | Включая HTTP-накладные расходы |
| tika-app (in-process JVM), 8 воркеров | ~1 ч 50 мин | Лучший сценарий для Tika |
| office_oxide, 8 воркеров | ~3 мин | Нативный парсинг |
Цифры зависят от соотношения форматов; для инжест-ориентированных Office-нагрузок разрыв обычно составляет 30–60 раз.
Смотрите также
- Бенчмарки производительности — полные числа по каждому формату
- Office для RAG — RAG-паттерны на замену Tika
- MCP-сервер — sidecar для кроссязычных пайплайнов