CN109977140B - Transaction data query method, device and system - Google Patents
Transaction data query method, device and system Download PDFInfo
- Publication number
- CN109977140B CN109977140B CN201910228682.4A CN201910228682A CN109977140B CN 109977140 B CN109977140 B CN 109977140B CN 201910228682 A CN201910228682 A CN 201910228682A CN 109977140 B CN109977140 B CN 109977140B
- Authority
- CN
- China
- Prior art keywords
- query
- database
- type
- transaction data
- message
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Abstract
The application provides a transaction data query method, a transaction data query device and a transaction data query system, wherein a large amount of historical transaction data are stored by taking a HADOOP database with the characteristic of mass storage as a cloud database. Because of the small storage capacity of the relational database, a small amount of recent transaction data is stored in the relational database. The integrity of the transaction data is guaranteed and mass data can be stored through a heterogeneous storage strategy. The query request is divided into the query of the relational database and the query of the cloud database according to the time attribute through the query routing device, and the complete transaction data is stored in the relational database and the cloud database, so that all transaction data can be synchronously queried, and the technical problem that the storage capacity of the relational database is not enough to support the query requirement of the transaction detail data is solved.
Description
Technical Field
The present application relates to the field of computers, and in particular, to a method, an apparatus, and a system for querying transaction data.
Background
At present, a traditional commercial bank usually uses a relational database to store transaction detail data, but with the increase of business volume and the lapse of time, the total amount of the transaction detail data is increased rapidly and gradually approaches the upper limit of the storage capacity of the relational database, the transaction detail data needs to be cleaned regularly, the cleaned data cannot be inquired, and the requirement that a commercial bank client inquires long-term historical transaction detail data in real time cannot be met. It can be seen that the storage capacity of the relational database is not sufficient to support the query requirement of the transaction detail data.
Disclosure of Invention
The application provides a transaction data query method, a device and a system, and aims to solve the problem that the storage capacity of a relational database is insufficient to support the query requirement of transaction detail data.
In order to achieve the above object, the present application provides the following technical solutions:
a transaction data query method, comprising:
receiving a query transaction request;
sending a first type of message in the query transaction request to a first database, wherein the first type of message is used for querying transaction data of a day other than the day of the day, and the first database is used for storing transaction data before T-k days, T is the day, and k is a positive integer;
sending a second type of message in the query transaction request to a second database, wherein the second type of message is used for querying transaction data of a day close to m, the second database is used for storing the transaction data from T day to T-n day, n is a positive integer, n is greater than k, and k +1 is not less than m and not more than n + 1;
and feeding back a query result based on the query result fed back by the first database and the query result fed back by the second database.
Optionally, the method further includes:
under the condition that the load of the first type of database is increased, increasing the value of m; and/or the presence of a gas in the gas,
reducing the value of m under the condition that the load of the second type database is increased;
wherein the load increase of the first type of database comprises: the increase rate of the query data volume of the first type of database is larger than a first threshold value, and/or the response time of the first type of database is larger than a second threshold value;
the load increase of the second type database comprises: the increase rate of the query data volume of the second type database is larger than a third threshold value, and/or the response time of the second type database is larger than a fourth threshold value.
Optionally, before sending the first type of message in the query transaction request to the first database, the method further includes:
acquiring a first type of target message from the query transaction request, wherein the first type of target message is used for querying messages of transaction data of days other than the day of the current day;
carrying out format conversion on the first type of target message to obtain the first type of message;
before the sending the second type message in the query transaction request to the second database, the method further includes:
acquiring a second type of target message from the query transaction request, wherein the second type of target message is used for querying a message of transaction data of a day close to m days;
and carrying out format conversion on the second type target message to obtain the second type message.
Optionally, the feeding back the query result based on the query result fed back by the first database and the query result fed back by the second database includes:
performing preset operation on the query result fed back by the first database and the query result fed back by the second database to obtain the query result, and feeding back the query result;
wherein the preset operation comprises: conversion to a preset format and/or merging.
A transaction data querying system, comprising:
the system comprises a first database, a second database and a query routing device;
the first database is used for storing transaction data before T-k days, wherein T is the current day, and k is a positive integer;
the second database is used for storing transaction data from T days to T-n days, wherein n is a positive integer and n > k;
the query routing device is used for executing the transaction data query method.
Optionally, the method further includes:
and the storage control device is used for storing the transaction data before T-k days into the first database and storing the transaction data from T days to T-n days into the second database.
Optionally, the first database comprises a HADOOP database, and the second database comprises a relational database.
A transaction data querying device, comprising:
the receiving module is used for receiving a query transaction request;
a routing module, configured to send a first type of message in the query transaction request to a first database, where the first type of message is a message used to query transaction data of a current day except for the next m days, the first database is used to store transaction data before T-k days, and send a second type of message in the query transaction request to a second database, the second type of message is a message used to query transaction data of the current day near m days, and the second database is used to store transaction data of T days to T-n days, where T is the current day, k is a positive integer, n is a positive integer, and n > k, and k +1 is not less than m and not more than n + 1;
and the feedback module is used for feeding back the query result based on the query result fed back by the first database and the query result fed back by the second database.
Optionally, the routing module is further configured to:
increasing the value of m under the condition that the load of the first type database is reduced; and/or the presence of a gas in the gas,
reducing the value of m under the condition that the load of the second type database is increased;
wherein the load reduction comprises: the increase rate of the query data volume is smaller than a first threshold value, and/or the response time is smaller than a second threshold value;
the load increase includes: the rate of increase of the amount of query data is greater than a third threshold and/or the response time is greater than a fourth threshold.
Optionally, the method further includes:
a conversion module, configured to obtain a first type target packet from the query transaction request before sending the first type packet in the query transaction request to a first database, where the first type target packet is used to perform format conversion on the first type target packet from a packet for querying transaction data of a day other than the day m, so as to obtain the first type packet; before sending the second type of message in the query transaction request to a second database, obtaining a second type of target message from the query transaction request, wherein the second type of target message is used for querying a message of transaction data of a day close to m days, and performing format conversion on the second type of target message to obtain the second type of message; and the number of the first and second groups,
performing preset operation on the query result fed back by the first database and the query result fed back by the second database to obtain the query result, and feeding back the query result; wherein the preset operation comprises: conversion to a preset format and/or merging.
According to the scheme, the transaction data query system is provided, wherein the system adopts heterogeneous storage strategies of a relational database and a non-relational cloud database. The method comprises the steps of utilizing a HADOOP database with mass storage characteristics as a cloud database to store a large amount of historical transaction data. Because of the small storage capacity of the relational database, a small amount of recent transaction data is stored in the relational database. The integrity of the transaction data is guaranteed and mass data can be stored through a heterogeneous storage strategy. The query request is divided into the query of the relational database and the query of the cloud database according to the time attribute through the query routing device, and the complete transaction data is stored in the relational database and the cloud database, so that all transaction data can be synchronously queried, and the technical problem that the storage capacity of the relational database is not enough to support the query requirement of the transaction detail data is solved.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiments or the prior art descriptions will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings without creative efforts.
FIG. 1 is a schematic diagram of an application scenario of a transaction data query system;
FIG. 2 is a schematic diagram of yet another transactional data querying system;
FIG. 3 is a flow chart of a specific implementation of the functionality of the query routing device;
fig. 4 is a schematic structural diagram of a transaction data query device.
Detailed Description
Fig. 1 is a schematic view of an application scenario of a transaction data query system disclosed in an embodiment of the present application, where the transaction data query system disclosed in the embodiment of the present application is connected to a query front end (for example, a query client) and is configured to query and feed back a query result of transaction data to the query front end based on a query instruction of the query front end.
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
Fig. 2 is a diagram of a transaction data query system according to an embodiment of the present application, where the system includes a query routing device, a relational database connected to the query routing device, a cloud database connected to the query routing device, and a storage control device connected to the relational database and the cloud database.
The storage control device is used for controlling the relational database and the cloud database to store the transaction data amount. And (4) storing transaction data before T-k days in a cloud database by setting the current day as T day. The cloud database is a non-relational database, and may be, for example, a HADOOP database, which is a mass storage database. Therefore, massive transaction data before T-k days can be stored in the cloud database. Transaction data from day T to day T-n are stored in a relational database. Wherein k and n are positive integers, and n > k.
Therefore, the storage control device in the application adopts a redundant data storage strategy to store all transaction data in the relational database and the cloud database, and the transaction data between the T-n day and the T-k day is the redundant data, so that the capacity of dynamically adjusting the query ranges of the two databases can be ensured, and the query pressure of the two databases is balanced. Wherein, the user sets k or/and n according to the actual requirement. For example, the user can set k or/and n according to the time range of the data most frequently queried by the client, so as to dynamically adjust the data volume of the stored transaction of the relational database and the cloud database.
The query routing device is used for receiving a query transaction request initiated by a query front end, sending a request including query of transaction data which is beyond a period of m days to the cloud database, sending a request including query of the transaction data which is beyond the period of m days to the relational database, and feeding back a query result to the query front end based on the query result fed back by the cloud database and the query result fed back by the relational database.
The relational database is used for receiving a request which is sent by the query routing device and comprises the transaction data of the near m days, querying the transaction data of the near m days according to the request for querying the transaction data of the near m days, and sending a query result of the transaction data of the near m days to the query routing device.
The cloud database is used for receiving a request which is sent by the query routing device and comprises the transaction data beyond m days, querying the transaction data beyond m days according to the request for querying the transaction data beyond m days, and sending a query result of the transaction data beyond m days to the query routing device.
Therefore, the system of the embodiment of the application adopts the heterogeneous storage strategies of the relational database and the non-relational cloud database, and stores complete transaction data through the heterogeneous storage strategies. The method comprises the steps of utilizing a HADOOP database with the mass storage characteristic as a cloud database to store a large amount of historical transaction data, namely storing a large amount of historical transaction data before T-k days in the cloud database. Because of the small storage capacity of the relational database, a small amount of recent transaction data is stored in the relational database. The integrity of the transaction data and the mass data can be guaranteed through a heterogeneous storage strategy, and the timeliness and flexibility of data query are guaranteed through redundant data storage. The query request is divided into the query of the relational database and the query of the cloud database according to the time attribute through the query routing device, and the complete transaction data is stored in the relational database and the cloud database, so that all transaction data can be synchronously queried, and the technical problem that the storage capacity of the relational database is not enough to support the query requirement of the transaction detail data is solved.
Furthermore, in the system according to the embodiment of the present application, a redundant data storage policy is adopted for the relational database and the cloud database, so that the system has the capability of dynamically balancing the query pressure of the two databases. Namely, the timeliness and flexibility of data query are ensured through a redundant data storage strategy.
Fig. 3 is a specific implementation flow of the function of the query routing device shown in fig. 2, which includes the following steps:
s101: and receiving a query transaction request initiated by a query front end.
The query routing device provides a uniform query entrance to receive a query transaction request initiated by a query front end.
S102: and converting the format of the inquiry transaction request.
Because the message formats of the query relational database and the query cloud database are not consistent, the message formats are uniformly converted in the query routing device, for example, the messages are uniformly converted into XML messages. Therefore, the message format difference of different databases is shielded through message conversion, and the processing logic is simplified.
S103: and analyzing the query request according to the converted query transaction request to obtain a query request message.
The specific way of parsing can be referred to in the prior art, and is not described herein.
S104: and performing message conversion on the request comprising the transaction data which is inquired for about m days, sending the converted message to the cloud database, performing message conversion on the request comprising the transaction data which is inquired for about m days, and sending the converted message to the relational database.
The request message including the transaction data which is inquired for a period of more than m days can be used as the first type of message, and the cloud database can be used as the first database. And taking the request message for inquiring the transaction data of the next m days as a second type message, and taking the relational database as a second database.
There are two cases of query requests:
in the first case, the queried transaction data is stored entirely in one database.
The second case is where the queried transaction data is stored in two databases. Aiming at the second situation, a data query and segmentation rule is set in the method, wherein the data query and segmentation rule is that transaction data within m days are queried from a relational database, the transaction data exceeding m days are queried from a cloud database, m is a positive integer, and k +1 is not less than m and not more than n + 1. Because the transaction data stored in the relational database and the cloud database have redundant data, the m value can be dynamically adjusted according to the performance conditions of the relational database and the cloud database, and the query pressure of the two databases is balanced. Alternatively, the user sets the value of m according to other requirements.
And dynamically adjusting the m value according to the load change conditions of the relational database and the cloud database. For example, the transaction amount and the transaction response time of the relational database and the cloud database can be monitored, and when the increase rate of the query data amount of the relational database is greater than a third threshold value or the response time is greater than a fourth threshold value, the value of m is automatically reduced, so that the resource occupation of the relational database is reduced. And when the increase rate of the query data volume of the cloud database is greater than a first threshold value or the response time is greater than a second threshold value, the value m is automatically increased, and the resource occupation of the cloud database is reduced. Thereby balancing the query pressure of the two databases and optimizing the response time of the client query request. The first threshold and the third threshold may be the same, and the second threshold and the fourth threshold may be the same.
S105: receiving the query result of the transaction data which is returned by the cloud database and is beyond the m days, performing message conversion on the received query result of the transaction data which is returned by the cloud database and is beyond the m days, receiving the query result of the transaction data which is returned by the relational database and is beyond the m days, and performing message conversion on the received query result of the transaction data which is returned by the relational database and is beyond the m days.
The message formats returned by different databases are uniformly converted, for example, the message formats are uniformly converted into an XML message for processing. Therefore, the message format difference of different databases is shielded through message conversion, and the processing logic is simplified.
S106: and feeding back the query result to the query front end based on the received query result returned by the cloud database after message conversion and the query result returned by the relational database after message conversion.
Wherein, the specific implementation manner of step S106 includes: and performing preset operation on the query result fed back by the cloud database and the query result fed back by the relational database to obtain a query result, and feeding back the query result to the query front end. The preset operation comprises the following steps: conversion to a preset format and/or merging.
It can be seen that, in the above example of the present application, the query routing apparatus provides a uniform query entry, and shields the influence of the internal data storage change caused by using the heterogeneous storage policy on the external query transaction. The query request is automatically segmented into a relational database query and a cloud database query according to the time attribute, and complete transaction data are stored in the relational database and the cloud database, so that all transaction data can be synchronously queried in real time.
Moreover, the query routing device can perform message conversion, message analysis and segmentation of query requests, so that the real-time performance of online query can be ensured, and the influence of the change of the transaction data storage position, the change of the storage format, the message change and the query rule change on online query transaction can be shielded.
Fig. 4 is a structure of a transaction data query device, including:
and the receiving module is used for receiving the inquiry transaction request initiated by the inquiry front end.
A routing module, configured to send a first type of message in the query transaction request to a first database, where the first type of message is a message used to query transaction data of a current day except for the next m days, the first database is used to store transaction data before T-k days, and send a second type of message in the query transaction request to a second database, the second type of message is a message used to query transaction data of the current day near m days, and the second database is used to store transaction data of T days to T-n days, where T is the current day, k is a positive integer, n is a positive integer, and n > k, and k +1 is not less than m and not more than n + 1;
and the feedback module is used for feeding back the query result based on the query result fed back by the first database and the query result fed back by the second database.
The routing module is further configured to:
under the condition that the load of the first type of database is increased, increasing the value of m; and/or the presence of a gas in the gas,
reducing the value of m under the condition that the load of the second type database is increased;
wherein the load increase of the first type of database comprises: the increase rate of the query data volume of the first type of database is larger than a first threshold value, and/or the response time of the first type of database is larger than a second threshold value;
the load increase of the second type database comprises: the increase rate of the query data volume of the second type database is larger than a third threshold value, and/or the response time of the second type database is larger than a fourth threshold value.
The transaction data inquiry device further comprises:
a conversion module, configured to obtain a first type target packet from the query transaction request before sending the first type packet in the query transaction request to a first database, where the first type target packet is used to perform format conversion on the first type target packet from a packet for querying transaction data of a day other than the day m, so as to obtain the first type packet; before sending the second type of message in the query transaction request to a second database, obtaining a second type of target message from the query transaction request, wherein the second type of target message is used for querying a message of transaction data of a day close to m days, and performing format conversion on the second type of target message to obtain the second type of message; and the number of the first and second groups,
performing preset operation on the query result fed back by the first database and the query result fed back by the second database to obtain the query result, and feeding back the query result; wherein the preset operation comprises: conversion to a preset format and/or merging.
The functions described in the method of the embodiment of the present application, if implemented in the form of software functional units and sold or used as independent products, may be stored in a storage medium readable by a computing device. Based on such understanding, part of the contribution to the prior art of the embodiments of the present application or part of the technical solution may be embodied in the form of a software product stored in a storage medium and including several instructions for causing a computing device (which may be a personal computer, a server, a mobile computing device or a network device) to execute all or part of the steps of the method described in the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.
The embodiments are described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same or similar parts among the embodiments are referred to each other.
The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the application. Thus, the present application is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims (7)
1. A transaction data query method is characterized in that the method is applied to a transaction data query system which comprises a query routing device, a relational database connected with the query routing device, a cloud database connected with the query routing device, and a storage control device connected with the relational database and the cloud database, wherein the query routing device provides a uniform query entrance to shield the influence of internal data storage change caused by adopting heterogeneous storage strategies on external query transactions, the query routing device automatically divides a query request into a relational database query and a cloud database query according to time attributes to realize real-time synchronous query of all transaction data, the storage control device is used for controlling the transaction data amount stored in the relational database and the cloud database and dynamically adjusting the transaction data amount stored in the relational database and the cloud database, the method for inquiring the transaction data comprises the following steps of setting a current day as a T day, storing mass transaction data before the T-k day in a cloud database, wherein the cloud database is a non-relational database, the non-relational database is a first database, the transaction data from the T day to the T-n day are stored in a relational database, and the relational database is a second database:
the query routing device receives a query transaction request;
the query routing device sends a first type of message in the query transaction request to a first database, wherein the first type of message is used for querying transaction data of a current day except for a day m, the first database is used for storing transaction data before a day T-k, T is the current day, and k is a positive integer;
the query routing device sends a second type of message in the query transaction request to a second database, wherein the second type of message is used for querying transaction data of the current day in the next m days, the second database is used for storing the transaction data from the T day to the T-n day, n is a positive integer, n is greater than k, and k +1 is not less than m and not more than n + 1;
the query routing device feeds back a query result based on the query result fed back by the first database and the query result fed back by the second database;
the query routing device increases the value of m under the condition that the load of the first type of database is increased; and/or the presence of a gas in the gas,
the query routing device reduces the value of m under the condition that the load of the second class database is increased;
wherein the load increase of the first type of database comprises: the increase rate of the query data volume of the first type of database is larger than a first threshold value, and/or the response time of the first type of database is larger than a second threshold value;
the load increase of the second type database comprises: the increase rate of the query data volume of the second type database is larger than a third threshold value, and/or the response time of the second type database is larger than a fourth threshold value.
2. The method according to claim 1, further comprising, before said sending the first type of message in the query transaction request to the first database:
acquiring a first type of target message from the query transaction request, wherein the first type of target message is used for querying messages of transaction data of days other than the day of the current day;
carrying out format conversion on the first type of target message to obtain the first type of message;
before the sending the second type message in the query transaction request to the second database, the method further includes:
acquiring a second type of target message from the query transaction request, wherein the second type of target message is used for querying a message of transaction data of a day close to m days;
and carrying out format conversion on the second type target message to obtain the second type message.
3. The method of claim 2, wherein feeding back the query result based on the query result fed back by the first database and the query result fed back by the second database comprises:
performing preset operation on the query result fed back by the first database and the query result fed back by the second database to obtain the query result, and feeding back the query result;
wherein the preset operation comprises: conversion to a preset format and/or merging.
4. A transaction data query system is characterized by comprising a query routing device, a relational database connected with the query routing device, a cloud database connected with the query routing device, and a storage control device connected with the relational database and the cloud database, wherein the query routing device provides a uniform query entrance to shield the influence of internal data storage change caused by adopting heterogeneous storage strategies on external query transactions, the query routing device automatically divides a query request into a relational database query and a query of the cloud database according to time attributes to realize real-time synchronous query of all transaction data, the storage control device is used for controlling the transaction data amount stored in the relational database and the cloud database, dynamically adjusting the transaction data amount stored in the relational database and the cloud database, and storing mass transaction data before T-k day and before the T day in the cloud database, the cloud database is a non-relational database, the non-relational database is a first database, the transaction data from T day to T-n day is stored in a relational database, the relational database is a second database,
the first database is used for storing transaction data before T-k days, wherein T is the current day, and k is a positive integer;
the second database is used for storing transaction data from T days to T-n days, wherein n is a positive integer and n > k;
the query routing device is used for executing the transaction data query method of any one of claims 1-3.
5. The system of claim 4, wherein the first database comprises a HADOOP database and the second database comprises a relational database.
6. A transaction data query device applied to the transaction data query system of claim 4, comprising:
the receiving module is used for receiving a query transaction request;
a routing module, configured to send a first type of message in the query transaction request to a first database, where the first type of message is a message used to query transaction data of a current day except for the next m days, the first database is used to store transaction data before T-k days, and send a second type of message in the query transaction request to a second database, the second type of message is a message used to query transaction data of the current day near m days, and the second database is used to store transaction data of T days to T-n days, where T is the current day, k is a positive integer, n is a positive integer, and n > k, and k +1 is not less than m and not more than n + 1;
the feedback module is used for feeding back a query result based on the query result fed back by the first database and the query result fed back by the second database;
the routing module is further configured to:
increasing the value of m under the condition that the load of the first type database is reduced; and/or the presence of a gas in the gas,
reducing the value of m under the condition that the load of the second type database is increased;
wherein the load reduction comprises: the increase rate of the query data volume is smaller than a first threshold value, and/or the response time is smaller than a second threshold value;
the load increase includes: the rate of increase of the amount of query data is greater than a third threshold and/or the response time is greater than a fourth threshold.
7. The apparatus of claim 6, further comprising:
a conversion module, configured to obtain a first type target packet from the query transaction request before sending the first type packet in the query transaction request to a first database, where the first type target packet is used to perform format conversion on the first type target packet from a packet for querying transaction data of a day other than the day m, so as to obtain the first type packet; before sending the second type of message in the query transaction request to a second database, obtaining a second type of target message from the query transaction request, wherein the second type of target message is used for querying a message of transaction data of a day close to m days, and performing format conversion on the second type of target message to obtain the second type of message; and the number of the first and second groups,
performing preset operation on the query result fed back by the first database and the query result fed back by the second database to obtain the query result, and feeding back the query result; wherein the preset operation comprises: conversion to a preset format and/or merging.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910228682.4A CN109977140B (en) | 2019-03-25 | 2019-03-25 | Transaction data query method, device and system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910228682.4A CN109977140B (en) | 2019-03-25 | 2019-03-25 | Transaction data query method, device and system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109977140A CN109977140A (en) | 2019-07-05 |
| CN109977140B true CN109977140B (en) | 2022-04-05 |
Family
ID=67080465
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910228682.4A Active CN109977140B (en) | 2019-03-25 | 2019-03-25 | Transaction data query method, device and system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109977140B (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112506970A (en) * | 2020-12-11 | 2021-03-16 | 中信银行股份有限公司 | Data query method and device, electronic equipment and computer readable storage medium |
| CN115065557B (en) * | 2022-08-05 | 2022-11-04 | 国网浙江省电力有限公司 | Data security interaction method suitable for multiple systems |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103093342A (en) * | 2013-01-11 | 2013-05-08 | 北京掌上汇通科技发展有限公司 | Online transaction processing platform and transaction processing method thereof |
| CN106649828A (en) * | 2016-12-29 | 2017-05-10 | 中国银联股份有限公司 | Data query method and system |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7827362B2 (en) * | 2004-08-24 | 2010-11-02 | Symantec Corporation | Systems, apparatus, and methods for processing I/O requests |
| CN106648446B (en) * | 2015-10-30 | 2020-07-07 | 阿里巴巴集团控股有限公司 | Storage method and device for time sequence data and electronic equipment |
| CN105243169B (en) * | 2015-11-12 | 2019-01-29 | 中国建设银行股份有限公司 | A kind of data query method and system |
| CN105488191A (en) * | 2015-12-03 | 2016-04-13 | 南京联成科技发展有限公司 | Data acquisition processing method and device based on big data information safety management operation and maintenance service platform |
| CN106874325B (en) * | 2016-06-29 | 2020-04-03 | 阿里巴巴集团控股有限公司 | Data query method and device |
-
2019
- 2019-03-25 CN CN201910228682.4A patent/CN109977140B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103093342A (en) * | 2013-01-11 | 2013-05-08 | 北京掌上汇通科技发展有限公司 | Online transaction processing platform and transaction processing method thereof |
| CN106649828A (en) * | 2016-12-29 | 2017-05-10 | 中国银联股份有限公司 | Data query method and system |
Non-Patent Citations (1)
| Title |
|---|
| "大型商业银行基于Hadoop分布式数据仓库建设初探";杨頲、韩路、许勤、孙元浩;《计算机应用与软件》;20170815;第34卷(第8期);第72-75页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109977140A (en) | 2019-07-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109947668B (en) | Method and device for storing data | |
| CN112860695B (en) | Monitoring data query method, device, equipment, storage medium and program product | |
| CN105824957A (en) | Query engine system and query method of distributive memory column-oriented database | |
| CN109977140B (en) | Transaction data query method, device and system | |
| MX2014002956A (en) | Marketplace for timely event data distribution. | |
| WO2021073510A1 (en) | Statistical method and device for database | |
| CN111782692B (en) | Frequency control method and device | |
| CN107194810B (en) | Asset configuration system and method of operation | |
| WO2023082681A1 (en) | Data processing method and apparatus based on batch-stream integration, computer device, and medium | |
| CN107609172B (en) | Cross-system multi-dimensional data retrieval processing method and device | |
| CN111770150B (en) | Access flow control method and device and electronic equipment | |
| CN106612329B (en) | Caching method and device | |
| Li et al. | Adaptive replica creation and selection strategies for latency-aware application in collaborative edge-cloud system | |
| EP4216076A1 (en) | Method and apparatus of processing an observation information, electronic device and storage medium | |
| CN109146672B (en) | Matching method and device based on production mode | |
| EP3905064A1 (en) | Method and apparatus for synchronously replicating database | |
| CN113254480A (en) | Data query method and device | |
| AU2019319729A1 (en) | Generating real-time aggregates at scale for inclusion in one or more modified fields in a produced subset of data | |
| CN110647706A (en) | Method, device and equipment for processing webpage access request and storage medium | |
| CN113590322A (en) | Data processing method and device | |
| CN109063201B (en) | Impala online interactive query method based on mixed storage scheme | |
| CN107480229B (en) | Distributed computer database system for object retrieval and retrieval method thereof | |
| CN110166429B (en) | Data packet processing method and device, computer readable storage medium and server | |
| CN109685101A (en) | A kind of adaptive acquisition method of multidimensional data and system | |
| CN111274203A (en) | Call bill storage system and method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |