cloud

Dic

2024

Las preguntas más absurdas que un DBA puede escuchar en una entrevista de RRHH (Artículo de HUMOR)

Quienes trabajamos como administradores de bases de datos (DBA) hemos pasado por entrevistas laborales que podrían calificarse como una experiencia de alto riesgo. Más que evaluar nuestras competencias técnicas, a menudo parecen un test de paciencia. Y no, no estamos hablando de preguntas como “¿Cuáles son las diferencias entre un índice clustered y non-clustered?”. Nos referimos a joyas del absurdo que solo un departamento de RRHH puede lanzar con total tranquilidad. Antes de seguir, un pequeño disclaimer, todo lo que vas a leer a continuación es pura ficción y una exageración, lo que no quiere decir que, en ocasiones, la realidad supere la ficción.

El examen de «personalidad» camuflado de absurdo

Algunos reclutadores no entienden del todo qué hace un DBA, no les culpo, no es su trabajo. El problema viene cuando deciden que, ya que no tienen ni idea de lo que hablamos lo mejor que pueden hacer es recurrir a particulares test de personalidad. Y no, no estoy hablando del test de MBTI, me refiero a preguntas mucho más absurdas que sacan lo peor (o mejor) de nosotros

Si fueras una tabla de SQL, ¿qué nombre tendrías y por qué?

Es aquí cuando miras al entrevistador con cara de ¿en serio? mientras piensas: «Esta pregunta viene con un CROSS JOIN de desconcierto y absurdidad». Pero, como eres un profesional, te pones creativo:

«Sería dbo.Entrevista_RRHH porque, al igual que en esta sala, hay muchos campos innecesarios que ralentizan el proceso». Y si estás inspirado: «Y, por supuesto, con una clave primaria, porque si algo me define es que siempre mantengo la integridad referencial».

El entrevistador sonríe y toma notas. No entiende ni una palabra, pero le parece bien.

¿Te consideras más un trigger o un procedimiento almacenado?

Aquí la cosa se complica porque sabes que cualquier respuesta va a derivar en algún análisis de personalidad de esos que llenan PowerPoints con diagramas de colores. Piensas en algo como: «Un trigger, porque reacciono rápido cuando algo va mal y siempre ejecuto la acción adecuada. Aunque, a diferencia de los triggers mal diseñados, no me cargo el rendimiento del sistema». Si ese día te has levantado con el pie izquierdo igual lo que te nace es algo mucho más irónico, como: «Un procedimiento almacenado, claro, porque en mi trabajo, igual que en los procesos bien optimizados, todo está planificado y nadie tiene que revisar los logs de errores inesperados.»

Pero, lo piensas dos veces, si respondes «un trigger», parece que saltas a la mínima. Si dices «un procedimiento almacenado», suena a que necesitas mucha preparación para hacer algo. Así que terminas diciendo que un ROLLBACK y a ver si le cortocircuita el cerebro y sobrevivimos unos minutos más hasta llegar a la siguiente pregunta.

¿Qué tipo de relación tienes con tus compañeros, un INNER JOIN o un LEFT JOIN?

Esta pregunta suena tan profunda como absurda. Te planteas si te has metido sin querer en una sesión de terapia grupal en lugar de una entrevista técnica. Respiras hondo y sueltas:

«Claramente un INNER JOIN, porque con mis compañeros siempre buscamos resultados eficientes y no nos gustan las inconsistencias. Si alguien no aporta, mejor quedarse con un NULL».

Aquí es cuando miras la cara del entrevistador y ves que has acertado, menos mal que no has dicho eso más sarcástico que realmente piensas: «Mis compañeros parecen LEFT JOIN con registros fantasma que solo ocupan espacio y no aportan nada al output.»

¿Cómo gestionarías tu vida personal si fuera una base de datos relacional?

Una de esas preguntas que te dejan boquiabierto y te hacen preguntarte si no habrá cámaras ocultas en la sala. Intentas mantener la compostura: «Primero haría una buena normalización, porque prefiero la eficiencia y no me gusta cargar con datos redundantes. Luego implementaría backups incrementales para cuando las cosas se complican y, por supuesto, borraría las tablas temporales que no aportan nada a mi día a día».

Si el entrevistador parece satisfecho, rematas con una sonrisa: «Y siempre con un buen índice de prioridades, porque la vida es como una query: si no la optimizas, acaba siendo lenta y costosa».

El desafío de lo no técnico

En ocasiones, una vez pasado el dudoso test de personalidad, llegamos a otra fase donde las preguntas parecen sacadas de un test de Rorschach. Para un DBA, acostumbrado a la lógica y la estructura, escuchar estas cuestiones es cómo ejecutar un delete sin WHERE. Me refiero a cosas como estas.

¿Qué harías si te encuentras con una base de datos rebelde?

Aquí intentas contener la risa y respondes algo técnico para sonar serio. Pero, ¿realmente ha dicho una base de datos rebelde? No sabía que la entrevista de trabajo era para trabajar como DBA Jedi en la Estrella de la Muerte.

Si la base de datos falla, ¿te estresarías?

Vuelve al ataque. Tus intentos de evitar la pregunta anterior han sido infructuosos y ahora el entrevistador golpea de nuevo con esta pregunta que parece un ataque directo. Te apetece contestar algo del tipo: “No, en absoluto, me pondría a bailar una jota mientras los usuarios gritan por un downtime. ¿Qué creen que hacemos?”

Porque, no nos engañemos, cualquier DBA que se respete ha vivido la experiencia traumática de una base de datos caída en producción a las 3 AM. Pero te detienes un instante, meditas y respondes con toda la ironía del mundo:

«¿Estresarme? ¡Para nada! Es una situación maravillosa para practicar mis habilidades de meditación transcendental mientras 300 usuarios esperan que resuelva el desastre».

Si te piden algo más serio, matizas: «Más que estresarme, actuaría. Es como un incendio, no te sientas a filosofar. Buscas el extintor, localizas el backup y vuelves a poner todo en orden.»

Clásicos «RRHH-style» que siempre vuelven

Y no pueden faltar las típicas preguntas genéricas vacías que ningún técnico puede soportar. Ya sabéis a las que me refiero, vamos a verlas.

¿Dónde te ves en 5 años?

Respondes sin pensar. Después de pasar por esta entrevista, cansado y con toda la ilusión por el puesto de trabajo ya perdida no te quedan fuerzas para más. Obviamente es una respuesta con un toque ácido pero que esconde un deseo de que el mundo se convierta en un lugar mejor:

«Me veo liderando un equipo de bases de datos en una empresa que no haga preguntas de terapia psicológica durante las entrevistas. Y, con suerte, trabajando en entornos que no tengan bases de datos heredadas sin documentación. Si no se puede, buscaré la manera de hacer tuning a tu proceso de selección para eliminar estas preguntas inútiles».

Ahora en serio, en el mundo en el que nos movemos todo cambia muy deprisa. Seguramente, tú que me estás leyendo, estás trabajando ahora con cosas que no existían hace 5 años. ¿Cómo quieren que respondamos a esa pregunta? Lo único que tengo claro es que, dentro de 5 años, el ticket ese que tengo pendiente esperando la respuesta del usuario va a seguir ahí, en el mismo estado.

¿Qué animal te representa mejor en tu trabajo?

Esto sí que es un clásico del manual de RRHH. La tentación de decir «un koala dormido porque mi sistema funciona sin incidentes» es fuerte, pero decides optar por algo más elegante: «Un búho, porque soy nocturno, vigilo todo con precisión y, cuando llega el desastre, actúo con rapidez y sin ruido innecesario. Además, no molesto mientras los demás duermen.”

Conclusión

Las entrevistas con RRHH son una prueba en sí mismas. Si sobrevives a preguntas como “¿qué tipo de JOIN eres?”, te puedes considerar un candidato resistente, optimizado y listo para cualquier desastre en producción. Porque, al final del día, un DBA siempre tiene claro cómo responder a las consultas más difíciles, incluso si vienen de un reclutador armado con un SELECT de preguntas innecesarias e ineficientes.

Si algo nos enseñan las entrevistas con RRHH es a dominar el arte de la diplomacia. Al final, todo se reduce a un simple hecho: por muy absurdo que suene el proceso, seguimos siendo los guardianes de los datos. Así que, estimado entrevistador, la próxima vez, menos triggers emocionales y más consultas bien indexadas.

Espero que este artículo te haya resultado divertido y ameno. Si tienes alguna duda o comentario, no dudes en contactarnos en Twitter o por mail o dejarnos un mensaje en los comentarios de aquí abajo. Y recuerda que también tenemos un grupo de LinkedIn al que te puedes unir.

Dic

2024

El día que el servidor dijo «Basta»: Confesiones de un DBA (Artículo de HUMOR)

Todo DBA tiene su límite. Esa delgada línea entre la paciencia infinita y querer estampar el teclado contra la pared. El día del que os hablo fue uno de esos. Un día que empezó tranquilo y terminó en una lucha encarnizada entre el servidor, el Optimizer y mi cordura.

Os cuento lo que ocurrió: un desplome monumental de rendimiento, misterios sin resolver y consultas que me hicieron replantear mi carrera profesional.

9:00 AM: La CPU al 100% y el misterio del índice fantasma

Llego a la oficina con mi café recién hecho y veo las alertas parpadeando como luces de Navidad: “CPU al 100%. El servidor está llorando”.

Abro el Activity Monitor y ahí está. Una consulta devorando recursos como si no hubiera mañana. La autora de semejante hazaña es la tabla Sales.OrderDetail, que por algún motivo ha pasado de ser una tabla tranquila a Satán hecho tabla.

La consulta en cuestión es:

SELECT OrderID, SUM(TotalAmount) AS Total
FROM Sales.OrderDetail
GROUP BY OrderID;

Aparentemente inocente, ¿verdad? Pues no. Esta tabla tiene 50 millones de registros y sin ningún índice útil. Le pregunto al equipo:

– “¿Dónde están los índices?”

– “Los quitamos ayer porque ralentizaban las inserciones”, responden orgullosos.

Respirando hondo, les explico que quitar índices no soluciona los problemas de rendimiento. Es como quitar los frenos del coche para ir más rápido: técnicamente es cierto, pero no saldrá bien.

Solución: Creamos un índice adecuado:

CREATE INDEX IX_SalesOrderDetail_OrderID_TotalAmount
ON Sales.OrderDetail(OrderID, TotalAmount);

Ejecuto la consulta de nuevo y, ¡milagro! La CPU se relaja. El servidor me guiña un ojo en señal de agradecimiento.

11:00 AM: La «Optimización» del Query Planner

Todo iba bien hasta que mi compañero Pepe —que jura que el Query Optimizer es inteligente— decidió lanzar su joyita del día.

– “He usado un HINT para asegurarme de que use el índice correcto”, dice, mientras me enseña esta aberración:

SELECT *
FROM Sales.Customers WITH (INDEX(0))
WHERE Country = 'Spain';

Sí, habéis leído bien: INDEX(0). El equivalente SQL a decirle al Optimizer: «Da igual que lo sepas hacer bien, quiero que me compliques la vida».

– “Pepe, eso no optimiza nada. Has forzado al Optimizer a usar una estrategia peor”.

Pepe, con cara de no entender nada, me pide una explicación. Así que se la doy:

El Optimizer no es un enemigo, es un colega que necesita que le demos buenos datos. WITH (INDEX(0)) indica al motor de base de datos que no tiene que usar ningún índice. Si la tabla es un HEAP hará un table scan aunque haya índices nonclustered. Si la tabla tiene un cluster jamás hará un seek y siempre hará un scan. Si lo que queremos es que use el índice clustered deberíamos usar WITH (INDEX(1)) que dejará que el motor use lo más eficiente, un seek o un scan, depende del caso. Pero rara vez vas a tener que usarlo, si tus estadísticas están actualizadas y tus índices bien creados, SQL Server tomará la mejor decisión posible.

Actualizo las estadísticas:

UPDATE STATISTICS Sales.Customers;

Le muestro cómo forzar buenos resultados sin jugar a ciegas con los HINTs:

SELECT *
FROM Sales.Customers
WHERE Country = 'Spain'
OPTION (RECOMPILE);

Resultado: La consulta se ejecuta en 0.2 segundos sin INDEX(0) ni tonterías. Pepe asiente. Creo que hoy hemos ganado una pequeña batalla.

2:00 PM: El Desastre del «Top 1» sin orden

Después de comer, el desarrollador novato —al que llamaremos Juanito— me lanza una consulta de soporte urgente:

– “Necesito el último pedido. Lo he arreglado con un TOP 1”.

Cuando veo la consulta, siento una punzada en el estómago:

SELECT TOP 1 OrderID, TotalAmount
FROM Sales.Orders;

– “¿Y dónde está el ORDER BY?” —pregunto yo, temblando.

– “¿Hace falta?”, responde Juanito, con una inocencia que me desarma.

Le explico que TOP 1 sin ORDER BY no garantiza el «último» ni el «primero». Solo devuelve el primero que pille, que puede ser cualquier registro según el orden físico de la tabla.

Solución:

SELECT TOP 1 OrderID, TotalAmount
FROM Sales.Orders
ORDER BY OrderDate DESC;

