Nuestra misi\u00f3n no es solo construir una soluci\u00f3n s\u00f3lida, sino tambi\u00e9n invertir en investigaci\u00f3n y desarrollo e ir m\u00e1s all\u00e1 de los l\u00edmites de las arquitecturas tradicionales para escalar mejor y abordar nuevos casos de uso desafiantes, como procesar y analizar una gran cantidad de datos en tiempo real. .<\/p>\n
Cada soluci\u00f3n tiene sus propias ventajas e inconvenientes, especialmente teniendo en cuenta que a menudo ejecutamos sistemas en redes y discos heredados y mantenemos bajo control los costos de CPU y memoria. Sin remontarnos a la era de Alan Turing, las caracter\u00edsticas de los problemas que aborda la soluci\u00f3n Moneythor se han clasificado desde hace mucho tiempo en dos categor\u00edas distintas: procesamiento de transacciones en l\u00ednea (OLTP)<\/strong> y procesamiento anal\u00edtico en l\u00ednea (OLAP)<\/strong>.<\/p>\n La soluci\u00f3n Moneythor ofrece un motor implementado entre los sistemas de registro de las instituciones financieras y sus canales digitales para impulsar experiencias atractivas y personalizadas para los usuarios finales. Por lo tanto, se espera que nuestra soluci\u00f3n pueda digerir un gran volumen de datos en tiempo real de forma confiable y escalable.<\/p>\n Hist\u00f3ricamente, se ha demostrado que los sistemas de gesti\u00f3n de bases de datos relacionales (RDBMS) son una forma eficiente y confiable de implementar dicho sistema OLTP, ya que tambi\u00e9n ofrecen el beneficio extremadamente valioso de ser compatibles con ACID.<\/p>\n Nuestra soluci\u00f3n tambi\u00e9n incluye Gesti\u00f3n de finanzas personales (PFM)<\/a> funciones impulsadas por API que pueden crear, leer, actualizar y eliminar objetos personalizados como presupuestos, objetivos, suscripciones y m\u00e1s. Por lo tanto, es crucial que los canales digitales que llaman a nuestra API puedan confiar incondicionalmente en sus respuestas y, para ello, nuestra soluci\u00f3n aprovecha en gran medida la Atomicidad<\/strong>, Consistencia<\/strong>, Aislamiento<\/strong> y Durabilidad <\/strong>(ACID) propiedades de la base de datos, ya sea un RDBMS o no.<\/p>\n La soluci\u00f3n Moneythor permite la entrega de conocimientos, recomendaciones y empujones basados en datos adaptados a cada cliente. Aqu\u00ed es donde brilla la parte anal\u00edtica de la soluci\u00f3n y permite a nuestros clientes imaginar una amplia gama de empujones contextuales y personalizados para sus clientes.<\/p>\n Este tipo de an\u00e1lisis de datos generalmente se basa en un sistema OLAP optimizado para esa tarea y es donde pueden surgir fricciones al intentar construir una soluci\u00f3n sobre OLTP y OLAP.<\/p>\n Si bien son inteligentes con lo que pueden hacer con los datos, los sistemas OLAP funcionan bien cuando los datos no cambian mucho, lo cual no es un escenario t\u00edpico con una soluci\u00f3n de banca digital que recibe millones de transacciones al d\u00eda, en tiempo real y cuando los datos Se espera que el an\u00e1lisis se realice en ese momento. Adem\u00e1s, los propios usuarios pueden cambiar los datos y esto puede llevar a un resultado completamente diferente cuando se trata de empujones personalizados.<\/p>\n Los sistemas OLAP no est\u00e1n necesariamente dise\u00f1ados con un tiempo de respuesta r\u00e1pido como m\u00e1xima prioridad, mientras que las nuevas experiencias de usuario creadas sobre la API de Moneythor se ofrecen a trav\u00e9s de HTTP y, por lo tanto, son sincr\u00f3nicas. Esperar m\u00e1s de unos segundos para que se renderice una pantalla hoy en d\u00eda parece una eternidad.<\/p>\n Teniendo en cuenta estas limitaciones, la soluci\u00f3n Moneythor aprovecha lo mejor de ambos tipos de sistemas y mitiga sus deficiencias a trav\u00e9s de una arquitectura distribuida con las caracter\u00edsticas siguientes.<\/p>\n i)<\/strong> Cuando los beneficios superan con creces el costo de la redundancia y el procesamiento adicional, los datos en el almac\u00e9n persistente se desnormalizan caso por caso. Esto nos permite continuar procesando datos transaccionales mientras mantenemos bajo control el tiempo de procesamiento anal\u00edtico.<\/p>\n ii)<\/strong> La soluci\u00f3n Moneythor se ubica entre otros sistemas y se integra de forma nativa con plataformas distribuidas de transmisi\u00f3n de eventos. Por ejemplo, Apache Kafka<\/a> es una herramienta muy popular y, junto con la soluci\u00f3n Moneythor, mejora enormemente el rendimiento general y simplifica la implementaci\u00f3n y la escalabilidad, porque ambos sistemas est\u00e1n distribuidos por dise\u00f1o. Si bien las API dependen en gran medida de las propiedades ACID presentadas anteriormente y garantizan una respuesta, cuando se trata de un flujo de mensajes, Kafka y otros generalmente ofrecen 3 modos diferentes de entrega de mensajes: un mensaje puede entregarse o no, un mensaje puede entregarse m\u00faltiples veces, o un mensaje se entrega exactamente una vez. El primer modo es obviamente prohibido cuando se trata de transacciones financieras, y si bien puede resultar atractivo buscar una entrega "exactamente una vez", esto conlleva un costo adicional de rendimiento y complejidad. Por esta raz\u00f3n y porque los mensajes en Moneythor son idempotentes, nuestra soluci\u00f3n se basa en un concepto de entrega de "al menos un" que garantiza que no se perder\u00e1 ning\u00fan mensaje y los consumidores pueden simplemente controlar los duplicados gracias a las banderas idempotentes.<\/p>\n ii)<\/strong> Finalmente, no podemos hablar de sistemas distribuidos sin prestar atenci\u00f3n a la GORRA<\/strong> y PACELC<\/strong> teoremas El primero establece que cualquier almac\u00e9n de datos distribuido s\u00f3lo puede ofrecer dos de las tres garant\u00edas siguientes:<\/p>\n Consistencia<\/strong> (C): cada lectura, cada llamada API en el contexto actual, recibe la versi\u00f3n m\u00e1s reciente de los datos o un error.<\/p>\n Disponibilidad<\/strong> (A): cada solicitud de API recibe una respuesta (sin error), sin la garant\u00eda de que contenga los datos m\u00e1s recientes.<\/p>\n Tolerancia de partici\u00f3n<\/strong> (P): el sistema contin\u00faa funcionando a pesar de que la red descarta (o retrasa) un n\u00famero arbitrario de mensajes entre nodos.<\/p>\n En la mayor\u00eda de los casos, la soluci\u00f3n Moneythor se implementa en un entorno donde solo hay una instancia l\u00f3gica de la base de datos (y este sistema de base de datos generalmente se ejecuta en un cl\u00faster para alta disponibilidad). El n\u00famero de particiones en este contexto es 1, pero ser\u00eda un error imaginar que el sistema podr\u00eda proporcionar coherencia y disponibilidad al mismo tiempo. De hecho, en ausencia de partici\u00f3n, el teorema PACELC refina esas reglas al afirmar que uno debe elegir entre Latencia<\/strong> (Tierra Consistencia<\/strong> (C).<\/p>\n La soluci\u00f3n Moneythor est\u00e1 dise\u00f1ada para escalar verticalmente agregando potencia de procesamiento y horizontalmente agregando instancias adicionales en su cl\u00faster. Tambi\u00e9n expone un conjunto de API de front-end que se utilizan para habilitar funciones interactivas enriquecidas para los usuarios finales con el m\u00ednimo tiempo de respuesta posible para una experiencia de usuario \u00f3ptima.<\/p>\n Por estos motivos, la soluci\u00f3n est\u00e1 optimizada para la latencia. Si bien esta elecci\u00f3n puede parecer contradictoria, especialmente despu\u00e9s de afirmar que las API se basan en el modelo ACID, la definici\u00f3n de coherencia es diferente aqu\u00ed y no se aplica a los datos manipulados y calculados por una API que debe ser coherente pase lo que pase, pero determina cu\u00e1ndo est\u00e1 m\u00e1s arriba. a los datos estar\u00e1n disponibles, inmediata o eventualmente.<\/p>\n Por el contrario, apuntar primero a la coherencia tambi\u00e9n significar\u00eda que el sistema tendr\u00eda que esperar a que se sincronicen muchas instancias en el cl\u00faster antes de devolver una respuesta, ya que la soluci\u00f3n utiliza cach\u00e9s en memoria para acelerar el procesamiento y los tiempos de respuesta de la API. A pesar de contar con la mejor red y CPU de su clase, ser\u00eda extremadamente dif\u00edcil garantizar tiempos de respuesta de primera clase en ese caso.<\/p>\n B\u00e1sicamente, existen principios simples que se pueden implementar para reducir dr\u00e1sticamente el riesgo de leer datos no sincronizados. Un ejemplo es un equilibrador de carga configurado correctamente que enruta las solicitudes en el cl\u00faster a la misma instancia donde los datos para el contexto actual ya se procesaron y almacenaron en cach\u00e9.<\/p>\n Crear una soluci\u00f3n altamente escalable y en tiempo real que combine datos transaccionales y anal\u00edticos es una compensaci\u00f3n entre las caracter\u00edsticas que se pueden proporcionar, cu\u00e1les son las expectativas de tiempos de respuesta y, por supuesto, el costo de implementar y operar dicho sistema.<\/p>\n Las arquitecturas distribuidas y descentralizadas pueden ser complejas de construir y es necesario comprender sus caracter\u00edsticas para cumplir sus promesas. Al mismo tiempo, la tecnolog\u00eda est\u00e1 evolucionando y la inform\u00e1tica de alto rendimiento es cada vez m\u00e1s accesible, especialmente con las plataformas en la nube. Estas son las razones por las que hemos elegido tomar esta direcci\u00f3n, lo que ahora nos permite satisfacer con \u00e9xito las necesidades de personalizaci\u00f3n basada en datos de los bancos digitales y las instituciones financieras de todos los tama\u00f1os.<\/p>\n Para obtener m\u00e1s informaci\u00f3n sobre la soluci\u00f3n Moneythor y nuestra tecnolog\u00eda, por favor Cont\u00e1ctenos<\/a>.<\/p>\n\tOLTP<\/h2>\n
\n
OLAP<\/h2>\n
Sistemas distribuidos<\/h2>\n
Conclusi\u00f3n<\/h2>\n
![\"Suscr\u00edbete](\"https:\/\/www.moneythor.com\/wp-content\/uploads\/2024\/02\/Article-CTA-NEW-BRANDING.png\")
\t\t\t\t\t\t\n\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/a>\t\t\n