Recientemente, veo mucho código en algunos proyectos que usan secuencias para filtrar objetos, como:
library.stream() .map(book -> book.getAuthor()) .filter(author -> author.getAge() >= 50) .map(Author::getSurname) .map(String::toUpperCase) .distinct() .limit(15) .collect(toList()));¿Hay alguna ventaja de usar eso en lugar de la consulta directa HQL/SQL a la base de datos que ya devuelve los resultados filtrados?
¿No es el segundo enfoque mucho más rápido?
Si los datos provienen originalmente de una base de datos, es mejor filtrar en la base de datos en lugar de buscar todo y filtrar localmente.
En primer lugar, los sistemas de gestión de bases de datos son buenos filtrando, es parte de su trabajo principal y, por lo tanto, están optimizados para ello. El filtrado también se puede acelerar mediante el uso de índices.
En segundo lugar, obtener y transmitir muchos registros y descomponer los datos en objetos solo para desechar muchos de ellos cuando se realiza el filtrado local es una pérdida de ancho de banda y recursos informáticos.
A primera vista: se puede hacer que los flujos se ejecuten en paralelo; simplemente cambiando el código para usar parallelStream() . (descargo de responsabilidad: por supuesto, depende del contexto específico si solo cambiar el tipo de transmisión dará como resultado resultados correctos; pero sí, puede ser así de fácil).
Luego: transmite "invitar" a usar expresiones lambda. Y eso, a su vez, conduce al uso de instrucciones de código de bytes invocar_dinámico ; a veces obteniendo ventajas de rendimiento en comparación con el tipo de escritura de dicho código de la "vieja escuela". (y para aclarar el malentendido: invocar_dinámica es una propiedad de lambdas, ¡no de flujos!)
Estas serían razones para preferir soluciones de "flujo" hoy en día (desde un punto de vista general).
Más allá de eso: realmente depende ... echemos un vistazo a su entrada de ejemplo. Esto parece tratar con los POJO de Java ordinarios, que ya residen en la memoria, dentro de algún tipo de colección. ¡Procesar dichos objetos en la memoria directamente definitivamente sería más rápido que ir a alguna base de datos fuera del proceso para trabajar allí!
Pero, por supuesto: cuando las llamadas anteriores, como book.getAuthor() estarían haciendo una "inmersión profunda" y en realidad hablarían con una base de datos subyacente; entonces lo más probable es que "hacer todo en una sola consulta" le brinde un mejor rendimiento.
Lo primero es darse cuenta de que no se puede saber con solo este código qué declaración se emite contra la base de datos. Es muy posible que se recopile todo el filtrado, la limitación y el mapeo, y al invocar collect toda esa información se use para construir una declaración SQL coincidente (o cualquier lenguaje de consulta que se use) y enviar a la base de datos.
Con esto en mente, hay muchas razones por las que se utilizan API similares a secuencias.
es moderno Los streams y lambdas aún son bastante nuevos para la mayoría de los desarrolladores de Java, por lo que se sienten geniales cuando los usan.
Si se usa algo como en el primer párrafo, en realidad crea un buen DSL para construir sus declaraciones de consulta. Scalas Slick y .Net LINQ son los primeros ejemplos que conozco, aunque asumo que alguien construyó algo así en LISP mucho antes de que yo naciera.
Los flujos pueden ser flujos reactivos y encapsular una API sin bloqueo. Si bien estas API son realmente buenas porque no lo obligan a bloquear recursos como hilos mientras espera resultados. Su uso requiere toneladas de devoluciones de llamada o el uso de una API basada en flujo mucho más agradable para procesar los resultados.
Son más agradables para leer el código imperativo. Tal vez el procesamiento realizado en la transmisión no pueda [fácilmente/por el autor] realizarse con SQL. Entonces, las alternativas no son SQL vs Java (o cualquier idioma que esté usando), sino Java imperativo o Java "funcional". El último a menudo se lee mejor.
Entonces, hay buenas razones para usar una API de este tipo.
Dicho todo esto: es, en casi todos los casos, una mala idea ordenar/filtrar y cosas por el estilo en su aplicación, cuando puede descargarlo en la base de datos. La única excepción en la que puedo pensar actualmente es cuando puede omitir todo el viaje de ida y vuelta a la base de datos, porque ya tiene el resultado localmente (por ejemplo, en un caché).