Diseño de aplicaciones de bases de datos SQL Azure
Upcoming SlideShare
Loading in...5
×
 

Diseño de aplicaciones de bases de datos SQL Azure

on

  • 649 views

Descripción general sobre la arquitectura de SQL Azure para generar eficientes diseño de bases de datos en SQL Database en Windows Azure

Descripción general sobre la arquitectura de SQL Azure para generar eficientes diseño de bases de datos en SQL Database en Windows Azure

Statistics

Views

Total Views
649
Views on SlideShare
649
Embed Views
0

Actions

Likes
0
Downloads
6
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Diseño de aplicaciones de bases de datos SQL Azure Diseño de aplicaciones de bases de datos SQL Azure Presentation Transcript

  • 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
  • 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 Abstracciones – Blobs y discos
  • COMPONENTES Abstracciones – Tablas y Queues
  • COMPONENTES
  • COMPONENTES
  • 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>
  • 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.
  • FUNCIONAMIENTO INTERNO
  • 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
  • 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
  • ARQUITECTURA
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • MEJORES PRACTICAS
  • 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
  • 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 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
  • 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
  • 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
  • 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
  • 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)
  • 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