Diseo de aplicaciones de

bases de datos
SQL Azure
Jos 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
Diseo 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 fcilmente 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 va sencilla y abierta a travs de APIs
Bibliotecas de cliente en .NET, Java, Node.js, Python, PHP, Ruby

COMPONENTES
COMPONENTES
Abstracciones Blobs y discos
COMPONENTES
Abstracciones Tablas y Queues
COMPONENTES
COMPONENTES
COMPONENTES
C
o
n
c
e
p
t
o
s

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 ingestin
del motor de bsqueda que consume casi en tiempo real el consumo de datos de
Twitter y Facebook, indexndolo, para as luego, generar las bsqueda
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 automticamente hacia fuera y cargar los datos, balancendolos para con ello,
satisfacer las demandas de trfico en puntos pico
Objetivos
FUNCIONAMIENTO INTERNO
Windows Azure Storage Stamps
Almacenamiento Blob para accesarlo a travs de la URL: http://<account>.blob.core.windows.net/










Storage Stamp
LB
Data access
Storage
Location
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)
Autenticacin/autorizacin
Mtricas/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 replicacin (JBOD)
Los datos se almacenan en un archivo denominado
extent, que se repite 3 veces a travs de distintos
nodos (UDs/FDs)
Sistema de archivos slo para anexar
Index
Distributed File System
Partition Layer
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 travs de todas las rplicas en un extent:
Anexa el ordenamiento a travs de todas las 3 rplicas en
un extent (archivo)
Slo retorna las ejecuciones satisfactoria si todas las 3
rplicas se anexan a las comprometidas para el
almacenamiento de informacin
Cuando el extent llega a un cierto tamao o en escritura
sea falla/LB, el mismo set de extent se rplicas en la medida
de su necesidad y nunca aade ms datos

Disponibilidad de escritura: Para manejar errores durante la escritura
Conjunto de rplicas en extent
Aade inmediatamente a un nuevo extent (conjunto de
rplicas) en otros 3 nodos disponibles
Aade este nuevo extent al final del registro de la particin
(stream)
Index
Distributed File System
Partition Layer

Read Consistency: Puede leer desde
cualquier rplica, ya que los datos de
cada rplica para un extent bit-wise
es idntico

Read Availability: Enva solicitudes de
lectura paralelas si la primera lectura
est tomando una latencia superior al
95%
Disponibilidad de consistencia
para la lectura
ARQUITECTURA
Index
Distributed File System
Partition Layer

Se extiende el procesamiento a travs de servidores
en particiones de ndice/transacciones
El Master supervisa la utilizacin de recursos y
carga de trfico en servidores de particiones
Dinmicamente 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 Dinmica
Partition Layer
ARQUITECTURA
Index
Distributed File System
Partition Layer

DFS leer balanceo de carga en las rplicas
Monitor de carga/latencia en cada nodo/rplica;
seleccionar dinmicamente qu rplica 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 rplicas 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 rplicas 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 Dinmico DFS
Layer
ARQUITECTURA
Distributed File System
Partition Layer
ARQUITECTURA
Durabilidad: Todos los datos almacenados con al menos tres rplicas
Consistencia: Todos los datos comprometidos a travs de las 3 rplicas son idnticos
Disponibilidad: Puede leer desde cualquiera de las 3 rplicas; Si se generan problemas de escritura
en el extent, esta contina aadiendo nuevos extent
Rendimiento/Escalabilidad: Reintento basado en el 95% de las latencias; Escala automtica hacia
fuera y equilibrio de carga basado en la capacidad de carga

Informacin adicional puede encontrarse en el siguiente artculo 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 lmite de conexin 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 prcticas para el almacenamiento de Azure con .NET
MEJORES PRACTICAS
Localizar cuentas de almacenamiento cerca de los escenarios de ejecucin
y usuarios

Entender el escenario de escalabilidad final
Usar varias cuentas de almacenamiento para obtener ms
Distribuir sus cuentas de almacenamiento de informacin en todas las regiones

Considerar la ejecucin del almacenamiento de datos para un mejor
rendimiento
Conjuntos de datos crticos en cach
Para obtener ms 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 enva & reciba
Blobs: Leer rangos, Metadata, Head Requests
Tablas: Upsert, Projection, Point Queries
Queues: Mensaje de actualizacin

Paralelismo de control en la capa de aplicacin
Paralelismo ilimitado puede conducir a baja latencia y pobre rendimiento

Habilitar Logging & Mtricas en cada servicio de almacenamiento
de informacin
MEJORES PRACTICAS
Tratar de coincidir tanto con el tamao de su lectura as como con el tamao de su escritura
Evitar lectura de bloques pequeos en blobs conjuntamente con grandes bloques
CloudBlockBlob.StreamMinimumReadSizeInBytes/ StreamWriteSizeInBytes

Cmo se puede subir una carpeta ms rpida?
Cargar simultneamente mltiples blobs

Cmo puedo subir un blob ms rpido?
Utilizar carga paralela en bloque

Concurrencia (C)- Mltiple concurrencia al cargar diferentes blobs
Paralelismo (P) Mltiple cargas de trabajo al subir bloques diferentes para el misma blob
Entornos Blob
MEJORES PRACTICAS
XL VM actualizando 512, 256MB Blobs (Total
tamao 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 conexin TCP est limitado por el control de la
velocidad TCP & RTT
P=30 vs. C=30: Prueba completada casi dos veces ms
rpido!
Blob solo est limitado por los lmites de una nica
particin
Acceso simultneamente a mltiples blobs escalables
Concurrencia Vs. Paralelismo Blob
0
2000
4000
6000
8000
10000
T
i
m
e

(
s
)

MEJORES PRACTICAS
XL VM Descargando 50, 256MB Blobs
(Tamao total de descargar = 12.5GB)
C=1, P=1 => Promedio ~ 96 MB/s
C=30, P=1 => Promedio ~ 130 MB/s
Descarga Blob
0
20
40
60
80
100
120
140
C=1, P=1 C=30, P=1
T
i
m
e

(
s
)

MEJORES PRACTICAS
Queries Crticos: 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 mltiples 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 clasificacin
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 actualizacin: Extender el tiempo de visibilidad basado en
mensajes o guardar su estado intermitente
Contador de mensaje: Usar esto para la escalabilidad de ejecucin
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
Mltiples colas: A ms de un objetivo nico (Particin)
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
participacin