Druid Reseñas y Detalles del Producto

1. Capacidad de pre-agregación que permite pre-calcular agregaciones y guardar agregados en segmentos. Así, reduce los costos de cómputo y almacenamiento.

2. Interfaz de usuario de Druid (0.14+) que tiene muchas mejoras y permite crear ingestion_specs a través de la interfaz de usuario.

3. Interfaz REST para druid_broker para la comunicación, lo que facilita la integración con microservicios.

4. Druid es una base de datos NoSQL, pero aún así tiene soporte para consultas SQL y los analistas de negocios están cómodos usando SQL para consultar Druid.

5. Opciones de seguridad de datos: se admite autenticación HTTP básica y LDAP. Reseña recopilada por y alojada en G2.com.

1. Arquitectura compleja: curva de aprendizaje pronunciada y tiene 6 servicios principales que hacen que el despliegue y la gestión del clúster de Druid sean complejos.

2. Servicios históricos intensivos en memoria: los servicios de Druid son bastante intensivos en memoria y requieren instancias en la nube con alta capacidad de cómputo y memoria.

3. Soporte de indexación: Druid solo admite una indexación (Índice Invertido), lo que limita la idea de optimizar las fuentes de datos según el caso de uso. Reseña recopilada por y alojada en G2.com.

Druid es increíblemente rápido y tiene conectores integrados para la mayoría de las fuentes de datos populares. Admite una variedad de paneles, lo que hace que Druid sea una elección perfecta para cualquier aplicación de transmisión en tiempo real. Reseña recopilada por y alojada en G2.com.

Druid consulta nativamente en formato Json, lo cual es difícil de entender para un usuario de SQL.

Las consultas de rollover no son dinámicas. Ejemplo: si deseas resumir de un momento específico de un día a un momento específico de otro día, eso podría no ser posible.

La interfaz gráfica web tampoco es muy amigable para un usuario de negocios.

Falta una consola de gestión de clúster amigable para operaciones.

Druid necesita un servidor dedicado y no puede utilizar los recursos existentes de Hadoop. Reseña recopilada por y alojada en G2.com.

Druid es el mejor para análisis de baja latencia, ya que combina las mejores cualidades de un almacén de columnas y un índice invertido. Con los almacenes de columnas, el druid puede minimizar los costos de E/S para consultas analíticas.

Admite OLTP y OLAP.

Agregación en tiempo real.

Ingesta por lotes y en tiempo real. Reseña recopilada por y alojada en G2.com.

1. No hay tolerancia a fallos en la ruta de ejecución de consultas. Ej: Una sola consulta se procesa en cientos de nodos históricos: carece completamente de tolerancia a fallos en la ruta de ejecución de consultas.

2. Las subconsultas rezagadas en los nodos históricos toman mucho tiempo.

3. El relleno posterior toma mucho tiempo. Pero es comprensible, ya que actualizar el segmento antiguo y actualizarlo toma mucho tiempo. No lo consideraría una desventaja.

4. Como los Druid Brokers necesitan mantener la vista de todo el clúster en memoria, requieren significativamente más memoria y también causan muchas pausas de GC de JVM.

5. En el caso de consultas grandes, satura la capacidad de procesamiento de toda la capa histórica durante hasta decenas de segundos. Reseña recopilada por y alojada en G2.com.

Es fácil integrarse con otros motores de bases de datos como MySQL. ¡Eso se llama que las características de integración son buenas! Reseña recopilada por y alojada en G2.com.

Será incapaz de configurarse con algunas de las plataformas de análisis de datos como "Metatron." ¡Metatron utiliza una versión modificada de Druid! Reseña recopilada por y alojada en G2.com.

La comunidad detrás de Druid y su documentación es excelente. La escala a la que Druid puede ingerir y consultar datos es impresionante. Reseña recopilada por y alojada en G2.com.

Solo las versiones recientes tienen soporte para uniones entre fuentes de datos. Algunos mensajes de registro podrían ser más detallados. Reseña recopilada por y alojada en G2.com.

Admite excelentemente la escalabilidad horizontal. La funcionalidad de almacenamiento profundo mejora la resiliencia de los datos y facilita la adición de un nuevo nodo. Dado que los datos están particionados por tiempo de forma predeterminada, las consultas basadas en tiempo se ejecutan excepcionalmente bien. Puede ingerir una gran cantidad de datos muy rápidamente. Tiene múltiples complementos para satisfacer tus necesidades y puede integrarse con muchas infraestructuras en la nube de forma predeterminada. Reseña recopilada por y alojada en G2.com.

Necesitamos proporcionar mejores características para acomodar a múltiples inquilinos. Las actualizaciones de los datos existentes actualmente se realizan reconstruyendo completamente el segmento de tiempo correspondiente desde la fuente original. En su lugar, debería soportar actualizaciones basadas en el ID del inquilino. Las actualizaciones del mismo día son un poco complicadas y necesitamos resolverlas.

Uno de los lugares donde lo usamos es para calcular la supresión de datos basada en demografía y es lento en ese escenario particular. Reseña recopilada por y alojada en G2.com.

Apache Druid funciona muy bien si necesitas agregaciones básicas en datos de series temporales inmutables. Tiene algunas aproximaciones realmente útiles, como HyperLogLog para estimaciones de cardinalidad rápidas que convergen a conteos exactos para conjuntos de datos pequeños. También ahora soporta Druid SQL como lenguaje de consulta, el cual no tiene la pronunciada curva de aprendizaje que requiere el lenguaje de consulta nativo de Druid. Reseña recopilada por y alojada en G2.com.

Apache Druid se vuelve difícil de usar y muy ineficiente cuando tus datos son 1) actualizados 2) ingeridos fuera de orden (basado en la marca de tiempo) o 3) requieren uniones. Desafortunadamente, esto limita en gran medida el número de casos de uso que Druid admite fácilmente. Se pueden construir herramientas alrededor de él para soportar cosas como la ingestión fuera de orden, pero esto hace que Druid sea muy ineficiente.

Druid también tiene cuellos de botella inherentes en su diseño: cada clúster puede tener solo un coordinador y un overlord. Descubrimos que esto hacía imposible escalar un solo clúster para satisfacer nuestras necesidades. Reseña recopilada por y alojada en G2.com.

Fácil de usar, buena documentación, flexible, escalable. Reseña recopilada por y alojada en G2.com.

El rendimiento no siempre es predecible. Las especificaciones de ingestión pueden ser difíciles de crear y depurar. Reseña recopilada por y alojada en G2.com.

Capacidad de ingestión y consulta en tiempo real

Rendimiento de consulta en subsegundos

Almacén de datos basado en series temporales

Soporte de Slice N Dice

Compresión de datos Reseña recopilada por y alojada en G2.com.

Incapacidad para soportar datos anidados

Soporte parcial de unión

Configuración para ponerlo en marcha por primera vez Reseña recopilada por y alojada en G2.com.

1) Datos pre-agregados en dimensiones y métricas

2) Recuperación de resultados de datos/consultas a gran velocidad Reseña recopilada por y alojada en G2.com.

Gestionar el corredor/clúster si la carga es alta

Limitación en dimensiones dinámicas Reseña recopilada por y alojada en G2.com.