Teoría y práctica del uso de HBase

Buenas tardes Mi nombre es Danil Lipova, nuestro equipo en Sbertech comenzó a usar HBase como depósito de datos operativos. Durante su estudio, se ganó experiencia que quería sistematizar y describir (esperamos que sea útil para muchos). Todos los experimentos a continuación se realizaron con versiones de HBase 1.2.0-cdh5.14.2 y 2.0.0-cdh6.0.0-beta1.

1. Arquitectura general
2. Escribir datos en HBASE
3. Lectura de datos de HBASE
4. Almacenamiento en caché de datos
5. Procesamiento por lotes MultiGet / MultiPut
6. Estrategia para dividir tablas en regiones (derrames)
7. Tolerancia a fallos, compactación y localidad de datos
8. Configuraciones y rendimiento
9. Prueba de carga
10. Conclusiones

1. Arquitectura general

El maestro en espera escucha los latidos activos en el nodo ZooKeeper y, en caso de desaparición, se hace cargo de las funciones del maestro.

2. Escribir datos en HBASE

Primero, considere el caso más simple: escribir un objeto clave-valor en una tabla determinada usando put (rowkey). El cliente primero debe averiguar dónde se encuentra el servidor de región raíz (RRS) que almacena la hbase: meta table. Recibe esta información de ZooKeeper. Luego recurre a RRS y lee la tabla hbase: meta, de la que recupera la información que RegionServer (RS) es responsable de almacenar los datos para la clave de fila dada en la tabla que le interesa. Para uso futuro, el cliente almacena en caché la metatabla y, por lo tanto, las llamadas posteriores van más rápido, directamente a RS.

Luego, RS, después de recibir la solicitud, primero la escribe en WriteAheadLog (WAL), que es necesaria para la recuperación en caso de un bloqueo. Luego guarda los datos en MemStore. Este es un búfer en la memoria que contiene un conjunto ordenado de claves para una región determinada. La tabla se puede dividir en regiones (particiones), cada una de las cuales contiene un conjunto disuelto de claves. Esto permite colocar regiones en diferentes servidores para obtener un mayor rendimiento. Sin embargo, a pesar de lo obvio de esta declaración, veremos más adelante que esto no funciona en todos los casos.

Después de colocar el registro en MemStore, el cliente recibe una respuesta de que el registro se guardó correctamente. Al mismo tiempo, realmente se almacena solo en el búfer y llega al disco solo después de un cierto período de tiempo o cuando se llena con nuevos datos.


Cuando se realiza la operación "Eliminar", no se produce la eliminación de datos físicos. Simplemente se marcan como eliminados, y la destrucción en sí ocurre cuando se llama a la función compacta principal, que se describe con más detalle en la Sección 7.

Los archivos en formato HFile se acumulan en HDFS y, de vez en cuando, se inicia el proceso compacto menor, que simplemente pega archivos pequeños en archivos más grandes sin eliminar nada. Con el tiempo, esto se convierte en un problema que se manifiesta solo al leer datos (volveremos a esto más adelante).

Además del proceso de arranque descrito anteriormente, existe un procedimiento mucho más eficiente, que es probablemente el lado más poderoso de esta base de datos: BulkLoad. Consiste en el hecho de que creamos HFiles de forma independiente y lo colocamos en el disco, lo que nos permite escalar perfectamente y alcanzar velocidades muy decentes. De hecho, la limitación aquí no es HBase, sino las posibilidades de hierro. A continuación se muestran los resultados de la carga en un clúster que consta de 16 RegionServers y 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 hilos), versión HBase 1.2.0-cdh5.14.2.



Se puede ver que al aumentar el número de particiones (regiones) en la tabla, así como los ejecutables Spark, obtenemos un aumento en la velocidad de descarga. Además, la velocidad depende de la cantidad de grabación. Los bloques grandes aumentan la medición de MB / seg, los pequeños en el número de registros insertados por unidad de tiempo, todas las demás cosas son iguales.

También puede comenzar a cargar en dos tablas al mismo tiempo y duplicar la velocidad. Se puede ver a continuación que los bloques de 10 KB se escriben en dos tablas a la vez a una velocidad de aproximadamente 600 Mb / s cada una (un total de 1275 Mb / s), lo que coincide con la velocidad de escritura de 623 MB / s en una tabla (ver No. 11 arriba)


