Este artículo proviene de un motor de traducción automática.

Puntos de datos

Almacenamiento de tablas de Windows Azure, no es la base de datos de su padre

Julie Lerman

Descargar el ejemplo de código

Almacenamiento de la tabla de Azure Windows hace que una gran cantidad de cabeza arañazos entre los desarrolladores. La mayor parte de su experiencia con el almacenamiento de datos es con las bases de datos relacionales con varias tablas, cada uno con un conjunto predefinido de columnas, de uno o varios de la que se suele designar como claves de identidad. Las tablas de utilizan para definir las relaciones entre un another.Windows Azure almacenes de información algunas de las formas, pero los dos que se centran en conservar los datos estructurados son Azure SQL y Windows Azure tabla de almacenamiento. La primera es una base de datos relacional y alinea bastante estrechamente con SQL Server. Tiene las tablas con el esquema definido, las claves, relaciones y otras restricciones, y se conecta a través de una cadena de conexión como lo haría con otras bases de datos y SQL Server.

Almacenamiento de información de la tabla de Azure de Windows, por otro lado, parece algo desconcertante para aquellos de nosotros que por lo tanto, se utilizan para trabajar con bases de datos relacionales. Aunque encontrará muchos procedimientos paso a paso excelente para crear aplicaciones que utilizan el almacenamiento de la tabla de Azure de Windows, muchos desarrolladores Buscar aún a sí mismos se ve obligado a realizar la medida de FE sin comprender verdaderamente lo que resulta.

Esta columna le ayudará a aquellos bloqueados en el puente de modo relacional que bisiestos de fe con suelo sólido por explicar algunos conceptos básicos del almacenamiento de la tabla de Azure de Windows desde la perspectiva de pensamiento relacional. Además, le toque en algunas de las estrategias importantes para el diseño de las tablas, en función de cómo piensa consultar y actualizar los datos.

Almacenamiento de datos para una recuperación eficaz y persistencia

Por diseño, servicios de Windows Azure tabla proporciona la posibilidad de almacenar enormes cantidades de datos, al tiempo que permite un acceso eficiente y persistencia. Los servicios de simplifican el almacenamiento, evitando de pasar a través de todo el aro necesario para trabajar con una base de datos relacional, las restricciones, vistas, índices, relaciones y los procedimientos almacenados. Sólo trabaja con datos, datos, los datos. Windows Azure tablas Utilice las teclas que permiten consultar eficaz y que puede emplear una; el PartitionKey: cuándo de equilibrio de carga se decide el servicio de la tabla es el momento de la propagación de la tabla a través de varios servidores. Una tabla no tiene un esquema específico. Es simplemente estructurado contenedor de filas (o las entidades) que le es indiferente el aspecto de una fila. Puede hacer que una tabla que almacena un tipo determinado, pero también puede almacenar las filas con estructuras diversas en una sola tabla, como se muestra en de figura 1.

Figura 1 de un único Windows Azure tabla puede contener filas de representación similares o diferentes entidades

Todo comienza con las clases de dominio de TI

Nuestro procedimiento de desarrollo típicas con bases de datos es crearlos, definir las tablas en ellos y, a continuación, para cada tabla, definir una estructura determinada; columnas específicas, cada uno con un tipo de datos especificado, así como las relaciones con otras tablas. Las aplicaciones, a continuación, inserción datos y extraer datos de las tablas.

No obstante, con los servicios de la tabla de Azure de Windows, no diseña una base de datos, sólo las clases. Se definen las clases y (tabla) que una o varias clases que pertenezcan a, a continuación, se pueden guardar objetos ha creado una instancia de un contenedor nuevo para el almacén como filas.

También en las propiedades que necesarias en las clases, cada clase debe tener tres propiedades que son cruciales para determinar cómo los servicios de Windows Azure tabla hacen su trabajo: PartitionKey, RowKey y TimeStamp. PartitionKey y RowKey son ambos cadenas, y hay un arte (o quizás una ciencia) a la definición de por lo que obtener el mejor equilibrio de la eficacia de transacciones y de la consulta junto con la escalabilidad en tiempo de ejecución. Para comprender mejor cómo definir PartitionKeys y RowKeys para el mayor beneficio, recomiendo encarecidamente la sesión de PDC09 “ Windows Azure tablas y colas de profundización, ” presentada por Haridas de la pelota, que puede ver en la de microsoftpdc.com/sessions/svc09 .

PartitionKeys y RowKeys a unidad de escalabilidad y rendimiento

Muchos desarrolladores se utilizan para un sistema de las claves principales, claves externas y las restricciones entre los dos. Con el almacenamiento de la tabla de Azure de Windows, tiene que ir de estos conceptos o tiene dificultades para captar su sistema de claves.

En Windows Azure tablas, la cadena PartitionKey y las propiedades de RowKey: trabajan conjuntamente como un índice para la tabla, por lo que al definirlos, debe tener en cuenta cómo los datos se consultan. Juntos, las propiedades también se proporcionan para que la unicidad, que actúa como una clave principal para la fila. Cada entidad en una tabla debe tener una combinación única de PartitionKey/RowKey.

Pero es necesario que considere más de consultar al definir un PartitionKey, ya que también se utiliza para crear físicamente particiones las tablas, que proporciona para el equilibrio de carga y escalabilidad. Por ejemplo, considere la posibilidad de una tabla que contiene información acerca de la comida y tiene PartitionKeys que corresponden a los tipos de alimentos, por ejemplo, verduras y fruta con grano. Durante el verano, las filas de la partición de theVegetable pueden ser muy ocupadas (se convierta en una partición de lo que se denomina “ hot ”). El servicio puede controlar de la tabla de comida al mover la partición de verduras en un servidor diferente para 
better el número de solicitudes realizado a la partición de equilibrar la carga.

Si va a realizar más actividad en la partición que puede controlar un único servidor, considere la posibilidad de crear particiones más granulares como Vegetable_Root y Vegetable_Squash. Esto es debido a que la unidad de granularidad para equilibrar la carga es el PartitionKey. Todas las filas con el mismo valor PartitionKey se mantienen juntos cuando equilibra la carga. Incluso puede diseñar la tabla para que cada entidad de seguridad de la tabla tiene una partición diferente.

Análisis de más de PartitionKeys y consultas

Tenga en cuenta que cuando sugiere que ajuste la PartitionKeys verduras, coloqué verduras al principio de la clave, no al final. Que es otro mecanismo para permitir consultas más eficaces. Las consultas de tablas de Azure de Windows de Microsoft .NET Framework utilizan LINQ, REST y un contexto que se deriva de la System.Data.Services.Client.DataServiceContext de servicios de datos de WCF. Si desea encontrar cualquier squash verde, es posible buscar en la partición Vegetable_Squash sin desperdiciar recursos para buscar en toda la tabla:

var query = _serviceContext.FoodTable.AsTableServiceQuery()
.Where(c => c.PartitionKey=="Vegetable_Squash"&& c.Color == "Green");

Una gran diferencia entre consultas OData (devuelto por los servicios de datos de WCF) y consultar con respecto a las tablas de Azure de Windows es que no se admiten las funciones de cadena. Si desea buscar en la parte de una cadena, debe utilizar String.CompareTo para inspeccionar los caracteres del principio de la cadena. Sin embargo, si desea consultar toda la categoría de verduras, puede utilizar el método CompareTo para realizar una búsqueda de prefijo en el inicio de la PartitionKey:

var query = _serviceContext.FoodTable.AsTableServiceQuery()
            .Where(c => c.PartitionKey.CompareTo("Vegetable")>=0
            && c.PartitionKey.CompareTo("Vegetablf")<0
            && c.Color == "Green");

Esto limitará la búsqueda a sólo las particiones que empiezan por verduras, nada menos y nada más. (Utilizar Vegetablf en lugar de verduras en el segundo predicado define el límite superior, que impide que los alimentos en particiones, como un yogur o VegetableLike devueltos). En el ejemplo de código que acompaña este artículo, verá cómo lo he hecho este reemplazo dinámicamente.

Análisis de consultas paralelas de la tabla completa

¿Qué ocurre si se han buscando todos los alimentos verde, con independencia del tipo? Windows Azure tiene que recorrer toda la tabla. Si se trata de una tabla grande, Azure de Windows se inicia en otro llave: Puede devolver sólo 1000 filas a una hora (o el proceso de cinco segundos). Windows Azure se devuelven los resultados junto con una clave de continuación de , a continuación, volver atrás para obtener más información. Esto puede ser un proceso sincrónico tedioso.

En su lugar se puede ejecutar un número de consultas, es posible recorrer en iteración una lista conocida de categorías, a continuación, crear cada consulta:

_serviceContext.FoodTable.AsTableServiceQuery()
.Where(c => c.PartitionKey == _category && c.Color == "Green");

A continuación, se puede enviar cierre todas las consultas para ejecutar en paralelo.

Obtener más consideraciones de diseño de consultas

La propiedad RowKey sirve para varios propósitos. En combinación con PartitionKey, puede definir la unicidad en una tabla para cada fila. Por ejemplo, sé que otro Lerman de Julia (realmente hago). Por lo tanto, el RowKey será importante diferenciar nos cuando se comparte un PartitionKey de lerman_julie. También puede utilizar RowKey para facilitar la ordenación, ya que actúa como parte de un índice. ¿Por lo tanto, a continuación, lo que sería útil RowKeys Julie Lerman el elder (es decir, me) y los más recientes de Julie Lerman? Sin duda, lo hará el truco para identidad de un GUID, pero no hace nada para las búsquedas u ordenación. En este caso, probablemente sería mejor una combinación de valores.

