Consultas grandes en PlanetScale con Laravel y OLAP

El problema no es solo que la consulta tarde

Una exportación completa, un informe de agregados o un backfill pueden necesitar leer muchas más filas que una petición normal. En una base Vitess como PlanetScale, conviene marcar ese trabajo como analítico en lugar de tratarlo como tráfico OLTP habitual. El detalle importante es que ese cambio afecta a la conexión, y una conexión reutilizada por un worker no debería quedarse en un modo distinto al terminar el proceso. Laravel incorpora una API para acotar ese cambio al bloque de código que realmente lo necesita. (laravel.com)

La API documentada se usa sobre una conexión

Aunque resulte tentador escribir DB::olap(), la API que aparece en la documentación oficial se invoca sobre una conexión concreta: DB::connection('mysql')->olap(...). El callback recibe la conexión que debe ejecutar la consulta y el valor que devuelva será también el resultado de olap. Así puedo mantener la consulta junto a la decisión de ejecutarla como carga analítica, sin tocar manualmente el estado antes y después. También evita esconder esa decisión en una configuración global poco visible.

use Illuminate\Support\Facades\DB;
 
$totals = DB::connection('mysql')->olap(
    fn ($connection) => $connection->table('orders')
        ->selectRaw('customer_id, sum(total) as total')
        ->groupBy('customer_id')
        ->get()
);

Este patrón encaja bien en un comando de Artisan, un job de cola o un proceso de exportación. El callback puede construir la consulta con el query builder igual que en el resto de la aplicación. No hace falta cambiar la forma de recoger el resultado ni crear un cliente específico para ese informe. Laravel devuelve exactamente lo que devuelve el callback. (laravel.com)

Por qué el callback importa en workers y Octane

Laravel establece el workload OLAP tanto en las conexiones de lectura como en las de escritura antes de ejecutar el callback. Al finalizar, restablece el workload OLTP, incluso si dentro del bloque se produce una excepción. Eso es especialmente útil cuando el proceso sigue vivo y puede reutilizar conexiones para más trabajo, como ocurre con workers de cola o servidores de larga duración. La limpieza queda ligada al ámbito de la operación y no depende de acordarme de ejecutar una llamada adicional en cada camino de error. (laravel.com)

No usaría este método como un adorno alrededor de cualquier consulta lenta. Lo reservaría para operaciones claramente analíticas y separadas del flujo de una petición web normal. Tener el bloque delimitado también facilita revisar qué consultas tienen ese tratamiento y en qué comandos o jobs se ejecutan. Si necesito registrar duración, SQL o bindings, puedo seguir utilizando las herramientas de observabilidad habituales de Laravel alrededor de esa operación.

La letra pequeña

olap no convierte una consulta mal diseñada en una consulta barata, ni sustituye revisar índices, filtros, agregaciones y volumen de datos. Tampoco gestiona por sí solo el troceado de una exportación, la reanudación de un backfill ni el almacenamiento del fichero resultante. Sigue siendo responsabilidad del proceso definir límites, controlar memoria y decidir cómo recuperarse de un fallo. La ventaja concreta es aislar el cambio de workload de Vitess de forma segura dentro de una operación.

La documentación también indica que, en una conexión MySQL que no usa Vitess, el callback se ejecuta sin cambiar el workload. Si necesito comprobarlo explícitamente, puedo usar isVitess() sobre la conexión antes de decidir si activo una ruta específica para PlanetScale. Eso permite compartir código entre entornos sin asumir que todas las conexiones MySQL tienen el mismo comportamiento. No conviene basar la lógica de negocio en OLAP si el resultado funcional debe ser idéntico en cualquier motor. (laravel.com)

$isVitess = DB::connection('mysql')->isVitess();
 
if ($isVitess) {
    // Aplicar decisiones operativas específicas para Vitess.
}

Una mejora pequeña, pero con un límite claro

La utilidad de esta API está en que expresa una intención operativa sin filtrar detalles de conexión por todo el código. La consulta sigue siendo Laravel normal; lo excepcional es únicamente el contexto en el que se ejecuta. Para trabajos grandes sobre PlanetScale, prefiero esa delimitación explícita a modificar el workload a mano y confiar en que todos los retornos y excepciones lo restauren. Es una solución precisa para un problema concreto, no una excusa para enviar cualquier consulta pesada a producción.

Fuente: Laravel News. Documentación oficial: Laravel Database — Running Analytical Queries on Vitess.