Pero el segundo lanzamiento con registros de 50 KB muestra que la velocidad de descarga ya está creciendo ligeramente, lo que indica una aproximación a los valores límite. Debe tenerse en cuenta que prácticamente no hay carga en HBASE en sí, todo lo que se requiere de él es primero proporcionar los datos de hbase: meta, y después de alinear HFiles, vaciar los datos de BlockCache y guardar el búfer MemStore en el disco si no es así. Vacío

3. Lectura de datos de HBASE

Si suponemos que toda la información de hbase: meta ya tiene un cliente (consulte la sección 2), la solicitud va inmediatamente al RS donde se almacena la clave deseada. Primero la búsqueda se realiza en MemCache. Independientemente de si hay datos allí o no, la búsqueda también se lleva a cabo en el búfer BlockCache y, si es necesario, en HFiles. Si los datos se encontraron en un archivo, se colocan en BlockCache y se devolverán más rápido en la próxima solicitud. Las búsquedas de archivos H son relativamente rápidas debido al uso del filtro Bloom, es decir Después de leer una pequeña cantidad de datos, determina de inmediato si este archivo contiene la clave deseada y, de lo contrario, pasa a la siguiente.


Habiendo recibido datos de estas tres fuentes, RS forma una respuesta. En particular, puede transferir varias versiones del objeto encontrado a la vez si el cliente solicitó el control de versiones.

4. Almacenamiento en caché de datos

Las memorias intermedias MemStore y BlockCache ocupan hasta el 80% de la memoria RS asignada en el montón (el resto está reservado para tareas de servicio RS). Si el modo de uso típico es tal que los procesos escriben e inmediatamente leen los mismos datos, entonces tiene sentido reducir BlockCache y aumentar MemStore, porque cuando la escritura de datos en la memoria caché de lectura no cae, entonces el uso de BlockCache ocurrirá con menos frecuencia. El búfer BlockCache consta de dos partes: LruBlockCache (siempre en el montón) y BucketCache (generalmente fuera del montón o en SSD). BucketCache debe usarse cuando hay muchas solicitudes de lectura y no encajan en LruBlockCache, lo que conduce al trabajo activo de Garbage Collector. Al mismo tiempo, no debe esperar un aumento radical en el rendimiento del uso de la memoria caché de lectura, pero volveremos a esto en la Sección 8


BlockCache es uno para todo el RS, y MemStore tiene el suyo para cada tabla (uno para cada familia de columnas).

Como se describe en teoría, cuando la escritura de datos no ingresa en la memoria caché, y de hecho, dichos parámetros CACHE_DATA_ON_WRITE para la tabla y "Datos de caché en escritura" para RS se establecen en falso. Sin embargo, en la práctica, si escribe datos en MemStore, luego los vacía en el disco (limpiándolo de esta manera), luego elimina el archivo resultante y luego, al ejecutar una solicitud de obtención, recibiremos los datos con éxito. E incluso si deshabilita completamente BlockCache y llena la tabla con nuevos datos, luego obtenga MemStore en el disco, elimínelos y solicite de otra sesión, aún se obtendrán de alguna parte. Entonces HBase almacena no solo datos, sino también misteriosos rompecabezas.

