Bienvenido de nuevo a la Academia de retroceso en esta conferencia.
Vamos a tener una mirada en profundidad a Amazon Dynamo D. SI..
Comenzaremos por echar un vistazo a sus características y luego veremos algunas
cosas más avanzadas sobre cómo funcionan los atributos de los elementos de tablas y las claves principales y cómo los usamos y veremos los
índices y cómo pueden ser solía acelerar el acceso a nuestros datos y también las diferencias entre consultas y
escaneos.
Bueno, mire cómo podemos obtener el máximo rendimiento de nuestras tablas
de dynamo DB. SI. flujos donde podemos tener flujos de cambios en nuestra base de datos y disparadores
que pueden basarse en cambios en nuestra base de datos.
Y finalmente veremos la dinamo D. SI. El acelerador que nos ayuda a aumentar
de forma masiva el rendimiento de nuestra tabla db dynamo y reducir la latencia de respuesta
a las solicitudes de dynamo IDB ofrece una serie de ventajas significativas sobre otros servicios como RDX.
Se escala sin problemas cambiando el rendimiento de aprovisionamiento de su tabla y puede hacerlo
a través de núcleos de interfaz de línea de comando o API o mediante uno de los
muchos kits de desarrollo de software que puede consultar sobre cualquier atributo utilizando índices secundarios que proporcionarán un rendimiento de
alta velocidad a sus datos admite la replicación de regiones cruzadas, su esquema es menos diferente a una base de datos secuela, admite
una gran consistencia en las lecturas, también tiene contadores atómicos y actualizaciones condicionales para los cambios y hablaremos más sobre eso en
las próximas diapositivas.
También hay una versión descargable disponible que puede ejecutar en su
escritorio localmente, lo que es ideal para fines de prueba, entonces, ¿por qué elegiría una secuela sobre Eskew?
Y eso realmente depende de su aplicación y de lo que busca obtener de su infraestructura.
Así que Eskew Well está optimizado para el almacenamiento.
No hay una secuela optimizada para la velocidad, por lo que si el espacio de almacenamiento es un problema para usted, lo mejor es
ir con Eskew Bueno, si la velocidad es un problema para usted, lo mejor es no tener secuela porque muchas
veces la información en una base de datos sin secuela puede repetirse s los datos de un año se normalizan, tiene relaciones
entre los datos, por ejemplo, puede tener una persona y puede tener una relación entre
esa persona y una determinada dirección o un cierto número de teléfono que no ocurre sin secuela, se
normaliza D y es más una estructura jerárquica.
Q Well tiene uniones y reglas, por lo que los datos nuevamente son conjuntos, por ejemplo, la persona y la
dirección, y hay reglas entre esos datos antiguos Eskew, ninguna secuela no tiene eso.
El idioma esquimal es muy rico.
Ninguna secuela se basa en consultas y escaneos simples.
Entonces, si está buscando algo fuera de la caja que pueda ejecutar consultas muy ricas, tendrá que ir
con Eskew l Eskew L. escala verticalmente.
Muy bien.
Ninguna secuela escala horizontalmente, lo que por supuesto es una ventaja.
P Bueno, es adecuado para el procesamiento analítico en línea o la superposición, y eso se
debe a que Eskew un lenguaje es rico y hay muchas relaciones entre esos datos, ninguna secuela es adecuada para
el procesamiento de transacciones en línea o LCP y eso es porque tiene esa alta velocidad D normalizada Las tablas de
estructura de datos son nuestra colección de datos o también podríamos llamar a eso una base de datos, por ejemplo, los datos de un cliente.
Ahora esas tablas contendrán elementos, ahora son similares a las filas o registros como lo haría en
Eskew.
Entonces, como podemos ver allí, tenemos una mesa de libros y allí tenemos una serie o tenemos dos registros allí.
Así que tenemos un registro allí con un ISP y otro registro allí con un número ISBN diferente.
Ahora los elementos pueden tener uno o más atributos y podemos ver que podría ser el cliente I. RE. primer nombre
etc.
Ahora, cuando miramos esa tabla de libros, podemos ver que hay un número
de atributos para esa tabla de libros y tenemos tablas de ficción de conteo de páginas de dimensiones de precios de autores de títulos ISBN.
Deben definir una clave primaria como un identificador único de esos elementos.
Y en esta situación, hemos resaltado en verde una clave principal para libros que sería ISBN porque es
un yo único. RE. de ese libro claves primarias.
Pueden ser particiones o también se llaman hash o partición y clasificación.
Que tienen una clave de partición y una clave de clasificación que también se denomina hash y range
en nuestra tabla.
Definimos una clave principal y en esta situación tenemos el ISBN como clave principal para la tabla de ese libro,
pero también podemos agregar índices secundarios y lo que pueden hacer es que pueden acelerar el acceso a nuestros datos en
función de uno de esos atributos .
Por lo tanto, le permiten consultar utilizando una clave alternativa y además de las claves principales.
Entonces, tenemos el ISBN, pero también podríamos querer buscar por título.
Usted especifica qué atributos desea copiar o proyectar en este índice.
No son esenciales, pero pueden proporcionar una mayor flexibilidad y acelerar en gran medida
la consulta de esos atributos.
Hay dos tipos de índices secundarios, índices secundarios locales y globales, un índice secundario local que tendrá la
misma clave de partición que una tabla.
Entonces, en esta situación, tendrá la misma clave de partición que ISBN, pero tendrá una clave de clasificación
diferente.
Por ejemplo, podría usar autores aquí ya que las tablas no
serán las mismas que una tabla, pero tendrá la misma clave de partición que una tabla, un índice secundario
global que tendrá una clave de partición y una clave de clasificación que son diferentes
de la tabla para que pueda ver aquí que el índice secundario global tiene títulos y autores, pero no incluye ISBN, puede definir hasta un
total de 25 índices secundarios y eso será un máximo de 20 índices globales y 5 en un máximo de cinco secundarios índices para un total de 25.
Hay dos formas en que puede buscar sus datos dentro de una tabla.
El primero ha sido una consulta y generalmente es la más eficiente y busca un
rango específico de claves que satisfagan un conjunto específico de condiciones.
Entonces, lo que realmente están buscando es limitado.
Esos resultados también se pueden filtrar después.
Eventualmente es consistente, pero también puede solicitar una lectura muy consistente.
El siguiente es un escaneo y ahora ese escaneo escanea toda la tabla o el índice secundario y luego filtra esos resultados luego, por
lo que está pasando por muchos más datos y es por eso que no es tan eficiente como
una consulta.
Eventualmente es consistente, pero nuevamente la lectura consistente establecida en verdadero devolverá los resultados en
el momento en que se inició la exploración y esto consumirá el doble de las unidades de capacidad y, finalmente, la lectura consistente.
Entonces, si tiene un conjunto de datos grande, la respuesta de un escaneo será significativamente más lenta que una
consulta ahora, digamos que tenemos un elemento que actúa como un contador.
Podría estar contando visitas a un sitio web o enlaces o podría ser desde un dispositivo remoto que está recopilando
datos, por ejemplo.
Y ese es un contador muy popular al que van a acceder varios clientes diferentes.
Y lo que podría suceder y lo que puede causar problemas es cuando varios clientes acceden a la base de datos
e intentan actualizar ese elemento al mismo tiempo.
Y tenemos una situación de conflicto ahora a la izquierda.
Allí podemos ver que para aumentar o disminuir un elemento en nuestra base de datos.
Necesitamos hacer dos operaciones primero, necesitamos obtener el valor actual de ese elemento y luego debemos agregarlo en nuestro
lado del cliente o disminuirlo en dos o lo que sea que sea y luego debemos hacer un elemento de actualización
para escribir eso de vuelta a la base de datos.
Entonces, mirando a la izquierda, podemos ver que tenemos a Alice y Bob Alice.
Ella quiere reducir eso en dos y Bob quiere aumentar el precio en dos.
Entonces, si hacen eso al mismo tiempo, ambos harán una operación de obtención de artículos en la base de
datos y recibirán ese precio de 10.
Ahora Alice, ella va a reducir eso en dos y va a escribir eso en la base de datos ya que
el precio es igual a ocho.
Ahora lo hará antes de que Bob tenga la oportunidad de escribir.
Él está allí, pero Bob todavía piensa que el precio es 10.
Entonces agrega y lo convierte en el precio 12 y luego lo escribe de nuevo en la base de datos.
Entonces, en lugar de que el precio sea 10 porque estamos disminuyendo en 2 y luego sumar
al precio termina siendo 12 porque la operación que Alice ha hecho en realidad se ignora, se sobrescribe con la
operación de Bob.
Entonces, ese es un problema en el que las operaciones de escritura pueden interferir entre sí, ahora los contadores atómicos nos resuelven ese problema porque en lugar de tener
que hacer dos operaciones, obtener un elemento y luego un elemento de actualización, le permiten realizar una operación de elemento de
actualización y simplemente especificar menos dos o más dos o menos lo que sea y más lo que sea y haga eso como una operación y
luego la base de datos o la dinamo D. SI. El servicio calculará qué
es eso.
Por lo tanto, recuperará el precio actual y lo cambiará según disminuya o aumente
el precio.
Y lo escribirá en la base de datos.
Entonces, a la derecha, podemos ver que si Allison Bob golpea eso al mismo tiempo o bastante
bien, el que sea más rápido obtendrá su operación primero, por lo que la otra derecha se retrasará hasta que
se complete la primera.
Entonces, si Alice llega allí un poco antes que Bob, entonces la operación de Alice irá primero.
Entonces ella cambiará el precio a ocho y luego la operación de Bob vendrá después de eso y él
aumentará y luego el precio terminará en 10.
Entonces, las dos operaciones no chocan, Alice va primero porque ella entró un poco más rápido.
Y luego Bob entra después de eso.
Ahora, eso no significa que esto sea perfecto y, a veces, puede salir mal porque, aunque no estamos haciendo dos operaciones, no tenemos
que obtener un elemento y luego un elemento de actualización, no estamos haciendo dos llamadas
como tales.
Todavía estamos leyendo y luego escribiendo de nuevo en la base de datos y eso es perfectamente contradictorio, aunque es
muy poco probable que pueda fallar y no vamos a saber si su operación de actualización
fue exitosa o si no fue exitosa o qué Terminamos con.
Si tenemos esa operación fallando, los contadores atómicos son excelentes para cosas que están agregando estadísticas que serán
geniales para los contadores de sitios web y todo ese tipo de cosas, pero imagínense si este precio era
para un sistema de contabilidad o si fuera el saldo de la cuenta del sistema contable de alguien que creará un
problema porque debe ser perfecto.
Entonces, los contadores atómicos no los usas donde requieres lo que llamamos cumplimiento ácido y
ahí es donde tendríamos una alta precisión de nuestros datos para que los contadores atómicos sean una operación de elemento de actualización
que incremente o disminuya el valor de un atributo y lo hace sin interferir con
otras solicitudes correctas.
Por lo tanto, esos derechos se aplicarán en el orden en que se reciben.
Entonces, si uno viene antes que el otro, el primero se irá y luego el otro se retrasará hasta
que haya terminado para que no interfieran entre sí.
Es muy bueno para aplicaciones de contador no críticas como el contador de un visitante, pero el contador puede incrementarse cada vez
que llame al elemento de actualización y eso es si la llamada fue exitosa o no.
Por lo tanto, puede obtener una situación en la que no recibió una devolución de llamada 200 o una devolución de llamada exitosa
de esa llamada, pero la operación real puede haber ocurrido y no sabrá exactamente por qué eso falló o cuál sería
el resultado final de eso estado.
Por lo tanto, debe asegurarse de que no se use para sistemas que requieren una alta
precisión de sus datos para superar los problemas con la obtención y actualización estándar y con contadores atómicos cuando varios
clientes intentan y actualizan el mismo elemento, puede aprovechar las actualizaciones condicionales y lo que
hacen es que pondrán una condición en esa actualización y si esa condición es verdadera, esa actualización continuará.
Si esa condición no es verdadera, entonces esa actualización no continuará.
Entonces, lo que puede hacer es poner una condición en esa actualización que diga que si el precio no cambia, continúe
con esa actualización.
Pero si el precio ha cambiado desde la primera vez que recibió el artículo, esa actualización fallará con gracia y luego
podrá volver y hacer esa llamada nuevamente hasta que tenga éxito.
Entonces, mirando a la derecha, donde Bob y Alice obtienen el artículo y obtienen precios iguales a
10 y lo hacen al mismo tiempo.
Pero Alice es un poco más rápida al obtener su artículo de actualización antes de Bob, de
modo que el precio cambiará de diez a ocho porque ella disminuyó eso en dos ahora Bob viene después de eso
y agrega dos al precio de diez ahora porque hay un Condición en la actualización de Bob que si el precio no ha cambiado.
Entonces, cuando ese derecho o la operación del elemento de actualización pasa por esa condición, fallará porque el precio ya
no es 10.
Ahora son las ocho.
Y entonces esa operación fallará.
Y luego Bob puede regresar y rehacer esa operación hasta que tenga éxito y no haya enfrentamientos.
Así es como superas los problemas con Dynamo D. SI..
Si tiene aplicaciones realmente críticas, pero si no es crítica y desea la forma más rápida de
actualizar un elemento, busque un contador atómico
para usar una actualización condicional.
Debe tener una operación de actualización con una expresión de condición asociada a eso.
Si la expresión de condición se evalúa como verdadera, la operación tendrá éxito.
De lo contrario, la operación fallará correctamente y puede volver a enviarla e intentarlo nuevamente.
Es ideal para aplicaciones críticas que requieren una alta precisión de esos datos.
Por ejemplo, si tiene un sistema financiero o un sistema de planificación de recursos
empresariales que necesita ser perfecto para ayudar a reducir el costo de almacenar datos antiguos e irrelevantes, podemos adjuntar un atributo de tiempo de
vida a un artículo.
Entonces, lo que eso hace es definir cuándo caducará un elemento de una tabla y, en un trabajo en segundo plano, comprobará la
actualización de la apertura TTL o el atributo de tiempo de vida de esos elementos para ver si han caducado.
Y si han expirado, los eliminará de la tabla.
También los eliminará de cualquier índice secundario.
Por lo tanto, es una excelente manera de reducir el costo indirecto de restaurar esos datos irrelevantes cuando creamos una tabla
y un índice, necesitamos especificar cuál es el rendimiento aprovisionado o la capacidad que necesitamos de esa
tabla o ese índice.
Y esos se definen por separado para la tabla y sus índices.
Los clientes también pueden comprar la capacidad reservada de dynamo DB.
Por lo tanto, hay dos parámetros de rendimiento aprovisionados que debemos definir.
Por lo tanto, una unidad de capacidad de lámina 1 Unidad de capacidad de lámina representa una lectura muy consistente por segundo
o dos lecturas finalmente constantes por segundo para artículos de hasta cuatro kilobytes de tamaño.
Por lo tanto, si tiene algo de hasta cuatro kilobytes de tamaño, entonces necesita una unidad de nueva capacidad.
Si tiene cinco tal vez en tamaño, entonces necesitará alcanzar unidades de capacidad para cubrir eso porque
lo ha excedido en k de tamaño.
Tenemos unidades de capacidad correctas ahora una unidad de capacidad correcta.
Representa un derecho por segundo para artículos de hasta 1 k de tamaño.
Ahora los índices secundarios requieren unidades de capacidad adicionales que necesitan uno para escribir en
la tabla y otro para escribir en el índice, debe tenerlo en cuenta en la
siguiente diapositiva. Echemos un vistazo a algunos ejemplos de cálculo para esto. un vistazo a algunos ejemplos de cómo
funciona esto.
Por lo tanto, si tenemos un tamaño de elemento de 5 k que estamos leyendo y necesitamos 50 lecturas consistentes eventualmente por segundo
que debemos planear para eso.
Por lo tanto, calculamos nuestro rendimiento aprovisionado en función de esto.
Así que requerimos leer unidades porque una unidad de capacidad de lectura es de cuatro K, así que tenemos 5 K allí.
Eso requerirá leer unidades de capacidad para cubrir ese tamaño de artículo de 5 K.
Por lo tanto, requerimos 50 lecturas finalmente consistentes, por lo que eventualmente las lecturas consistentes requerirán
la mitad de la cantidad de unidades de capacidad que las lecturas fuertemente consistentes.
Entonces, lo que tenemos allí es dos multiplicado por 25.
Por lo tanto, debemos planificar una capacidad de suministro de 50 unidades de lectura.
Entonces, el siguiente que tienen allí es dos tamaños de elemento K y 50 requerían lecturas muy consistentes por segundo
esta vez.
Entonces, las dos K estarán debajo de las cuatro debajo de las cuatro K para una unidad Reid.
Por lo tanto, solo necesitamos una unidad Reid para eso, pero tenemos 50 lecturas muy consistentes requeridas.
Entonces eso se quedará en 50 porque necesitamos el doble de la cantidad que normalmente tendríamos eventualmente.
Entonces, eso será una vez por 50, así que nuevamente será 50.
Unidades de capacidad de Reid que necesita y eso se debe a que, aunque el tamaño de nuestro artículo es mucho
más pequeño, hemos pasado por Reid más consistentes, que son el doble del requisito que los
Reid eventualmente consistentes, así que veamos la planificación de la capacidad para los derechos.
Así que tenemos aquí diez puntos cinco K que vamos a escribir y vamos a
necesitar 50 REIT por segundo.
Por lo tanto, un K correcto es una unidad de capacidad correcta.
Entonces diez punto cinco K requerirá once de esas unidades de capacidad correctas y necesitamos eso en 50.
Watts necesarios disturbios por segundo.
Eso nos da un total de 550 unidades de capacidad correctas que debemos planificar en
nuestra
dinamo de rendimiento aprovisionado D. SI. los flujos son un flujo ordenado
de información sobre los cambios que se han realizado en los elementos de una tabla db de dynamo. Consiste en registros de flujo que se
crean cada vez que la aplicación crea actualizaciones o elimina elementos en esa tabla y tiene un número de secretos asignado y estos
registros de flujo se organizan en grupos o fragmentos de registros y esos registros de flujo dentro de un fragmento se eliminan automáticamente después
de 24 horas.
Esto le brinda una buena oportunidad para implementar el registro o implementar algo
que pueda desencadenar una dinamo D. SI. disparador para alertarlo sobre algo o para hacer algún tipo de cambio en su aplicación.
Ahora podemos usar una dínamo D. SI. transmitir para implementar un desencadenador basado en algo
que le sucede a nuestra base de datos para que sean activados por actualizaciones de nivel de elemento en esa tabla db de dinamita.
Y al hacerlo, puede invocar una función de tierra que luego puede hacer otra cosa, podría hacer un registro en
un segmento de entrada, podría implementar una notificación SNF que podría alertarlo sobre algún problema allí
y asociar esa función lambda a esa secuencia y eso implementará un proceso automático para que eso suceda siempre
que se realicen actualizaciones a nivel de elemento en su dynamo DP table
dynamo D. SI. acelerador o Dex para abreviar.
Es un estuche de memoria totalmente administrado y altamente disponible para Dynamo D. SI..
Es similar a una caja de plástico donde obtiene información de una caja de memoria.
No va a volver a un disco duro para obtener esa información.
Y al hacerlo, dará un aumento de rendimiento de hasta 10 veces en sus lecturas.
Entonces puede ver que tenemos nuestra aplicación y también tenemos un cliente dex en
la aplicación.
Y eso tendrá un caso de elemento y un caso de consulta.
Entonces, para los elementos solicitados regularmente o las consultas solicitadas regularmente, se ubicarán en ese Dax en el estuche de memoria
y eso volverá directamente a su aplicación sin interferir de ninguna manera con Amazon
dynamo D. SI.
entonces el proceso para leer una dinamo D. SI. El caso del acelerador es el siguiente.
Primero, su aplicación intentará leer los datos del caso DAX si lo encuentra allí si recibe un
caso, saltará al paso cuatro allí y simplemente devolverá ese valor a la aplicación.
Pero si no hay una mierda de caso y esos datos no están en el acelerador de dynamo DB, entonces
el DAX volverá a dynamo D. SI. y obtenga ese par de valores clave que
se requiere para que el par de valores clave se vuelva a llenar en el acelerador DAX y luego finalmente se devuelva a la aplicación.
Y así, ahora está ubicado en el acelerador DAX.
Ahora, el proceso para escribir a través de un caso Dax comienza con la aplicación escribiendo a ese Dax en el punto, el DAX luego escribe
un par de valores clave en dynamo DB o en el dynamo D. SI. tabla cuando eso tiene éxito, ese par de valores
clave se envía de vuelta al acelerador de dinamo DB que luego se completará en su caso y,
finalmente, el proceso DAX devolverá una llamada exitosa, por lo que ahora se inicia el proceso para escribir a través de un
caso dex con la aplicación escribiendo en ese punto final de Dax, el DAX luego escribe un par de valores
clave en dynamo DB o en la dynamo D. SI. tabla cuando eso tiene éxito, ese par
de valores clave se envía de nuevo al acelerador dynamo DB que luego
se completará en su caso y, finalmente, el proceso DAX devolverá una llamada exitosa.
Así que eso nos lleva al final de la conferencia que viene a continuación, vamos a tener un laboratorio sobre Dynamo D. SI.
Como laboratorio bastante avanzado, cargaremos datos a Dynamo IDB y consultaremos esos datos.
Así que espero verte en ese.