Categorías
Donaciones

Todo el contenido es gratuito y en beneficio de la comunidad. Puedes reconocer el esfuerzo con una donación si lo deseas.

Inserte aquí su publicidad

Archivo de la categoría ‘Opinión’

Ya viene SQL Server 2014, lo que significa por lo menos que hay que ponerse a leer para ir aprendiendo. Y eso he hecho, por lo menos de la estrella revolucionaria que esta versión traerá debajo del brazo, in-memory OLTP. Después de unos cuantos whitepapers, guías, blogs, etc., recojo aquí un conjunto de preguntas que yo mismo me he hecho y a las que a algunas le he ido encontrando respuesta de cara a suavizar el golpe a los que comiencen. Lo haré en dos partes, esta primera más del lado técnica (aunque sin profundizar en lo teórico para no perderse), y una segunda más filosófica o reflexiva sobre le cambio. Vayamos a ello.

Hekaton

Nombre en clave de la funcionalidad in-memory OLTP, la estrella en SQL Server 2014. También llamado XTP (extreme transaction processing).

¿Qué es?

La explicación corta, los datos residen permanentemente en memoria, no en disco, con lo que al trabajar siempre en caché, se suprimen a la vez las esperas por disco y las esperas por bloqueos, lo que aumenta dramáticamente el rendimiento.

¿Por qué surge?

El disco es lo más lento de un sistema de bases de datos. El SSD es carísimo. La CPU hace ya bastante que no corre más, de hecho, el escalado va por multiplicar los núcleos y procesadores de un servidor, pero una consulta simple no corre en más de un core. Sin embargo, la memoria es muy barata, al ser casi un consumible de cliente, y puedes montar un servidor con 2 Tb de RAM sin que el coste sea astronómico. La solución pasa por tenerlo todo en memoria.

(Bueno, también surge porque motores de la competencia lo tienen, véase SAP Hana u Oracle Exadata.)

¿Si los datos no están en el disco, dónde están cuando se para el servicio?

Existe un trabajo en background que va salvando a disco los datos cambiados y borrados (aparte, una especie de checkpoint continuo en la sombra para que cuando se pare el servidor, los datos no se pierdan). Se estructuran bloques de 128 Mb y se van realizando las lecturas del log de transacciones para poder hacer el redo o recovery. De hecho, hay dos, el “data” y el “delta” (el delta es en el que se anotan los registros borrados). Cuando se inicia el servicio, como parte del redo o recovery, se suben a memoria los datos (data), todos, salvo los borrados (delta). Examinando el “fichero”, se observa que es un directorio con un buen montón de ficheros, entre los que hay un conjunto de ellos de 128Mb de tamaño.

¿Cómo es que no hay bloqueos?

No hay ningún tipo de bloqueo, se gestionan por snapshot (por defecto) y se controla por timestamp cuál es el valor válido del registro. Al iniciar una actualización, tomas tu versión del registro, lo cambias y se marca, se guardo lo que había y lo nuevo y se diferencia el “estado actual” de la tabla por el timestamp.

¿Cómo se estructuran las páginas en esa memoria?

No, ya no hay páginas. La estructura es totalmente diferente. Son acumulaciones de información de registros en un hash (no en arbol B) en los que en cada registro tiene acoplada la ordenación de cada índice definido para la tabla. De hecho, los registros de una misma tabla no tienen ni por qué estar cerca.

¿Todas las tablas tienen que estar en memoria en una base de datos?

No, no es necesario, puede haber tablas que estén en memoria y tablas que no. Eso sí, hay que marcar la base de datos para que permita la posibilidad de crear tablas in-memory.

¿Cómo es el acceso a los datos?

El T-SQL es el mismo, existe dentro del motor un intérprete que transforma el código a sintaxis para acceder a tablas en memoria. También se pueden construir consultas que mezclen unas tablas en memoria y otras en disco. Sin embargo, para el acceso exclusivo a tablas en memoria, lo ideal es preparar procedimientos almacenados compilados en forma nativa (concepto nuevo también). Hay algunas cosillas raras en la creación de tablas y de estos procedimientos almacenados, pero nada especialmente complicado.

