diseño de aplicaciones de bases de datos sql azure

Diseño de aplicaciones debases de datos

SQL AzureJosé Redondo - @redondoj

Chapter Leader SQL PASS Venezuela – DPA SolidQ – SC SynergyTPC

[email protected]

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

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


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


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


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


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


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


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

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

diseño de aplicaciones de bases de datos sql azure

Technology