Windows Azure Insider

Datos NoSQL en la nube con las tablas de Windows Azure

Bruno Terkaly
Ricardo Villalobos

Descargar el ejemplo de código

Bruno Terkally; Ricardo Villalobos El precio del almacenamiento de datos en disco ha bajado tan dramáticamente parece de ciencia ficción, abriendo las compuertas para que las empresas almacenar enormes cantidades de datos. Pero ser capaces de almacenar grandes cantidades de datos económicamente resuelve sólo la mitad del problema. Los datos se ha convertido en tan grande y complejo que herramientas de gestión de base de datos tradicionales y aplicaciones de procesamiento de datos son muy insuficientes. Con tantos datos en disco, han surgido nuevos problemas, tales como ingerir los datos, realizar búsquedas, compartir los datos, analizarla y, en última instancia, visualizando lo.

El poder del cloud computing ha intensificado para llenar esta necesidad. La posibilidad de ejecutar soluciones software masivamente paralelo — en decenas, cientos o incluso miles de servidores, es la bala de plata que permite a las organizaciones enfrentar todos esos datos almacenados.

Microsoft se dio cuenta de esta importante tendencia hace varios años. Windows Azure Storage (WAS) fue lanzado en noviembre de 2008 y mejoró dramáticamente la capacidad de las empresas para obtener el valor de los grandes cantidades de datos que se almacenan.

En palabras de Brad Calder, un distinguido Ingeniero de Microsoft y el pastor que guió la construcción del sistema WAS, "Windows Azure Storage es un sistema de almacenamiento de nube que proporciona a los clientes la posibilidad de almacenar cantidades extensas de datos de cualquier duración de tiempo que es altamente disponible y durable. Cuando se utiliza el almacenamiento de Windows Azure, usted tiene acceso a sus datos desde cualquier lugar y en cualquier momento y sólo paga por lo que utiliza y almacena.

FUE se utiliza dentro de Microsoft para aplicaciones tales como la búsqueda de redes social; servicio de video, música y contenido del juego; y gestión de registros médicos. También se utiliza el motor de búsqueda Bing para proporcionar contenido público Búsquedo casi inmediato de mensajes de Facebook o Twitter o actualizaciones de estado. Con alrededor de 350 TB de datos, el alcance de los datos de Facebook y Twitter es notable. Cuando estos datos es ser ingeridos, rendimiento de transacciones alcanza picos de alrededor de 40.000 transacciones por segundo y totales de entre 2 a 3 billones de operaciones por día.

Este mes exploraremos una faceta de WAS — Windows Azure tablas — tanto cómo funciona y cómo los desarrolladores pueden conseguirlo rápidamente en marcha.

El paisaje

El científico de datos moderno se enfrenta con muchas opciones al seleccionar una plataforma de datos, cada uno con sus propias fortalezas y debilidades. Por ejemplo, muchas soluciones big data se basan en el concepto de NoSQL, que significa que no se utiliza un modelo de sistema (RDBMS) de gestión de bases de datos relacionales, hay no hay mesas y ningunas declaraciones SQL. En cambio, las estructuras de datos suelen ser una gran colección de pares clave/valor o matrices asociativas. Las opciones populares son hoy MongoDB, Cassandra, HBase, CouchDB, Neo4j y Windows Azure tablas. Este artículo se centrará en Windows Azure tablas.

A pesar de las diferencias principales, bases de datos NoSQL tanto SQL tienen una cosa en común: estas tecnologías se ofrecen como un servicio en la nube, liberando a los desarrolladores de tener servidores de datos manualmente disposición y disponibilidad. Por ejemplo, Windows Azure tablas se ofrece como un servicio y un desarrollador nunca tiene que pensar en términos de servidores físicos separados.

En la columna de este mes, comenzaremos con un breve análisis de algunas de las características y capacidades de Windows Azure tablas. A continuación, le proporcionaremos un código para demostrar cómo podría trabajar con Windows Azure tablas en términos de inserción y consulta de datos. Y, finalmente, tomaremos un vistazo a algunos de los objetivos de diseño y los detalles de implementación de alto nivel de WAS.

Algunos conceptos básicos

Una de las grandes características de Windows Azure tablas es que el almacenamiento de información se ofrece en tres regiones geográficamente distribuidas, incluyendo los Estados Unidos, Europa y Asia. Cada centro de datos de Microsoft cumple con la organización internacional de normalización (ISO) 27001, SSAE 16 ISAE 3402, cláusulas de UE y Health Insurance Portability and Accountability Act (HIPAA) negocio asociado estándares de acuerdo (BAA). Otra característica importante es el almacenamiento de información geo-redundante, que permite replicar sus datos en otro centro de datos dentro de la misma región, añadiendo otro nivel de recuperación ante desastres.