¿Native Compiled Stored Procedures?

La gran ventaja de estos Native Compiled SPs está en que ahorras capas de llamadas a funciones que componen cada operador de un plan de ejecución, puntos intermedios que al final suponen consumo de CPU a la hora de ejecutar un plan de ejecución ya compilado. Estos procedimientos compilados de forma nativa ya van en C, dentro de una DLL que se carga en el sqlsvr.exe, todo está ya dentro. Ojo, esto tiene unas connotaciones importantes para el rendimiento que hay que tener en cuenta, no todo son cosas buenas. Sólo valen para casos en los que todas las tablas implicadas residan en memoria.

¿Vale todo? ¿Qué no se puede hacer?

Hay bastantes, las que son más significativas para mí son:

  • No se pueden usar tipos de datos grandes, estando cada registro está limitado a 8000 bytes potenciales. Ni varchar(max) ni ningún otro blob de los que siguen estando en esta versión.
  • No se pueden modificar las tablas con un ALTER (hay que borrar y volver a crear). Y los índices se crean con la tabla, no se pueden crear después. Tampoco se pueden truncar tablas.
  • La intercalación también está muy restringida (sólo de Windows, _BIN2 para campos que estén indexados).
  • Tampoco puede hacerse una consulta a dos tablas que estén en distintas bases de datos (ni un inner join ni un inser..select).
  • No todas las funciones están admitidas, aunque sí la mayoría.
  • Tampoco se pueden crear cursores (evitando así el oxímoron).
  • No se pueden usar identities (hay que usar secuencias).

¿Se puede pasar una tabla en disco a tabla en memoria?

Sí, eso facilita mucho las migraciones. Aunque hay que hacer notables adaptaciones en las aplicaciones.

¿Y para el ETL?

Pues también, sobre todo para cuando se tienen que guardar tablas de staging. Hay una funcionalidad concreta que permite no tener que persistir nada, sólo se conserva la estructura (tipo tempdb, pero en memoria). Al no tener que escribir nada en disco, el rendimiento se dispara. Cuando le pasa algo al servicio, estas tablas se crean de nuevo vacías (algo que de todas formas ya se hace por el mero significado de ellas, son intermedias que se “truncan” y cargan en cada ejecución del proceso).

Conclusión

El resumen es que la idea no es en qué tablas y aplicaciones emplear Hekaton, sino en qué casos no podrá ser utilizado, ya que la diferencia potencial en rendimiento es la que hay entre la velocidad de un disco y la memoria. Hay que tener reservas y tener también muy claro que hay que cuidarse de querer solucionar problemas con esto, orientándolo más a desarrollos nuevos o a mejorar/escalar desarrollos existentes que ya afinados.

Preguntas del más allá (sin respuesta, algunas)

¿Por qué tras tanto empeño de MS (y el resto) en el cloud, ahora esta monstruosa funcionalidad orientada 100% al on-premisse?

Si se buscaba optimizar la escritura en OLTP, ¿por qué no va tempdb, donde se producen entorno al 50% de las escrituras, de forma nativa, dentro de memoria (y no va, al menos por ahora, con la de limitaciones que hay con la intercalación)?

¿Y no hay nada más que esto? Por supuesto que sí, aunque sin duda esta funcionalidad es la principal novedad.

Bibliografía

Algunos de los documentos y referencias consultadas, así como documentación para profundizar.

http://blogs.technet.com/b/dataplatforminsider/archive/2013/08/01/hardware-considerations-for-in-memory-oltp-in-sql-server-2014.aspx

http://en.wikipedia.org/wiki/Hekaton_(database)

http://download.microsoft.com/download/F/5/0/F5096A71-3C31-4E9F-864E-A6D097A64805/SQL_Server_Hekaton_CTP1_White_Paper.pdf

http://technet.microsoft.com/es-es/evalcenter/dn205290.aspx

http://msdn.microsoft.com/en-us/library/dn133186(v=sql.120).aspx