hbase(main):001:0> create 'ns:magic', 'cf' Created table ns:magic Took 1.1533 seconds hbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'try_to_delete_me' Took 0.2610 seconds hbase(main):003:0> flush 'ns:magic' Took 0.6161 seconds hdfs dfs -mv /data/hbase/data/ns/magic/* /tmp/trash hbase(main):002:0> get 'ns:magic', 'key1' cf:c timestamp=1534440690218, value=try_to_delete_me 

La DATOS de la caché en lectura se establece en falso. Si tiene alguna idea, bienvenido a discutir esto en los comentarios.

5. Procesamiento por lotes de datos MultiGet / MultiPut

El procesamiento de solicitudes individuales (Get / Put / Delete) es una operación bastante costosa, por lo que debe combinarlas tanto como sea posible en una Lista o Lista, lo que le permite obtener un aumento significativo del rendimiento. Esto es especialmente cierto en la operación de escritura, pero cuando se lee hay el siguiente escollo. El siguiente gráfico muestra el tiempo de lectura de 50,000 registros de MemStore. La lectura se realizó en una secuencia y el eje horizontal muestra el número de claves en la solicitud. Se puede ver que cuando aumenta a mil claves en una solicitud, el tiempo de ejecución disminuye, es decir la velocidad aumenta Sin embargo, cuando el modo MSLAB está activado de forma predeterminada, después de este umbral, comienza una caída dramática en el rendimiento, y cuanto mayor es la cantidad de datos en el registro, mayor es el tiempo de ejecución.



Las pruebas se realizaron en una máquina virtual, 8 núcleos, HBase versión 2.0.0-cdh6.0.0-beta1.

El modo MSLAB está diseñado para reducir la fragmentación del almacenamiento dinámico, que ocurre debido a la mezcla de datos de generación nueva y antigua. Como solución al problema cuando MSLAB está habilitado, los datos se colocan en celdas relativamente pequeñas (trozos) y se procesan en lotes. Como resultado, cuando el volumen en el paquete de datos solicitado excede el tamaño asignado, el rendimiento cae bruscamente. Por otro lado, desactivar este modo tampoco es aconsejable, ya que provocará paradas debido a GC durante los momentos de trabajo intensivo con datos. Una buena salida es aumentar el volumen de la celda, en el caso de la escritura activa a través de la colocación simultánea con la lectura. Vale la pena señalar que el problema no ocurre si, después de la grabación, ejecuta el comando flush que descarga MemStore en el disco o si la carga se realiza utilizando BulkLoad. La siguiente tabla muestra que las consultas de los datos de MemStore de un volumen mayor (y la misma cantidad) conducen a una desaceleración. Sin embargo, aumentar el tamaño del fragmento vuelve el tiempo de procesamiento a la normalidad.


Además de aumentar el tamaño del fragmento, la fragmentación de datos por región ayuda, es decir Mesa dividida. Esto lleva al hecho de que llegan menos solicitudes a cada región y si se colocan en una celda, la respuesta sigue siendo buena.

6. La estrategia de dividir tablas en regiones (corte)

Dado que HBase es un almacenamiento de valor clave y la partición se realiza por clave, es extremadamente importante compartir datos de manera uniforme en todas las regiones. Por ejemplo, dividir dicha tabla en tres partes dará como resultado que los datos se dividan en tres regiones:


Sucede que esto conduce a una fuerte desaceleración si los datos cargados en el futuro se verán, por ejemplo, como valores largos, la mayoría de los cuales comienzan con el mismo dígito, por ejemplo:

1000001
1000002
...
1100003

Dado que las claves se almacenan como una matriz de bytes, todas ellas comenzarán de la misma manera y pertenecerán a la misma región # 1 que almacena este rango de claves. Hay varias estrategias divididas:

HexStringSplit: convierte la clave en una cadena con codificación hexadecimal en el rango "00000000" => "FFFFFFFF" y la llena con ceros a la izquierda.

UniformSplit: convierte una clave en una matriz de bytes con codificación hexadecimal en el rango "00" => "FF" y la llena con ceros a la derecha.

Además, puede especificar cualquier rango o conjunto de teclas para dividir y configurar la división automática. Sin embargo, uno de los enfoques más simples y efectivos es UniformSplit y el uso de concatenación de hash, por ejemplo, un alto par de bytes para ejecutar una clave a través de la función CRC32 (rowkey) y rowkey en sí:

hash + rowkey

Luego, todos los datos se distribuirán de manera uniforme en todas las regiones. Al leer, los primeros dos bytes simplemente se descartan y la clave original permanece. RS también controla la cantidad de datos y claves en la región y cuando se exceden los límites, se divide automáticamente en pedazos.

7. Tolerancia a fallos y localidad de datos

Dado que solo una región es responsable de cada conjunto de claves, la solución a los problemas asociados con fallas de RS o desmantelamiento es almacenar todos los datos necesarios en HDFS. Cuando RS falla, el maestro detecta esto a través de la ausencia de un latido en el nodo ZooKeeper. Luego asigna la región servida a otro RS y, dado que los archivos H se almacenan en un sistema de archivos distribuido, el nuevo host los lee y continúa sirviendo los datos. Sin embargo, dado que algunos de los datos pueden estar en MemStore y no tuvieron tiempo de ingresar a HFiles, los WAL, que también se almacenan en HDFS, se utilizan para restaurar el historial de operaciones. Después de la transferencia de los cambios, RS puede responder a las solicitudes, sin embargo, el movimiento lleva al hecho de que parte de los datos y sus procesos están en nodos diferentes, es decir. Disminución de la localidad.

La solución al problema es una compactación importante: este procedimiento mueve los archivos a los nodos que son responsables de ellos (donde se encuentran sus regiones), como resultado de lo cual la carga en la red y los discos aumenta considerablemente durante este procedimiento. Sin embargo, en el futuro, el acceso a los datos se acelera notablemente. Además, major_compaction combina todos los archivos H en un archivo dentro de la región, y también limpia los datos según la configuración de la tabla. Por ejemplo, puede especificar el número de versiones de un objeto que desea guardar o su duración, después de lo cual el objeto se elimina físicamente.

Este procedimiento puede tener un efecto muy positivo en HBase. La siguiente imagen muestra cómo se degradó el rendimiento como resultado de la grabación activa de datos. Aquí puede ver cómo se escribieron 40 secuencias en una tabla y 40 secuencias leyeron datos al mismo tiempo. Las secuencias de escritura forman cada vez más archivos H, que otras secuencias leen. Como resultado, es necesario eliminar más y más datos de la memoria y al final el GC comienza a funcionar, lo que prácticamente paraliza todo el trabajo. El lanzamiento de una gran compactación condujo a la limpieza de los bloqueos resultantes y la restauración del rendimiento.


La prueba se realizó en 3 DataNode y 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 hilos). HBase Versión 1.2.0-cdh5.14.2

Vale la pena señalar que el lanzamiento de la compactación mayor se realizó en una tabla "en vivo", en la que los datos se escribieron y leyeron activamente. Hubo una declaración en la red de que esto podría conducir a una respuesta incorrecta al leer los datos. Para verificar, se lanzó un proceso que generó nuevos datos y los escribió en la tabla. Después de lo cual leí inmediatamente y verifiqué si el valor obtenido coincidía con lo que se registró. Durante este proceso, se lanzó una compactación importante unas 200 veces y no se registró una sola falla. Quizás el problema aparece raramente y solo durante una carga alta, por lo que es más seguro detener de forma programada los procesos de escritura y lectura y realizar la limpieza sin permitir tales reducciones de GC.

Además, la compactación principal no afecta el estado de MemStore, para vaciarlo en el disco y compactar, debe usar flush (connection.getAdmin (). Flush (TableName.valueOf (tblName))).

8. Configuración y rendimiento

Como ya se mencionó, HBase muestra el mayor éxito donde no necesita hacer nada al ejecutar BulkLoad. Sin embargo, esto se aplica a la mayoría de los sistemas y personas. Sin embargo, esta herramienta es más adecuada para el apilamiento masivo de datos en bloques grandes, mientras que si el proceso requiere muchas solicitudes de lectura y escritura de la competencia, se utilizan los comandos Get y Put descritos anteriormente. Para determinar los parámetros óptimos, se realizaron lanzamientos con varias combinaciones de parámetros y configuraciones de la tabla:

• Se iniciaron 10 hilos al mismo tiempo 3 veces seguidas (llamémoslo un bloque de hilos).
• El tiempo de operación de todos los flujos en el bloque se promedió y fue el resultado final de la operación del bloque.
• Todos los hilos trabajaron con la misma tabla.
• Antes de cada inicio del bloque de subprocesos, se ejecutó una compactación importante.
• Cada bloque realizó solo una de las siguientes operaciones:

- Poner
- obtener
- Obtener + poner

• Cada bloque realizó 50,000 repeticiones de su operación.
• El tamaño del registro en el bloque es de 100 bytes, 1000 bytes o 10000 bytes (aleatorio).
• Los bloques se lanzaron con un número diferente de claves solicitadas (una clave o 10).
• Los bloques se lanzaron en varias configuraciones de tabla. Parámetros cambiados:

- BlockCache = activado o desactivado
- Tamaño de bloque = 65 Kb o 16 Kb
- Particiones = 1, 5 o 30
- MSLAB = encendido o apagado

Por lo tanto, el bloque se ve así:

a. Modo MSLAB activado / desactivado.
b. Se creó una tabla para la cual se establecieron los siguientes parámetros: BlockCache = true / none, BlockSize = 65/16 Kb, Partitions = 1/5/30.
c. Establecer compresión GZ.
d. Se lanzaron 10 subprocesos simultáneamente haciendo 1/10 de las operaciones put / get / get + put en esta tabla con registros de 100/1000/10000 bytes, ejecutando 50,000 consultas seguidas (claves aleatorias).
e. El punto d se repitió tres veces.
f. Se promedió el tiempo de funcionamiento de todos los hilos.

Se verificaron todas las combinaciones posibles. Es predecible que a medida que aumenta el tamaño de la grabación, la velocidad disminuirá o que la desactivación del almacenamiento en caché disminuirá. Sin embargo, el objetivo era comprender el grado y la importancia de la influencia de cada parámetro, por lo tanto, los datos recopilados se alimentaron a la entrada de la función de regresión lineal, lo que permite evaluar la confiabilidad utilizando estadísticas t. A continuación se muestran los resultados de los bloques que realizan operaciones Put. Un conjunto completo de combinaciones 2 * 2 * 3 * 2 * 3 = 144 opciones + 72 desde algunos se realizaron dos veces. Por lo tanto, un total de 216 lanzamientos:


Las pruebas se llevaron a cabo en un mini-cluster que consta de 3 DataNode y 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 flujos). HBase versión 1.2.0-cdh5.14.2.

La velocidad de inserción más alta de 3.7 segundos se obtuvo cuando el modo MSLAB estaba apagado, en una tabla con una partición, con BlockCache habilitado, BlockSize = 16, registros de 100 bytes de 10 piezas por paquete.
La velocidad de inserción más baja de 82.8 segundos se obtuvo cuando se habilitó el modo MSLAB, en una tabla con una partición, con BlockCache habilitado, BlockSize = 16, registros de 10,000 bytes cada uno.

Ahora veamos el modelo. Vemos un modelo de buena calidad para R2, pero está claro que la extrapolación está contraindicada aquí. El comportamiento real del sistema al cambiar los parámetros no será lineal, este modelo no es necesario para los pronósticos, sino para comprender lo que sucedió dentro de los parámetros dados. Por ejemplo, aquí vemos según el criterio de Student que para la operación Put, los parámetros BlockSize y BlockCache no importan (lo que generalmente es predecible):


Pero el hecho de que un aumento en el número de particiones conduzca a una disminución en el rendimiento es algo inesperado (ya hemos visto el efecto positivo de un aumento en el número de particiones con BulkLoad), aunque es comprensible. Primero, para el procesamiento, es necesario formar consultas en 30 regiones en lugar de una, y la cantidad de datos no es tal que proporcione una ganancia. En segundo lugar, el tiempo de operación total está determinado por el RS más lento, y dado que el número de DataNode es menor que el número de RS, algunas regiones tienen cero localidades. Bueno, echemos un vistazo a los cinco primeros:


Ahora vamos a evaluar los resultados de la ejecución de los bloques Get:


El número de particiones ha perdido importancia, lo que probablemente se deba al hecho de que los datos están bien almacenados en caché y el caché de lectura es el parámetro más significativo (estadísticamente). Naturalmente, aumentar el número de mensajes en una solicitud también es muy útil para el rendimiento. Los mejores resultados:


Bueno, finalmente, mire el modelo del bloque que ejecutó primero, y luego ponga:


Aquí todos los parámetros son significativos. Y los resultados de los líderes:

9. Prueba de carga

Bueno, finalmente, lanzaremos una carga más o menos decente, pero siempre es más interesante cuando hay algo para comparar. El sitio de DataStax, un desarrollador clave de Cassandra, tiene los resultados de NT de varios repositorios NoSQL, incluida HBase versión 0.98.6-1. La carga se realizó mediante 40 flujos, tamaño de datos de 100 bytes, discos SSD. El resultado de probar las operaciones de Lectura-Modificación-Escritura mostró estos resultados.


Según tengo entendido, la lectura se realizó en bloques de 100 registros y para 16 nodos HBase, la prueba DataStax mostró un rendimiento de 10 mil operaciones por segundo.

Es una suerte que nuestro clúster también tenga 16 nodos, pero no es muy "afortunado" que cada uno tenga 64 núcleos (subprocesos), mientras que en la prueba DataStax solo tiene 4. Por otro lado, tienen discos SSD, y tenemos HDD y más La nueva versión de HBase y la utilización de la CPU durante la carga prácticamente no aumentó significativamente (visualmente en un 5-10 por ciento). Sin embargo, intentaremos comenzar con esta configuración. Configuración de la tabla de forma predeterminada, la lectura se realiza en un rango de teclas de 0 a 50 millones al azar (es decir, cada vez que hay una nueva). En la tabla, 50 millones de entradas se dividen en 64 particiones. Las claves son crc32 hash. La configuración de la tabla está predeterminada, MSLAB está habilitado. Comenzando 40 subprocesos, cada subproceso lee un conjunto de 100 claves aleatorias e inmediatamente escribe los 100 bytes generados en estas claves.


Soporte: 16 DataNode y 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 flujos). HBase versión 1.2.0-cdh5.14.2.

El resultado promedio es más cercano a 40 mil operaciones por segundo, lo cual es significativamente mejor que en la prueba DataStax. Sin embargo, para los fines del experimento, las condiciones pueden cambiar ligeramente. Es bastante improbable que todo el trabajo se realice exclusivamente con una tabla, y solo con claves únicas. Suponga que hay un cierto conjunto de teclas "activas" que genera la carga principal. Por lo tanto, trataremos de crear una carga con registros más grandes (10 KB), también en paquetes de 100 cada uno, en 4 tablas diferentes y limitando el rango de claves solicitadas a 50 mil. El siguiente gráfico muestra el inicio de 40 hilos, cada secuencia lee un conjunto de 100 claves y escribe inmediatamente 10 al azar. KB en estas teclas de nuevo.


Soporte: 16 DataNode y 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 flujos). HBase versión 1.2.0-cdh5.14.2.

Durante la carga, se lanzó una compactación importante varias veces, como se muestra arriba sin este procedimiento, el rendimiento se degradará gradualmente, sin embargo, también se produce una carga adicional durante la ejecución. Las reducciones son causadas por varias razones. Algunas veces los subprocesos terminaron y mientras se reiniciaron hubo una pausa, a veces las aplicaciones de terceros crearon una carga en el clúster.

Leer y escribir de inmediato es uno de los escenarios de trabajo más difíciles para HBase. Si solo coloca solicitudes de colocación de un tamaño pequeño, por ejemplo, 100 bytes cada una, combinándolas en lotes de 10-50 mil piezas, puede obtener cientos de miles de operaciones por segundo y la situación es similar con las solicitudes de solo lectura. Vale la pena señalar que los resultados son radicalmente mejores que los que se obtuvieron en DataStax, sobre todo debido a las solicitudes en bloques de 50 mil.


Soporte: 16 DataNode y 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 flujos). HBase versión 1.2.0-cdh5.14.2.

10. Conclusiones

Este sistema es lo suficientemente flexible como para configurarlo, pero aún se desconoce el efecto de una gran cantidad de parámetros. Algunos de ellos fueron probados, pero no se incluyeron en el conjunto de pruebas resultante. Por ejemplo, los experimentos preliminares mostraron la insignificancia de un parámetro como DATA_BLOCK_ENCODING, que codifica la información utilizando valores de celdas vecinas, lo cual es bastante comprensible para los datos generados aleatoriamente. En el caso de utilizar una gran cantidad de objetos repetidos, la ganancia puede ser significativa. En general, podemos decir que HBase da la impresión de una base de datos bastante seria y bien pensada, que puede ser bastante productiva cuando se trata de grandes bloques de datos. Especialmente si es posible difundir los procesos de lectura y escritura a tiempo.

Si algo en su opinión no se divulga lo suficiente, estoy listo para contarle más. Sugerimos compartir su experiencia o debatir si no está de acuerdo con algo.