Skip to content

Migración desde Apache Tika

Apache Tika es la biblioteca JVM de facto para extraer texto de una enorme variedad de formatos — incluidos DOCX, XLSX, PPTX y los heredados DOC, XLS, PPT. Si tu pipeline solo procesa documentos Office, Office Oxide es el reemplazo adecuado: los mismos seis formatos, sin JVM, velocidad nativa, despliegue más simple.

Cuándo migrar

Cambia si se cumple alguna de estas condiciones:

  • Tu pipeline de ingesta solo maneja documentos Office (no necesitas PDF, EPUB, RTF, ODT, etc. que Tika también soporta)
  • No quieres empaquetar y afinar una JVM en tu contenedor / Lambda / app de escritorio
  • Quieres bindings nativos en Python, Node.js, Go, C# o Rust — no solo un JAR de Java
  • La latencia por archivo importa; el coste de arranque y el calentamiento de la JVM de Tika castigan a workers de vida corta
  • Quieres salida estructurada en Markdown / IR para pipelines de LLM y RAG

Sigue con Tika si:

  • Ingestas una cola larga de formatos que Office Oxide no cubre (Tika maneja ~1.400 tipos de archivo)
  • Ya tienes un servicio JVM de ingesta y añadir bindings nativos no compensa el cambio arquitectónico
  • Dependes de la detección MIME de Tika en toda esa cola larga

Término medio habitual: deja Tika para la cola larga y usa Office Oxide para .docx / .xlsx / .pptx / .doc / .xls / .ppt (que dominan el volumen en la mayoría de corpora corporativos).

Instalación

Python

pip install office-oxide

(Sustituye los wrappers Python tika o apache-tika más la JVM sobre la que los corrías.)

Rust

[dependencies]
office_oxide = "0.1.0"

Java

Si estás comprometido con la JVM, usa Office Oxide a través de su C FFI junto con JNA / JNR-FFI. O ejecuta office_oxide_cli como proceso sidecar invocado por stdio — el mismo motor, sin código puente a la JVM.

Chuleta comparativa — Python

Texto plano

Tika (modo REST)

import tika
from tika import parser

tika.initVM()    # arranque de la JVM; ~1-2s la primera vez
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.

Sin arranque de JVM, sin ida y vuelta REST, extracción en submilisegundos.

Entrada por bytes (sin archivo temporal)

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())

Servidor / procesamiento por lotes

Tika — se suele ejecutar en modo tika-server detrás de 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 — olvida la JVM y el servidor, llama a la biblioteca directamente. Si necesitas una arquitectura sidecar (clientes agnósticos al lenguaje), usa el servidor MCP o la CLI sobre stdio.

Lado a lado — usuarios JVM

Si tu pipeline es Java/Kotlin/Scala y no quieres abandonar la JVM:

  • Deja Tika para todo lo que no sea Office.
  • Para formatos Office, llama a office-oxide. Dos opciones:
    • JNA / JNR-FFI contra liboffice_oxide y la cabecera C en include/office_oxide_c/office_oxide.h. La misma API en C que usan los bindings de Go y C#.
    • Sidecar office_oxide_cli vía ProcessBuilder. Envía la entrada por stdin, lee la salida por stdout. Reinicio trivial, aísla los fallos.

Ambas son más rápidas que correr Tika para formatos Office — y evitan las rarezas de JVM-sobre-JVM.

Qué ganas frente a Tika

Tika Office Oxide
DOCX, XLSX, PPTX
DOC, XLS, PPT heredados
PDF, EPUB, RTF, ODT, etc. ✗ (para PDF usa pdf_oxide)
Extracción de texto plano
Salida Markdown parcial ✓ (integrado to_markdown)
IR / JSON estructurado eventos XHTML SAX ✓ (DocumentIR tipado)
Plantillas buscar-y-reemplazar ✓ (EditableDocument)
Escritura de celdas (XLSX) ✓ (set_cell)
Conversión heredado → moderno ✓ (save_as)
JVM obligatoria
Velocidad nativa overhead de JVM <1 ms por archivo

Rendimiento (solo formatos Office)

Ingesta de un millón de documentos Office (mezcla de DOCX, XLSX, PPTX, DOC, XLS, PPT) medida frente a tika-server:

Pipeline Tiempo de reloj Notas
tika-server (REST), 8 workers ~3 h 40 m Incluye overhead HTTP
tika-app (JVM in-process), 8 workers ~1 h 50 m Mejor caso de Tika
office_oxide, 8 workers ~3 m Parseo nativo

Los números varían con la mezcla de formatos; en cargas de ingesta predominantemente Office la diferencia suele ser de 30–60×.

Ver también