¿Qué más diferencia a nosotros? Vivimos en extremos opuestos de los Estados Unidos, pero las ubicaciones pueden cambiar, de modo no es útil para una clave. Sin duda, la fecha de nacimiento es diferente (por más de 20 años) y es un valor estático. Pero siempre existe la posibilidad de que otro Lerman de Julia con la fecha de nacimiento existe en algún lugar del mundo y se colocará en la base de datos, altamente implausible, pero no imposible. Después de todo de la que es posible que avanzo a través de deliberation, fecha de nacimiento puede no ser un valor en el que está buscando o la ordenación mi aplicación. Por lo tanto, en este caso, RowKey pueden no ser parte de las consultas y basta con un GUID sin formato de edad. Deberá hacer para que este tipo de decisiones para todas las tablas de Azure de Windows.

Mucho más para obtener más información acerca de la definición de las claves y, por ejemplo, para recuperar los datos, almacenamiento de datos, la escalabilidad y equilibrio de carga todos entran en juego factores.

Replanteamiento de relaciones

En una base de datos relacional, confiamos en que las claves externas y restricciones para definir relaciones. Sin duda, podemos definir una propiedad de clave externa en una clase que se hace referencia a otra clase, pero no hay nada en el almacenamiento de la tabla Azure de Windows para exigir las relaciones. Seguirá siendo responsable de el código.

Esto afecta a cómo realizar consultas y actualizaciones (incluidas las inserciones y eliminaciones) de tablas.

Cuando se realiza la consulta, no se puede realizar combinaciones entre tablas. Y cuando se almacena datos, no se dispone de transacción comandos que abarcan las particiones o tablas. Sin embargo, hay un mecanismo para trabajar con datos en gráficos, que es algo que señalado al principio de esta columna, puede almacenar las filas de esquemas diferentes en una sola tabla.

Si la aplicación requiere que los usuarios trabajar con los contactos y direcciones juntos, no se puede almacenar las direcciones en la misma tabla como los contactos. Sería muy importante asegurarse de que las direcciones tienen la misma PartitionKey, por ejemplo, “ lerman_julie. ” Además, el RowKey debe contener un valor que especifica el tipo o el tipo de entidad, como “ address_12345 ”, por lo que fácilmente puede diferenciar entre los tipos de contacto y los tipos de direcciones cuando se consulta.

El common PartitionKey garantiza que las filas siempre permanecerá juntos para aprovechar las ventajas de una característica denominada grupo de entidades transacciones (EGT). Esto permite que una sola transacción para llevar a cabo las operaciones de forma atómica a través de varias entidades siempre y cuando todas las entidades tienen el mismo valor de PartitionKey. Una de las ventajas de EGT con respecto a los datos relacionados es que puede realizar una actualización de transacciones en todas las entidades en una sola transacción.

Una base de la descripción de para obtener más información

Tablas de Azure de Windows live en la nube, pero para mí comienza en un tipo de niebla. Tenía una gran cantidad de problemas para obtener mi cabeza ajustado a mi preconcebida comprensión de las bases de datos relacionales. Hizo una gran cantidad de trabajo (y pestered mucha gente) para permitir que yo mismo para los delimitadores RDBMS suelte, de forma podría adoptar y realmente valorar la belleza de tablas de Azure de Windows. Espero que mi trayecto hará suyo más corto.

No hay mucho más para obtener más información acerca de los servicios de Windows Azure tabla. El equipo de Microsoft dispone de gran ayuda en MSDN. También en el vídeo PDC09 que se ha mencionado anteriormente, consulte esta página de recursos en el blog del equipo de almacenamiento de Windows Azure en blogs.msdn.com/windowsazurestorage/archive/2010/03/28/windows-azure-storage-resources de . El equipo continúa agregando entradas detallados, informativos para el blog y se puede saber en el tiempo o ni siquiera por el momento en que se publique esta columna, encontrará respuestas a mis preguntas multitud. Estoy deseando proporcionar algunos ejemplos concretos de una columna futura de puntos de datos.

Julie Lerman es MVP de Microsoft, profesora de .NET y consultora que vive en las colinas de Vermont. Puede encontrar su presentación sobre acceso a datos y otros temas de Microsoft .NET en grupos de usuarios y conferencias en todo el mundo. Lerman mantiene un blog en thedatafarm.com/blog y es la autora del célebre libro, “Programming Entity Framework” (O’Reilly Media, 2009). Siga su en Twitter.com: julielerman.

Gracias a los siguientes expertos técnicos de este artículo: Brad CalderandPelota Haridas