In recent years, in-memory database (IMDB) technology has developed rapidly. In addition to its inherent high performance, IMDB itself is increasingly moving toward being a full-featured standalone DB.
The following briefly describes a few of the more common IMDB application scenarios, hoping to inspire fellow IMDB technology aspirants--
1. Telecom billing
The largest application of IMDB is concentrated in the telecom field, especially in the billing system. Of course, in recent years, it has begun to expand to new telecom business areas, such as core network, CRM, precision marketing and so on. The following diagram shows the architecture of IMDB in telecom billing for your reference.
2. Securities online trading
Current securities trading is basically the use of J2EE to cache all the trading objects, which inevitably leads to a large amount of system overhead in the middle tier, as well as increasing system and labor costs. The use of IMDB, the transaction by logical classification, and cached to the application server can greatly improve system performance and object access uniformity.
3. Regional Data Collection Centers
For large-scale business systems across geographic boundaries, the existence of regional data centers greatly improves the accuracy, speed, and security of data and other characteristics. Typical application scenarios include: highway toll collection systems, restaurant chain billing/revenue systems, and agency ticketing systems. Typical system architecture is as follows:
The most important feature of this type of system is that the load on dedicated machines is low, and cheaper hardware configurations can be used. However, regional data centers require higher hardware configurations to cope with potentially large concurrent tasks (such as the restaurant's daily inventory at 10:00 p.m., and the agent's ticketing system's end-of-month submission of monthly reports, etc.). Considering that large concurrency does not happen every time, replacing the high-performance database server with an in-memory database + lightweight database server configuration as the regional database server can manage and maintain hot data during large concurrency at the lowest cost.
In actual deployment, the in-memory database can be deployed in both the terminal dedicated machine and the regional database server; the dedicated machine can be synchronized with the regional database server in a synchronous/asynchronous manner; ultimately, the headquarter's data center reads the aggregated data directly from the in-memory database of the regional data centers and processes it accordingly.
4. BI System
The BI system is composed of a data warehouse + a large number of OLAP applications. Traditional BI system bottlenecks often come from the database server, which is IBM, Oracle and other companies are actively launching the database all-in-one original intention. But look at the domestic BI market, many customers rush into the data warehouse and BI projects, but early on did not realize that with the expansion of data scale, the future may appear serious system bottlenecks. These bottlenecks directly affect the efficiency of report generation. Database all-in-one look? able to solve customer problems, but with it also comes a high equipment price? and directly affects the credibility of the customer's IT department throughout the company. Without additional hardware investment in the premise of the use of in-memory databases, and a certain amount of transformation of the existing system can be a large extent to solve this problem:
In the existing system on the basis of the in-memory database will be deployed in the application / BI system on the server, or in the case of sufficient funds to configure an additional layer of data acceleration layer. It is important to note that such a deployment requires a great deal of familiarity with the workflow of the application / BI system, and in accordance with specific logical rules of the artificial division of data routing, so as to achieve the specialized concentration of dedicated data, so that each application system in their own corresponding hardware resources under the proprietary operation of their respective OLAP. if you can successfully sort out the business and deployment, such an architecture not only to solve the existing system bottlenecks, but also clearly to solve the problem. This architecture not only solves the existing system bottlenecks, but also clearly organizes the business processes and facilitates the future expansion of the system.