Capacidades y performance WAS están correlacionadas con cuentas de almacenamiento. Una cuenta de almacenamiento individual incluye 200 TB de almacenamiento. Windows Azure tablas han sido optimizadas para ofrecer un rendimiento increíblemente rápido consulta bajo escritura pesadas cargas de trabajo. Puedes leer más en bit.ly/cMAWsZ.

Figura 1 muestra los objetivos de la escalabilidad para una cuenta de almacenamiento único creado después de 07 de junio de 2012.

Figura 1 escalabilidad objetivos para una cuenta de almacenamiento único

FUE el análisis también están disponibles, permitiendo a los desarrolladores a las solicitudes de almacenamiento de rastro, analizar las tendencias de uso y optimizar los patrones de acceso a datos en una cuenta de almacenamiento. Leer más en bit.ly/XGLtGt.

Tenga en cuenta que el sistema era incluye otras abstracciones, como manchas y colas. Nos centraremos aquí en Windows Azure mesas, que se utilizan para almacenar datos estructurados y semiestructurados no relacionales. La forma más sucinta de expresar el valor de Windows Azure tablas es que apoyan las búsquedas de clave-valor NoSQL en gran escala y bajo escritura pesadas cargas de trabajo. Desde el punto de vista de un desarrollador, Windows Azure tablas son para almacenar grandes colecciones de objetos no uniforme o para servir páginas en un sitio de Web de alto tráfico.

Windows Azure tablas puede accederse desde casi cualquier lugar. El sistema de almacenamiento está habilitado con resto de transferencia de estado representacional, que implica que cualquier cliente capaz de HTTP puede comunicarse con el sistema WAS. Obvios clientes incluyen diferentes distribuciones de Linux, iOS, Android y Windows 8. La API REST soporta inserciones, upserts, actualizaciones y eliminaciones y selecciona o consultas.

Al trabajar con Windows Azure tablas, una clave de punto de partida es entender cómo controlar el esquema de particionado de datos. Para cualquier Windows Azure tabla determinada, el arquitecto de datos debe definir (por adelantado) un PartitionKey y un RowKey. Este es tal vez la decisión más importante que harás cuando use Windows Azure tablas. PartionKeys y RowKeys determinar cómo sus datos automáticamente es repartidos por el servicio de almacenamiento y lo que realizan sus consultas. Se recomienda que usted entienda cómo se consultar sus datos antes de finalizar sus decisiones en PartitionKey y RowKey. Más tarde, nos va adentrar en la mecánica de consistencia transaccional y su relación con PartitionKeys. Por ahora, vamos a caminar a través de un simple ejemplo de cómo las particiones de sistema WAS table data.

Un rápido Tutorial

Imagínese que desea almacenar y recuperar mensajes de correo electrónico de vari­dominios de unidades organizativas, como las siguientes: bterkaly@Microsoft.com, ricardo.villalobos@microsoft.com, brunoterkaly@hotmail.com y ricardovillalobos@hotmail.com. En estas direcciones de correo electrónico, los nombres de dominio son microsoft.com y hotmail.com, mientras que los nombres de correo electrónico son bterkaly y ricardo.villalobos. Consultas típicas primero buscar por nombre de dominio, luego por el nombre de correo electrónico.

En este ejemplo simple, la elección de PartitionKey y RowKey son bastante sencillas. Nos va asignar el nombre de dominio a la PartitionKey y el nombre de correo electrónico a la RowKey.

El código en figura 2 debe hacer las cosas un poco más claras. Ilustra cuatro capacidades simples:

  • Definir una entidad (EmailAddressEntity)
  • Definir la tabla que almacenará las entidades (correo electrónico­AddressTable)
  • Insertar la entidad en la tabla (Insertar dirección de correo electrónico­entidad en EmailAddressTable)
  • Consultar la tabla para buscar una entidad específica (buscar bterkaly@microsoft.com)

Figura 2 la entidad EmailAddressEntity

          // Our entity derives from TableEntity