– “¿Y si quiero asegurarme de que sea rápido?”, me pregunta.

– “Pon un índice en OrderDate. Tu servidor te lo agradecerá”.

CREATE INDEX IX_Orders_OrderDate ON Sales.Orders(OrderDate);

La consulta ahora funciona como debe. Juanito toma notas en su libreta titulada “SQL para Torpes”.

5:00 PM: El plan de backup olvidado

Pensaba que el día había terminado cuando, de repente, entra en mi despacho el jefe:

-“¿Hiciste un backup esta mañana? Necesitamos restaurar la base de datos de ventas de ayer”.

Aquí el humor negro se hace real. Porque claro, en esta oficina, el backup se convierte en un problema solo cuando hace falta. Le miro fijamente:

– “¿Sabes qué es un backup, jefe?”.

Silencio incómodo. Por suerte, en esta ocasión sí tenemos backup diferencial. Aprovecho para darle una lección. Sin backups no hay paraíso. El desastre es cuestión de tiempo.

Ejecutamos la restauración:

RESTORE DATABASE SalesDB
FROM DISK = 'C:\Backups\SalesDB_Full.bak'
WITH REPLACE, NORECOVERY;

RESTORE DATABASE SalesDB
FROM DISK = 'C:\Backups\SalesDB_Differential.bak'
WITH RECOVERY;

El jefe respira aliviado. Yo termino el día con la satisfacción de que los backups me salvaron el pellejo.

Conclusión: El servidor puede fallar, yo no

La vida de un DBA está llena de desafíos. Desde índices borrados hasta HINTs absurdos y consultas sin ORDER BY. Pero si algo aprendemos con el tiempo es que el desastre no es opcional; la preparación sí lo es.

Cierro mi sesión, guardo los logs y me despido del servidor, que hoy ha sobrevivido gracias a mí. Y mañana… mañana será otro día lleno de misterios.

Como dice el viejo refrán de DBA: «No hay problema en SQL Server que no pueda arreglarse con índices, backups y un buen café«.

Dic

2024

ID autoincrementales, GUID y secuencias: ¿cuál elegir?

ID incrementales o GUID ¿cuál elegir?, esta es la pregunta que me hizo uno de vosotros hace unos días. Y yo también añadiría a la pregunta las secuencias. Vamos a tratar de responder esta duda.

Cuando diseñamos un modelo de datos en SQL Server o cualquier otro sistema de bases de datos relacional, una de las decisiones más importantes es la elección del tipo de identificador principal para nuestras tablas. ID autoincrementales, GUID y secuencias son opciones comunes, cada una con sus ventajas y limitaciones. En este artículo veremos las características de cada enfoque, sus diferencias y cómo afectan al rendimiento y a la fragmentación de índices para tratar de llegar a la respuesta ideal para cada escenario. Porque sí, como pasa siempre con las soluciones de bases de datos, vais a ver que no existe una respuesta única para todos los escenarios.

IDs autoincrementales

Los ID autoincrementales, conocidos como IDENTITY, son probablemente la solución más utilizada. Se generan de manera automática con cada inserción en la tabla, siguiendo un orden secuencial. Este tipo de identificador es ideal para sistemas centralizados donde no se necesita garantizar unicidad global. Su principal ventaja radica en el consumo reducido de espacio y el bajo impacto en la fragmentación de índices clustered, ya que las inserciones se producen siempre al final del índice.

Lo normal para este tipo de IDs es usar valores numéricos del tipo INT (desde -2.147.483.648 hasta 2.147.483.647) o BIGINT (desde – 9.223.372.036.854.775.808 a 9.223.372.036.854.775.807). Porque sí, los valores negativos también existen y son utilizables.

Sin embargo, los ID autoincrementales no están exentos de problemas. Por ejemplo, en sistemas distribuidos o replicados, la generación secuencial puede llevar a conflictos si diferentes nodos intentan generar los mismos valores. Además, al ser fácilmente predecibles, pueden ser problemáticos desde una perspectiva de seguridad.

GUID: ID con unicidad global

Los GUID o identificadores únicos globales son valores generados al azar que garantizan unicidad, incluso entre sistemas distribuidos. Esta característica los hace indispensables en escenarios de replicación o cuando los datos se integran desde múltiples orígenes.

El problema de los GUID radica en su tamaño: 16 bytes por registro frente a los 4 u 8 bytes de un INT o BIGINT respectivamente. Esto aumenta significativamente el tamaño de las tablas y los índices y, en consecuencia, el coste de las consultas. Además, su naturaleza aleatoria introduce fragmentación en índices, afectando negativamente al rendimiento en sistemas con altas tasas de inserción.

Para mitigar estos problemas, SQL Server ofrece la función NEWSEQUENTIALID(), que genera GUID en orden secuencial, reduciendo la fragmentación pero sin eliminarla completamente.

Secuencias: ID compartidos

Las secuencias son una alternativa poderosa introducida en SQL Server 2012. Se definen como objetos independientes a las tablas que generan números únicos bajo demanda, ofreciendo un control total sobre cómo se producen los valores. A diferencia de los ID autoincrementales, las secuencias no están ligadas a una tabla específica, lo que las hace reutilizables en múltiples tablas o contextos. Una de sus ventajas clave es la posibilidad de configurarlas para satisfacer requisitos específicos, como usar valores iniciales personalizados o incrementos distintos de uno. Además, permiten generar identificadores únicos en sistemas distribuidos mediante estrategias como prefijos por nodo.

Sin embargo, las secuencias también presentan limitaciones, como la posibilidad de generar brechas en caso de transacciones fallidas y una configuración inicial más compleja que los ID autoincrementales.

Comparativa: ID autoincrementales, GUID y secuencias

A continuación, os muestro una tabla resumen con una comparación detallada de las tres opciones:

Criterio	Autoincrementales	GUIDs	Secuencias
Tamaño	4-8 bytes (INT, BIGINT)	16 bytes (uniqueidentifier)	4-8 bytes (INT, BIGINT)
Fragmentación	Baja	Alta (aleatoria)	Baja si se utiliza con cuidado
Unicidad global	No	Sí	Sí (configurable)
Flexibilidad	Baja	Alta	Muy alta
Desempeño	Alto	Medio-bajo	Alto
Compatibilidad distribuida	Limitada	Alta	Media-alta

Fragmentación de índices y su impacto

La fragmentación es un factor crucial en el rendimiento de una base de datos. En índices clustered, los valores secuenciales de ID autoincrementales o secuencias generan inserciones ordenadas, minimizando la fragmentación. Por el contrario, los GUID, debido a su naturaleza aleatoria, obligan a reordenamientos constantes en las páginas del índice, aumentando tanto la fragmentación como el coste de mantenimiento.

