Este documento presenta una agenda sobre diseño de aplicaciones de bases de datos SQL Azure. La agenda incluye secciones sobre Windows Azure Storage, componentes, funcionamiento interno, arquitectura, mejores prácticas y una demostración. El orador, José Redondo, es el líder del capítulo de SQL PASS Venezuela.

1. Diseño 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

2. AGENDA
• Windows Azure Storage
• Componentes
• Funcionamiento interno
• Arquitectura
• Mejores Practicas
• Demo

3. Diseño de aplicaciones de
bases de datos
SQL Azure

4. WINDOWS AZURE STORAGE

5. 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

6. COMPONENTES

7. COMPONENTES
Abstracciones – Blobs y discos

8. COMPONENTES
Abstracciones – Tablas y Queues

9. COMPONENTES

10. COMPONENTES

11. COMPONENTES
Conceptos
Container
Blobs
https://<account>.blob.core.windows.net/<container>
Account
Table
Entities
https://<account>.table.core.windows.net/<table>
Queue
Messages
https://<account>.queue.core.windows.net/<queue>

12. COMPONENTES
Como es utilizado el Azure Storage por parte de Microsoft?
• 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.

13. FUNCIONAMIENTO INTERNO

14. FUNCIONAMIENTO INTERNO
Objetivos
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

15. FUNCIONAMIENTO INTERNO
Windows Azure Storage Stamps
Almacenamiento Blob para accesarlo a través de la URL: http://<account>.blob.core.windows.net/
Storage
Location
Service
Data access
LB
LB
Front-Ends
Front-Ends
Partition Layer
Partition Layer
Inter-stamp (Geo) replication
DFS Layer
DFS Layer
Intra-stamp replication
Intra-stamp replication

16. ARQUITECTURA

17. ARQUITECTURA
Disponibilidad con consistencia de
escritura
• 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
Partition Layer
Index
• 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
Distributed File System

18. ARQUITECTURA
Architecture Layers inside Stamps
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)
Partition Layer
Index
Distributed File System

19. ARQUITECTURA
Disponibilidad de consistencia
para la lectura
• 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%
Partition Layer
Index
Distributed File System

20. ARQUITECTURA
Balanceo de Carga Dinámica –
Partition Layer
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
Partition Layer
Index
Distributed File System

21. ARQUITECTURA
Balanceo de Carga Dinámico – DFS
Layer
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
Partition Layer
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
Distributed File System

22. ARQUITECTURA
Resumen
• 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

23. MEJORES PRACTICAS

24. MEJORES PRACTICAS
Mejores prácticas para el almacenamiento de Azure con .NET
• 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

25. 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

26. 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

27. MEJORES PRACTICAS
Entornos Blob
• 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

28. MEJORES PRACTICAS
Concurrencia Vs. Paralelismo Blob
10000
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
8000
Ú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
•
6000
4000
Time (s)
2000
0

29. MEJORES PRACTICAS
Descarga Blob
140
• 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
100
Time (s)
•
•
120
80
60
40
20
0
C=1, P=1
C=30, P=1

30. MEJORES PRACTICAS
Tablas de datos
• 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

31. MEJORES PRACTICAS
Queue
• 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)

32. DEMO

33. PREGUNTAS &
RESPUESTAS

34. CONTACTO
Sitio web:
http://venezuela.sqlpass.org/
Facebook:
https://www.facebook.com/sqlpassvzla
Twitter:
https://twitter.com/sqlpassve

35. Los Invitamos al

36. Muchas gracias por su
participación