http://technet.microsoft.com/en-us/library/dn296374(v=sql.120).aspx

http://research.microsoft.com/pubs/193594/Hekaton%20-%20Sigmod2013%20final.pdf

http://blogs.msdn.com/b/arvindsh/archive/2013/07/03/sql-2014-in-memory-oltp-hekaton-training-videos-and-white-papers.aspx

Por el foro y por mi propio trabajo, vengo notando que últimamente está cogiendo cada vez más fuerza la cuestión de la calidad de los datos que se manejan. Inicio aquí una serie de post sobre este tema, creo también una categoría dentro del blog para agruparlos. No es que sea un experto en la materia. He realizado y participo actualmente en este tipo de proyectos, aunque de hecho, pido que me los hagan más que implementarlos yo. Pero en ese camino de perfeccionamiento creo que puedo aportar los errores que cometa para que los que vengan detrás… Los repitan a pesar de todo. Y por eso justamente empezaré, los errores que he visto y sigo viendo al afrontar la cuestión.

Al menos a mí, me llama la atención en contraposición a otro gran tema del momento (no es que venga de ahora), como Big Data. Esto es,  por un lado lo acaparo todo, me vale todo para ser tratado, si está estructurado mejor, si no, me da lo mismo, que ya me ocupo yo. Y por otro, vaya, que tengo dos veces un señor (o lo parece), de otro tengo su email, pero que es “a@a.es” y de otros tres no tengo ni siquiera eso.

Obviamente, no es de extrañar que si no se es riguroso con la toma de datos, el resultado no puede tener una calidad adecuada. Más grave es cuando los datos que sí se pretende que sean estructurados presentan lagunas más que notables, inconsistencias, huecos, etc. Y esto teniendo en cuenta que son los datos personales de la gente que una vez adquirió tus productos, o que te los regaló para una acción concreta. Cuando más en boga está lo relacionado con la conservación de clientes frente la obtención de los nuevos, resulta que ni siquiera es posible establecer una comunicación con un cliente porque no sabes su teléfono. No nos rasguemos las vestiduras, somos clientes de datos muchas más veces que poseedores de los datos de los demás y, en general, no le prestamos especial atención a ello, con lo que la tarea de mantener una base de datos de calidad y actualizada es muy compleja.

Me contaron una anécdota sucedida con los datos de contacto del colegio de los niños, que lo ilustra bien a las claras. Hubo que realizar un cambio en las cuentas bancarias donde se domiciliaban los pagos del comedor (cuestiones de fusiones y desaparición de cajas de ahorro). La dirección del colegio tenía que comunicárselo a los papás y recibir una respuesta, no es lo mismo que hacer un comunicado o publicar un anuncio, y recurrió a las bases de datos que se recopilan con el alta inicial del alumno, cuando éste entra al colegio. Son unos pocos años los que han transcurrido y lo que allí se encontró fue bastante desolador, a la par que normal. Descartado el envío postal, ya que se requería respuesta, quedaban los emails y los teléfonos. Los emails, no valía ni la décima parte. De los que había, una gran parte pertenecían a cuentas de correo del trabajo. Aunque yo no lo entienda, es mucha la gente que emplea la cuenta de correo electrónico profesional para cuestiones personales. Y claro, ya no es sólo que haya mucha gente que haya perdido su trabajo, a eso hay que sumarle la gente que ha cambiado de empresa y la que su empresa ha cambiado, no ya de nombre, sino de dominio. Hasta “hotmail” es ahora “outlook”. Lo de los teléfonos sí estaban algo mejor, y bien de forma directa (ojo, también ayuda que pidan tres, el del papá, la mamá y el fijo de casa) o indirecta, pero seguían teniendo un buen montón de niños a los que  hubo que enviar para casa con una notita en la bolsa del desayuno.

Si en algo como el colegio de tus hijos se es descuidado a la hora de mantener al día los datos de contacto, por si te tienen que avisar de alguna cosa poco importante, como que tu hijo está enfermo o ha sufrido un accidente , ¿qué se puede esperar de… Todo lo demás? Así que primer error: pensar que los datos están bien o que están bien ahora.

