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’

Además de DBA, también debo ocuparme de gestionar vacaciones, una de esas aborrecibles tareas que conlleva administrar algo bastante más complejo que el engine de Analysis Services. Pero bueno, aprendiendo de aquí y de allá (más por los tantos ejemplos de lo que no se debe hacer que se van recopilando que otra cosa), uno intenta hacerlo lo mejor posible, la mayor parte de las veces para no conseguirlo. De todos modos, lo mejor es que no hagan la encuesta aquellos que tienen esa alegría que es el tenerme de jefe. De ese modo, la estadística mejora considerablemente.

Justo ahora se acaba de reabrir en la liga de fútbol en España lo que se conoce como “mercado de invierno”. Es un periodo que es generalmente de mucho ruido y pocas nueces, y más en estas épocas de vacas flacas, pero permite apuntalar las plantillas con algún jugador secundario, o dar salida a otros que no han contado con muchos minutos durante la primera vuelta. En ocasiones, los grandes clubes tratan de dar un golpe de efecto realizando alguna incorporación de relumbrón. Y otras, equipos más modestos, pero bien gestionados y en clara trayectoria ascendente, aprovechan la coyuntura para dar un salto de calidad. Es una metáfora, pero de esas posibilidades, me gusta pensar que es esta última la que aplica.

Este año, excepcionalmente, en mi equipo tendremos dos de esos fichajes, empiezan la semana que viene. Las expectativas son altas, confío en que estén a la altura de una exigencia, un jefe que tiene su aquél y una empresa en la que, cómo en todos lados, cuecen habas. También confío en que sabremos acogerles para que den el máximo de su potencial, que aprendan y que sobre todo aprendamos de esas personas. Es curioso que por regla general el punto de vista ante un recién llegado sea el hecho de que hay que enseñarle a hacer todo aquello que vaya hacer, cuando debe ser lo contrario, esto es, que esa persona aporte al grupo su conocimiento, el enriquecimiento ha de ser mutuo. Así, tendremos unos días de presentaciones, de contar a qué se dedica cada uno, a quién preguntarle las cosas, de enseñarle cómo se usa la aplicación de gestión de horario y dónde está el bar. El resto espero que me lo enseñen a mí. Que transmitan la ilusión de un nuevo trabajo, unos nuevos retos, el empuje de querer demostrar que valen para esto.

Esta buena noticia viene bien también para el resto del equipo. Ellos lo ven así porque estamos algo sobrepasados y tendrán la ilusión de que el trabajo será el mismo y se repartirá (angelitos). En este caso me refiero a que mueves el árbol y haces que todos estemos con las orejas tiesas, atentos para hacerse valer, ser más productivos y eficientes. No quiero decir con esto que tenga que existir competencia, sino compenetración y compromiso, pero sin que nadie desentone ni se acomode.

Como continuamente les repito, hay una ingente cantidad de curro comparada con los brazos, no puedo permitirme el lujo de tener un recurso que no sea realmente bueno o que siéndolo, no dé su 100% (al menos). Tenemos que ser los más listos, los más ágiles, y que además tengamos margen para formarnos e ir por delante de manera que tengamos respuesta a las preguntas cuando estas surjan. Y sí, eso pasa por poner mucho de su parte, sacrificando tiempo de ocio, de descanso o de la familia para invertirlo en su carrera profesional, que siempre ha de ir en crecimiento, ya que no crecer es lo mismo que estancarse, que es lo mismo morir.

Con todo, lo más importante es que encajen a nivel personal. Lo técnico se presupone, se aprende o está en internet. El esfuerzo que pondrán se da por descontado. Pero si no se llevan bien dentro del equipo, si no nos entendemos, si no están a gusto con nosotros, será imposible. Digo yo que será así, para eso se hacen entrevistas y se piden referencias, y si bien tenemos ya alguna mala experiencia con eso en concreto, espero no haberme equivocado esta vez.

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.


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

ACEPTAR
Aviso de cookies