Actualmente existen dos soluciones de almacenamiento tabular en Microsoft Azure, y esta pregunta se relaciona fuertemente con ambas:
SQL Azure, una versión reducida pero redundante y escalable de SQL Server 2008 y Azure Table Storage, una solución sin sql.
SQL Azure se caracteriza por un costo de E / S cero y altos costos de almacenamiento ($ 10 / mes / GB), mientras que Azure Table Storage tiene un bajo costo de almacenamiento y un costo de E / S medio ($ 1 por 1 millón de transacciones, $ 0.15 / mes / GB). También SQL Azure se escala en el nivel de la base de datos, mientras que Azure Table Storage se escala en el nivel de Clave de partición.
- ¿En qué se diferencia Google Cloud de otro proveedor de nube como AWS o Azure?
- ¿Cuáles son los principales servicios de AWS que ha utilizado?
- ¿Dónde puedo aprender Amazon Web Services?
- Cómo cifrar los datos antes de almacenarlos en la nube
- En los proveedores de alojamiento web, ¿cuál es una mejor solución para el almacenamiento de archivos, Amazon S3 o Rackspace Cloud Files? ¿Por qué? ¿Cuál es más rápido de transferir, es tolerante a fallas y tiene mejores precios para un presupuesto pequeño?
Ambos son extremadamente efectivos, pero deben usarse correctamente, de lo contrario, experimentará no solo una desaceleración extrema sino también altos costos:
SQL Azure se utiliza bien en escenarios de datos altamente transaccionales y altamente volátiles, mientras que Azure Table Storage es el más adecuado para grandes cantidades de datos con un número limitado de transacciones.
Una estrategia de implementación típica es la siguiente:
Use SQL Azure para todo el almacenamiento a corto plazo y datos altamente interactivos (me vienen a la mente las secuencias de actividad en una aplicación Web 2.0).
Use Azure Table Storage para almacenar todos los datos a largo plazo, por ejemplo, los perfiles de usuario. No se accede a la mayoría de los perfiles de usuario con tanta frecuencia, por lo que tiene sentido almacenarlos en un almacenamiento económico, ya que la E / S no es tan importante.
Como Azure Table Storage no tiene esquemas, también tiene la opción de agrupar datos relacionados bajo una clave de partición (detalle maestro) y leerlos con solo una transacción facturable. Lo mismo ocurre con las escrituras utilizando transacciones de entidad. Este enfoque puede reducir su costo en un factor de hasta 100.
Use la desnormalización cuando trabaje con Azure Table Storage. Querrás evitar cualquier cosa que se parezca remotamente a una unión, ya que esto matará el rendimiento y costará una fortuna.
Use el almacenamiento en caché local para almacenar en caché los resultados de todas las operaciones en Azure Table Storage. Use plinq para paralelizar consultas en Azure Table Storage. Cuando esté disponible, use Velocity, hasta entonces Caché de memcached o local con medidas de coherencia de caché.
Cree su estructura clave para que cada entidad se haga referencia a través de una clave de partición y una clave de fila, o una clave de partición si utiliza el patrón de detalle maestro.
Asegúrese de utilizar las babosas (especificadores legibles pero inmutables del mundo real) como claves de partición. Básicamente, la arquitectura de su sistema debe fluir desde el punto final web al backend sin tener que buscar ninguna guía. Por ejemplo, en un sitio de viajes esto significaría que http://travel.com/destinations/p… se traduciría en una clave de partición: paris.
También asegúrese de que cuando tenga una clave de partición en ejecución basada en el tiempo (por ejemplo, para registros) no se encuentre con un escenario en el que siempre escriba en el mismo servidor físico (lo que sucede si tiene claves de partición consecutivas) . Utilice algún tipo de prefijo en su lugar en tales casos.
Verifique la viabilidad de usar blobs para el almacenamiento a corto plazo de datos masivos. Esto tiene sentido para el registro, donde puede recopilar todo localmente, volcarlo en el almacenamiento del blog a intervalos específicos que consumen solo 1 transacción, y luego leerlo y publicarlo.
Analice todo y optimice en función de los comentarios que reciba del sistema.
En este momento no conozco herramientas especiales para cargar datos. Normalmente uso los métodos de repositorio para cargar cualquier dato que necesitemos, que también es un buen caso de prueba real en vivo.
