Lista de comprobación de rendimiento y de escalabilidad para Table Storage
Microsoft ha creado muchos procedimientos de demostrada eficacia para desarrollar aplicaciones de alto rendimiento con Table Storage. Esta lista de comprobación identifica los procedimientos clave que pueden seguir los desarrolladores para optimizar su rendimiento. Tenga presente estos procedimientos tanto para diseñar su aplicación como a lo largo de todo el proceso.
Azure Storage tiene objetivos de escalabilidad y rendimiento en lo que se refiere a capacidad, tasa de transacciones y ancho de banda. Para más información sobre los objetivos de escalabilidad de Azure Storage, consulte Objetivos de escalabilidad y rendimiento para cuentas de almacenamiento estándar y Objetivos de escalabilidad y rendimiento de Table Storage.
Lista de comprobación
En este artículo se organizan los procedimientos de eficacia probada a la hora de mejorar el rendimiento en una lista de comprobación que puede seguir al desarrollar su aplicación en Table Storage.
Objetivos de escalabilidad
Si su aplicación se aproxima o supera cualquiera de estos objetivos de escalabilidad, puede notar que aumenta la limitación o las latencias de las transacciones. Cuando Azure Storage limita su aplicación, el servicio comienza a devolver códigos de error 503 (Servidor ocupado) o 500 (Tiempo de espera de la operación). Evitar estos errores, mediante la permanencia en los límites de los objetivos de escalabilidad, es una parte importante de la mejora del rendimiento de la aplicación.
Para más información acerca de los objetivos de escalabilidad de Table service, consulte Objetivos de escalabilidad y rendimiento para Table Storage.
Número máximo de cuentas de almacenamiento
Si se aproxima al número máximo de cuentas de almacenamiento permitido para una combinación de suscripción/región concreta, ¿usa varias cuentas de almacenamiento para la partición para aumentar la entrada, la salida, las operaciones de E/S por segundo o la capacidad? En este escenario, Microsoft recomienda aprovechar las ventajas del aumento de los límites de las cuentas de almacenamiento para reducir el número de cuentas de almacenamiento necesarias para la carga de trabajo, siempre que sea posible. Póngase en contacto con el soporte técnico de Azure para solicitar el aumento de los límites de la cuenta de almacenamiento.
Objetivos de capacidad y transacción
Si su aplicación se aproxima a los objetivos de escalabilidad para una sola cuenta de almacenamiento, plantéese la adopción de uno de los siguientes enfoques:
- Reconsidere la carga de trabajo que hace que su aplicación se aproxime al objetivo de escalabilidad o lo supere. ¿Puede designarla de forma diferente para que use menos ancho de banda o capacidad, o menos transacciones?
- Si su aplicación debe superar uno de los objetivos de escalabilidad, cree varias cuentas de almacenamiento y realice particiones de los datos de su aplicación entre esas cuentas. Si usa este patrón, entonces debe asegurarse de designar la aplicación de forma que pueda agregar más cuentas de almacenamiento en el futuro para equilibrio de carga. Las propias cuentas de almacenamiento no tienen ningún costo aparte del de su uso en términos de datos almacenados, transacciones realizadas o datos transferidos.
- Si la aplicación se aproxima a los objetivos de ancho de banda, considere la posibilidad de comprimir los datos en el cliente para reducir el ancho de banda necesario para enviar los datos a Azure Storage. Aunque comprimir datos puede ahorrar ancho de banda y mejorar el rendimiento de la red, también puede tener efectos negativos en el rendimiento. Evalúe el impacto en el rendimiento de los requisitos de procesamiento adicionales para la compresión y descompresión de datos en el cliente. Tenga en cuenta que el almacenamiento de los datos comprimidos puede dificultar la solución de problemas, ya que es muy probable que sea más complicado ver los datos con herramientas estándar.
- Si la aplicación se acerca a los objetivos de escalabilidad, asegúrese de que usa un retroceso exponencial para los reintentos. Es recomendable que intente evitar llegar a los objetivos de escalabilidad mediante la implementación de las recomendaciones que se describen en este artículo. Sin embargo, el uso de un retroceso exponencial para los reintentos impedirá que la aplicación vuelva a intentarlo rápidamente, lo que podría empeorar la limitación. Para más información, consulte la sección Errores de tiempo de expiración y servidor ocupado.
Destinos para operaciones de datos
Azure Storage equilibra la carga a medida que aumenta el tráfico hacia la cuenta de almacenamiento, pero si el tráfico exhibe ráfagas repentinas, es posible que no pueda conseguir este volumen de rendimiento de inmediato. Espere ver el límite o los tiempos de espera durante la ráfaga ya que Azure Storage equilibra automáticamente la carga de la tabla. El aumento lento generalmente proporciona mejores resultados, ya que el sistema tiene tiempo para equilibrar la carga apropiadamente.
Entidades por segundo (cuenta de almacenamiento)
El límite de escalabilidad para el acceso a tablas es de hasta 20 000 unidades (1 KB cada una) por segundo para una cuenta. En general, cada entidad que se inserta, actualiza, elimina o examina, cuenta para este objetivo. Por tanto, una inserción por lotes que contiene 100 entidades contaría como 100 entidades. Una consulta que examina 1.000 y devuelve 5, contaría como 1.000 entidades.
Entidades por segundo (partición)
Dentro de una sola partición, el objetivo de escalabilidad para obtener acceso a las tablas es de 2000 entidades (1 KB cada una) por segundo, usando el mismo recuento descrito en la sección anterior.
Redes
Las restricciones de red físicas de la aplicación pueden tener un impacto considerable en el rendimiento. En las siguientes secciones se describen algunas de las limitaciones que pueden observar los usuarios.
Capacidad de red del cliente
El ancho de banda y la calidad del vínculo de red juegan roles importantes en el rendimiento de la aplicación, como se describe en las secciones siguientes.
Throughput
Para el ancho de banda, el problema suele residir en las capacidades del cliente. Las instancias de Azure mayores tienen NIC con mayor capacidad, por lo que debe plantearse la posibilidad de usar una instancia mayor o más máquinas virtuales si necesita aumentar los límites de red de una sola máquina. Si accede a Azure Storage desde una aplicación local, se aplica la misma regla: conozca las funcionalidades de red del dispositivo cliente y la conectividad de red con la ubicación de Azure Storage y mejórelas según sea necesario, o diseñe la aplicación para que funcione dentro de sus funcionalidades.
Calidad del vínculo
Como siempre que se usa la red, tenga en cuenta que las condiciones de la red generan errores y la pérdida de paquetes reduce el rendimiento efectivo. El uso de WireShark o NetMon puede ayudar a diagnosticar este problema.
Location
En cualquier entorno distribuido, la ubicación del cliente cerca del servidor ofrece el mejor rendimiento. Para acceder a Azure Storage con la mínima latencia, la mejor ubicación para el cliente es dentro de la misma región de Azure. Por ejemplo, si tiene una aplicación web de Azure que usa Azure Storage, coloque ambas en una sola región, como Oeste de EE. UU. o Sudeste de Asia. La colocalización reduce la latencia y el costo, ya que el uso del ancho de banda dentro de una sola región es gratuito.
Si las aplicaciones cliente acceden a Azure Storage, pero no están hospedadas en Azure, como por ejemplo las aplicaciones de dispositivos móviles o los servicios empresariales locales, la colocación de la cuenta de almacenamiento en una región próxima a los clientes puede reducir la latencia. Si los clientes están distribuidos en sitios distantes (por ejemplo, algunos en Norteamérica y otros en Europa), considere la posibilidad de usar una cuenta de almacenamiento por región. Este enfoque es más sencillo de implementar si los datos que almacena la aplicación son específicos de usuarios individuales y no se requiere la replicación de datos entre cuentas de almacenamiento.
SAS y CORS
Supongamos que necesita autorizar código, como JavaScript, que se ejecuta en el explorador web de un usuario o en una aplicación de teléfono móvil para acceder a los datos de Azure Storage. Un enfoque consiste en crear una aplicación de servicio que actúe como proxy. El dispositivo del usuario se autentica con el servicio, que a su vez autoriza el acceso a los recursos de Azure Storage. De esta forma, puede evitar la exposición de sus claves de cuenta de almacenamiento en dispositivos no seguros. Sin embargo, este enfoque supone una importante sobrecarga para la aplicación de servicio, ya que todos los datos transferidos entre el dispositivo del usuario y Azure Storage deben pasar por la aplicación de servicio.
El uso de firmas de acceso compartido (SAS) le permite evitar el uso de una aplicación de servicio como proxy para Azure Storage. Mediante SAS se puede permitir que el dispositivo del usuario realice solicitudes directamente en Azure Storage mediante un token de acceso limitado. Por ejemplo, si un usuario desea cargar una foto en la aplicación, la aplicación de servicio puede generar una SAS y enviarla al dispositivo del usuario. El token de SAS puede conceder permiso para escribir en un recurso de Azure Storage durante un intervalo de tiempo especificado, después del cual expirará el token. Para obtener más información sobre las firmas de acceso compartido, consulte Otorgar acceso limitado a recursos de Azure Storage con firmas de acceso compartido (SAS).
Por lo general, los exploradores web no permiten que haya código JavaScript en una página hospedada por un sitio web de un dominio que realiza operaciones concretas, como operaciones de escritura, en otro dominio. Esta directiva, que se conoce como directiva de mismo origen, impide que un script malintencionado de una página acceda a los datos de otra página web. Sin embargo, la directiva de mismo origen puede ser una limitación al compilar una solución en la nube. El uso compartido de recursos entre orígenes (CORS) es una característica del explorador que permite al dominio de destino comunicarle al explorador en el que confía solicitudes que se originan en el dominio de origen.
Por ejemplo, supongamos que una aplicación web que se ejecuta en Azure realiza una solicitud de un recurso en una cuenta de Azure Storage. La aplicación web es el dominio de origen y la cuenta de almacenamiento es el dominio de destino. Puede configurar CORS para que cualquiera de los servicios de Azure Storage comunique al explorador web que Azure Storage confía en las solicitudes del dominio de origen. Para más información sobre CORS, consulte Soporte técnico del uso compartido de recursos entre orígenes (CORS) para Azure Storage.
Tanto SAS como CORS pueden evitar una carga innecesaria en la aplicación web.
Transacciones por lotes
Table service admite transacciones por lotes en entidades que están en la misma tabla y pertenecen al mismo grupo de particiones. Para más información, consulte Realización de transacciones de grupos de entidades.
Configuración de .NET
Para proyectos que usan .NET Framework, esta sección enumera algunas configuraciones rápidas que puede usar para realizar mejoras de rendimiento significativas. Si usa un lenguaje distinto de .NET, compruebe si se aplican conceptos similares en el lenguaje elegido.
Aumento del límite de conexiones predeterminado
Nota:
Esta sección se aplica a los proyectos que usan .NET Framework, ya que la agrupación de conexiones se controla mediante la clase ServicePointManager. .NET Core introdujo un cambio significativo en la administración del grupo de conexiones, donde la agrupación de conexiones se produce en el nivel HttpClient y el tamaño del grupo no está limitado de forma predeterminada. Esto significa que las conexiones HTTP se escalan automáticamente para satisfacer la carga de trabajo. Se recomienda usar la versión más reciente de .NET, siempre que sea posible, para aprovechar las mejoras de rendimiento.
Con los proyectos que utilizan .NET Framework, puede usar el siguiente código para aumentar el límite de conexiones predeterminado (que normalmente es 2 en un entorno de cliente o 10 en un entorno de servidor) a 100. Normalmente, debe establecer el valor en aproximadamente el número de subprocesos usados por su aplicación. Establezca el límite de conexiones antes de abrir cualquier conexión.
ServicePointManager.DefaultConnectionLimit = 100; //(Or More)
Para más información sobre los límites del grupo de conexiones en .NET Framework, consulte Límites del grupo de conexiones de .NET Framework y el nuevo Azure SDK para .NET.
En el caso de otros lenguajes de programación, consulte la documentación del lenguaje en cuestión para determinar cómo establecer el límite de conexiones.
Aumento del número mínimo de subprocesos
Si usa llamadas sincrónicas junto con tareas asincrónicas, puede que quiera aumentar el número de subprocesos del grupo de subprocesos:
ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)
Para más información, consulte el método ThreadPool.SetMinThreads.
Paralelismo sin enlazar
Aunque el paralelismo puede ser excelente para el rendimiento, tenga cuidado al usar el paralelismo sin enlazar, lo que significa que no se aplica ningún límite en cuanto al número de subprocesos o solicitudes paralelas. Asegúrese de limitar las solicitudes paralelas para cargar o descargar datos, para acceder a varias particiones de la misma cuenta de almacenamiento o para acceder a varios elementos de la misma partición. Si el paralelismo está sin enlazar, la aplicación puede superar las funcionalidades del dispositivo cliente o los objetivos de escalabilidad de la cuenta de almacenamiento, lo que puede provocar latencias y limitaciones mayores.
Herramientas y bibliotecas cliente
Para obtener el mejor rendimiento posible, utilice siempre las herramientas y bibliotecas de cliente más recientes que proporciona Microsoft. Las bibliotecas cliente de Azure Storage están disponibles para varios lenguajes. Azure Storage también admite PowerShell y la CLI de Azure. Microsoft desarrolla de forma activa estas herramientas y bibliotecas de cliente pensando en el rendimiento, las mantiene actualizadas con las versiones de servicio más recientes y se asegura de que controlan internamente muchos de los procedimientos de rendimiento de eficacia probada.
Control de errores del servicio
Azure Storage devuelve un error cuando el servicio no puede procesar una solicitud. Conocer los errores que devuelve Azure Storage en un escenario dado resulta útil para optimizar el rendimiento.
Errores debidos al tiempo de expiración y a que el servidor está ocupado
Azure Storage puede limitar la aplicación si se aproxima a los límites de escalabilidad. En algunos casos, es posible que Azure Storage no pueda controlar una solicitud debido a alguna condición transitoria. En ambos casos, el servicio puede devolver un error 503 (servidor ocupado) o 500 (tiempo de espera agotado). Estos errores también pueden producirse si el servicio reequilibra las particiones de datos para permitir un mayor rendimiento. Normalmente, la aplicación cliente debería reintentar la operación que provoca cualquiera de estos errores. Sin embargo, si Azure Storage está limitando la aplicación porque está superando los objetivos de escalabilidad, o incluso si el servicio no ha podido atender a la solicitud por alguna otra razón, intentarlo una y otra vez puede empeorar el problema. Se recomienda usar una directiva de reintentos de retroceso exponencial y las bibliotecas cliente se comportan así de forma predeterminada. Por ejemplo, su aplicación podría reintentarlo al cabo de 2 segundos, luego 4 segundos, después 10 segundos, luego 30 segundos y, después, dejarlo completamente. De esta forma, la aplicación reduce considerablemente su carga en el servicio, en lugar de exagerar el comportamiento que puede provocar la limitación.
Los errores de conectividad se pueden reintentar inmediatamente porque no se derivan de la limitación y se espera que sean transitorios.
Errores que no se pueden reintentar
Las bibliotecas cliente controlan los reintentos sabiendo qué errores se pueden reintentar y cuáles no. Sin embargo, si va a llamar directamente a la API de REST de Azure Storage, hay algunos errores que no debe reintentar. Por ejemplo, un error 400 (solicitud incorrecta) indica que la aplicación cliente ha enviado una solicitud que no se pudo procesar porque no tenía el formato esperado. El reenvío de esta solicitud genera la misma respuesta siempre, por lo que no tiene sentido reintentarla. Si llama directamente a la API de REST de Azure Storage, tenga en cuenta los posibles errores y si deben reintentarse.
Para más información sobre los códigos de error de Azure Storage, consulte Estado y códigos de error.
Configuración
En esta sección se enumeran varias configuraciones rápidas que puede usar para realizar mejoras de rendimiento significativas en Table service:
Uso de JSON
A partir de la versión del 15 de agosto de 2013 del servicio Storage, Table service admite el uso de JSON en lugar del formato AtomPub basado en XML para transferir datos de las tablas. El uso de JSON puede reducir los tamaños de carga hasta en un 75 % y puede mejorar significativamente el rendimiento de la aplicación.
Para más información, consulte la publicación Tablas de Microsoft Azure: introducción a JSON y Payload Format for Table Service Operations (Formato de carga para las operaciones de Table service).
Deshabilitación de Nagle
El algoritmo de Nagle está ampliamente implementado en redes TCP/IP como medio de mejorar el rendimiento de la red. Sin embargo, no es óptimo en todas las situaciones (como por ejemplo, en entornos muy interactivos). El algoritmo de Nagle tiene un efecto negativo en el rendimiento de las solicitudes en Azure Table service y debe deshabilitarlo si es posible.
Schema
La forma de representar los datos y realizar consultas es el factor más importante que afecta al rendimiento de Table service. Aunque cada aplicación es diferente, en esta sección se describen algunas prácticas probadas generales relacionadas con:
- Diseño de tablas
- Consultas eficientes
- Actualizaciones de datos eficientes
Tablas y particiones
Las tablas se dividen en dos particiones. Cada entidad almacenada en una partición comparte la misma clave de partición y tiene una clave de fila única para identificarla dentro de esa partición. Las particiones proporcionan ventajas pero también presentan limitaciones de escalabilidad.
- Ventajas: Puede actualizar entidades de la misma partición en una sola transacción por lotes atómica que contenga hasta 100 operaciones de almacenamiento independientes (límite de tamaño total de 4 MB). Suponiendo que se recupera el mismo número de entidades, también puede consultar datos dentro de una sola partición más eficientemente que los datos que se extienden por particiones (siga leyendo para conocer más recomendaciones sobre la consulta de datos de tabla).
- Limite de escalabilidad: no se puede realizar el equilibrio de carga en el acceso a entidades almacenadas en una sola partición porque las particiones admiten transacciones por lotes atómicas. Por esta razón, el objetivo de escalabilidad de una partición de tabla individual es inferior al de Table service en conjunto.
Debido a estas características de tablas y particiones, debe adoptar los siguientes principios de diseño:
- Busque los datos que su aplicación cliente actualiza o consulta con frecuencia en la misma unidad lógica de trabajo de la misma partición. Por ejemplo, busque los datos en la misma partición si la aplicación agrega escrituras o realiza operaciones por lotes atómicas. Asimismo, los datos de una sola partición pueden ser consultados de forma más eficiente en una sola consulta que los datos que se encuentran repartidos por particiones.
- Busque los datos que la aplicación cliente no inserta, actualiza o consulta en la misma unidad lógica de trabajo (es decir, en una consulta o una actualización por lotes) en distintas particiones. Tenga en cuenta que no hay límite en el número de claves de partición que contiene una sola tabla, por lo que tener millones de claves de partición no es un problema y no afectará al rendimiento. Por ejemplo, si la aplicación es un sitio web conocido con inicio de sesión de usuario, el uso del identificador de usuario como clave de partición podría ser una buena elección.
Particiones calientes
Una partición caliente es aquella que recibe un porcentaje desproporcionado de tráfico en una cuenta, y no se puede realizar un equilibrio de carga en ella porque es una sola partición. En general, las particiones calientes se crean de una de dos formas:
Patrones Solo anexar y Solo anteponer
El patrón "Solo anexar" es aquel en el que todo (o casi todo) el tráfico que llega a una clave de partición dada aumenta y disminuye en función de la hora. Por ejemplo, suponga que su aplicación usa la fecha actual como clave de partición para los datos de registro. El resultado de este diseño es que todas las inserciones van a la última partición de la tabla y el sistema no puede equilibrar la carga correctamente. Si el volumen del tráfico en esa partición supera el objetivo de escalabilidad de nivel de partición, dará lugar a una limitación. Es mejor garantizar que el tráfico se envía a varias particiones para habilitar el equilibrio de carga de las solicitudes en la tabla.
Datos con mucho tráfico
Si el esquema de partición da lugar a una partición que solamente tiene datos y que se utiliza mucho más que otras particiones, también puede observar limitaciones cuando esa partición se aproxime al objetivo de escalabilidad de una sola partición. Conviene asegurarse de que el esquema de partición no provoca que las particiones individuales se aproximen a los objetivos de escalabilidad.
Consultas
En esta sección se describen procedimientos de eficacia probada para realizar consultas en Table service.
Ámbito de la consulta
Hay varias formas de especificar el intervalo de entidades para consultar. En la siguiente lista se describe cada una de las opciones del ámbito de la consulta.
- Consultas de punto: las consultas de punto recuperan exactamente una entidad mediante la especificación tanto de la clave de la partición como de la clave de la fila de la entidad que se va a recuperar. Estas consultas son eficientes y debe usarlas siempre que sea posible.
- Consultas de partición: Una consulta de partición es una consulta que recupera un conjunto de datos que comparte una clave de partición común. Normalmente, la consulta especifica un intervalo de valores de clave de fila o un intervalo de valores para alguna propiedad de entidad además de una clave de partición. Estas consultas son menos eficientes que las consultas de punto y se deben usar con moderación.
- Consultas de tabla: las consultas de tabla recuperan un conjunto de entidades que no comparte una clave de partición común. Estas consultas no son eficientes y debe evitarlas siempre que sea posible.
En general, evite las exploraciones (consultas mayores que una sola entidad), pero si debe realizarlas, intente organizar los datos de forma que dichas exploraciones recuperen los datos necesarios sin explorar o devolver grandes cantidades de entidades innecesarias.
Densidad de la consulta
Otro factor clave en la eficiencia de las consultas es el número de entidades devueltas comparado con el número de entidades examinadas para encontrar el conjunto devuelto. Si la aplicación realiza una consulta de tabla con un filtro para un valor de propiedad que solamente comparte el 1 % de los datos, la consulta examina 100 entidades por cada entidad que devuelva. Los objetivos de escalabilidad de tabla tratados anteriormente están relacionados con el número de entidades que se examinan, no con el número de entidades que se devuelven: una densidad de consulta baja fácilmente puede provocar que el servicio Table limite la aplicación porque debe examinar muchas entidades para recuperar la entidad que busca. Para más información acerca de cómo evitar la limitación, consulte la sección Desnormalización.
Limitación de la cantidad de datos devueltos
Cuando sepa que una consulta devuelve entidades que no necesita en la aplicación cliente, plantéese el uso de un filtro para reducir el tamaño del conjunto devuelto. Aunque las entidades no devueltas al cliente siguen contando para los límites de escalabilidad, el rendimiento de la aplicación mejora debido a la reducción del tamaño de la carga de red y a la reducción del número de entidades que la aplicación cliente debe procesar. Tenga en cuenta que los objetivos de escalabilidad están relacionados con el número de entidades examinadas, por lo que una consulta que filtre muchas entidades puede seguir dando lugar a limitaciones aunque se devuelvan pocas entidades. Para más información sobre cómo mejorar la eficacia de las consultas, consulte la sección Densidad de consulta.
Si la aplicación cliente solamente necesita un conjunto limitado de propiedades de las entidades de la tabla, puede usar proyección para limitar el tamaño del conjunto de datos devuelto. Como en el caso de los filtros, una proyección ayuda a reducir la carga de la red y el procesamiento del cliente.
Desnormalización
A diferencia del trabajo con bases de datos relacionales, las prácticas probadas para consultar datos de tabla de forma eficiente conducen a la desnormalización de los datos. Es decir, a la duplicación de los mismos datos en múltiples entidades (una por cada clave que se pueda utilizar para encontrar los datos) para minimizar el número de entidades que una consulta debe escanear para encontrar los datos que el cliente necesita, en lugar de tener que escanear un gran número de entidades para encontrar los datos que su aplicación necesita. Por ejemplo, en un sitio web de comercio electrónico, puede que le interese encontrar un pedido tanto por el identificador del cliente (ver los pedidos de este cliente) como por la fecha (ver los pedidos con esa fecha). En Table Storage, es mejor almacenar la entidad (o una referencia a ella) dos veces, una vez con el nombre de tabla, la clave de partición y la clave de fila para facilitar la búsqueda por identificador de cliente y otra para facilitar la búsqueda por la fecha.
Inserción, actualización y eliminación
En esta sección se describen prácticas de eficacia probada para modificar entidades almacenadas en Table service.
Lotes
Las transacciones por lotes se conocen como transacciones de grupos de entidades en Azure Storage. Todas las operaciones de una transacción de grupos de entidades deben estar en una sola partición de una sola tabla. Siempre que sea posible, use las transacciones de grupos de entidades para realizar inserciones, actualizaciones y eliminaciones por lotes. El uso de transacciones de grupos de entidades reduce el número de recorridos de ida y vuelta de la aplicación cliente al servidor, disminuye el número de transacciones facturables (una transacción de grupos de entidades cuenta como una sola transacción desde el punto de vista de facturación y puede contener hasta 100 operaciones de almacenamiento) y permite actualizaciones atómicas (todas las operaciones se realizan correctamente o en todas ellas hay errores dentro de una transacción de grupos de entidades). Los entornos con altas latencias, como por ejemplo, dispositivos móviles, sacarán un enorme provecho al uso de transacciones de grupos de entidades.
Upsert
Use operaciones Upsert de tabla siempre que sea posible. Hay dos tipos de operaciones Upsert; ambos pueden ser más eficientes que las operaciones Insert y Update tradicionales:
- InsertOrMerge: Use esta operación cuando quiera cargar un subconjunto de propiedades de la entidad, pero no está seguro de si la entidad ya existe. Si la entidad ya existe, esta llamada actualiza las propiedades incluidas en la operación Upsert y deja todas las propiedades existentes como están; si la entidad no existe, inserta la nueva entidad. Esto es similar a usar proyección en una consulta, donde solamente necesita actualizar las propiedades que cambian.
- InsertOrReplace: Use esta operación cuando quiera cargar una entidad completamente nueva, pero no está seguro de si ya existe. Use esta operación cuando sepa que la entidad recién cargada es totalmente correcta porque sobrescribe completamente la entidad antigua. Por ejemplo, quiere actualizar la entidad que almacena la ubicación actual de un usuario independientemente de si la aplicación ha almacenado los datos de ubicación del usuario anteriormente; la entidad de la nueva ubicación está completa y no necesita información de ninguna otra entidad anterior.
Almacenamiento de series de datos en una sola entidad
A veces, una aplicación almacena una serie de datos que necesita recuperar de una sola vez con frecuencia: por ejemplo, un aplicación podría hacer un seguimiento del uso de CPU a lo largo del tiempo para representar un gráfico dinámico de los datos de las últimas 24 horas. Un enfoque es tener una entidad de tabla por hora, de forma que cada entidad represente una hora específica y almacene el uso de CPU para esa hora. Para representar estos datos, la aplicación necesita recuperar las entidades que contienen los datos de las 24 horas más recientes.
Como alternativa, la aplicación podría almacenar el uso de CPU por cada hora como propiedad independiente de una sola entidad: para actualizar cada hora, la aplicación puede usar una sola llamada InsertOrMerge Upsert para actualizar el valor de la hora más reciente. Para representar los datos, la aplicación solamente necesita recuperar una entidad, no 24, lo que hace que la consulta sea eficiente. Para más información sobre la eficacia de las consultas, consulte la sección Ámbito de la consulta.
Almacenamiento de datos estructurados en blobs
Si va a realizar inserciones por lotes y, después, a recuperar intervalos de entidades de forma conjunta, plantéese el uso de blobs en lugar de tablas. Un buen ejemplo es un archivo de registro. Puede procesar por lotes varios minutos de registros, insertarlos y, después, recuperar varios minutos de registros simultáneamente. En ese caso, el rendimiento mejora si se usan blobs en lugar de tablas, ya que se puede reducir considerablemente el número de objetos en los que se escribe o que se leen, y posiblemente el número de solicitudes que hay que realizar.