Recientemente hemos actualizado nuestro registro para usar el almacenamiento de tablas de Azure, que debido a su bajo costo y alto rendimiento al realizar consultas por fila y partición es muy adecuado para este propósito.

Estamos tratando de seguir las pautas dadas en el documento.Diseño de una estrategia de particionamiento escalable para Azure Table Storage. Como estamos haciendo un gran número de inserciones en esta tabla (y con suerte un número creciente, a medida que escalamos) debemos asegurarnos de no alcanzar nuestros límites, lo que provocará la pérdida de registros. Estructuramos nuestro diseño de la siguiente manera:

Tenemos una cuenta de almacenamiento de Azure por entorno (DEV, TEST, PROD).

Tenemos una mesa por producto.

Estamos utilizando un GUID TicksReversed + para la clave de fila, de modo que podamos consultar bloques de resultados entre ciertos momentos con un alto rendimiento.

Originalmente elegimos particionar la tabla por Logger, que para nosotros eran áreas amplias del producto, como API, aplicación, rendimiento y almacenamiento en caché. Sin embargo, debido al bajo número de particiones, nos preocupaba que esto resultara en las denominadas particiones "en caliente", donde se realizaron muchas inserciones en una partición en un período de tiempo determinado. Así que cambiamos a la partición en Contexto (para nosotros, el nombre de la clase o el recurso API).

Sin embargo, en la práctica hemos descubierto que esto es menos que ideal, porque cuando miramos nuestros registros de un vistazo, nos gustaría que aparecieran en orden de tiempo. En su lugar, terminamos con bloques de resultados agrupados por contexto, y tendríamos que obtener todas las particiones si queremos ordenarlas por tiempo.

Algunas ideas que tuvimos fueron

use bloques de tiempo (digamos 1 hora) para las claves de partición para ordenarlas por tiempo (resulta en particiones activas durante 1 hora)

use unos pocos GUID aleatorios para las claves de partición para tratar de distribuir los registros (perdemos la capacidad de consultar rápidamente características como Context).

Como esta es una aplicación tan común del almacenamiento de tablas de Azure, debe haber algún tipo de procedimiento estándar.¿Cuál es la mejor práctica para particionar tablas de Azure que se usan para almacenar registros?

Restricciones de solución

Use almacenamiento de Azure barato (el almacenamiento de tablas parece la opción obvia)

Escrituras rápidas y escalables

Baja posibilidad de pérdida de registros (es decir, al exceder la tasa de escritura de la partición de 2000 entidades por segundo en el almacenamiento de la tabla de Azure).

Lectura ordenada por fecha, la más reciente primero.

Si es posible, particionar en algo que sería útil consultar (como el área del producto).