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_oxidey la cabecera C eninclude/office_oxide_c/office_oxide.h. La misma API en C que usan los bindings de Go y C#. - Sidecar
office_oxide_clivíaProcessBuilder. Envía la entrada por stdin, lee la salida por stdout. Reinicio trivial, aísla los fallos.
- JNA / JNR-FFI contra
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
- Benchmarks de rendimiento — cifras completas por formato
- Office para RAG — patrones RAG como reemplazo de Tika
- Servidor MCP — sidecar para pipelines multilenguaje