Diseño de aplicaciones debases de datos

SQL AzureJosé Redondo - @redondoj

Chapter Leader SQL PASS Venezuela – DPA SolidQ – SC SynergyTPC

jredondo@solidq.com

http://redondoj.wordpress.com

AGENDA

•Windows Azure Storage• Componentes• Funcionamiento interno• Arquitectura•Mejores Practicas•Demo

Diseño de aplicaciones de bases de datos

SQL Azure

WINDOWS AZURE STORAGE

WINDOWS AZURE STORAGE• Almacenamiento en la nube - En cualquier lugar y accesarlo en

cualquier momento• Blobs, Discos, Tablas y Queues

• Altamente disponible y escalable • Construir fácilmente aplicaciones "Escalable a internet"• Capacidad de almacenaje de 10 trillones de objetos• Solicitud de 900K/seg en promedio (2,3 trillones por mes)

• Se paga por lo que se usas• Accesar por una vía sencilla y abierta a través de API’s • Bibliotecas de cliente en .NET, Java, Node.js, Python, PHP, Ruby

COMPONENTES

COMPONENTES

• Blobs – Interfaz sencilla para almacenar y recuperar archivos en la nube

• Uso compartido de datos – Compartir documentos, fotos, vídeo, música, etc.

• Big Data – Tienda de registros de datos RAW• Copias de Seguridad – Backups de datos y el dispositivo

• Discos – Red montada discos durables para VMs en Azure • Discos montados son almacenada en los Blobs Azure VHD• Traslado de aplicaciones ON-Premise a la nube

Abstracciones – Blobs y discos

COMPONENTES

• Tablas – Masivamente escalable y extremadamente fácil de usar en sistemas NoSQL que auto escalas

• Búsquedas de clave y valor a escala• Almacenar información del usuario, información del dispositivo, cualquier tipo

de metadatos para su servicio

• Queues – Sistema de mensajería confiable • Separar los Componentes / Roles

• Roles web para una fluida comunicación con los participantes• Permite funciones independientemente de la escalabilidad

• Implementar la programación de tareas asincrónicas• Construimos procesos y flujos de trabajo ('Workflow')

Abstracciones – Tablas y Queues

COMPONENTES

COMPONENTES

COMPONENTESC

on

cep

tos

Account

Container Blobs

Table Entities

Queue Messages

https://<account>.blob.core.windows.net/<container>

https://<account>.table.core.windows.net/<table>

https://<account>.queue.core.windows.net/<queue>

COMPONENTES

• Xbox: Utilizado en datos Blobs, Tablas & Queues para Cloud Game Saves, Halo 4, XBox Music, XBox Live, etc.

• Skype: Utilizado en datos Blobs, Tablas and Queues para videos mensajes en Skype y almacenar metadatos para permitir a los clientes Skype conectarse con otros

• Bing: Utilizado en datos Blobs, Tablas y Queues para proporcionar una ingestión del motor de búsqueda que consume casi en tiempo real el consumo de datos de Twitter y Facebook, indexándolo, para así luego, generar las búsqueda optimizadas en Bing

• SkyDrive: Utilizado en datos Blobs para almacenar fotos, documentos, videos, archivos, etc.

Como es utilizado el Azure Storage por parte de Microsoft?

FUNCIONAMIENTO INTERNO

FUNCIONAMIENTO INTERNO

Alta disponibilidad con consistencia fuerte• Proporcionar acceso a datos ante fallas | en particiones

Durabilidad• Replicar los datos dentro de varios entornos y en todas las regiones

Escalabilidad• Necesita escalar a zettabytes• Proporcionar un espacio de nombres global para acceder a datos de todo el mundo• Escalar automáticamente hacia fuera y cargar los datos, balanceándolos para con

ello, satisfacer las demandas de tráfico en puntos pico

Objetivos

FUNCIONAMIENTO INTERNO

Windows Azure Storage StampsAlmacenamiento Blob para accesarlo a través de la URL: http://<account>.blob.core.windows.net/

Storage Stamp

LB

Data access

StorageLocation Service

Partition Layer

Front-Ends

DFS Layer

Intra-stamp replication

Storage Stamp

LB

Partition Layer

Front-Ends

DFS Layer

Intra-stamp replication

Inter-stamp (Geo) replication

ARQUITECTURA

Disponibilidad con consistencia de escritura

ARQUITECTURA

• Front-end Layer• REST front-end (blob, tablas, queue)• Autenticación/autorización• Métricas/logging

• Partition Layer• Entiende nuestras abstracciones de datos y

proporciona la concurrencia optimista• Índice masivamente escalable• Registro estructurado Merge Tree

• Cada registro (stream) es una lista vinculada extendible

• Distributed File System Layer• Persistencia de datos y replicación (JBOD)• Los datos se almacenan en un archivo

denominado extent, que se repite 3 veces a través de distintos nodos (UDs/FDs)

• Sistema de archivos sólo para anexar

Index

Front-End Layer

Distributed File System

Partition Layer

M

Architecture Layers inside Stamps

ARQUITECTURA

Todas las escrituras son anexa al final de un registro, que es un anexar a la última medida en el registro

Escribe la consistencia a través de todas las réplicas en un extent:

• Anexa el ordenamiento a través de todas las 3 réplicas en un extent (archivo)

• Sólo retorna las ejecuciones satisfactoria si todas las 3 réplicas se anexan a las comprometidas para el almacenamiento de información

• Cuando el extent llega a un cierto tamaño o en escritura sea falla/LB, el mismo set de extent se réplicas en la medida de su necesidad y nunca añade más datos

Disponibilidad de escritura: Para manejar errores durante la escritura

• Conjunto de réplicas en extent • Añade inmediatamente a un nuevo extent

(conjunto de réplicas) en otros 3 nodos disponibles • Añade este nuevo extent al final del registro de la

partición (stream)

Index

Front-End Layer

Distributed File System

Partition Layer

M

• Read Consistency: Puede leer desde cualquier réplica, ya que los datos de cada réplica para un extent bit-wise es idéntico

• Read Availability: Envía solicitudes de lectura paralelas si la primera lectura está tomando una latencia superior al 95%

Disponibilidad de consistencia para la lectura

ARQUITECTURA

Index

Front-End Layer

Distributed File System

Partition Layer

M

Se extiende el procesamiento a través de servidores en particiones de índice/transacciones

• El Master supervisa la utilización de recursos y carga de tráfico en servidores de particiones

• Dinámicamente se particiona el balanceo de carga en los servidores para lograr una mejor performance e incrementar la disponibilidad

• No se mueve los datos, solamente se reasigna la parte del índice que es comprometido de un servidor de particiones

Balanceo de Carga Dinámica – Partition Layer

ARQUITECTURA

Index

Front-End Layer

Distributed File System

Partition Layer

M

DFS leer balanceo de carga en las réplicas• Monitor de carga/latencia en cada nodo/réplica;

seleccionar dinámicamente qué réplica leer y empezar adicional; y leer en paralelo basado en 95% de latencia

DFS escribir balanceo de carga• Monitor de carga/latencia en cada nodo; establecer

el conjunto de réplicas con un nodo sobrecargado, y cambiarlo a un nuevo extent en otro conjunto de nodos para anexarlo

DFS Balanceo de carga en la capacidad • Lentamente desplaza las réplicas para asegurar los

discos y los nodos al tener igual cantidad de datos sobre ellos

• Importante para evitar la sobrecarga de temperatura en los nodos/discos

Balanceo de Carga Dinámico – DFS Layer

ARQUITECTURA

Front-End Layer

Distributed File System

Partition Layer

M

ARQUITECTURA

• Durabilidad: Todos los datos almacenados con al menos tres réplicas

• Consistencia: Todos los datos comprometidos a través de las 3 réplicas son idénticos

• Disponibilidad: Puede leer desde cualquiera de las 3 réplicas; Si se generan problemas de escritura en el extent, esta continúa añadiendo nuevos extent

• Rendimiento/Escalabilidad: Reintento basado en el 95% de las latencias; Escala automática hacia fuera y equilibrio de carga basado en la capacidad de carga

• Información adicional puede encontrarse en el siguiente artículo SOSP:• “Windows Azure Storage: A Highly Available Cloud Storage Service with Strong

Consistency”, ACM Symposium on Operating System Principals (SOSP), Oct. 2011

Resumen

MEJORES PRACTICAS

MEJORES PRACTICAS

• Deshabilitar Nagle para mensajes cortos(< 1400 b)• ServicePointManager.UseNagleAlgorithm = false;

• Deshabilitar Expect 100-Continue* • ServicePointManager.Expect100Continue = false;

• Incrementar el límite de conexión por defecto• ServicePointManager.DefaultConnectionLimit = 100; (O mas)

• Toma ventaja de .Net 4.5 GC• El funcionamiento GC es mejorado grandemente• GC a fondo: http://msdn.microsoft.com/en-us/magazine/hh882452.aspx

Mejores prácticas para el almacenamiento de Azure con .NET

MEJORES PRACTICAS• Localizar cuentas de almacenamiento cerca de los escenarios de

ejecución y usuarios

• Entender el escenario de escalabilidad final• Usar varias cuentas de almacenamiento para obtener más• Distribuir sus cuentas de almacenamiento de información en todas las regiones

• Considerar la ejecución del almacenamiento de datos para un mejor rendimiento

• Conjuntos de datos críticos en caché • Para obtener más peticiones por segundo que las solicitudes en las particiones por cuenta• Como un conjunto de datos de copia de seguridad

• Distribuir la carga sobre muchas particiones y evitar picos

MEJORES PRACTICAS

• Utilizar HTTPS• Optimizar lo que envía & reciba

• Blobs: Leer rangos, Metadata, Head Requests• Tablas: Upsert, Projection, Point Queries• Queues: Mensaje de actualización

• Paralelismo de control en la capa de aplicación• Paralelismo ilimitado puede conducir a baja latencia y pobre rendimiento

• Habilitar Logging & Métricas en cada servicio de almacenamiento de información

MEJORES PRACTICAS

• Tratar de coincidir tanto con el tamaño de su lectura así como con el tamaño de su escritura

• Evitar lectura de bloques pequeños en blobs conjuntamente con grandes bloques• CloudBlockBlob.StreamMinimumReadSizeInBytes/ StreamWriteSizeInBytes

• Cómo se puede subir una carpeta más rápida?• Cargar simultáneamente múltiples blobs

• Cómo puedo subir un blob más rápido?• Utilizar carga paralela en bloque

• Concurrencia (C)- Múltiple concurrencia al cargar diferentes blobs• Paralelismo (P) – Múltiple cargas de trabajo al subir bloques diferentes para el misma

blob

Entornos Blob

MEJORES PRACTICAS

XL VM actualizando 512, 256MB Blobs (Total tamaño de la carga = 128GB)• C=1, P=1 => Promedio ~ 13. 2 MB/s• C=1, P=30 => Promedio ~ 50.72 MB/s• C=30, P=1 => Promedio ~ 96.64 MB/s

• Única conexión TCP está limitado por el control de la velocidad TCP & RTT

• P=30 vs. C=30: Prueba completada casi dos veces más rápido!

• Blob solo está limitado por los límites de una única partición

• Acceso simultáneamente a múltiples blobs escalables

Concurrencia Vs. Paralelismo Blob

0

2000

4000

6000

8000

10000

Tim

e (s

)

MEJORES PRACTICAS

•XL VM Descargando 50, 256MB Blobs (Tamaño total de descargar = 12.5GB)• C=1, P=1 => Promedio ~ 96 MB/s• C=30, P=1 => Promedio ~ 130 MB/s

Descarga Blob

C=1, P=1 C=30, P=10

20

40

60

80

100

120

140

Tim

e (s

)

MEJORES PRACTICAS

• Queries Críticos: Select PartitionKey, RowKey para evitar hotspots• Table Scans son muy costosos – Evitarlos a toda costa para escenarios sensibles

de latencias• Batch: El mismo PartitionKey para entidades que necesitan ser actualizados

juntos• Schema-less: Almacenar múltiples tipos de misma tabla• Single Index – {PartitionKey, RowKey}: Si es necesario, concatenar

columnas para formar claves compuestas• Entity Locality: {PartitionKey, RowKey} determina el orden de clasificación

• Almacenar entidades relacionadas para reducir IO y mejorar el rendimiento• Table Service Client Layer en 2.1 y 2.2: Mejoras de rendimiento

espectacular y mejor interfaz NoSQL

Tablas de datos

MEJORES PRACTICAS

• Crear mensaje de procesamiento: Los mensajes se hacen visibles si el cliente no logra borrar mensaje

• Beneficios de los mensajes de actualización: Extender el tiempo de visibilidad basado en mensajes o guardar su estado intermitente

• Contador de mensaje: Usar esto para la escalabilidad de ejecución

• Contador Dequeue: Usar para identificar mensajes de errores o validar la invisibilidad de tiempo usado

• Blobs para almacenar los mensajes grandes: Incrementan el rendimiento por tener grandes lotes

• Múltiples colas: A más de un objetivo único (Partición)

Queue

DEMO

PREGUNTAS & RESPUESTAS

CONTACTO

Sitio web:http://venezuela.sqlpass.org/

Facebook: https://www.facebook.com/sqlpassvzla

Twitter: https://twitter.com/sqlpassve

Los Invitamos al

Muchas gracias por su participación