CN109656978A - The optimization method of near real-time search service - Google Patents
The optimization method of near real-time search service Download PDFInfo
- Publication number
- CN109656978A CN109656978A CN201811580863.5A CN201811580863A CN109656978A CN 109656978 A CN109656978 A CN 109656978A CN 201811580863 A CN201811580863 A CN 201811580863A CN 109656978 A CN109656978 A CN 109656978A
- Authority
- CN
- China
- Prior art keywords
- data
- cold
- dsc
- solr
- indexed
- 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.)
- Pending
Links
Abstract
This application discloses a kind of optimization method of near real-time search service, method includes creation SolrCloud;Dsc data collection is set;Cold data collection is set;Receive new data to be indexed;New data to be indexed is handled and is stored by cold data collection;When new data to be indexed dsc data concentrate when, then dsc data concentration retrieved;When new data to be indexed not dsc data concentrate when, then cold data concentration retrieved;When new data part to be indexed dsc data concentrate when, then dsc data collection and cold data concentration retrieved respectively.The present invention greatly improves search speed, and improve the experience of user and the search performance of system using the mode of hot and cold data dynamic adjustment.By creating at least one Solr example in each disk on single server, the speed of reading data is greatly improved, is reduced because reading data due to the time-consuming caused by entire search service.
Description
Technical field
The present invention relates to computer application technology more particularly to a kind of optimization methods of near real-time search service.
Background technique
Relatively common search technique has Solr, Elasticsearch etc. at present, principle and technology relatively at
It is ripe, but in specific industry or specific transactions scene, common framework and scheme are no longer satisfied the requirement to its performance.
Search service in conventional system or project is to be realized by the inquiry of database earliest, is relatively suitble to small data
Collection and simple business scenario realize that simple, cost is relatively low.In the case of slightly complicated for large data sets or business will power not from
The heart, when data volume reaches millions or more, common inquiry or search are time-consuming very long, are not able to satisfy user to system
Performance requirement.
Search technique popular at present has Solr, Elasticsearch, and (the enterprise-level search based on Lucence is answered
With server) etc., it is based on the realization of Lucence (kit of the full-text search engine of open source code) kernel, Neng Gouti
For quick search service and provide searching interface abundant.In data scale in millions, searching for Millisecond can be realized
Rope service.With the accumulation of data, index file is increasing, and data time-consuming is searched in full dose data more next can also grow.
For the pressure for reducing individual server, SolrCloud technology realizes the distributed search mode of search service,
By data set equiblibrium mass distribution to multiple servers, thus mitigate the data set size of single server, it can be achieved that data load
Data disaster tolerance ability that is balanced, improving service.But hardware resource can not infinitely increase, and the data set of single server still can
It is gradually increased.
Further, there is a kind of scheme for combining Solr and HBase, pass through HBase (distributed, opening towards column
Source database) storage metadata, Solr offer secondary index service, to reduce the size of Solr directoried data set, reduction is searched
The memory pressure of server when rope, to improve search speed.But with the sustainable growth of data set, Solr index data is still
Can be increasing, when reaching hundred million grades of data, the length of time-consuming still allows people that can not endure.The sustainable growths of data and fast search
Contradiction cannot be solved effectively.
The above kinds of schemes not can solve data sustainable growth and stablize the contradictory problems of search speed.Traditional think of
Road and scheme, with the increase of data volume, inherently cause the decline of search performance in the case where hardware resource is certain.
It traces it to its cause presence and Railway Project:
1, there are small range retrieval, a wide range of the case where screening.I.e. most search result may be only in partial data
It is centrally stored, fail effectively to analyze such situation during its design, in full dose data centralized indexes, inherently expend more
The hardware resources such as more memories.
2, dsc data and cold data are adjusted without dynamic.I.e. most of search result data may exist only in recently
New index data or the hot spot datas such as often searched data set in, fail the such dsc data of Effective selection, searching for it
When the cold datas such as its a greater amount of old index data or infrequently searched data set, and it may require that more times and hard
Part resource.
3, single server list service.I.e. conventional SolrCloud framework creates a Solr reality on a server
Example, can only sufficiently use monolithic disk, and other disks are in idle state.With big data quantity read operation when, it is single
The readwrite performance of block disk becomes a bottleneck of search service.
Summary of the invention
The invention discloses a kind of optimization methods of near real-time search service, comprising steps of
SolrCloud is created, comprising steps of
At least one Solr example is created on each piece of disk of server, wherein the number of servers is at least
One, the Solr example includes the Solr example of NRT mode and the Solr example of pattern ram;
Each Solr example on each piece of disk is named, and storage allocation;
Dsc data collection is set: by the Solr example of the pattern ram, dsc data being stored to the dsc data collection and is specified
The server memory in;
Cold data collection is set: by the Solr example of the NRT mode, cold data being stored to the cold data collection and is specified
Disk or solid state hard disk in, while it is more than the data buffer storage of hit threshold to institute that the cold data, which is concentrated hit-count, automatically
It states in server memory;
Receive new data to be indexed;
The new data to be indexed is handled and is stored by the cold data collection;
When the new data to be indexed is when the dsc data is concentrated, then retrieved in dsc data concentration;
When the new data to be indexed not the dsc data concentrate when, then the cold data concentration retrieved;
When the new data part to be indexed is when the dsc data is concentrated, then in the dsc data collection and the cold number
It is retrieved respectively according to concentrating.
Preferably, when the cold data that the cold data is concentrated is searched or the number of hit is more than the hit threshold,
The cold data is then added to the dsc data from cold data concentration to concentrate;
When the dsc data that the dsc data is concentrated is more than that also searched or hit-count is not lower than number threshold to time threshold
When value, then the dsc data is concentrated from the dsc data and rejected.
Preferably, it is retrieved in cold data concentration, is further described to rope in cold data concentration positioning
Sub- cold data collection where the new data drawn concentrates row retrieval in the sub- cold data.
Preferably, the dsc data is the data that searched or hit-count is more than the hit threshold.
Preferably, the cold data is that searched or hit-count is not lower than the number lower than the time threshold
The data of threshold value.
Preferably, the cold data integrates as full dose data set, including dsc data collection.
Preferably, total memory of each piece of disk is equal.
Compared with prior art, the optimization method of near real-time search service provided by the invention, reach it is following the utility model has the advantages that
First, cold data collection is logically and physically split into multiple sub- cold data collection by the present invention, is being provided
When search service, can logically rapid drop set to be searched range, more computing resources are used for lesser data
Collection, improves search speed.
Second, the present invention will be shot straight, searched hot number often using the mode of hot and cold data dynamic adjustment
According to collection storage into expensive and limited memory, provide one design on caching, by long-time miss or by
The lower cold data collection of search rate is stored in the disk or hard disk that price is cheap and search speed is relatively slow, greatly
Search speed is improved, and improves the experience of user and the search performance of system.
Third, the present invention is by creating at least one Solr example, composition one in each disk on single server
A SolrCloud, takes full advantage of the cheap disk resource of the price of server, and the data on monolithic disk are assigned to muti-piece
On disk, in the case where same data set, muti-piece disk can carry out disk read operation simultaneously, greatly improve data reading
The speed taken is reduced because reading data due to the time-consuming caused by entire search service.
Below by drawings and examples, technical scheme of the present invention will be described in further detail.
Detailed description of the invention
The drawings described herein are used to provide a further understanding of the present application, constitutes part of this application, this Shen
Illustrative embodiments and their description please are not constituted an undue limitation on the present application for explaining the application.In the accompanying drawings:
Fig. 1 is the data directory figure of the optimization method of near real-time search service in the embodiment of the present invention 1;
Fig. 2 is the data retrieval figure of the optimization method of near real-time search service in the embodiment of the present invention 1;
Fig. 3 is the SolrCloud visioning procedure figure of the optimization method of near real-time search service in the embodiment of the present invention 2;
Fig. 4 is the hot and cold data set Stored Procedure figure of the optimization method of near real-time search service in the embodiment of the present invention 2;
Fig. 5 is the architecture diagram of the search service of the optimization method of near real-time search service in the embodiment of the present invention 3;
Fig. 6 is the flow chart of the search service of the optimization method of near real-time search service in the embodiment of the present invention 3.
Specific embodiment
Following will be combined with the drawings in the embodiments of the present invention, and technical solution in the embodiment of the present invention carries out clear, complete
Site preparation description.It should be noted that described embodiment only actually is a part of the embodiment of the present invention, rather than whole realities
Example is applied, and is actually merely illustrative, never as to the present invention and its application or any restrictions used.The guarantor of the application
Protect range as defined by the appended claims.
Embodiment 1:
It is shown the specific embodiment of the optimization method of herein described near real-time search service, this method comprises:
It is data directory figure, including step 101- step 105 referring to Fig. 1;
Step 101, creation SolrCloud, comprising steps of
At least one Solr example is created on each piece of disk of server, wherein the number of servers is at least
One, the Solr example includes the Solr example of NRT mode and the Solr example of pattern ram;The Solr example is for depositing
Storage index data simultaneously provides search service;
Each Solr example on each piece of disk is named, and storage allocation;
Step 102, setting dsc data collection: by the Solr example of the pattern ram, by dsc data storage to the hot number
According in the specified server memory of collection;
Step 103, setting cold data collection: by the Solr example of the NRT mode, by cold data storage to the cold number
In the disk or solid state hard disk specified according to collection, while it is more than the data of hit threshold that the cold data, which is concentrated hit-count, automatically
It is cached in the server memory;
Step 104 receives new data to be indexed;
Step 105, the new data to be indexed are handled and are stored by the cold data collection;
It is referring to fig. 2 data retrieval figure, including step 106- step 108;
Step 106, when the new data to be indexed is when the dsc data is concentrated, then concentrate and carry out in the dsc data
Retrieval;
Step 107, when the new data to be indexed not the dsc data concentrate when, then the cold data concentrate into
Row retrieval;
Step 108, when the new data part to be indexed is when the dsc data is concentrated, then in the dsc data collection and
The cold data concentration is retrieved respectively.
Embodiment 2:
This application provides another embodiments of the optimization method of near real-time search service, this method comprises:
Step 201 creates SolrCloud, shown in Figure 3, comprising steps of
At least one Solr example is created on each piece of disk of server, wherein the number of servers is at least
One, the Solr example includes the Solr example of NRT mode and the Solr example of pattern ram;
Each Solr example on each piece of disk is named, and storage allocation, each piece of disk
Total memory it is equal;
Step 202, setting dsc data collection: by the Solr example of the pattern ram, by dsc data storage to the hot number
According in the specified server memory of collection;
Step 203, setting cold data collection: by the Solr example of the NRT mode, by cold data storage to the cold number
In the disk or solid state hard disk specified according to collection, while it is more than the data of hit threshold that the cold data, which is concentrated hit-count, automatically
It is cached in the server memory, it is shown in Figure 4;
Step 204 receives new data to be indexed;
Step 205, the new data to be indexed are handled and are stored by the cold data collection;
Step 206, when the new data to be indexed is when the dsc data is concentrated, then concentrate and carry out in the dsc data
Retrieval;
Step 207, when the new data to be indexed not the dsc data concentrate when, then the cold data concentrate into
Row retrieval;
Step 208, when the new data part to be indexed is when the dsc data is concentrated, then in the dsc data collection and
The cold data concentration is retrieved respectively.
In above-mentioned steps 203, when the number that the cold data that the cold data is concentrated is searched or hits is more than the hit
When threshold value, then the cold data is added to the dsc data from cold data concentration and concentrated;The cold data is lower than institute
State time threshold often do not searched for or hit-count be lower than the frequency threshold value data;The cold data integrates as full dose
Data set, including dsc data collection.
In above-mentioned steps 202, when the dsc data that the dsc data is concentrated is more than that time threshold is not also searched or hits
When number is lower than frequency threshold value, then the dsc data is concentrated from the dsc data and rejected;The dsc data is searched or life
Middle number is more than the data of the hit threshold.
It in above-mentioned steps 207, is retrieved in cold data concentration, specific method is that it is fixed to concentrate in the cold data
Sub- cold data collection where the new data to be indexed of position is retrieved in corresponding sub- cold data concentration.
The hit threshold, the time threshold and the frequency threshold value are determines according to actual conditions.
Embodiment 3:
A practical embodiment of the optimization method of near real-time search service is present embodiments provided, specific as follows:
Two-server is provided for building search service, the configuration of every server is 64GB memory, two pieces of 1TB's
Hard disk.
The Solr example of two NRT modes is created on the disk of First server, and distributes the memory of 8GB respectively,
It is named as Solr1 and Solr2;The Solr example an of pattern ram is created again, and distributes the memory of 16GB, is named as Solr3.
Likewise, similarly creating the Solr example of two NRT modes on the disk of second server, the interior of 8GB is distributed respectively
It deposits, and is named as Solr4 and Solr5;The Solr example an of pattern ram is created again, and distributes the memory of 16GB, is named as
Solr6。
Multiple ColdCollection set for storing full dose data (being defaulted as cold data) are created, configure 4
Shard provides service by the Solr example of Solr1, Solr2, Solr4 and Solr5 this four NRT modes jointly.Creation one
For storing the set of dsc data, it is named as HotCollection, configures 2 Shard, there are the two RAM of Solr3 and Solr6
The Solr example of mode provides service jointly.
Data to be indexed be certain districts and cities cross car data, including unique number, license plate number, cross the vehicle time, cross the vehicle date,
Vehicle characteristics etc., corresponding schema file setting are shown in Table 1.
Car data is crossed by 1 certain districts and cities of table
Serial number | name | type | indexed | stored | Explanation |
1 | Id | string | true | true | Number |
2 | PlateNo | string | true | false | License plate number |
3 | PassDate | pdate | true | false | Spend the vehicle date |
4 | PassTime | pTime | true | false | Spend the vehicle time |
5 | IMGUrl | string | true | false | Picture address |
6 | Address | string | true | false | Shoot address |
7 | Other | string | true | false | Other features |
Over time, cross car data can continual real time indexing into Solr set.Comparatively, time interval
From closer crossing, car data is more significant for users and searching times can be more, and the remoter car data of crossing of time gap is searched
The number of rope can be fewer.
Shown in referring to figs. 5 and 6, it is based on the above business scenario, by nearest one month data dynamic memory to set
Search service is provided as dsc data in " HotCollection ";Full dose is crossed car data not deposited according to the vehicle time excessively by month
It stores up in different ColdCollection.
For storing the set " HotCollection " of dsc data, if current time is on October 26th, 2018,
In the crossing car data as dsc data storage to " HotCollection " and gather of September in 2018 on October 26th, 26 days 1,
And subsequent car data of crossing can constantly index " HotCollection " set.When the time is i.e. 2018 10 by second day
At months 27 days, the dsc data that stores in set is to cross car data on the October 27th, 27 days 1 of September in 2018, before 2018
The car data excessively on October 26, in can be rejected from set, and so on.
For storing full dose data, that is, cold data set, if current time is in October, 2018, the month
It is all cross car datas can be stored in the cold set for being named as " ColdCollection201810 ", entered when the time
When in November, 2018, crossing car data can be stored in automatically in the cold set for being named as " ColdCollection201811 ", with
This analogizes.
During search service, when system receives searching request, the commencement date and deadline of search condition is first determined whether.
If the commencement date and deadline of search condition in the date range of current dsc data collection, only searches in dsc data concentration
Rope data simultaneously return, and otherwise need to concentrate search data in cold data.Such as: the commencement date and deadline of search condition is 2018 10
On October 12nd, 11 days 1 moon, and the date of current dsc data collection is on the October 26th, 26 days 1 of September in 2018, then
It concentrates and searches in dsc data.
If the commencement date and deadline of search condition, need to be corresponding cold not all in the date range of current dsc data collection
Data are searched in data set.Such as: the commencement date and deadline of search condition is on the October 5th, 20 days 1 of September in 2018, then needs to search
The cold data collection of rope is " ColdCollection201809 " and " ColdCollection201810 ".
The final result composition search result set retrieved, returns to user as final inspection for described search result set
Hitch fruit.
As can be seen from the above embodiments beneficial effect existing for the application is:
First, cold data collection is logically and physically split into multiple sub- cold data collection by the present invention, is being provided
When search service, can logically rapid drop set to be searched range, more computing resources are used for lesser data
Collection, improves search speed.
Second, the present invention will be shot straight, searched hot number often using the mode of hot and cold data dynamic adjustment
According to collection storage into expensive and limited memory, provide one design on caching, by long-time miss or by
The lower cold data collection of search rate is stored in the disk or hard disk that price is cheap and search speed is relatively slow, greatly
Search speed is improved, and improves the experience of user and the search performance of system.
Third, the present invention is by creating at least one Solr example, composition one in each disk on single server
A SolrCloud, takes full advantage of the cheap disk resource of the price of server, and the data on monolithic disk are assigned to muti-piece
On disk, in the case where same data set, muti-piece disk can carry out disk read operation simultaneously, greatly improve data reading
The speed taken is reduced because reading data due to the time-consuming caused by entire search service.
Above by drawings and examples, example is passed through to of the invention one although doing to technical solution of the present invention
A little specific embodiments are described in detail, but it should be appreciated by those skilled in the art example above is merely to carry out
Illustrate, the range being not intended to be limiting of the invention.Although the present invention is described in detail referring to the foregoing embodiments, right
For those skilled in the art, it can still modify to technical solution documented by previous embodiment or right
Part of technical characteristic is equivalently replaced.All within the spirits and principles of the present invention, it is made it is any modification, equally replace
It changes, improve, should all be included in the protection scope of the present invention.The scope of the present invention is defined by the appended claims.
Claims (7)
1. a kind of optimization method of near real-time search service, which is characterized in that comprising steps of
SolrCloud is created, comprising steps of
At least one Solr example is created on each piece of disk of server, wherein the number of servers is at least one,
The Solr example includes the Solr example of NRT mode and the Solr example of pattern ram;
Each Solr example on each piece of disk is named, and storage allocation;
Dsc data collection is set: by the Solr example of the pattern ram, the institute that dsc data storage is specified to the dsc data collection
It states in server memory;
Cold data collection is set: by the Solr example of the NRT mode, the magnetic that cold data storage is specified to the cold data collection
In disk or solid state hard disk, while it is more than the data buffer storage of hit threshold to the clothes that the cold data, which is concentrated hit-count, automatically
It is engaged in device memory;
Receive new data to be indexed;
The new data to be indexed is handled and is stored by the cold data collection;
When the new data to be indexed is when the dsc data is concentrated, then retrieved in dsc data concentration;
When the new data to be indexed not the dsc data concentrate when, then the cold data concentration retrieved;
When the new data part to be indexed is when the dsc data is concentrated, then in the dsc data collection and the cold data collection
It is middle to be retrieved respectively.
2. the optimization method of near real-time search service according to claim 1, which is characterized in that when the cold data is concentrated
When cold data is searched or the number of hit is more than the hit threshold, then the cold data is added from cold data concentration
The dsc data is added to concentrate;
When the dsc data that the dsc data is concentrated is more than that also searched or hit-count is not lower than frequency threshold value to time threshold
When, then the dsc data is concentrated from the dsc data and is rejected.
3. the optimization method of near real-time search service according to claim 1, which is characterized in that concentrated in the cold data
It is retrieved, further the sub- cold data collection where positioning the new data to be indexed to be concentrated in the cold data, in institute
It states sub- cold data and concentrates row retrieval.
4. the optimization method of near real-time search service according to claim 1, which is characterized in that the dsc data is to be searched
Rope or hit-count are more than the data of the hit threshold.
5. the optimization method of near real-time search service according to claim 1, which is characterized in that the cold data be lower than
The time threshold is not searched or hit-count is lower than the data of the frequency threshold value.
6. the optimization method of near real-time search service according to claim 1, which is characterized in that the cold data collection is complete
Measure data set, including dsc data collection.
7. the optimization method of near real-time search service according to claim 1, which is characterized in that each piece of disk
Total memory is equal.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811580863.5A CN109656978A (en) | 2018-12-24 | 2018-12-24 | The optimization method of near real-time search service |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811580863.5A CN109656978A (en) | 2018-12-24 | 2018-12-24 | The optimization method of near real-time search service |
Publications (1)
Publication Number | Publication Date |
---|---|
CN109656978A true CN109656978A (en) | 2019-04-19 |
Family
ID=66116340
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201811580863.5A Pending CN109656978A (en) | 2018-12-24 | 2018-12-24 | The optimization method of near real-time search service |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN109656978A (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110083627A (en) * | 2019-04-28 | 2019-08-02 | 江苏满运软件科技有限公司 | Data processing method, system, computer equipment and storage medium |
CN110399451A (en) * | 2019-06-29 | 2019-11-01 | 苏州浪潮智能科技有限公司 | A kind of full-text search engine caching method based on Nonvolatile memory, system, equipment and readable storage medium storing program for executing |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102129472A (en) * | 2011-04-14 | 2011-07-20 | 上海红神信息技术有限公司 | Construction method for high-efficiency hybrid storage structure of semantic-orient search engine |
CN102693308A (en) * | 2012-05-24 | 2012-09-26 | 北京迅奥科技有限公司 | Cache method for real time search |
CN103488687A (en) * | 2013-09-02 | 2014-01-01 | 用友软件股份有限公司 | Searching system and searching method of big data |
CN104781810A (en) * | 2012-09-28 | 2015-07-15 | 甲骨文国际公司 | Tracking row and object database activity into block level heatmaps |
-
2018
- 2018-12-24 CN CN201811580863.5A patent/CN109656978A/en active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102129472A (en) * | 2011-04-14 | 2011-07-20 | 上海红神信息技术有限公司 | Construction method for high-efficiency hybrid storage structure of semantic-orient search engine |
CN102693308A (en) * | 2012-05-24 | 2012-09-26 | 北京迅奥科技有限公司 | Cache method for real time search |
CN104781810A (en) * | 2012-09-28 | 2015-07-15 | 甲骨文国际公司 | Tracking row and object database activity into block level heatmaps |
CN103488687A (en) * | 2013-09-02 | 2014-01-01 | 用友软件股份有限公司 | Searching system and searching method of big data |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110083627A (en) * | 2019-04-28 | 2019-08-02 | 江苏满运软件科技有限公司 | Data processing method, system, computer equipment and storage medium |
CN110083627B (en) * | 2019-04-28 | 2021-08-24 | 江苏满运软件科技有限公司 | Data processing method, system, computer device and storage medium |
CN110399451A (en) * | 2019-06-29 | 2019-11-01 | 苏州浪潮智能科技有限公司 | A kind of full-text search engine caching method based on Nonvolatile memory, system, equipment and readable storage medium storing program for executing |
CN110399451B (en) * | 2019-06-29 | 2021-11-26 | 苏州浪潮智能科技有限公司 | Full-text search engine caching method, system and device based on nonvolatile memory and readable storage medium |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102521405B (en) | Massive structured data storage and query methods and systems supporting high-speed loading | |
CN102521406B (en) | Distributed query method and system for complex task of querying massive structured data | |
CN101216821B (en) | Data acquisition system storage management method | |
CN105930428B (en) | For executing the method and system of the interleaved connection in multi-tenant storage | |
CN103853727B (en) | Improve the method and system of big data quantity query performance | |
CN102214176B (en) | Method for splitting and join of huge dimension table | |
US9454572B2 (en) | Out-of-place materialized view refresh | |
CN103176754A (en) | Reading and storing method for massive amounts of small files | |
CN105631003A (en) | Intelligent index establishing, inquiring and maintaining method supporting mass data classification and counting | |
CN103366015A (en) | OLAP (on-line analytical processing) data storage and query method based on Hadoop | |
CN110188080A (en) | Telefile Research of data access performance optimization based on client high-efficiency caching | |
CN101916302A (en) | Three-dimensional spatial data adaptive cache management method and system based on Hash table | |
CN105117417A (en) | Read-optimized memory database Trie tree index method | |
CN110058822A (en) | A kind of disk array transverse direction expanding method | |
CN106354805A (en) | Optimization method and system for searching and caching distribution storage system NoSQL | |
CN103399945A (en) | Data structure based on cloud computing database system | |
CN111552885B (en) | System and method for realizing automatic real-time message pushing operation | |
CN108509437A (en) | A kind of ElasticSearch inquiries accelerated method | |
Hu et al. | Indexing techniques for wireless data broadcast under data clustering and scheduling | |
CN103473276A (en) | Storage method of very large data and distributed database system and retrieval method thereof | |
CN110309233A (en) | Method, apparatus, server and the storage medium of data storage | |
CN111159176A (en) | Method and system for storing and reading mass stream data | |
CN109656978A (en) | The optimization method of near real-time search service | |
CN109828975A (en) | A kind of extensive quick account book access system based on block chain | |
CN104391961A (en) | Tens of millions of small file data read and write solution strategy |
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 | ||
RJ01 | Rejection of invention patent application after publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20190419 |