Para mitigar este problema con GUID, se recomienda usar índices no clustered (no exentos de fragmentación pero con menor impacto) o estrategias como NEWSEQUENTIALID() cuando sea posible. En el caso de secuencias, su comportamiento depende de cómo se configuren, los valores secuenciales preservan el orden, mientras que configuraciones más complejas pueden introducir fragmentación.

Conclusión

No hay una única solución ideal; la elección depende del contexto y los requisitos del sistema. Si el rendimiento y el espacio son prioritarios, los ID autoincrementales son la mejor opción en sistemas centralizados. Para entornos distribuidos donde la unicidad global es crucial, los GUID son indispensables, aunque con un coste en rendimiento y espacio. Finalmente, las secuencias ofrecen una alternativa flexible y controlada que puede adaptarse a múltiples escenarios, especialmente cuando se necesita compatibilidad entre tablas o nodos. En última instancia, el éxito radica en comprender las ventajas y limitaciones de cada enfoque, optimizando su uso según las necesidades específicas del proyecto.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Dic

2024

¿Qué alternativa tengo a SSMS?

Existen múltiples alternativas a SQL Server Management Studio (SSMS) que pueden ajustarse mejor a distintas necesidades y presupuestos. Estas opciones incluyen herramientas tanto de Microsoft como de terceros, así como opciones gratuitas y de pago. La elección de una alternativa adecuada a SSMS dependerá en gran medida del contexto de uso, las funcionalidades requeridas y la infraestructura de cada organización. Hoy quiero repasar con vosotros algunas de las principales opciones que vais a poder utilizar y para que casos de uso son más recomendadas.

Azure Data Studio: Una Alternativa Moderna de Microsoft

Una de las alternativas más destacadas la vamos a encontrar en el catálogo de Microsoft y no es otra que Azure Data Studio. De Azure Data Studio ya hemos hablado en alguna ocasión y es una herramienta moderna diseñada para entornos de nube y escenarios híbridos. Azure Data Studio se caracteriza por ser multiplataforma, permitiendo su uso en sistemas operativos Windows, macOS y Linux. Esto lo convierte en una opción versátil, especialmente para desarrolladores y administradores de bases de datos que requieren una interfaz ligera y flexible. Su sistema de extensiones permite personalizar el entorno y añadir funcionalidades específicas, como soporte para Power BI o notebooks interactivos que facilitan la visualización de datos.

Sin embargo, aunque Azure Data Studio admite complementos y se actualiza regularmente, algunas funcionalidades avanzadas de administración de SQL Server todavía no están presentes, lo que limita su uso para tareas puramente administrativas en comparación con SSMS. Además, su enfoque está orientado más hacia el desarrollo que hacia la administración, lo que puede resultar insuficiente para ciertos administradores de bases de datos que necesitan un control total sobre sus instancias.

Aqua Data Studio: Versatilidad y soporte multi base de datos para desarrolladores

Otra opción a considerar es Aqua Data Studio, una herramienta que destaca por su compatibilidad con múltiples sistemas de gestión de bases de datos (SGBD), entre ellos SQL Server, Oracle, MySQL y PostgreSQL. Aqua Data Studio permite a los usuarios administrar, modelar y desarrollar sobre diversas bases de datos en una sola interfaz, lo que la convierte en una opción ideal para entornos con múltiples bases de datos. La herramienta también ofrece funcionalidades avanzadas de visualización de datos, que son útiles para el análisis y la toma de decisiones basadas en datos como por ejemplo poder filtrar y ordenar los resultados de una consulta como si de una tabla de excel se tratase. Para esto, hace uso de los datos ya cargados en local y no vuelve a ejecutar la consulta.

Otras de sus ventajas son la interfaz intuitiva, su soporte para diagramas ER y sus herramientas de depuración de SQL, que facilitan la optimización de consultas. No obstante, Aqua Data Studio es una herramienta de pago, y su coste puede ser elevado para algunos usuarios, especialmente aquellos que solo necesitan una solución específica para SQL Server.

DbForge Studio for SQL Server: Una alternativa para desarrollo y optimización

Siguiendo con las herramientas de terceros, DbForge Studio for SQL Server de Devart es una alternativa robusta, conocida por su enfoque en el desarrollo y optimización de bases de datos. Esta herramienta incluye un editor de SQL avanzado con funcionalidades de autocompletado, refactorización de código y análisis de dependencias, lo cual facilita el trabajo de desarrollo.

Además, ofrece capacidades de perfilado de bases de datos, lo que permite identificar y resolver cuellos de botella en el rendimiento de consultas SQL, y funcionalidades para la comparación y sincronización de bases de datos. Estas características la convierten en una opción poderosa para entornos donde se requiere un control avanzado y optimización. Sin embargo, su precio puede ser una barrera, especialmente en organizaciones con presupuesto limitado, y está disponible únicamente en Windows, lo que limita su uso en entornos que requieren multiplataforma.

DBeaver: Una Alternativa Multiplataforma para Entornos Híbridos

Otra herramienta relevante es DBeaver, una aplicación de código abierto y multiplataforma compatible con diversos SGBD, incluyendo SQL Server. DBeaver es popular en entornos híbridos por su flexibilidad, y su sistema de plugins permite añadir funcionalidades específicas. La versión gratuita de DBeaver incluye funcionalidades básicas, mientras que la edición Enterprise (de pago) añade opciones avanzadas, como la administración de bases de datos y el soporte para control de versiones.

Sin embargo, su interfaz, aunque flexible, puede resultar sobrecargada para quienes buscan un entorno exclusivamente enfocado en SQL Server. Además, al ser una herramienta genérica, carece de integración nativa con algunas soluciones de Microsoft, lo que puede limitar su uso en infraestructuras completamente basadas en el ecosistema de Microsoft.

Toad for SQL Server: Optimización y automatización para DBAs

Toad for SQL Server de Quest Software también es una alternativa sólida, especialmente valorada por sus capacidades de optimización y monitorización. Esta herramientas permite a los administradores de bases de datos automatizar tareas de mantenimiento y administración, así como optimizar consultas SQL con sugerencias basadas en análisis de rendimiento en tiempo real.

Su soporte para control de versiones lo convierte en una excelente herramienta para el trabajo en equipo, permitiendo a los desarrolladores y administradores sincronizar cambios y trabajar colaborativamente en proyectos de base de datos. No obstante, el alto coste de Toad y la complejidad de su interfaz pueden ser barreras para usuarios con menos experiencia o para organizaciones pequeñas con recursos limitados.