Donde se podría observar un pantano de desesperación, y que yo veo como un nicho de negocio con mucho recorrido, es donde entra el siguiente punto en el catálogo de confusiones. Como el que confunde la parte con el todo, he tenido que escuchar ya muchas veces que el responsable de la base de datos es el departamento de IT. Y sí, de la base sí, pero de los datos es responsable el conjunto de la compañía. En otras palabras, un adecuado mantra, a barridos no se arregla. Es una cuestión transversal que implica a un gran número de áreas, que pasa primeramente por la definición de unas políticas, de una revisión continua, de medir el impacto de las medidas que se tomen para ver si se va por el buen camino.

De aquí se desprende otro error común. Llegado el momento, se decide “externalizar” y se contrata a una empresa especializada en estas lides para que haga un trabajo de depuración de la información. Suponiendo que ese trabajo se haga bien (algo que yo no he tenido la suerte de vivir, no digo que sea imposible), el que lo contrata piensa que, una vez hecho ese proyecto nuestra base de datos estará inmaculada hasta el fin de los tiempos. Craso error: la calidad de datos es una tarea continua, no puntual. Como decía en el párrafo anterior, a barridos no se arregla, y estas acciones puntuales son eso, un barrido, que podrá suponer un punto de inflexión (aunque sólo sea por el escarmiento de la factura del trabajo externalizado), pero no una solución.

Y aquí finalizo este primer post sobre este tema, vendrán más, porque da para mucho más.

 

Explotar un cubo con Excel es quizá de las cosas más agradecidas de esta profesión. Es fácil, el usuario lo entiende y lo conoce (en ocasiones bastante mejor que uno mismo), no requiere de un esfuerzo importante preparar la interfaz (porque ya existe). Permite recoger muy rápidamente el fruto de tu trabajo, algo que en otras ocasiones, bien no existe (nadie llama para felicitarte porque la base de datos hoy vaya muy bien), bien se observa pasado el tiempo, cuando la aplicación evoluciona y es resaltada por la ausencia de la misma. Sí, me estoy refiriendo a cuando se critica a esa nueva aplicación que se está implantando, pero, oye, es ver el vaso medio lleno, el menoscabo de lo nuevo encumbra lo anterior.

Hoy la base de datos va muy bien

El esfuerzo, y no pequeño, está antes de eso. Hay que hacer nada menos que un proyecto de inteligencia de negocio. Claro que es complejo, si no, lo haría cualquiera. Lo que sí puede hacer cualquiera es utilizar ese trabajo, exprimirle el jugo y descubrir todo aquello que como usuario conocedor de la materia que se analiza ni siquiera fue capaz de verbalizar en la fase de recogida de requisitos. Y es ahí donde llega el verdadero reto. Soltar ahí las dimensiones tiempo, geografía y producto con sus métricas de ventas y objetivos, eso se nos ocurre a todos, y para la demo o la primera puesta de largo, todo un éxito. Pero, hete aquí que cuando presentas aquello, ve el usuario las posibilidades y, como aquellos dibujos en los que hay que desenfocar la vista para ver la imagen en relieve (estereogramas), ve un universo de nuevas posibilidades, que serán muy complicado de implementar.

Más allá de esa revelación, es imprescindible que tengamos la capacidad de aguantar ese segundo tirón para cubrir las necesidades del usuario. Sí, unas necesidades que no sabía que tenía en muchos casos, pero que al haberle mostrado lo que se puede conseguir, no nos quedará más remedio que realizarlo.

Por estas cosas que pasan, resulta que estando el patio como está, tenemos de nuevo en puertas un nuevo proceso de selección que me tocará disfrutar, en este caso un perfil de BI. Como ya comenté en mi anterior experiencia estos asuntos hace un par de años (leer aquí), sobre la inexistencia de una clase media en este mundillo, cuando buscas un DBA o un profesional de SQL Server en general, te llegan perfil de todo tipo, pero muy poquitos de lo que uno busca. Malo si lo buscas y no posees ese expertice, sí, pero excelente noticia por todo lo demás.

