diseño de aplicaciones de bases de datos sql azure
Post on 24-Jun-2015
500 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
top related