SQuirreL SQL: Una alternativa gratuita y multi base de datos

Ya vamos acercándonos al final de este artículo con SQuirreL SQL, una opción de código abierto que, aunque no está especializada en SQL Server, ofrece una solución gratuita y multiplataforma para trabajar con múltiples SGBD. Si necesitamos compatibilidad con diversos motores de base de datos en un solo entorno SQuirreL SQL es la herramienta adecuada. Sin embargo, esta herramienta carece de funcionalidades avanzadas para administración y monitoreo de rendimiento en SQL Server, y su interfaz es menos moderna, lo que puede ser una desventaja para usuarios acostumbrados a herramientas más actuales.

HeidiSQL: Una alternativa portable

HeidiSQL es conocido principalmente por su compatibilidad con bases de datos MySQL y MariaDB, pero también soporta conexiones a SQL Server y PostgreSQL, ampliando su utilidad en entornos multi-SGBD. Es una herramienta liviana, con un diseño intuitivo y que permite gestionar bases de datos sin ocupar mucho espacio ni recursos del sistema. Su naturaleza portable es ideal para administradores y desarrolladores que necesitan acceder a SQL Server ocasionalmente o en situaciones donde no es posible instalar software de forma permanente.

Una de las principales ventajas de HeidiSQL es su facilidad de uso y su enfoque en la administración básica y el desarrollo de SQL. Además, permite realizar tareas como editar y ejecutar consultas SQL, exportar e importar datos, y administrar tablas y vistas. Estas funcionalidades pueden ser suficientes para tareas de mantenimiento diario y desarrollo básico en SQL Server, sin la necesidad de instalar software más pesado como SSMS.

Sin embargo, es importante destacar que HeidiSQL no proporciona las herramientas avanzadas de administración y optimización que se encuentran en SSMS o en alternativas como Toad for SQL Server o DbForge Studio. Esto limita su uso a entornos en los que se requieren operaciones sencillas. Asimismo, su interfaz y opciones están más orientadas a usuarios de MySQL y MariaDB, por lo que algunos aspectos pueden resultar limitados en el entorno de SQL Server.

Conclusión

En conclusión, la alternativa más adecuada a SSMS dependerá de las necesidades específicas de cada equipo o proyecto. Herramientas como Azure Data Studio y Aqua Data Studio ofrecen opciones multiplataforma y flexibles que se integran bien en entornos modernos y de nube, mientras que DbForge Studio y Toad for SQL Server proporcionan funcionalidades avanzadas de optimización y administración, a un coste. DBeaver, SQuirreL SQL y HeidiSQL son opciones gratuitas (con opción de pago) adecuadas para entornos multi-SGBD, aunque con ciertas limitaciones en el ámbito de SQL Server. La elección final debe considerar factores como la funcionalidad necesaria, el presupuesto y el ecosistema tecnológico en el que se desarrollarán las actividades de administración y desarrollo.

Dic

2024

Christmas Power Platform Euskadi 2024: Tecnología Solidaria al Servicio de la Comunidad

Los días 13 y 14 de diciembre de 2024, llega el evento que combina lo mejor de la Power Platform con el espíritu solidario de la Navidad. El Christmas Power Platform Euskadi 2024 se consolida como uno de los eventos más destacados de la comunidad tecnológica este año y será el punto de encuentro virtual para expertos y apasionados de las tecnologías de Microsoft, ofreciendo una agenda cargada de aprendizaje, innovación y propósito social.

Participación Solidaria: Un Evento con Valor

Aunque la convocatoria para ponentes ya ha finalizado, aún puedes ser parte de este evento único como asistente. Para asistir al evento, solo necesitas adquirir tu entrada a través de la plataforma Eventbrite, donde el coste de tu entrada será donado directamente al Banco de Alimentos de Guipúzcoa. De esta manera, no tendrás que realizar la donación por tu cuenta; al comprar tu entrada, estarás contribuyendo automáticamente a esta causa solidaria.

Con un mínimo de 1€, puedes ser parte de esta experiencia transformadora mientras ayudas a quienes más lo necesitan.

SoyDBA: Mi Participación en Christmas Power Platform Euskadi

Tengo el honor de ser uno de los patrocinadores y además ponente en este evento. En mi charla, compartiré conocimientos clave sobre SQL Server y Power BI, abordando estrategias prácticas y consejos para sacar el máximo partido a estas herramientas. Será una excelente oportunidad para conectar contigo y explorar juntos cómo optimizar el rendimiento en proyectos tecnológicos.

Como creador del blog SoyDBA, este Christmas Power Platform Euskadi 2024 me brinda una plataforma para continuar aportando a la comunidad y generar un impacto positivo. Espero verte en mi sesión.

Agenda del Evento: Un Espacio para el Conocimiento

La agenda del evento se ha desvelado parcialmente, como ves en la imagen parte de los ponentes aún son sorpresa.

Si quieres estar al día de todas las novedades te recomiendo no esperar más y unirte al evento comprando una entrada. Lo que sí te puedo asegurar es que durante los dos días del evento, te esperan:

Charlas de Expertos: Descubre las últimas novedades y casos prácticos en Power BI, Power Apps, Power Automate, Power Pages y más.
Casos de Éxito Empresariales: Aprende cómo las organizaciones están utilizando Power Platform para transformar sus operaciones.
Oportunidades de Networking Virtual: Conéctate con otros asistentes y expande tu red profesional.

Cómo Participar

Para participar es sencillo, lo único que tienes que hacer es adquirir tu entrada en Eventbrite. Esto asegura tu acceso al evento realizando tu donación solidaria mínima de 1€ hasta lo que tu quieras donar. Antes del evento todos los inscritos recibirán en su email los enlaces para la conexión al evento. Simplemente tendrás que esperar y conectarte a alguno de los tracks los días del Evento. Y ya está, ya solo queda disfrutar de todas las sesiones desde la comodidad de tu hogar y aprovechar al máximo esta experiencia.

Bueno no, una cosa más, si te apasiona esta idea tanto como a nosotros por favor, comparte. Cuantos más seamos mejor.

Haz de la Tecnología una Fuerza para el Bien

El Christmas Power Platform Euskadi 2024 no es solo un evento tecnológico, sino también un movimiento que combina innovación y solidaridad. Cada entrada adquirida, cada charla atendida y cada idea compartida contribuyen a hacer una diferencia positiva.

Reserva tu entrada en Eventbrite, marca las fechas en tu calendario y prepárate para ser parte de una Navidad llena de aprendizaje y propósito. ¡Nos vemos el 13 y 14 de diciembre, y no olvides asistir a mi charla! Será un placer compartir este espacio contigo.

Dic

2024

Los peligros del permiso SHOWPLAN

Cuando administramos bases de datos en SQL Server, no debemos perder el foco en asegurar la confidencialidad, integridad y disponibilidad de los datos. Sin embargo, a veces, centrados en el rendimiento, subestimamos cómo ciertos permisos pueden abrir brechas de seguridad inesperadas. Uno de estos permisos es SHOWPLAN. ¿Alguna vez le has dado permisos de SHOWPLAN en producción a un desarrollador? Puede parecer inofensivo y además es una herramienta poderosa y útil para que los desarrolladores puedan optimizar sus consultas, pero no es tan sencillo. ¿Sabías que puede convertirse en un riesgo significativo si se concede de manera inapropiada? A continuación, te cuento en profundidad qué implica este permiso, sus ventajas legítimas y los riesgos que puede acarrear cuando se utiliza fuera de contexto.

¿Qué es el permiso SHOWPLAN?

El permiso SHOWPLAN en SQL Server permite a los usuarios generar y visualizar los planes de ejecución de las consultas. Esto incluye detalles sobre cómo el motor de base de datos planea ejecutar una consulta SQL, mostrando operaciones como búsquedas en índices, uniones, escaneos de tablas, y predicados de filtro.

Existen dos variantes principales de este permiso, SHOWPLAN_XML y SHOWPLAN_TEXT, que permiten generar una representación del plan de ejecución en formato XML o texto, respectivamente. Además, SHOWPLAN_ALL muestra información completa sobre el plan de ejecución.

Cuando se activa este permiso, SQL Server no ejecuta realmente la consulta, sino que devuelve un «plan estimado», describiendo cómo se procesaría la consulta en términos de operaciones lógicas y físicas.

Ventajas del permiso SHOWPLAN

El permiso SHOWPLAN tiene aplicaciones legítimas y valiosas en el desarrollo y mantenimiento de bases de datos. Entre sus principales beneficios, podríamos destacar los siguientes:

Identificación de problemas de rendimiento

La principal utilidad del permiso SHOWPLAN es ayudar a identificar cuellos de botella en el rendimiento de las consultas. Tanto los administradores de bases de datos (DBAs) y desarrolladores podemos usar esta información para optimizar consultas, ajustar índices o rediseñar tablas. Por ejemplo, un plan de ejecución puede revelar que una consulta está realizando un «escaneo completo de tabla» (Table Scan) en lugar de usar un índice, lo que indica la necesidad de crear un índice o ajustar el predicado.

Análisis predictivo sin ejecutar consultas

Con SHOWPLAN, es posible analizar cómo SQL Server ejecutaría una consulta sin necesidad de ejecutarla realmente. Esto es crucial cuando se trabaja con consultas que afectan grandes volúmenes de datos, ya que permite evaluar su impacto sin riesgo de sobrecargar el sistema.

Comparación de estrategias de consulta

Los desarrolladores pueden usar SHOWPLAN para comparar alternativas de diseño de consultas. Por ejemplo, al evaluar si una subconsulta correlacionada es más eficiente que una JOIN, los planes de ejecución ayudan a elegir la mejor estrategia.

Herramienta educativa y formativa

En entornos de desarrollo, SHOWPLAN también se usa para enseñar a nuevos DBAs y desarrolladores cómo optimizar consultas y comprender el comportamiento interno de SQL Server. Es una herramienta ideal para profundizar en cómo el optimizador toma decisiones.

Riesgos asociados al permiso SHOWPLAN

Aunque las ventajas de SHOWPLAN son innegables en manos de DBAs y desarrolladores, los riesgos emergen cuando este permiso se concede a usuarios fuera de estos roles o sin las medidas de seguridad adecuadas.

Exposición de datos sensibles

Una característica poco conocida de SHOWPLAN es que los planes de ejecución pueden revelar los valores exactos de las variables o parámetros utilizados en las consultas. Aunque un usuario no tenga acceso directo a las tablas implicadas, podría deducir información confidencial a través del análisis del plan.

Por ejemplo si ves esta consulta en ejecución:

SELECT * FROM Clientes WHERE NumeroTarjetaCredito = @Numero;

El plan de ejecución en XML mostrará que @Numero contiene un valor como 1234-5678-9012-3456, exponiendo información sensible.

Mapeo de la estructura de la base de datos

Los planes de ejecución muestran detalles como nombres de índices, columnas y relaciones entre tablas. Un usuario malintencionado podría utilizar esta información para mapear la estructura de la base de datos y diseñar ataques dirigidos, como inyecciones SQL más efectivas o extracción de datos.

Imagina que alguien, gracias a técnicas de SQLi es capaz de vulnerar la seguridad de tu app y llegar a la base de datos. Si el usuario de la aplicación tiene más permisos de los estrictamente necesarios el daño puede ser gravísimo.

Ingeniería inversa de estadísticas

Los planes de ejecución contienen estadísticas sobre cardinalidad y distribución de datos, lo que permite deducir patrones sensibles, como la cantidad de registros que cumplen ciertas condiciones. Esto podría facilitar ataques de análisis estadístico. Sumale a esto los anteriores peligros y tendrás el cóctel perfecto para una fuga inesperada de datos.

Uso en ataques de denegación de servicio (DoS)

Por último, pero no menos importante, un usuario malintencionado con acceso a SHOWPLAN podría diseñar consultas costosas que generen planes de ejecución extremadamente complejos, agotando recursos del servidor.

Mejores prácticas para mitigar los riesgos de SHOWPLAN

Para evitar que el permiso SHOWPLAN se convierta en un vector de ataque, es esencial adoptar un enfoque de seguridad robusto que contemple varias estrategias complementarias. En primer lugar, es imprescindible seguir el principio de menor privilegio, limitando el uso de este permiso exclusivamente a administradores de bases de datos (DBAs) y algunos desarrolladores, y exclusivamente en entornos de desarrollo o pruebas. En producción, el acceso debe ser excepcional y estrictamente controlado.

Cuando se trabaja con bases de datos reales en entornos de prueba, la anonimización o el enmascaramiento de datos son medidas clave para evitar la exposición accidental de información sensible. Esta práctica protege los datos al tiempo que permite un análisis seguro del rendimiento de las consultas.

Además, las auditorías regulares resultan fundamentales para identificar usuarios que dispongan de permisos sensibles como SHOWPLAN. Herramientas nativas como Extended Events en SQL Server pueden facilitar el rastreo y análisis del uso de este permiso, asegurando un monitoreo constante de posibles accesos indebidos.

Por último, la formación continua de los equipos de desarrollo y administración es un pilar esencial. Educar a los responsables sobre los riesgos asociados al uso indebido de permisos sensibles y las mejores prácticas para gestionarlos garantiza que las concesiones innecesarias puedan evitarse de manera efectiva, fortaleciendo así la postura de seguridad general del entorno.

Conclusión

El permiso SHOWPLAN es una gran herramienta para la optimización de consultas y el análisis del rendimiento en SQL Server, pero su mal uso puede comprometer la seguridad de los datos. Concederlo sin restricciones puede exponer datos sensibles, facilitar ataques y comprometer la integridad del sistema.

Para evitar estos riesgos, es esencial adoptar un enfoque de seguridad proactiva, restringiendo su uso a roles específicos, monitoreando su aplicación y utilizando alternativas seguras cuando sea posible. De esta manera, podemos aprovechar las ventajas de SHOWPLAN sin comprometer la seguridad de nuestras bases de datos. Como siempre, en SQL Server, un enfoque basado en “confianza cero» (Zero Trust) es la mejor política.

Nov

2024

Fabric Lakehouse vs Warehouse

Comparar Fabric Lakehouse y Fabric Warehouse dentro del ecosistema de Microsoft Fabric nos lleva a analizar dos enfoques arquitectónicos que, aunque comparten una base tecnológica común, se diseñan para resolver problemas muy diferentes. Ambas soluciones surgen como respuesta a la necesidad de gestionar datos en un panorama empresarial cada vez más complejo, pero destacan por sus diferencias en flexibilidad, rendimiento y casos de uso.

Para empezar, debemos saber que Microsoft Fabric utiliza Delta Lake como formato de tabla unificado tanto para los componentes de Lakehouse como para los Warehouses. Las tablas Delta son esencialmente archivos Delta Parquet, un formato de código abierto compatible con la mayoría de las soluciones de otras nubes. Esto permite un acceso sin problemas a los datos en todos los motores de proceso de Microsoft Fabric y también entre diferentes nubes como Google, AWS, IBM, etc.

Por lo tanto, aunque los Warehouses en Microsoft Fabric pueden tener algunas similitudes con las bases de datos SQL tradicionales que tan bien conocemos, también tienen muchas características en común con los Lakehouses, incluyendo el uso de tablas Delta Parquet. Pero, entremos un poco más en detalle.

¿Qué es Fabric Lakehouse?

Fabric Lakehouse es una solución híbrida que combina lo mejor de los data lakes y los data warehouses. Este modelo permite gestionar datos estructurados, semiestructurados y no estructurados en un entorno único y flexible. Su arquitectura está basada en tecnologías de almacenamiento de objetos, como Delta Lake, optimizadas para trabajar con grandes volúmenes de datos en formatos diversos como Parquet, CSV y JSON.

Su enfoque permite a las empresas procesar datos en bruto, realizar análisis exploratorios y aplicar modelos avanzados como machine learning, sin necesidad de transformaciones estrictas previas. Por esta razón, Fabric Lakehouse es ideal para casos en los que se manejan datos históricos, flujos de datos en tiempo real o múltiples fuentes heterogéneas.

Fabric Warehouse: Optimización para consultas estructuradas

Fabric Warehouse, por su parte, representa el enfoque más tradicional de los almacenes de datos. Diseñado para cargas de trabajo analíticas OLAP, este modelo almacena los datos en un formato tabular estructurado que facilita consultas rápidas y eficientes. Su base tecnológica incluye índices columnstore que aceleran significativamente el tiempo de respuesta en análisis complejos.

Fabric Warehouse se destaca en escenarios de reporting empresarial, donde la precisión y la rapidez son fundamentales. Además, su integración nativa con herramientas como Power BI y Excel lo convierte en una elección prioritaria para la generación de informes y dashboards operativos.

Diferencias entre Fabric Lakehouse y Warehouse

Aunque ambos modelos comparten objetivos relacionados con la gestión de datos, presentan diferencias importantes en cuanto a flexibilidad, rendimiento y casos de uso.

Flexibilidad en el manejo de datos

Fabric Lakehouse ofrece un enfoque más versátil, permitiendo trabajar con datos en su estado original sin transformaciones previas. Esto es crucial en proyectos donde los datos cambian constantemente o provienen de múltiples fuentes con formatos variados. Por otro lado, Fabric Warehouse requiere un modelo de datos predefinido y procesos ETL claros para garantizar la eficiencia en el análisis.

Rendimiento en consultas y análisis

En términos de rendimiento, Fabric Warehouse sobresale en escenarios donde se necesitan consultas estructuradas y rápidas sobre datos optimizados. En cambio, Fabric Lakehouse es más adecuado para procesar grandes volúmenes de información y ejecutar análisis avanzados, aunque puede ser menos eficiente para consultas pequeñas.

Integración con herramientas de análisis

Fabric Lakehouse se integra de manera natural con entornos de Big Data y plataformas como Apache Spark, lo que lo hace ideal para análisis exploratorio y aprendizaje automático. Fabric Warehouse, por su parte, está optimizado para herramientas de BI tradicionales, siendo la opción preferida para usuarios de Power BI y Excel.

Endpoints de Fabric. La principal diferencia

Hasta ahora hemos estado viendo las definiciones más comerciales y las diferencias teóricas entre ambos sistemas. Vamos ahora con algo que va a marcar la diferencia entre ambas soluciones, los endpoints o puntos de conexión (me niego a llamarlos puntos finales como me niego a llamar tejido a fabric). Estos endpoints son los extremos finales de nuestros lakehouse y warehouse a los que nos vamos a conectar y vamos a ver que hay 3 tipos principales.

Lakehouse Endpoint para Spark Runtimes/Libraries

Para trabajar con archivos y tablas de Lakehouse, ya sea para análisis, transformaciones o procesamiento usando Spark, nos conectaremos al endpoint del Lakehouse que está separado del endpoint de SQL Analytics. Igual que con los métodos estándar fuera de Fabric para trabajar con archivos y tablas delta, para conectarnos, usaremos la URL, la ruta ABFS o montaremos el Lakehouse directamente en nuestro explorador. El uso de Spark nos permite realizar operaciones de escritura con Scala, PySpark, Spark SQL o R. Sin embargo, si deseamos utilizar T-SQL, deberemos utilizar SQL Analytics Endpoint, donde vamos a ver que solo podemos realizar operaciones de “solo lectura”.

SQL Analytics Endpoint (Lakehouse)

El endpoint SQL Analytics se crea automáticamente cuando creamos un Lakehouse. Cada Lakehouse tiene solo un endpoint SQL y, como cada Workspace o Área de Trabajo de Fabric puede tener más de un Lakehouse, la cantidad de endpoints SQL en un espacio de trabajo coincide con la cantidad de Lakehouses que tengamos.

Estos endpoint nos ofrecen una experiencia SQL para leer tablas Delta. Es importante destacar que este Endpoint es solo lectura y únicamente sirve para las tablas, como es lógico no podremos usar SQL para consultar archivos e información no estructurada. Por algo la S de SQL significa Structured, ¿no?

Esto no es todo, SQL Analytics Endpoint no solo nos permite analizar las tablas Delta utilizando T-SQL, también vamos a poder guardar funciones, generar vistas y aplicar seguridad a nivel de objetos SQL. Gracias a estas funcionalidades los ingenieros de datos podrán crear una capa relacional sobre los datos físicos en Lakehouse, y exponerlos para que los analistas usen sus a herramientas de informes utilizando una cadena de conexión SQL.

Ya que estos endpoint son solo lectura, la creación/modificación de tablas Delta (y los datos dentro de las tablas Delta) se debe hacer usando Apache Spark. Una vez creadas las tablas Delta con Spark dentro de Lakehouse se podrán ver y leer automáticamente a través del endpoint SQL. ¿Y qué pasa si hay tablas Delta externas creadas con código Spark? Estas tablas no serán visibles desde el endpoint SQL hasta que cree un acceso directo o Shortcut a la tabla Delta externa.

Seguridad en el SQL Endpoint de Fabric Lakehouse

Como hemos visto, podemos configurar la seguridad a nivel de objeto (OLS) para acceder a los datos mediante el punto final de análisis SQL. Sin embargo, es importante destacar que estos permisos solo se aplicarán cuando accedamos a los datos a través endpoint de análisis SQL. Si deseamos asegurar que no se pueda acceder a nuestros datos de otras maneras (a través de diferentes endpoints o directamente), debemos establecer roles y permisos en el Área de Trabajo.

Conexión al SQL Analytics Endpoint

Para esta parte del artículo me voy a basar en este del blog de Microsoft publicado por Marc Bushong y voy a tomar prestadas sus fotos.

Dejadme que antes de nada os enseñe su Área de Trabajo de Fabric. Como veis tiene un Lakehouse llamado “BronzeLakehouse” y, en la imagen, podemos ver el endpoint de SQL Analytics (rojo) y el endpoint de Lakehouse (verde)

Accediendo al endpoint de Lakehouse vemos Files (rojo) y Tables Delta (verde). Si queremos asegurarnos, en la esquina superior derecha veremos un menú desplegable con el endpoint estamos viendo seleccionado.

Si cambiamos la vista al Endpoint de SQL Analytics vais a ver que ya solo podemos ver las tablas:

Antes de pasar al siguiente endpoint tenemos que saber que también podemos conectar al endpoint SQL desde fuera de Fabric con las herramientas que conocemos como SSMS o Azure Data Studio. Simplemente tendremos que poner la autenticación y cadena de conexión del endpoint como si de cualquier otra conexión de servidor SQL se tratara.

Data Warehouse Endpoint

El Data Warehouse Endpoint opera como un DWH SQL en un entorno tradicional. Esto significa que proporciona compatibilidad casi total con T-SQL, de manera similar a una base de datos SQL Server implementada en nuestros servidores. Este endpoint ofrece múltiples ventajas funcionales.

T-SQL de lectura y escritura

Entre estas ventajas funcionales podemos destacar que cuenta con soporte para lectura y escritura en tablas Delta, lo que permite consultar los datos tanto con Spark como con T-SQL. Sin embargo, mientras que en el Lakehouse las operaciones de escritura solo se podían realizar con Spark, en el Warehouse es al revés y únicamente pueden realizarse mediante T-SQL. Además, incluye soporte casi completo para operaciones DML y DDL, lo que abarca la ingesta, el modelado y el desarrollo de datos a través de T-SQL o mediante interfaces gráficas. Esto nos permite un control absoluto sobre la creación de tablas, la carga de datos y las transformaciones, utilizando herramientas como COPY INTO, pipelines, dataflows o métodos de ingesta cruzada entre bases de datos como CREATE TABLE AS SELECT (CTAS), INSERT..SELECT o SELECT..INTO. Solo hay una pega, a día de hoy todavía no es compatible con la sintaxis MERGE.

Soporte ACID

Este endpoint también garantiza el cumplimiento de las propiedades ACID para transacciones aunque trabaje con tablas Delta. Cabe destacar que, aunque Lakehouse ofrece compatibilidad ACID, se limita a las tablas Delta, por lo que los ficheros de un Lakehouse podrían no cumplir con estas propiedades.

Transacciones Multitabla

Otra característica es el soporte para transacciones que abarcan múltiples tablas, lo que facilita flujos de trabajo complejos. Al combinar estas capacidades de lectura/escritura con las herramientas de ingesta entre bases de datos, es posible integrar datos sin complicaciones desde varios Warehouses o Lakehouses. Cuando se ingieren datos en el Warehouse, estos se almacenan automáticamente en formato Delta dentro de OneLake, garantizando una estructura optimizada y unificada.

En la siguiente imagen podemos ver todo lo que hemos comentado hasta ahora en acción, una consulta entre bases de datos para cargar datos en el Warehouse desde el Lakehouse, donde se crea y se carga la tabla de Warehouse «holiday.Warehouse_Holiday_Clean» con los datos de la tabla «Silverlakehouse.dbo.Holiday_Clean» del Lakehouse como origen, y luego se muestran los registros.

Conclusión

Para cerrar esta comparativa, queda claro que tanto Fabric Lakehouse como Fabric Warehouse son piezas fundamentales en el ecosistema de Microsoft Fabric, cada uno respondiendo a diferentes necesidades en el manejo y análisis de datos. A través de su integración en OneLake, ambas soluciones permiten un acceso uniforme y una gestión eficiente de los datos, aprovechando las ventajas de las tablas Delta como formato unificado.

La verdadera innovación radica en cómo Microsoft Fabric ofrece puntos de conexión (endpoints) especializados para cada solución. Estos endpoints no sólo habilitan el acceso a los datos según las necesidades específicas de cada modelo, sino que también permiten combinar diferentes entornos de datos en operaciones cruzadas, como lo demuestra la imagen adjunta. Aquí vemos cómo los endpoints para Lakehouse y Warehouse trabajan en conjunto, integrando datos de manera fluida y demostrando el poder de esta arquitectura unificada.

Este enfoque, que facilita tanto la conexión como el intercambio de datos entre sistemas, posiciona a Microsoft Fabric como una solución robusta y flexible para las necesidades actuales de la analítica empresarial.

cloud

La SQLCon llega a España

NO TE PIERDAS NADA

Colabora con nosotros

Entradas recientes

Etiquetas

Comentarios recientes