Ahora que tendré que ponerme a revisar los CVs que lleguen y a entrevistar, me surge de nuevo esa duda: ¿Hay algún profesional de SQL Server que no tenga trabajo? De otro modo, eso significará que cuando yo termine, le habré traspasado el problema a algún otro que tendrá que verse en mi misma situación, con lo que al menos se habrá movido un poco el árbol. Y supongo que será así. A menudo tengo noticias de puestos que surgen aquí y allá, en los que me preguntan si sé de alguien que pueda estar interesado. Nunca he sido capaz de recomendar a nadie porque no sabía de nadie que buscara.

En esa línea, me gustaría recibir comentarios sobre esta cuestión, ya que es posible que esté completamente confundido. También me gustaría recibirlos de la gente de selección que se ocupa de estas búsquedas, ya que en general uno sabe de lo suyo (como se suele decir, cada cual cuenta la feria según le va), pero el que tiene que lidiar con ello a diario seguro que posee una opinión mejor formada del estado del mercado laboral en este sector.

Y por último, el que quiera probar suerte a tenerme de jefe, que se anime.

Escribí estas notas hace unos meses, sobre un tema del que la gente de mi equipo está más que acostumbrada oírme hablar (y lo que les queda) y las encuentro ahora para publicarlas.

 

Por circunstancias, aterrizo hoy en París. En este ratito que llevo aquí, he pagado 2,50 € por una botella de agua de 50cl. expedido por una máquina y he esperado pacientemente durante 30 minutos observando cómo se fumaba un cigarrillo tras otro un conjunto de 4 trabajadores de la empresa de autobuses que me tenía que trasladar a mi destino, al cual sin duda llegaré tarde, ya que además el atasco que tenemos es digno de nuestra M-40 madrileña.

Y españolito que soy, de los que como tantos, trabaja para una compañía francesa(*), uno no puede evitar la humana tentación de pensar “está claro, si es que no somos productivos”.

Indignado pues, que además de ello es la época, he decidido aprovechar este tiempo para no perderlo, escribiendo una entrada para el blog, reflexionando al hilo de la experiencia. Cuando estás hasta el gorro de oír que no somos productivos, que hay que trabajar más por menos, te encuentras con que ese país teóricamente tan próspero te cobra el agua a 10 veces su valor y emplea cuatro veces más de los trabajadores que son necesarios para hacer un trabajo, por cierto, que las maletas las he tenido que subir yo. Pero a eso sí que estoy más acostumbrado, a que un francés me cobre un huevo para que yo le haga su trabajo. Así que no sé si serán más productivos, ahora, más listos, eso seguro.

A estas alturas, el lector habitual estará echando de menos la relación de este tema con Sql Server y con la vida de un DBA. La relación está en que un DBA es un trabajador cualificado. Dicho de una forma más acorde a los tiempos, es un servicio de valor añadido, tan necesario como interesante para una empresa, sobre todo si se cuenta con formación, experiencia y ganas de trabajar. Si los hay que a un botellín de agua le sacan ese partido, qué decir por una labor como la seguridad de la información, el rendimiento de las aplicaciones, la calidad de los datos, y ese largo etc. que componen la cartera de servicios que se desempeñan en nuestro día a día.

Y como conclusión, aparte de la puesta en valor del trabajo del profesional de base de datos, para la aplicación de  cada uno: En cada tarea que realizas, evalúa el valor añadido que aportas y cuestiónate si ese tiempo que inviertes repercute directamente en ello. Como si de una sentencia sql se tratara, revisa el plan de ejecución, trata de reducir las lecturas lógicas, liberando recursos para tareas más críticas y mejorando el rendimiento.

 

(*) Cuando escribí el artículo, la compañía para la que trabajo era una filial del grupo francés Groupama Seguros. Desde Octubre, pertenece al grupo Catalana Occidente, habiendo cambiado su denominación a Plus Ultra Seguros.

 

 


Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies