Esecuele Sin Fronteras

SQL Server, Reporting Services y Biztalk Server
  • Esecuele Sin Fronteras

    Hekaton en SQL Server vNext

    • 2 Comments

    Primero, que significa hekaton, hekaton es una palabra griega (ἑκατόμ) que significa cien.

    Para Microsoft Hekaton es el codename de una nueva característica que se introducirá en la siguiente versión de SQL Server, Hekaton es un motor relacional en memoria (http://en.wikipedia.org/wiki/In-memory_database) siguiendo la filosofía de SAP HANA (http://en.wikipedia.org/wiki/SAP_HANA)  o Oracle TimesTen (http://en.wikipedia.org/wiki/TimesTen) pero con una gran diferencia, mientras que HANA o TimesTen son productos separados de la base de datos relacional Hekaton se va a integrar dentro de SQL Server.

    Hekaton empieza como un proyecto de colaboración entre Microsoft Research y el grupo de SQL Server  en 2009, la principal causa de este proyecto es que en los modelos tradicionales la base es que los datos están en disco y son almacenadas como paginas en disco, esto crea un overhead grande a la hora de acceder a registros, si los registros están siempre en memoria el acceso a los datos se simplifica lo que hace que tengamos estructuras de datos mas simples optimizadas para memoria.

    Siendo optimistas.

    El primer paso fue moverse de una aproximación particionada (que lo que hace es asimilar a un sistema multiprocesador a un sistema distribuido) hacia un diseño sin bloqueos lo que incrementa la escalabilidad.

    Los bloqueos son sistemas de sincronización para evitar corrupción en sistemas concurrentes, desgraciadamente esto crea cuellos de botella en sistema multiprocesador y limita el uso de cpu.

    Hekaton utiliza un sistema sin bloqueos (optimista), nunca se bloquea datos de las estructuras, el reto de este sistema es proporcionar el beneficio de un sistema sin bloqueos y evitar corrupción, es donde entra el control de visiones (MVCC – multiversion concurrency control).

    MVCC, ha demostrado en las pruebas que es ideal para un sistema con alta carga y alta contención, en un sistema de concurrencia de una sola versión los datos son sobrescritos en cada cambio, MVCC maneja los cambios marcando los datos antiguos como obsoletos y añadiendo una nueva versión, en cualquier momento hay diferentes versiones de los datos, pero solo una es la última. El gran beneficio es que las actualizaciones añaden nuevas versiones sin interferir en las lecturas concurrentes.

    Hekaton implementa una nueva forma de motor transaccional MVCC, en el siguiente enlace se puede ver mas información sobre este motor (High-Performance Concurrency Control Mechanisms for Main-Memory Databases)

    Un nuevo árbol binario (B-Tree)

    Además del control concurrente de versiones hay otros cambios, como un nuevo árbol binario para almacenar los datos, este nuevo árbol binario se llama Bw-Tree, aprovechando la filosofía optimista sin bloqueos de Hekaton se ha optimizado la estructura para ofrecer un mejor rendimiento a nivel de cache del procesador. Podeis leer mas sobre este nuevo árbol binario aquí: http://research.microsoft.com/apps/pubs/default.aspx?id=178758

    Tradicionalmente cuando se implementa un mecanismo sin bloqueos la primera opción es una “skiplist” (http://en.wikipedia.org/wiki/Skiplist)  ya que se percibe más ligero que un árbol binario(B-Tree) el Bw-Tree demuestra que esto es falso y se puede tener una implementación de un árbol binario de mayor rendimiento que una skiplist.

    bwin – Una apuesta segura

    Una de las mayores empresas de apuestas online (BWIN) colabora a la hora de probar Hekaton en entornos reales, BWIN tenia un problema de rendimiento en su web (15.000 peticiones/segundo) y no escalaba más, después de implementar Hekaton en parte del sistema el problema se solucionó llegando las pruebas de carga hasta 250.000 peticiones/segundo. Podéis comprobar la experiencia en el siguiente video:

    bwin y Hekaton

     

    Colaboración

    El proyecto de Hekaton nace gracias a la colaboración entre Microsoft Research y el grupo de SQL Server, según sepamos mas de esta tecnología os iremos actualizando.

    Hekaton aumentando el rendimiento cien veces.

    Mas información:

    http://research.microsoft.com/en-us/news/features/hekaton-122012.aspx

    http://blogs.technet.com/b/dataplatforminsider/archive/2012/12/11/how-fast-is-project-codenamed-hekaton-it-s-wicked-fast.aspx

     

    Pablo Gavela López – Ingeniero de Soporte de SQL Server

  • Esecuele Sin Fronteras

    ¿Cuánto espacio ocupará un índice no clúster y por qué?

    • 0 Comments

    A la hora de crear un índice en una de nuestras tablas, especialmente si es de un tamaño considerable, una de las preguntas que nos pueden surgir es: ¿Cuánto espacio nos va a ocupar?

    Veamos un ejemplo concreto, y luego trataremos de explicarlo. Imaginemos que tenemos una tabla con los clientes de un gimnasio, con una primary key que sería el número de socio, y que realizamos muchas búsquedas basadas en el número de teléfono del cliente. Nos estaríamos planteando crear un índice no-clúster para el número de teléfono.

    Nuestra tabla sería la siguiente:

    image

    Esta tabla tiene un millón de socios (pongamos que es un gimnasio con mucho éxito), y el tamaño de la tabla observamos que es:

    image

    Si creamos el índice no clusterizado, utilizando la constraint unique, vemos que ocupa:

    image

    Veamos cómo es la estructura de este índice no clúster:

    En el nivel inferior, cada línea tendrá:

    -El número de teléfono, de tipo char(9) que ocupará 9 bytes

    -El puntero a la página donde se encuentra el dato, 6 bytes

    -Un overhead de 2 bytes

    Por lo tanto, tendremos 17 bytes en cada entrada. Además por cada una de ellas, necesitaremos dos bytes en el slot array (http://blogs.msdn.com/b/askjay/archive/2011/01/07/what-is-a-slot-array.aspx). En total, 19 bytes.

    En cada página, tenemos disponibles 8096 bytes (8K de página menos el overhead), por lo que en cada página del último nivel, podemos incluir (8096/19)= 426 entradas. Como tenemos un millón de registros, necesitaremos (1000000/506=2347,41), como necesitamos un número entero de páginas: 2348.

    Hay que tener en cuenta que este número de páginas indica tan sólo el número de páginas en el nivel inferior. A continuación, existiría otro nivel que en lugar de referenciar la página donde está el dato, referencia la página del nivel inferior. Y por último, el nivel raíz, que apunta a este nivel intermedio.

Page 1 of 1 (2 items)