Diferencias clave y principios de diseño de No design SQL

Ningún sistema SQL de bases de datos como Amazon Keyspaces utiliza modelos alternativos para la administración de datos, como pares clave-valor o almacenamiento de documentos. Al cambiar de un sistema de administración de bases de datos relacionales a un sistema sin SQL bases de datos como Amazon Keyspaces, es importante entender las diferencias clave y los enfoques de diseño específicos.

Diferencias entre el diseño de datos relacionales y el no SQL

Los sistemas de bases de datos relacionales (RDBMS) y las SQL bases de datos No tienen diferentes puntos fuertes y débiles:

• EnRDBMS, los datos se pueden consultar de forma flexible, pero las consultas son relativamente caras y no se escalan bien en situaciones de mucho tráfico (consulte). Mejores prácticas de modelado de datos: recomendaciones para diseñar modelos de datos

• En una SQL base de datos sin datos, como Amazon Keyspaces, los datos se pueden consultar de manera eficiente de un número limitado de formas, fuera de las cuales las consultas pueden resultar costosas y lentas.

Estas diferencias hacen que el diseño de las bases de datos sea muy distinto entre los dos sistemas:

• En ellaRDBMS, diseñas pensando en la flexibilidad sin preocuparte por los detalles de la implementación o el rendimiento. Por lo general, la optimización de consultas no afecta al diseño del esquema, pero la normalización es importante.

• En Amazon Keyspaces, usted diseña específicamente su esquema para que las consultas más comunes e importantes sean lo más rápidas y económicas posible. Las estructuras de datos se ajustan a los requisitos específicos de los casos de uso de la organización.

Dos conceptos clave para No SQL design

Ningún SQL diseño requiere una mentalidad diferente a la RDBMS del diseño. Por ejemploRDBMS, puede seguir adelante y crear un modelo de datos normalizado sin pensar en los patrones de acceso. Posteriormente, podrá ampliar este modelo cuando surjan nuevos requisitos sobre preguntas y consultas. Puede organizar cada tipo de datos en su propia tabla.

Por qué ningún SQL diseño es diferente

• Por el contrario, no debería comenzar a diseñar su esquema para Amazon Keyspaces hasta que conozca las preguntas a las que debe responder. Es esencial conocer de antemano los problemas del negocio y los casos de uso de la aplicación.

• En una aplicación de Amazon Keyspaces debería mantener el menor número posible de tablas. Tener menos tablas permite que las cosas sean más escalables, requiere menos administración de permisos y reduce la sobrecarga de su aplicación de Amazon Keyspaces. También puede ayudar a mantener los costos de las copias de seguridad generalmente más bajos.

Acercándose a No SQL design

El primer paso en el diseño de su aplicación de Amazon Keyspaces es identificar los patrones de consulta específicos que debe satisfacer el sistema.

En particular, antes de empezar, es importante entender tres propiedades fundamentales de los patrones de acceso de la aplicación:

• Tamaño de los datos: saber cuántos datos se almacenarán y solicitarán a la vez permite determinar la forma más eficaz de particionar los datos.

• Forma de los datos: en lugar de cambiar la forma de los datos cuando se procesa una consulta (como hace un RDBMS sistema), una SQL base de datos tipo «No» organiza los datos de manera que su forma en la base de datos se corresponda con lo que se va a consultar. Este es un factor crucial para aumentar la velocidad y la escalabilidad.

• Velocidad de los datos: Amazon Keyspaces escala mediante el aumento del número de particiones físicas disponibles para procesar las consultas y la distribución eficiente de los datos entre dichas particiones. Conocer de antemano cuáles serán las cargas de consulta máximas puede ayudar a determinar cómo deben particionarse los datos para hacer un uso óptimo de la capacidad de E/S.

Después de identificar los requisitos de consulta específicos, puede organizar los datos con arreglo a los principios generales que rigen el rendimiento:

• Agrupar los datos relacionales.   Cuando hace 20 años se investigaba cómo optimizar las tablas de direccionamiento, se descubrió que la "cercanía de referencias" era el factor más importante para acelerar el tiempo de respuesta y consistía en mantener los datos relacionados reunidos en el mismo lugar. En la actualidad, esto también es cierto en SQL los sistemas No System, donde mantener los datos relacionados muy cerca tiene un impacto importante en el costo y el rendimiento. En lugar de distribuir los elementos de datos relacionados en varias tablas, debe mantener los elementos relacionados en su SQL sistema No lo más juntos posible.

  Como regla general, en una aplicación de Amazon Keyspaces debería mantener el menor número posible de tablas.

  Las excepciones son aquellos casos en los que hay implicados datos de serie temporal de gran volumen o conjuntos de datos que tienen patrones de acceso muy diferentes. Normalmente, basta una sola tabla con índices invertidos para permitir que, a través de consultas simples, se creen y recuperen las estructuras de datos jerárquicas y complejas que necesita la aplicación.

• Utilizar un orden de clasificación.   Los elementos relacionados pueden agruparse y consultarse de forma eficaz si su diseño de claves hace que se ordenen juntos. Esta es una importante estrategia de no SQL diseño.

• Distribuir consultas.   También es importante que no haya una gran cantidad de consultas concentradas en la misma parte de la base de datos, donde podría sobrepasarse la capacidad de E/S. En su lugar, debe diseñar claves de datos que distribuyan el tráfico lo más uniformemente posible entre las particiones y eviten la creación de "puntos calientes".

Estos principios generales se traducen en unos patrones de diseño comunes que puede utilizar para modelar los datos de forma eficaz en Amazon Keyspaces.