Es bastante simple si conoce cosas básicas sobre HTTP y la base de datos.
Caché – Caché – Caché
La mayoría de los sitios web funcionan mal cuando no usan caché, existe un gran beneficio del almacenamiento en caché en cada etapa, servidor, navegador, almacenamiento en caché en la página. Los golpes en el servidor para cada solicitud HTTP y, posteriormente, los golpes en la base de datos para cada solicitud tienen un diseño deficiente.
- ¿Cómo se puede ser bueno para resolver problemas de algoritmos / programación? Soy un principiante, y me sugirieron que leyera el libro CLRS para aprender sobre algoritmos.
- ¿Cuál es la diferencia entre la estructura de datos y la base de datos para almacenar datos?
- Si quiero resolver problemas del mundo real, ¿qué debo hacer, encontrar esos problemas y luego aprender las estructuras de datos y algoritmos requeridos o viceversa?
- ¿Cuál es la estrategia de divide y vencerás? Escribe un algoritmo para encontrar x a la enésima potencia usando el método de dividir y conquistar.
- ¿Existe un libro o sitio web que describa los problemas y luego le solicite la estructura de datos / algoritmos más apropiados necesarios para resolver el problema?
La regla simple es que si va a leer algo más de una vez en su unidad de lógica de negocios, debe almacenarse en caché en el almacenamiento local dentro de su unidad de lógica de negocios.
Si algo no ha cambiado, nunca se debe volver a solicitar al servidor.
Vencimiento de caché más largo
Mantenga un campo de versión en su objeto de base de datos lógica, por ejemplo, si se trata de una lista de precios o algo así y solicita solicitudes de URL de caché junto con la etiqueta de versión, cuando llegue una nueva lista, la URL debe incluir una nueva etiqueta de versión, esto eliminará la necesidad de validación de caché .
Escribe uno lee muchos
La réplica de lectura múltiple y la base de datos única para la transacción es lo suficientemente buena como para manejar millones de transacciones por día. Recuerde, las transacciones como la reserva de boletos deben cumplir con ACID y ningún NoSQL lo ofrece.
Los servidores de lectura NoSQL típicos deberían actuar principalmente como Cache Proxy para entregar datos frecuentemente no modificados a los clientes. Para mantener la coherencia, todos los datos solo deben almacenarse en RDBMS con conformidad con MVCC ACID, sin embargo, excepto Cache Proxy, ninguna otra máquina debería leer de la base de datos.
CDN
Mueva los datos NoSQL y los recursos de Script / Imagen a CDN. Lo más probable es que las listas de configuración, el contenido de descripción, etc. se almacenen en NoSQL en lugar de en la base de datos. La base de datos solo debe almacenar datos financieros críticos. Por ejemplo, la descripción, los términos y condiciones, etc., todo el texto grande debe moverse del campo de la base de datos y debe colocarse en NoSQL servido a través de CDN.
Escalado vertical antes del escalado horizontal
Las personas a menudo comienzan a implementar la escala horizontal sin darse cuenta de que primero hay suficiente espacio para la escala vertical. Acceder a cada solicitud en la base de datos con el clúster de base de datos es un diseño pobre.
Asegúrese de haber aislado todas las solicitudes no transaccionales a CDN y otro Cache Proxy y luego determine la cantidad real de transacciones que afectan a la base de datos.
Solo cuando sus transacciones sean más altas y no haya margen de escala vertical, aplique la escala horizontal y cree un clúster de base de datos. Este es un paso importante porque el escalado horizontal de la base de datos es más costoso que el Proxy CDN / Caché. El escalado horizontal para la base de datos suele ser 10 veces o incluso más costoso en comparación con la implementación del Cache Proxy / CDN adecuado.
