Improving Speed, Scalability, and the Customer Experience with In

WHITE PAPER

Improving Speed, Scalability, and the Customer Experience with In-Memory Data Grids A GridGain Systems In-Memory Computing White Paper Improving Speed, Scalability, and the Customer Experience with In-Memory Data Grids WHITE PAPER

One of the biggest challenges for customer- and partner-fac- THE CHALLENGES WITH EXISTING ing applications is keeping up with ever-increasing database AND NEW APPLICATIONS, APIS, AND loads. The 10-1000 times growth in data transactions, que- ANALYTICS ries, and size over the last decade has overwhelmed many databases. The most common solutions are vertically scaling The most common reason for the exponentially growing writes with expensive hardware and handling query loads loads on existing applications is digital transformation. The with replication. But both solutions have their limitations. reason for these increased loads is readily apparent. Consum- ers demand a faster, more convenient customer experience More and more, companies are instead using in-memory anytime, anywhere, on any device. When consumers do get data grids (IMDG) or broader in-memory computing (IMC) this new experience, they use it to access data much more platforms as a solution. An IMDG adds in-memory speed frequently But delivering this experience requires a combina- and horizontal scale to existing applications. This solution tion of real-time data, analytics, and automation. slides in-between the applications and their databases, and keeps all the data in-memory and in-sync with the data- Delivering an improved, more-digital customer experience is base. An IMC platform combines the capabilities of an IMDG critical to business survival. Consumers will quickly abandon with in-memory database (IMDB), streaming analytics, and a vendor to get a better experience someplace else. An Aber- machine and deep learning. It allows the same technology deen study found that companies with a strong omnichannel and data to be reused across projects. engagement retained 89 percent of their customers. Those with a weak strategy retained 33 percent. Digital transfor- Many companies first adopted an IMDG to fix a point per- mation has spread beyond sales and services to all parts of formance and scalability problem with a single application. a company. It also helps improve core operations and supply But over time, these companies ended up extending their chain efficiency, by leveraging the Internet of Things (IoT), new IMDG and IMC platforms to create a new real-time data for example. layer for customer facing applications. IMC not only provided the speed and scale, but it also helped with their digital But delivering a better customer experience, and supporting transformation because it brings together data from dispa- these loads, is not easy. rate systems and makes it easily accessible. First, existing applications need more speed and scale. This white paper provides an overview of IMDGs, as well as Over the last decade, query and transaction volumes have IMDG functionality as part of an IMC platform. Its prime focus grown 10 to 1000 times. Data has grown 50 times. End is on how companies implement IMDGs to improve speed consumers now expect sub-second response times, every and scale for existing applications, and how this is the first time, which is easily 1000 times faster than the hours or step in their larger digital transformation. It also introduces days that many traditional processes traditionally took to Apache® Ignite™ and the GridGain® in-memory computing complete. This 10 to 1000 times growth in speed and scale platform, and how companies use Ignite and GridGain first usually overwhelms existing applications first, because new as an IMDG, and then as a broader IMC platform for digital applications need to access the data in existing applications. transformation across new and exisiting applications, APIs, But these legacy applications and their underlying databases and analytics. were not originally designed to handle this growth.

Second, new applications and APIs also need speed and IMPLEMENTING HTAP AND IMC AS THE scale. Even if existing applications could handle the growth, BRIDGE TO DIGITAL BUSINESS they would only address part of the end-to-end speed and scale challenges. Delivering sub-second response times, Several companies have added both speed and scale to every time, from a mobile or web app requires lowering the existing applications, and delivered a more personalized, total end-to-end latency of: responsive, and real-time customer experience. They have also delivered new capabilities that are much more flexible • The connection from the customer application over the Internet. to change, and added the analytics and decision automation needed to improve the customer experience. • Several layers and network hops of security, APIs, and microservices. Solving these problems requires a major shift in a company’s focus on the customer. But it also requires adopting new • A middleware layer that eventually accesses existing appli- technologies that collect a lot more information and perform cations, which in turn access databases. analytics and decision automation during each transaction It also requires much greater scale than the existing appli- or interaction. Gartner and others call this approach hybrid cations. Legacy applications mostly use “transactional” data, transactional/analytical processing (HTAP). which is about 10 percent of the total data saved by a Many of the companies addressing improving customer company. It is the newer applications and APIs that use the experience implemented HTAP using an in-memory comput- majority data available today, or “Big Data.” ing (IMC) solution. Whatever technology is used for HTAP, it Third, new applications and APIs need to be much more must be able to handle the 10-1000 times increase in inter- flexible to change. IT must also deliver new capabilities in actions and 50 times increase in data. By using IMC, they: weeks (or days) in order to compete with the digital leaders. • Performed analytics and automation in real-time during But these new applications and APIs need to access data their transactions and sub-second interactions with cus- and functionality in existing applications, and those existing tomers. applications usually take months or years to change. • Automated decisions to personalize the experience or Fourth, digital business requires real-time analytics and cross-promote products. automation. Transactional and analytical infrastructures have • Proactively addressed a customer issue before it impacted traditionally been separate, with the operational data getting a customer’s satisfaction, purchasing decision, or loyalty. extracted, transformed, and loaded (ETL) over time into data warehouses and data lakes. This worked because existing IMC added the speed, scale, and distributed computing databases could barely support the transactional workloads, needed for real-time, in-process HTAP. analytics were better served by different technologies any- Companies using IMC for HTAP do not have to rip out and way, and most analytics did not need real-time data. But replace their existing applications and databases. Instead, existing analytics infrastructure cannot deliver the real-time they added speed and scalability by sliding an in-memory analytics needed to improve the customer experience. The data grid (IMDG) between their existing applications and analytics and automation required to replace a process that databases, one application at a time. This cost-effective, took hours, days, or weeks with a “one-click” process must incremental approach enables companies to, over time, build run in the same place as the operational applications in order a new in-memory layer for accessing and processing existing to complete during a “sub-second” interaction. and new data. In-memory computing is the foundation that Fifth, delivering this new experience needs to be built allows them to address other challenges as well. It allows incrementally. Most “big bang” IT initiatives fail. Digital them to combine transactions and services with real-time transformation, and adding speed and scale to applications, analytics over time, and deliver new HTAP applications for must get done incrementally. The architecture and technol- their digital transformations and customer experience initia- ogies used must be flexible enough to be easily added one tives. project at a time.

ADDING SPEED AND SCALE TO EXISTING For an IMDG to be minimally disruptive to an existing appli- APPLICATIONS WITH AN IMDG cation and not require additional coding, it needs to support the application’s way of accessing data. For most applica- Many companies tried to support ever-increasing query and tions, that is SQL (the second most popular developer lan- transaction growth by solving point performance and scal- guage after JavaScript and the most popular language for ability issues one application at a time. For most applica- data access). tions the bottleneck is the database, and the most common An IMDG is minimally disruptive if it can be added as a trans- approach to the issue was scaling vertically with much more parent proxy, one that does not require a change to the expensive hardware. But this approach was never cost effec- application, in between an application and database. That tive or sustainable in the long run. System loads are growing means it must provide JDBC/ODBC drivers to the applica- faster than annual performance and cost improvements for tion that support standard SQL and the full range of ACID any single server, and this growth shows no signs of slowing transactions developers expect to use in a database. The down. IMDG also needs to connect to and pass the same SQL to Many companies turn to in-memory computing (IMC). Com- the database, and keep the data in sync across the IMDG and panies first started with caches: in-memory data stores databases. The best IMDGs do this well. designed to hold frequently-used data for reuse. Traditional It is true that the application and data usually get redesigned caches such as Redis or Memcached implement a “cache to some extent to improve performance and scalability, and aside” pattern, where the cache sits “on the side” of the that over time the SQL and schema might need to be rede- application outside of the connection to the database. signed to improve horizontal scalability or optimize some Using a cache has several challenges: queries. But an IMDG is still the least disruptive approach. • First, a developer must add code to each application that Without SQL support, all the existing SQL in an application populates, queries, and manages the cache. must be ripped out and replaced (usually with a key-value API). • Second, it is up to the application to keep the cache up to date because the cache is “on the side” and out of the path Like a cache, an IMDG adds speed by storing and processing of transactions. This means invalidating and refreshing the data in memory rather than continually retrieving data from cache as soon as the data might be out of date. disk(s) before processing. While hard disk drive (HDD) media • Third, it is hard to scale a cache. When the application speeds are measured in milliseconds, RAM speeds can be does not need “big” data, the cache can reside on the ap- measured in nanoseconds—one million times faster. plication. But big data sets require maintaining a cluster on IMDG scalability comes from distributing data and computing a separate set of servers. In practice, companies end up together horizontally across a cluster of servers (or nodes) managing the data partitioning manually. Soon, the net- with a “shared-nothing” architecture. Data is usually parti- work becomes a bottleneck for moving cached data be- tioned based on data affinity, the relationships across the tween the application code and the cache. data, and how it is used by different workloads. For example, These cache challenges led to the creation of in-memory data in two tables might be partitioned so that any data data grids (IMDG). An IMDG is an in-memory data store that related by a common (foreign) key end up on the same node. usually implements a “read/write-through” cache pattern. It This allows a join of two tables to run as fully distributed sits between an application and database in the path of all SQL where the join first takes place on each node, and then transactions and queries. For each write, it commits it to only the results are sent over the network and aggregated memory and then passes the transaction through immedi- together. The best IMDGs do this automatically instead of ately (“write through”) or eventually (“write behind”). This manually (like many caches). allows the IMDG to keep in-memory data completely in sync with data in the underlying database if it is in the only path to the database as a proxy, and handles all queries directly. An IMDG offloads the entire read workload from the database without the need for cache invalidation and refreshing.

Adding Speed, Scalability and Data-intensive code often needs to be distributed to the data. The simple reason is that the code is smaller to move Analytics at Wellington Management than the data. If you can partition the data and distribute Wellington Management is one of the top 20 global asset the code to each node in such a way that maximizes data management firms in the world, with more than $1 trillion in client being processed locally on each node, and minimizes data assets under management. movement over the network, you can minimize end-to-end Wellington had three major challenges: latency. The combination of a shared-nothing architecture 1. Its current systems were no longer scalable due to an exploding with this form of distributed computing—call collocated growth of financial data. It needed horizontal scalability to computing by some—helps achieve horizontal, linear scal- handle the long-term growth. ability on commodity infrastructure with a lower cost of 2. The 2008 financial crisis resulted in a wave of new financial ownership compared to other approaches. Because there are regulations that resulted in more complexity and risk in existing many developer languages, the collocated computing must systems. be general-purpose. It must support collocating any code, 3. Many more new and complex asset classes have been introduced whether—written in JavaScript, SQL, Java, .Net or C++/C— in the last few years based on customer demand, and there’s a with any data. big need to release new asset classes faster. For companies that implement an IMDG, the combination of rading ortolio Systems Management a true read/write-through data store with distributed SQL, Investment ccounting is the full range of distributed ACID transaction management, Systems oo o ecord Management I and general-purpose collocated computing provides a lower ther egulatory ac ice Compliance risk, cost-effective, and longer term solution than the alter- GridGain In-Memory Computing Platform natives. It provides much better longer-term speed and scale than scaling vertically with hardware. And it usually pays In-Memory In-Memory Streaming Continuous Data Grid Database Analytics Learning Framework for itself: it is much cheaper than buying expensive new racle C hardware and additional database licenses. The other alter- natives, such as rewriting the application or replacing the Wellington’s solution was to deploy its investment book of record database, are more costly and risky. (IBOR) on the GridGain in-memory computing platform. The Wellington IBOR serves as the single source of truth for investor positions, exposure, valuations, and performance. All trading ADDING SPEED AND SCALE ONE transactions and account and back office activity flow through the PROJECT AT A TIME IBOR in real time. An IMDG solves another problem: adopting technology incre- • Horizontal Speed and Scalability: Wellington’s IBOR has mentally. If an IMDG supports SQL and ACID transactions and unlimited horizontal scalability. It uses GridGain’s SQL support to add speed and scalability by sliding in-between Oracle, its can act as a transparent proxy, it is straightforward to adopt system of record, and the applications. The result is at least 10 it one project at a time. In general, an IMDG is very cost times faster performance by adding in-memory computing on effective across projects. top of its Oracle database deployment. An IMDG can be deployed as a single shared cluster that • Use of HTAP: The IBOR is an HTAP system that is used by supports any number of applications. Supporting different portfolio management teams for real-time position, market applications is very similar to supporting multiple workloads value, exposure, and performance analytics; by risk management teams for risk analytics and overall risk management; and by in a single project. Partitioning helps distribute data to sup- compliance teams to ensure, in real-time, that all regulatory port collocated computing. Replicating partitions also helps requirements are met. collocate data, distribute the load, and improve availability Why Wellington chose GridGain and reliability. Some IMDGs can auto-rebalance as nodes

• In-memory computing are added or removed, which provides true horizontal elastic scalability. Some IMDGs also allow nodes, caches, and copies • Horizontally scalable of data to be dedicated to different applications, which help • Supports distributed SQL ensure applications do not impact each other’s performance • ACID compliant (consistent data) or have access to data outside their domain. • Collocates data and computing

• Combines operational and analytical workflows (HTAP)

DELIVERING MUCH GREATER FLEXIBILITY TO CHANGE “WE WANT TO BE A TECH COMPANY The main reason for having a shared cluster is not to save on WITH A BANKING LICENSE.” costs. It is to create a single real-time data and computing — Ralph Hamers, CEO, ING Group layer that merges data across applications and is much more flexible to change. As each new application is added to the IMDG, the data in the application can be accessed and used Creating a Differentiated Banking Ex- in new ways. perience with In-Memory Computing Having a shared cluster makes it easy to provision access to ING wanted to increase their pace of innovation, both to existing data. You can quickly add new nodes, caches, or service changing customer needs and to move beyond copies of the data to support new uses. If additional logic is traditional banking with new services and business models. needed to process the data, it can be deployed outside the Part of the challenge was that core banking services resided application, within the IMDG or as part of a new application on a mainframe that was hard to change. They were also unable to continue to scale their infrastructure and handle or API. increasing loads. Mobile traffic was growing 25 percent per This approach is much faster than directly accessing existing year, and each mobile user interacted seven times more than applications. For one, application teams need to consider a web user. how to handle any additional load on their applications. They Using GridGain, ING added an in-memory computing layer in may also need to consider how to add new logic or merge front of their mainframe and middleware that helped open up and share previously siloed data and functionality across data across applications. An IMDG solves both problems and channels. GridGain not only easily scaled to offload from the helps ensure SLAs can be met. mainframe and handle the growth. It helped cut end-to-end latency to less than 100 milliseconds. It also helped the bank ADDING SPEED AND SCALE TO NEW rapidly create new APIs from microservices for consumers APPLICATIONS AND APIS and third parties, and be first-to-market with new services for the revised Payment Services Directive (PSD2), the Single There are three basic goals of API management as part of Euro Payment Area (SEPA) initiative, and instant payments. any digital business initiative: Watch the ING In-Memory Computing Summit presentation. • Open up existing data and assets as APIs. • Deliver new APIs or any changes in weeks or days, not By the time they experience challenges with speed and months or years. scale, companies often discover that IMDGs are ideally suited for API management and microservices as well. An IMDG • Improve the real-time customer experience and business allows enterprises to: operations. • Add speed and scale incrementally one project at a time. The fourth goal that often gets added later once it becomes an issue, is: • Rapidly open up data for an API. • Deliver 10-1000 times increase in speed and scale. • Embed all the data of API together, in memory, within each API. • Scale horizontally with each API or microservice. This makes an IMDG the ideal data foundation for API management.

ADDING REAL-TIME ANALYTICS AND • Mobile applications that create 7 times or more interac- INTELLIGENT AUTOMATION tions with customers than customers using to non-mobile platforms. Now customers expect an omnichannel experi- The final goal of API management is to improve the customer ence that proactively engages, guides, makes recommen- experience. Customers want a more convenient, real-time, dations, and creates new personalized experiences (like personalized, and responsive experience. They also want a one-click buying). better way to resolve their issues when they happen. • The Internet of Things (IoT) and all the related real-time information and context that help deliver better connected Delivering a better, more-digital experience pays for any IT products and customer experiences as applications respond initiative. One Harvard business school study found that the to device data in real-time. Just think about Google Maps, digital leaders were 50 percent more profitable than the Waze, TripAdvisor, mobile boarding passes, and even basic digital laggards. The main reason for the increased profit- alerting features. ability is increased customer retention, driven by increased • Service management across industries from retail sales customer satisfaction. and services to claims processing or clinical care manage- Do the math. A loyal customer can be twice as profitable ment that require gathering up-to-date information about as a normal customer. That means that even a 20 percent customers and their issues. Analytics or calculations help reduction in churn can double profitability over 5 to 10 years. streamline or automate responses. The benefits to operations are also huge. For example, • Fraud detection that requires analyzing the current behav- predictive maintenance, based on real-time analytics and ior of each “user” and others in real-time, and combining it machine learning, increased revenues by 10 percent for one with historical data and models to detect potential fraud on oil company. an individual or larger scale. Fraud detection increasingly uses streaming analytics or machine and deep learning to Improving the customer experience or business operations improve detection. not only requires adding new channels or new data feeds. It also requires collecting new data that you can use to sense • Risk analytics, whether for trading, portfolio manage- and respond to issues as they happen, in real-time. For ment, loans, insurance, or online betting, that is increas- example, two-thirds of all customer churn is because of poor ingly conducted in real-time to improve business decisions and outcomes. service, not product issues. One study found that only 4 percent of all customers who have had a bad experience give • Regulatory or internal compliance that increasingly re- feedback. 91 percent just leave without saying anything. If quires real-time calculations of overall risk to support au- you catch their problem and fix it in time, 70 percent of tomation. Examples include regulations like Basel III that dissatisfied customers stay. In the case of predictive mainte- emerged following the last financial crisis, the Payment Card Industry (PCI) security standards, or GDPR. nance for the oil company, detecting leading indicators and doing preventative maintenance before a well head failed • Personalization during any web session that requires much increased the overall production levels. more historical and contextual data to be analyzed in real-time. Personalization is based on the customer’s past For most companies, delivering a better, more-digital and current behavior and on the behavior of others as a experience requires more real-time information about the predictor of future intent. customer, product, service, or company. It also requires real- time analytics and actions through automation that move fast enough to make a difference. Every company benefits from implementing real-time analytics and automation. Some of the more common examples include:

anaement ata enter nterrise aa nitrin eicatin Secrity nnectr

in Sementatin ata ae Gden Gate rades rtectin cceeratr nnectr

GridGain Inemry mtin atrm

In-Memory In-Memory Streaming ontinuous ata rid atabase Analytics earning Framework

ransactina ersistence

etr , Incrementa intinime eterens acs ntins acs ecery ecery

Figure 1. Apache Ignite and the GridGain In-Memory Computing Platform APACHE IGNITE AND THE GRIDGAIN IN- unlocked more information for use by other applications on MEMORY COMPUTING PLATFORM a platform with real-time performance at peak loads and always-on availability. As a result, they can develop new GridGain is the leading in-memory computing platform for projects faster, are more flexible to change, and are more real-time business. It is the only enterprise-grade, commer- responsive in ways that have improved their experiences and cially supported version of the Apache® Ignite™ (Ignite) open business outcomes. source project. GridGain includes enterprise-grade security, deployment, management, and monitoring capabilities which ADDING SPEED AND SCALABILITY TO are not in Ignite, plus global support and services for busi- EXISTING APPLICATIONS WITH AN IMDG ness-critical systems. GridGain Systems contributed the code that became Ignite to the Apache Software Foundation and One of the core GridGain capabilities and most common use continues to be the project’s lead contributor. cases is as an IMDG. GridGain can increase the performance and scalability of existing applications and databases by slid- GridGain and Ignite are used by tens of thousands of com- ing in-between the application and data layer with no rip- panies worldwide to add in-memory speed and unlimited and-replace of the database or application and without major horizontal scalability to existing applications, and then add architectural changes. HTAP to support new initiatives to improve the customer experience and business outcomes. With GridGain, companies have:

In-Memory In-Memory Streaming Continuous • Improved speed and scalability by sliding GridGain in-be- Data Grid Database Analytics Learning Framework tween existing applications and databases as an IMDG with no rip-and-replace of the applications or databases. Key-Value ANSI-99 SQL ACID Transactions

• Improved transactional throughput and data ingestion by Compute and Service Grid leveraging GridGain as a distributed IMDB. • Improved the customer experience or business outcomes In-Memory Data Store by adding HTAP that leverages real-time analytics, streaming analytics and continuous learning. GridGain customers have been able to create a new shared in-memory data foundation. This single system of record RDBMS NoSQL Hadoop for transactions and analytics enables real-time visibility and action for their business. With each project, they have Figure 2. GridGain as an In-Memory Data Grid (IMDG)

This is because GridGain supports ANSI-99 SQL and ACID Computing (HPC) applications as well as a host of real-time transactions. GridGain can sit on top of leading RDBMSs HTAP applications. including IBM DB2®, Microsoft SQL Server®, MySQL®, Ora- GridGain has implemented all of its built-in computing on cle® and PostgreSQL® as well as NoSQL databases such as the GridGain Compute Grid, including GridGain distributed Apache Cassandra™ and MongoDB®. GridGain generates the SQL as well as the GridGain Continuous Learning Framework application domain model based on the schema definition for machine and deep learning. Developers can write their of the underlying database, loads the data, and then acts as own real-time analytics or processing in multiple languages, the new data platform for the application. GridGain handles including Java, .NET and C++, and then deploy their code all reads and coordinates transactions with the underlying using the Compute Grid. database in a way that ensures data consistency in the database and GridGain. By utilizing RAM in place of a disk-based Collocation is driven by user-defined data affinity, such as database, GridGain lowers latency by orders of magnitude declaring foreign keys in SQL DDL (data definition language) compared to traditional disk-based databases. when defining schema. Collocation helps ensure all data needed for processing data on each node is stored locally ADDING REAL-TIME ANALYTICS AND either as the data master or copy. This helps eliminate the HTAP WITH MASSIVELY PARALLEL network as a bottleneck by removing the need to move large PROCESSING (MPP) data sets over the network to applications or analytics. Once GridGain is put in place, all of the data stored in exist- ADDING DEEPER INSIGHTS AND ing databases or in GridGain is now available in memory for AUTOMATION WITH STREAMING any other use. Additional workloads are easily supported by ANALYTICS AND CONTINUOUS LEARNING GridGain with unlimited linear horizontal scalability for real- time analytics and HTAP. The capabilities GridGain supports are not just limited to real-time analytics that support transactions. GridGain is also GridGain accomplishes this by implementing a general pur- used by the largest companies in the world to improve the pose in-memory compute grid for massively parallel pro- customer experiences or business outcomes using streaming cessing (MPP). GridGain optimizes overall performance by analytics and machine and deep learning. These companies distributing data across a cluster of nodes, and acting as a have been able to incrementally adopt these technologies compute grid that sends the processing to the data. This using GridGain to ingest, process, store and publish stream- collocates data and processing across the cluster. Collocation ing data for large-scale, mission critical business applications. enables parallel, in-memory processing of CPU-intensive or other resource-intensive tasks without having to fetch data over the network. In-Memory In-Memory Streaming Continuous Data Grid Database Learning Framework Client Server Massively Parallel Processing (MPP) Analytics

rocessing Data Messaging Stream Processing Events Data esult rocessing Data ggregation Data Data esult Key-Value ANSI-99 SQL ACID Transactions ersistent Store ersistent Store Data Data Compute and Service Grid ersistent Store ersistent Store

Data Data ersistent Store ersistent Store In-Memory Data Store Data esult esult esult GridGain Cluster GridGain Cluster Transactional Persistence 1. Initial Request 1. Initial Request 2. Fetch data from remote nodes 2. Co-locate processing with data 3. Process the entire data-set 3. Reduce multiple results into one 4. Return result 4. Return result Figure 3. GridGain Compute Grid – Client Server vs.

Collocated Processing (MPP) RDBMS GridGain NoSQL Hadoop

The GridGain Compute Grid is a general-purpose framework Figure 5. GridGain for Stream Ingestion, Processing and that developers can use to add their own computations for Analytics any combination of transactions, analytics, stream processing, or machine and deep learning. Companies have used GridGain’s MPP capabilities for traditional High-Performance

GridGain is used by several of the largest banks in the world GridGain also provides the broadest in-memory computing for trade processing, settlement and compliance. Telecom- integration with Apache Spark. The integration includes munications companies use it to deliver call services over native support for Spark DataFrames, a GridGain RDD API telephone networks and the Internet. Retail and e-commerce for reading in and writing data to GridGain as mutable Spark vendors rely on it to deliver an improved real-time experi- RDDs, optimized SQL, and an in-memory implementation of ence. And leading cloud infrastructure and SaaS vendors use HDFS with the GridGain File System (GGFS). The integration it as the in-memory computing foundation of their offerings. allows Spark to: Companies have been able to ingest and process streams • Access all the in-memory data in GridGain, not just data with millions of events per second on a moderately-sized streams. cluster. • Share data and state across all Spark jobs. • Take advantage of all GridGain’s in-memory processing including continuous learning to train models in near- In-Memory In-Memory Streaming Continuous Data Grid Database Analytics Learning Framework real-time to improve outcomes for in-process HTAP appli-

Machine and Deep Learning cations.

Messaging Stream Processing Events GridGain also provides the GridGain Continuous Learning

Key-Value ANSI-99 SQL ACID Transactions Framework. It enables companies to automate decisions by adding machine and deep learning with real-time perfor- Compute and Service Grid mance on petabytes of data. GridGain accomplishes this by In-Memory Data Store running machine and deep learning in RAM and in place on

Transactional Persistence each machine without having to move data over the network. GridGain provides several standard machine learning algo- rithms optimized for MPP-style processing including linear RDBMS GridGain NoSQL Hadoop and multi-linear regression, k-means clustering, decision trees, k-NN classification and regression. It also includes a Figure 6. GridGain for Machine and Deep Learning multilayer perceptron and TensorFlow integration for deep learning. Developers can develop and deploy their own algo- GridGain is integrated and used with major streaming tech- rithms across any cluster as well as using the compute grid. nologies including Apache Camel™, Kafka™, Spark™ and The result is continuous learning that can be incrementally Storm™, Java Message Service (JMS) and MQTT to ingest, retrained at any time against the latest data to improve every process and publish streaming data. GridGain also includes a decision and outcome. Data Lake Accelerator that provides bi-directional integration between operational data in memory with data stored in Hadoop. Once loaded into the cluster, companies can lever- age GridGain’s built-in MPP-style libraries for concurrent data processing, including concurrent SQL queries and continuous learning. Clients can then subscribe to continuous queries which execute and identify important events as streams are processed.

SUMMARY

More and more, companies are using in-memory data grids (IMDG) or broader in-memory computing (IMC) platforms as a solution to manage increasing data loads. The most common reason for the exponentially growing loads on existing applications is digital transformation of the systems and applications used to meet the customer demand for a faster, more convenient experience anytime, anywhere, on any device. But delivering a better customer experience and innovating faster ways to support these loads is not easy. You need to: • Add speed and scale to existing applications. • Add speed and scale to new applications and APIs. • Have much greater flexibility to change for any new functionality. • Obtain real-time analytics and automation. • Possess a solid plan for incrementally transforming into a digital business. Many companies have tried to meet ever-increasing query and transaction load demands by solving point performance and scalability issues one application at a time—usually by scaling their databases vertically. But this approach is neither cost effective nor sustainable in the long run. The right solution is using an IMC platform as an IMDG for existing applications and any new applications, APIs, analytics, and automation over time. An IMC platform helps build a new real-time layer as a foundation for digital business.

Contact GridGain Systems To learn more about how GridGain can help your business, please email our sales team at [email protected],call us at +1 (650) 241-2281 (US) or +44 (0)208 610 0666 (Europe), or complete our contact form at www.gridgain.com/contact.

About GridGain Systems GridGain Systems is revolutionizing real-time data access and processing with the GridGain in-memory computing platform built on Apache® Ignite™. GridGain and Apache Ignite are used by tens of thousands of global enterprises in financial services, fintech, software, e-commerce, retail, online business services, healthcare, telecom and other major sectors, with a client list that includes ING, Raymond James, American Express, Societe Generale, Finastra, IHS Markit, ServiceNow, Marketo, RingCentral, American Airlines, Agilent, and UnitedHealthcare. GridGain delivers unprecedented speed and massive scalability to both legacy and greenfield applications. Deployed on a distributed cluster of commodity servers, GridGain software can reside between the application and data layers (RDBMS, NoSQL and Apache® Hadoop®), requiring no rip-and-replace of the existing databases, or it can be deployed as an in-memory transactional SQL database. GridGain is the most comprehensive in-memory computing platform for high-volume ACID transactions, real-time analytics, web-scale applications, continuous learning and hybrid transactional/analytical processing (HTAP). For more information on GridGain products and services, visit www.gridgain.com.

© 2019 GridGain Systems. All rights reserved. This document is provided “as is”. Information and views expressed in this document, including URL and other web site references, may change without notice. This document does not provide you with any legal rights to any intellectual property in any GridGain product. You may copy and use this document for your internal reference purposes. GridGain is a trademark or registered trademark of GridGain Systems, Inc. Windows, .NET and C# are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Java, JMS and other Java-related products and specifications are either registered trademarks or trademarks of Oracle Corporation and its affiliates in the United States and/or other countries. Apache, Apache Ignite, Ignite, the Apache Ignite logo, Apache Spark, Spark, Apache Hadoop, Hadoop, Apache Camel, Apache Cassandra, Cassandra, Apache Flink, Apache Flume, Apache Kafka, Kafka, Apache Rocket MQ, Apache Storm are either registered trademarks or trademarks of the Apache Software Foundation in the United States and/or other countries. All other trademarks and trade names are the property of their respective owners and used here for identification purposes only.

11 August 29, 2019