Skip to content

Миграция с 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. Легко перезапускается, изолирует сбои.

Оба варианта быстрее, чем запускать 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 раз.

Смотрите также