public class EmailAddressEntity : TableEntity
{
  // Basic information that makes up our entity
  public string EMailAddress { get; set; }
  public string PhoneNumber { get; set; }
  // A necessary default constructor
  public EmailAddressEntity()
  {
  }
  // A two-parameter constructor
  public EmailAddressEntity(string email, string phone)
  {
    EMailAddress = email;
    PhoneNumber = phone;
    SetKeys(email, phone);
  }
  // A method that initializes the partition key and row key
  public void SetKeys(string email, string phone)
  {
    int startIndex = email.IndexOf("@");
    // Extract the mailname from the e-mail address
    string mailname = email.Substring(0, startIndex);
    // Extract the domain from the e-mail address
    string domain = email.Substring(startIndex + 1);
    // Perform the mandatory assignments to the partition key and row key
    PartitionKey = domain;
    RowKey = mailname;
    PhoneNumber = phone;
  }
}
        

En primer lugar, definimos la estructura de entidad propia, EmailAddressEntity, como se muestra en la figura 2. La tabla real (un contenedor de entidades) se definirá más adelante, cuando introduzca EmailAddressEntity en la tabla. Una entidad puede ser considerada como un objeto individual; es la unidad más pequeña de datos que pueden almacenarse en una tabla de Windows Azure. Como se mencionó anteriormente, una entidad es una colección de pares de nombre-valor mecanografiados, referido a menudo como propiedades. Las tablas son colecciones de entidades, y cada entidad pertenece a una tabla, así como una fila en una tabla de base de datos relacional. Pero las tablas en almacenamiento de Windows Azure tabla no tiene un esquema fijo. No es obligatorio que todas las entidades en una tabla ser estructuralmente idénticos, como es el caso de una tabla de base de datos relacional.

Hay cuatro piezas principales de la información en figura 2. Los dos primeros, dirección de correo electrónico y número de teléfono, simplemente son dos cuerdas que queremos. Los otros dos son las propiedades PartitionKey y RowKey, que comentábamos anteriormente. Una tercera propiedad necesaria de todas las entidades es Timestamp, que es utilizado internamente por el sistema para facilitar la concurrencia optimista.

La primera columna Timestamp difiere de las columnas PartitionKey y RowKey porque se rellena automáticamente por el sistema WAS. En contraste, los desarrolladores deben insertar en las propiedades PartitionKey y RowKey.

Para resumir, la importancia de PartitionKey y RowKey es en su mayoría sobre el rendimiento de las consultas y consistencia transaccional. Explicamos el rendimiento de las consultas previamente y depende en gran medida la forma en que los datos se reparten en los nodos de almacenamiento de información. Pero PartitionKeys también permite realizar cambios en varias entidades como parte de la misma operación, permitiendo a los desarrolladores deshacer los cambios si cualquier falla de operación única. El requisito es que las entidades forman parte de un mismo grupo de la entidad, que realmente significa que entidades comparten el mismo PartitionKey. Las transacciones son compatibles dentro de un solo PartitionKey.

El código en figura 3 ilustra a instancias de una entidad de tipo EmailAddressEntity (de figura 2) y luego insertar EmailAddressTable a esa entidad. Tenga en cuenta que estamos utilizando el emulador de almacenamiento local. Esto nos permite ejecutar y probar nuestro código y datos localmente sin conectarse a un centro de datos.

Figura 3 insertar un EmailAddressEntity

          try
{
  // Use the local storage emulator
  var storageAccount = CloudStorageAccount.DevelopmentStorageAccount;
  // Create a cloud table client object
  CloudTableClient tableClient = storageAccount.CreateCloudTableClient();
  // Create an e-mail address table object
  CloudTable emailAddressTable =
    tableClient.GetTableReference("EmailAddressTable");
  // Create the table if it does not exist
  // Only insert a new record once for this demo
  if (emailAddressTable.CreateIfNotExists() == true)
  {
    // Create a new EmailAddressEntity entity
    EmailAddressEntity emailaddress = new
      EmailAddressEntity("bterkaly@microsoft.com", "555-555-5555");
    // Create an operation to add the new e-mail and phone number to
    // the emailAddressTable
    TableOperation insertEmail = TableOperation.Insert(emailaddress);
    // Submit the operation to the table service
    emailAddressTable.Execute(insertEmail);
  }
}
catch (Exception ex)
{
  // Put the message in the Web page title (for testing purposes)
  // Real error messages should go to a proper log file
  this.Title = ex.Message.ToString();
  throw;
}
        

Puede ver sus datos en el panel explorador de servidores en Visual Studio 2012, como se muestra en la figura 4, que facilita el proceso de escribir y probar código mucho más fácil. También puede adjuntar explorador de servidores a una instancia real de sus tablas de Windows Azure en un centro de datos.

Server Explorer
Figura 4 Server Explorer

El código en figura 5 ilustra cómo consultar los datos.

Figura 5 consultar Windows Azure tablas

          // Use the local storage emulator
var storageAccount = CloudStorageAccount.DevelopmentStorageAccount;
try
{
  // Create the table client
  CloudTableClient tableClient = storageAccount.CreateCloudTableClient();
  CloudTable emailAddressTable =
    tableClient.GetTableReference("EmailAddressTable");
  // Retrieve the entity with partition key of "microsoft.com" 
  // and row key of "bterkaly"
  TableOperation retrieveBrunoEmail =
    TableOperation.Retrieve<EmailAddressEntity>(
    "microsoft.com", "bterkaly");
  // Retrieve entity
  EmailAddressEntity specificEntity =
    (EmailAddressEntity)emailAddressTable.Execute(retrieveBrunoEmail).Result;
  TableResult result =
    emailAddressTable.Execute(TableOperation.Retrieve<EmailAddressEntity>(
    "microsoft.com", "bterkaly"));
  // Pull the data out that you searched for
  // Do something with emailAddress and phoneNumber
  string emailAddress = specificEntity.EMailAddress;
  string phoneNumber = specificEntity.PhoneNumber;
}
catch (Exception ex)
{
  // Put the message in the Web page title (for testing purposes)
  // Real error messages should go to a proper log file
  this.Title = ex.Message.ToString();
  throw;
}
        

El código realiza una consulta simple usando PartitionKey y RowKey. Tenga en cuenta que usted puede construir consultas bastante complejas usando estos filtros porque usted puede unirlos juntos de una manera ad hoc. Creamos un objeto de consulta utilizando el filtro combinado. El paso final es simplemente ejecutar la consulta y hacer lo que sea necesario con el EmailAddressEntity. El WAS Client Library simplifica enormemente las operaciones de crear/leer/actualizar/eliminar (CRUD), así como las consultas necesarias.

Lo que está dentro

Pensamos que podría ser útil echar un vistazo un poco más profundo de la arquitectura interna del sistema WAS, se muestra en la figura 6. Gran parte de la narrativa siguiente se basa en el papel de Brad Calder que se hace referencia más adelante en este artículo.

Windows Azure Storage Internals
Figura 6 Windows Azure Storage Internals

FUE está compuesta por una serie de sellos de almacenamiento a través de sus ocho centros de datos. Un sello de almacenamiento es un conglomerado de unos 10 a 20 racks de nodos de almacenamiento. Cada rack se encuentra en un dominio separado falla. Cada estante viene con poder y redes redundantes. Cada sello de almacenamiento contiene aproximadamente 30PBs de almacenamiento crudo.

Para mantener los costos bajos, es importante mantener estos sellos de almacenamiento sobre el 70 por ciento de utilización, que se mide en términos de capacidad, transacciones y banda ancha. Va por encima de 90 por ciento se considera demasiado alto, sin embargo, ya que deja poco espacio en caso de fallas de la parrilla, cuando el sistema tiene que hacer más con menos.

Servicio de ubicación de almacenamiento

El desarrollador no tiene ningún control directo sobre el servicio de ubicación de almacenamiento (SLS). A nivel de cuenta, no sólo hace los SLS mapa cuenta los espacios de nombres a través de los sellos, también es responsable de la recuperación ante desastres, asignación de almacenamiento cuenta y balanceo de carga. El SLS simplifica enormemente la posibilidad de agregar nuevo almacenamiento de información en un centro de datos. Puede asignar nuevas cuentas de almacenamiento para los nuevos sellos para clientes como cuentas existentes de almacenamiento de equilibrio de carga de estampillas antiguas a los nuevos sellos. Todas estas operaciones por el SLS se realizan automáticamente.

Echemos un vistazo un poco más a las tres capas que componen un sello de almacenamiento, final de la secuencia, la partición y el frente (FE) — a partir de la parte inferior.

La capa de corriente proporciona una interfaz interna de que la capa de la partición se utiliza para leer y escribir archivos de grandes tamaño y es responsable de la funcionalidad de replicación. La capa de corriente también encarga de apertura, cierre, eliminar, cambiar nombre, lectura, anexando a y concatenación de estos archivos de grandes tamaño. No preocuparse con la semántica de los objetos que se encuentran en el flujo de datos.

La capa de partición proporciona el modelo de datos para los diferentes tipos de objetos almacenados (mesas, blobs, colas); la lógica y la semántica para procesar los diferentes tipos de objetos; un espacio de nombres escalable para los objetos; carga equilibrar a los objetos de acceso en los servidores de particiones disponibles; pedido de transacción y consistencia fuerte para el acceso a los objetos; y la geo-replicación de datos de objetos de la primaria a la región secundaria.

La capa de partición también encapsula una estructura de datos interna importante llamada una tabla de objetos. Hay varias versiones de la tabla de objetos, incluyendo la tabla de la entidad, que almacena todas las filas de la entidad para todas las cuentas en el sello. Se utiliza para exponer públicamente la abstracción de datos tabla de Windows Azure. La tabla de objetos también interactúa con la capa de la partición para asegurar la consistencia de los datos por pedido las transacciones con los blobs, cuentos y colas.

La capa de la FE se compone de un conjunto de servidores sin estado que tome las solicitudes entrantes. Previa solicitud, una FE busca el nombre de cuenta, autentica y autoriza la solicitud, luego dirige la solicitud al servidor apropiado de la partición en la capa de partición (basado en el PartitionName). Para mejorar el rendimiento, la FE se mantiene y almacena en caché un mapa de particiones, que encaminamiento al servidor apropiado de la partición se facilite en los datos de acceso frecuente.

En resumen

En este artículo, le ofrecemos algunas pautas de alto nivel, útiles, así como algunos de los detalles arquitectónicos en cómo está diseñado el sistema era, y en particular cómo Windows Azure tablas puede ayudar a administrar sus datos. Nos gustaría agradecer a Brad Calder para algunos de sus puntos de vista compartidos en "Windows Azure Storage: Una gran nube almacenamiento servicio disponible con Strong consistencia,"un artículo publicado recientemente por la 23 ACM Symposium sobre principios de sistemas operativos (SOSP). Usted puede descargar su papel en bit.ly/tMIPus.

Biblioteca de cliente de Windows Azure Storage 2.0

A finales de octubre de 2012, Microsoft lanzó una nueva biblioteca de almacenamiento del lado del cliente — biblioteca de cliente de Windows Azure Storage (WAS) 2.0 — que dramáticamente mejora usabilidad, extensibilidad y rendimiento al interactuar con Windows Azure tablas. Usted puede instalar el WAS cliente biblioteca 2.0 con NuGet de bit.ly/YFeHuw. Esto puede hacerse dentro de Visual Studio 2012. Para una mirada detallada a algunas de las grandes novedades, visite bit.ly/VQSaUv.

La nueva biblioteca incluye algunos nuevos enfoques que mejoran la funcionalidad con respecto a la facilidad de uso, extensibilidad y rendimiento. Una característica interesante le ahorra la molestia de preocuparse por la lógica de la serialización y deserialización al trabajar con Plain Old C# objetos (POCO). Otra característica interesante es el EntityResolver, que le permite realizar proyecciones del lado del cliente, para que pueda crear objetos sobre la marcha basada en sólo la información que te interesa. En Resumen, puede convertir directamente datos de la entidad de mesa a un tipo de objeto de cliente sin un tipo de clase de entidad separada de la tabla que deserializa individualmente cada propiedad. Otra tecnología potente es la interfaz IQueryable, que le da una forma expresiva para definir consultas LINQ complejas.

Bruno Terkaly es un evangelista de desarrollador de Microsoft. Su profundidad de conocimiento proviene de años de experiencia en el campo, escribir código con una multitud de plataformas, idiomas, Marcos, SDK, bibliotecas y APIs. Pasa escribir código de tiempo, blogging y dando presentaciones en vivo en la construcción de aplicaciones basadas en la nube, específicamente con la plataforma Windows Azure. Terkaly es también el autor de dos aplicaciones Windows Store, enseñar niños coche colores y niños enseñar Música. Usted puede leer su blog en blogs.msdn.com/brunoterkaly.

Ricardo Villalobos es un arquitecto de software experimentado con más de 15 años de experiencia en diseño y creación de aplicaciones para empresas en la industria de gestión de cadena de suministro. Sostiene diferentes certificaciones técnicas, así como una maestría en administración de empresas de la Universidad de Dallas, trabaja como un arquitecto de la nube en el grupo de incubación de Windows Azure CSV para Microsoft.

Terkaly y Villalobos conjuntamente presentar conferencias de la industria en general. Animan a los lectores al contacto con ellos para la disponibilidad. Terkaly puede ser contactado en bterkaly@microsoft.com y Villalobos puede ser contactado en Ricardo.Villalobos@microsoft.com.

Gracias a los siguientes expertos técnicos por su ayuda en la revisión de este artículo: Brad Calder (Microsoft) y Jai Haridas (Microsoft)