CN116737664A - Efficient index organization method of object-oriented embedded database - Google Patents
Efficient index organization method of object-oriented embedded database Download PDFInfo
- Publication number
- CN116737664A CN116737664A CN202311013916.6A CN202311013916A CN116737664A CN 116737664 A CN116737664 A CN 116737664A CN 202311013916 A CN202311013916 A CN 202311013916A CN 116737664 A CN116737664 A CN 116737664A
- Authority
- CN
- China
- Prior art keywords
- data
- offset
- index
- page
- data object
- 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.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 20
- 230000008520 organization Effects 0.000 title claims abstract description 11
- 239000000872 buffer Substances 0.000 claims description 8
- 238000013508 migration Methods 0.000 claims description 7
- 230000005012 migration Effects 0.000 claims description 7
- 238000013144 data compression Methods 0.000 claims description 5
- 238000007726 management method Methods 0.000 description 8
- 238000013500 data storage Methods 0.000 description 5
- 238000012217 deletion Methods 0.000 description 5
- 230000037430 deletion Effects 0.000 description 5
- 238000004364 calculation method Methods 0.000 description 4
- 238000007906 compression Methods 0.000 description 3
- 230000006835 compression Effects 0.000 description 3
- 238000003780 insertion Methods 0.000 description 3
- 230000037431 insertion Effects 0.000 description 3
- 238000013459 approach Methods 0.000 description 2
- 230000003139 buffering effect Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 239000012634 fragment Substances 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 238000013507 mapping Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000007493 shaping process Methods 0.000 description 2
- 239000002699 waste material Substances 0.000 description 2
- 238000009825 accumulation Methods 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000001680 brushing effect Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 239000008358 core component Substances 0.000 description 1
- 238000013479 data entry Methods 0.000 description 1
- 238000013523 data management Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000002688 persistence Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/11—File system administration, e.g. details of archiving or snapshots
- G06F16/119—Details of migration of file systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/13—File access structures, e.g. distributed indices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/21—Design, administration or maintenance of databases
- G06F16/214—Database migration support
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/22—Indexing; Data structures therefor; Storage structures
- G06F16/2228—Indexing structures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/289—Object oriented databases
Abstract
The invention discloses an efficient index organization method of an object-oriented embedded database, which comprises the following steps: constructing an index structure and a number multiplexing structure aiming at a storage space applied by an embedded database; establishing an object number for each data object in the index structure and storing the offset in the storage space; the number multiplexing structure is used for storing the object number corresponding to the deleted data object; when writing a data object A, firstly inquiring whether an object number exists in the number multiplexing structure; if not, generating an object number for the data object A in the index structure and storing the offset of the data object A in the storage space at a corresponding position; if so, selecting an object number from the object numbers, moving the object numbers into an index structure, and storing the offset of the data object A in a storage space at a corresponding position; when a data object B is deleted from the storage space, the object number of the data object B in the index structure is moved into the number multiplexing structure.
Description
Technical Field
The invention belongs to the technical field of computer software, and particularly relates to an efficient index organization method of an object-oriented embedded database.
Background
At present, the application field of the embedded database is rapidly developed, and with the gradual improvement of the specifications of bottom hardware such as a current processor, a memory, a magnetic disk and the like, the construction of an embedded operating system is gradually perfected, and the embedded database has new requirements on the aspect of data persistence while ensuring the real-time data operation. The storage engine in the embedded database is a core component for realizing data storage of the database, and the architecture design of the storage engine influences a series of database core functions such as data entry speed, retrieval efficiency, memory, file occupation and the like. The main function of the storage engine is data organization, different data storage formats are designed according to the characteristics of different storage media such as memory, magnetic disk and the like so as to optimize the efficiency of data storage access, and how to organize the bottom index of the embedded database can store data more efficiently becomes one of main research directions.
In conventional general-purpose relational databases, most databases use Hash indexes or b+ trees as the underlying organization of data files, such as Redis and InnodB and MyISAM storage engines in MySQL. In an embedded environment, because resources are limited, the page structure of the b+ tree needs to store pointers or offsets of pages at each level, offsets of data blocks, and the like, so that more redundant memory and disk space are needed. Meanwhile, the B+ tree index can only retrieve disk pages or records, and other structures such as metadata, data tables, index structures and the like are required to be designed for storage management for other objects created in the database, so that the embedded database architecture has higher overall complexity and does not have a unified data management architecture.
Disclosure of Invention
Aiming at the problems existing in the prior art, the invention aims to provide an object-oriented efficient index organization method (OOMI) of an embedded database, which can reduce occupied memory and disk space as much as possible under the condition of ensuring query efficiency, and uses a unified storage architecture for managing all data objects in the embedded database. In terms of time complexity, if a B+ tree index commonly used in the database field is used, the time complexity of inquiring one piece of data is O (Log n), and finishing operations such as merging and splitting of tree nodes exist during data input, so that extra management and calculation resources are consumed; the time complexity of the index provided by the invention for inquiry is O (1), and the fixed length characteristic based on the array does not have the adjustment condition of an index structure.
In the aspect of occupied space, taking InnoDB as an example, under the condition that actual data are the same, each management node of the InnoDB needs to additionally store 14 bytes of data, and the management structure of the object-oriented hybrid index disclosed by the invention needs to be 8 bytes in size, so that the occupied space is saved by more than 40%.
The technical scheme of the invention is as follows:
an efficient index organization method of an object-oriented embedded database, comprising the following steps:
constructing an index structure and a number multiplexing structure aiming at a storage space applied by an embedded database; the index structure is used for managing various types of data objects stored in the storage space; establishing an object number for each data object in the index structure and storing the offset in a storage space; the number multiplexing structure is used for storing the object number corresponding to the deleted data object;
when a data object A is written in the storage space, firstly inquiring whether an object number exists in the number multiplexing structure; if no object number exists, generating an object number for the data object A in the index structure and storing the offset of the data object A in a storage space at a corresponding position; if the object number exists, selecting an object number from the object numbers, moving the object number into the index structure, and storing the offset of the data object A in the storage space at a corresponding position;
when deleting a data object B in the storage space, the object number of the data object B in the index structure is moved into the number multiplexing structure.
Further, the memory space corresponding to the index structure is a continuous array, and the object number of the data object corresponds to the subscript of the array one by one.
Further, each position of the array is used for storing the offset of the data object corresponding to the object number; the offset stored in the array position corresponding to the unoccupied object number is set as a default value.
Further, when the embedded database is searched, the object number i of the corresponding data object is obtained according to the object number information input during the search, and then the offset corresponding to the object number i is searched in the index structure according to the object number iOffsThe method comprises the steps of carrying out a first treatment on the surface of the The offset is then usedOffsDivided by page sizeSpAnd rounding down to obtain the file page number to be extractedNpWill offsetOffsFor page sizeSpTaking the remainder to obtain the offset of the data object in the pageP Offs =Offs%S p The method comprises the steps of carrying out a first treatment on the surface of the The page number is then passed through the storage engineNpThe corresponding disk page is fetched into the memory or the page number is queried in the buffer zoneNpCorresponding page P, using the offsetP Offs The queried data object is obtained from the page P.
Furthermore, when the embedded database performs data file migration, the index structure and the number multiplexing structure are used as a file to perform data compression and data migration.
Further, object numbers of the data objects of each type are generated using the same number sequence.
Further, the data object comprises metadata, an index node and a data record.
The invention has the following characteristics:
1. in terms of retrieval complexity, the object-oriented hybrid index can be used for inquiring the corresponding data object within the time complexity of O (1), so that the data inquiry speed is increased, and the calculation resources required by data retrieval are reduced.
2. In terms of disk IO performance, in an object-oriented hybrid index, because the index structure is generally a full amount of resident memory, a required data page can be calculated after the offset is obtained, and therefore disk IO overhead is one time.
3. An object number multiplexing structure is introduced, and in combination with the index structure, the deleted object number ONum can be multiplexed.
4. The idle bit can enable the object offset to carry type information, and comparison can enable the database to have internal verification capability when in operation during data retrieval.
5. For all types of data objects, they are identified by ONum, and multiple meaning data objects can be stored using one index structure. The complexity of the overall architecture is reduced compared to other indexing approaches.
The invention has the following advantages:
compared with the B+ tree index, the method for organizing the object-oriented hybrid index has the advantages that the accurate retrieval speed of the index structure is higher, and the method is more suitable for being used as a main index and an auxiliary index of a data file to be matched and called for data retrieval. The management information of the object-oriented hybrid index is not provided with other redundant information, is all effective data load, has higher utilization rate, can save limited computing storage resources in an embedded environment, and is more suitable for data file organization of an embedded database.
Compared with the hash index, the index structure query speed in the invention is not affected by the data volume, and the object-oriented hybrid index can still keep the retrieval time complexity of O (1) when the data volume is increased.
The object-oriented hybrid index in the invention manages the data objects used in all embedded databases, has higher flexibility, and can be optimized for different data objects in various queries.
Drawings
FIG. 1 is a block diagram of an object-oriented hybrid index.
Detailed Description
The invention will now be described in further detail with reference to the accompanying drawings, which are given by way of illustration only and are not intended to limit the scope of the invention.
Aiming at the data storage and processing requirements in the embedded environment, the invention has higher requirements on the real-time performance and the reliability of the system due to low power consumption, small volume and relatively limited storage and calculation resources of the embedded environment.
The main structure of the object-oriented hybrid index is shown in fig. 1, wherein the index structure provided by the invention is based on the unified storage space of the embedded database application, and the unified index structure is created for all types of data objects to manage on the basis of the storage space. In the design, an object number, namely ONum, is established for each data object, and the same number sequence is used for different types of data objects, such as metadata, index nodes, data records and the like. When in use, firstly, the memory space for storing the data object index structure is initialized, the memory space is of a continuous array structure, based on the characteristic that the object numbers are sequentially increased, the memory space and the subscripts of the arrays can have a one-to-one mapping relation, and under ideal conditions (such as counting from 0), the memory space and the subscripts can be completely consistent, such as object numbers 1-5 in fig. 1, and when in initialization, the data of each position in the object index space is set as the maximum value of offset to be expressed as an unused quantity. After the initialization of the object index space, along with the creation of the data objects such as meta information, index, data, etc., the offset of each data object is stored in the object index space, for example, for the object Obj1 in fig. 1, the offset Offs1 of Obj1 is stored at the position of the index 1 in the object index space. The actual data arrangement may be either continuous or discrete as long as the byte alignment requirements are met.
When the pointed data object is deleted, as in number 5 in fig. 1, the data object of Obj5 is deleted. After the mark deletion is performed in the storage space, the corresponding object number 5 is put into the number multiplexing structure, and the stored offset is set to a default value (maximum value). When a new data object is assigned a data number next time, an available object number is first acquired from the multiplexing structure for use, and the offset of the new data object in the storage space is stored into the space with index 5.
Firstly, corresponding accumulated object numbers ONum are established for each object reference in the database, the meaning of the accumulated numbers is similar to that of a main key of the database, the embedded database establishes a main index of a storage space by taking the ONum as a key, and the ONum can be mapped with the initialized object index space index one by one due to sequential accumulation, so that the mapping relation between the object numbers and the object offset is established.
Pre-allocating a memory space with a certain length to store the offset corresponding to the object numberOffsThe offset records the offset difference of the subject relative to the initial position of the database storage space. In the conventional index organization based on the array, due to deletion, modification and the like of data corresponding to numbers, the positions of the data are reserved, but offset information in the data is deleted, so that a large number of internal fragments can appear in a memory, and the utilization rate of limited memory resources is reduced. In order to avoid the situation of excessive internal fragments in the memory, the invention uses a number multiplexing structure to be combined with an object index space for use, records the deleted object number, checks the number multiplexing structure when in next allocation, and performs quick allocation and reuse if a reusable idle number exists. The queue structure may be an array or a linked list of a single structure, and the time space complexity of the linked list and the array is the same in the use case. The multiplexing structure can be realized by using an ordered queue structure under different scenes, so that the memory blocks in front are filled preferentially, and the utilization rate is higher.
Due to embedded environment resource limitations and relatively simple usage requirements, embedded databases store data using a single data file. Wherein, the data objects in the database file and the memory include but are not limited to: page objects, data objects, table objects, inode objects, and the like. In allocating space for various data objects, it is necessary toAt 2 n Byte alignment is performed by taking bytes as a minimum unit, default data is performed by byte alignment according to 16 bytes, and n is 4. Therefore, the last n bits of each offset can be used as idle bits to store the data object type corresponding to the data stored by the offset in the form of enumeration coding, for example, metadata object coding is 0001, b-tree auxiliary index node data object coding is 0010, and data object coding is 0100. The operation of bit and by using the n-bit check code and the code of the data object type after reading can verify the acquired data type, which is equivalent to additionally storing the information of the object type in the data of an offset. And because a unified index management mode is used for all data objects used in the database, the embedded database can use a single complete storage space to store all data information such as metadata and user data.
The buffers mentioned here have different implementations in different databases, for example, in case the embedded file system is simpler to implement for file page buffering, the relevant page buffering can be implemented by the embedded database, enabling page swapping with the disk. In the cache, a page is marked as a dirty page and is flushed when writing, updating, deleting or the like operations are performed on data of a certain part of the page. When the file system realizes the caching mechanism better, the memory buffer area with an indefinite length can be realized in a linked list mode and the like, and the time for physically brushing the disk can be decided by the bottom operating system.
The object-oriented hybrid indexing approach, when implemented, shares several aspects:
1. index initialization
Before the OOMI is used, an object index space OFFS_ARR is required to be initialized, an array of a fixed-length space is firstly applied to a memory, the array type is determined according to the number of bits of an operating system, an unsigned four-byte shaping array is used in a 32-bit system, and an unsigned eight-byte shaping array is used in a 64-bit system, so that the offset can cover the memory space, and the space waste is reduced as far as possible. The location of each stored offset in the array is initialized to a default value (maximum value) of the corresponding type after the space application is completed.
For the storage space of data, the data file is mapped to a continuous memory space, the data file is organized and arranged by taking pages as units, and the page space is generally 4K-16K, so that the writing and reading efficiency is improved.
An unsigned four-byte or eight-byte variable num_in_use is declared at the database file header to store how many object numbers are used in the current database. And applies for a number multiplexing structure for storing the released object numbers for multiplexing when applying for the object numbers next time.
2. Data insertion
When data insertion is performed, firstly, the data type of the data object currently inserted into the storage space of the database needs to be clarified, the size of the data object is calculated, and the object number is allocated. When the object numbers are allocated, firstly, whether values exist in the number multiplexing structure or not is searched, if so, the corresponding object numbers ONum are dequeued and used as ONum of the current data object. If there is no object number in the number multiplexing structure that can be multiplexed, the number in the data file header is used to use the number num_in_use as the ONum of the data object currently to be inserted, and the num_in_use value is incremented by one.
And acquiring the position to be stored and the storage space offset of the corresponding data object through a memory management module. And performing bit operation coding assignment on the check code of the last n bits according to the type of the inserted object.
3. Data query
When searching database file, firstly, the user accesses logic such as data with query ID less than X to call auxiliary index built on ID field to confirm object number, or the user maintains object number information to directly obtain object number ONum of corresponding data object, and then searches in object index space with object number as index to obtain offset of object numberOffs. First dividing the offset by the page sizeSpAnd rounding downObtaining the file page number to be extracted, and taking the offset to the page size to obtain the offset of the data object in the pageP Offs =Offs% S p . Fast page number calculation by storage engineNpThe corresponding disk page is fetched into the memory or is queried in the buffer zoneNpCorresponding page P and using calculated page offsetP Offs The actual data object is retrieved from page P.
Since the object-oriented hybrid index is a hash index, in principle ordering and scope queries are not supported except special handling, and related operations can be done in queries using auxiliary indexes. The auxiliary index is created by a user, is built on a certain field, uses structures such as a B tree, a T tree, a hash table and the like to index data, and stores a value which is the object number of the current record. When the range search is needed, searching is firstly carried out in an auxiliary index supporting the range search, the obtained object numbers are stored in a result set, and then the object numbers ONum are used for searching in the OOMI main index, so that the real position of the data object is obtained.
In terms of query performance, the query time complexity of the object-oriented hybrid index is O (1), and is O (1) compared with the conventional hash index, but the hash index also needs to traverse the coincidence linked list or use other methods to search for two times when hash conflicts exist, and in the worst case, the time complexity is O (n), and the object-oriented hybrid index has no data conflict due to the limitation of the unique object number. Compared with the B+ tree, the time complexity of the B+ tree query is O (Log n) which is longer than the time complexity of the index O (1).
4. Data deletion
In performing a delete operation of a data object in the storage space, the actual data object in the buffer needs to be processed first. Depending on the manner in which the buffers are managed, the data objects in the buffers may be selected to be emptied or marked as deleted. Meanwhile, the offset position of the corresponding data object needs to be set to a default value in the object index space, indicating that the data object has been deleted.
After the deletion operation is completed, the object numbers of the deleted data objects need to be stored in the number multiplexing structure so that these spaces can be reused at the next allocation. By storing the object numbers of the deleted data objects in the number multiplexing structure, multiplexing of the object numbers can be achieved, and frequent memory allocation operations are avoided.
The deletion and multiplexing strategy can effectively manage the objects in the data file and improve the efficiency and performance of data storage. The released space can be fully utilized through the deleted multiplexing, and the continuous expansion and waste of the data file are avoided. Meanwhile, the object numbers of the deleted data objects are stored in a queue mode, so that the next space allocation can be conveniently carried out, and the management and utilization efficiency of the data files is improved.
5. Data migration
When the embedded database performs data file migration, the object-oriented hybrid index in the invention can be independently used as a file for data compression and data migration. And because the index structure is mostly stored with continuous offset of data under the use scene of a general embedded environment, the size variance of each record is smaller under the scene of sequential insertion, and the index structure is suitable for data compression of the offset by using second-order differential coding. Differential value array for obtaining differential value after using second order differential codingArr dd In the case of data of all fixed lengthArr dd Compression using LZW coding will result in a very high compression ratio, which will contain a large amount of 0. When there is a variable-length data in the data,Arr dd the stored difference will also be smaller, where data compression of smaller integer types using the Zig-Zag algorithm on the index data will result in a higher compression ratio.
Although specific embodiments of the invention have been disclosed for illustrative purposes, it will be appreciated by those skilled in the art that the invention may be implemented with the help of a variety of examples: various alternatives, variations and modifications are possible without departing from the spirit and scope of the invention and the appended claims. Therefore, it is intended that the invention not be limited to the particular embodiment disclosed as the best mode contemplated for carrying out this invention, but that the invention will have the scope indicated by the scope of the appended claims.
Claims (7)
1. An efficient index organization method of an object-oriented embedded database, comprising the following steps:
constructing an index structure and a number multiplexing structure aiming at a storage space applied by an embedded database; the index structure is used for managing various types of data objects stored in the storage space; establishing an object number for each data object in the index structure and storing the offset in a storage space; the number multiplexing structure is used for storing the object number corresponding to the deleted data object;
when a data object A is written in the storage space, firstly inquiring whether an object number exists in the number multiplexing structure; if no object number exists, generating an object number for the data object A in the index structure and storing the offset of the data object A in a storage space at a corresponding position; if the object number exists, selecting an object number from the object numbers, moving the object number into the index structure, and storing the offset of the data object A in the storage space at a corresponding position;
when deleting a data object B in the storage space, the object number of the data object B in the index structure is moved into the number multiplexing structure.
2. The method of claim 1, wherein the memory space corresponding to the index structure is a continuous array, and the object numbers of the data objects are in one-to-one correspondence with the subscripts of the array.
3. The method of claim 2, wherein each location of the array is used to store an offset of a data object corresponding to an object number; the offset stored in the array position corresponding to the unoccupied object number is set as a default value.
4.The method according to claim 1, wherein, when the embedded database is searched, the object number i of the corresponding data object is obtained according to the object number information input during the search, and the offset corresponding to the object number i is searched in the index structure by using the object number iOffsThe method comprises the steps of carrying out a first treatment on the surface of the The offset is then usedOffsDivided by page sizeSpAnd rounding down to obtain the file page number to be extractedNpWill offsetOffsFor page sizeSpTaking the remainder to obtain the offset of the data object in the pageP Offs =Offs%S p The method comprises the steps of carrying out a first treatment on the surface of the The page number is then passed through the storage engineNpThe corresponding disk page is fetched into the memory or the page number is queried in the buffer zoneNpCorresponding page P, using the offsetP Offs The queried data object is obtained from the page P.
5. The method of claim 1, wherein the index structure and the number multiplexing structure are used as a file for data compression and data migration when the embedded database performs data file migration.
6. The method according to any one of claims 1 to 5, wherein the object numbers of the data objects of each type are generated using the same number sequence.
7. The method of any one of claims 1-5, wherein the data object includes metadata, an inode, and a data record.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311013916.6A CN116737664B (en) | 2023-08-14 | 2023-08-14 | Efficient index organization method of object-oriented embedded database |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311013916.6A CN116737664B (en) | 2023-08-14 | 2023-08-14 | Efficient index organization method of object-oriented embedded database |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN116737664A true CN116737664A (en) | 2023-09-12 |
| CN116737664B CN116737664B (en) | 2023-11-14 |
Family
ID=87911760
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311013916.6A Active CN116737664B (en) | 2023-08-14 | 2023-08-14 | Efficient index organization method of object-oriented embedded database |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116737664B (en) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6349308B1 (en) * | 1998-02-25 | 2002-02-19 | Korea Advanced Institute Of Science & Technology | Inverted index storage structure using subindexes and large objects for tight coupling of information retrieval with database management systems |
| CN108388569A (en) * | 2018-01-09 | 2018-08-10 | 杭州电子科技大学 | A kind of system and method for building up of quick key value database |
| CN112637616A (en) * | 2020-12-08 | 2021-04-09 | 网宿科技股份有限公司 | Object storage method, system and server |
| CN115757462A (en) * | 2022-11-15 | 2023-03-07 | 中国科学院软件研究所 | Object-oriented database dynamic interface generation method and operation method |
-
2023
- 2023-08-14 CN CN202311013916.6A patent/CN116737664B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6349308B1 (en) * | 1998-02-25 | 2002-02-19 | Korea Advanced Institute Of Science & Technology | Inverted index storage structure using subindexes and large objects for tight coupling of information retrieval with database management systems |
| CN108388569A (en) * | 2018-01-09 | 2018-08-10 | 杭州电子科技大学 | A kind of system and method for building up of quick key value database |
| CN112637616A (en) * | 2020-12-08 | 2021-04-09 | 网宿科技股份有限公司 | Object storage method, system and server |
| CN115757462A (en) * | 2022-11-15 | 2023-03-07 | 中国科学院软件研究所 | Object-oriented database dynamic interface generation method and operation method |
Also Published As
| Publication number | Publication date |
|---|---|
| CN116737664B (en) | 2023-11-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Ren et al. | SlimDB: A space-efficient key-value storage engine for semi-sorted data | |
| EP2633413B1 (en) | Low ram space, high-throughput persistent key-value store using secondary memory | |
| US4611272A (en) | Key-accessed file organization | |
| KR101792168B1 (en) | Managing storage of individually accessible data units | |
| KR100856245B1 (en) | File system device and method for saving and seeking file thereof | |
| US7831626B1 (en) | Integrated search engine devices having a plurality of multi-way trees of search keys therein that share a common root node | |
| WO2009033419A1 (en) | A data caching processing method, system and data caching device | |
| IL156117A (en) | Method and computer program for organising a database and a database organised according to such a method | |
| US6654868B2 (en) | Information storage and retrieval system | |
| AU2002222096A1 (en) | Method of organising, interrogating and navigating a database | |
| US8086641B1 (en) | Integrated search engine devices that utilize SPM-linked bit maps to reduce handle memory duplication and methods of operating same | |
| JP2007004801A (en) | Skip list with address-related table structure | |
| CN111459884B (en) | Data processing method and device, computer equipment and storage medium | |
| JP3024619B2 (en) | File management method | |
| Ramamohanarao et al. | Recursive linear hashing | |
| Amur et al. | Design of a write-optimized data store | |
| US7987205B1 (en) | Integrated search engine devices having pipelined node maintenance sub-engines therein that support database flush operations | |
| US8156126B2 (en) | Method for the allocation of data on physical media by a file system that eliminates duplicate data | |
| US7953721B1 (en) | Integrated search engine devices that support database key dumping and methods of operating same | |
| CN116737664B (en) | Efficient index organization method of object-oriented embedded database | |
| CN108804571B (en) | Data storage method, device and equipment | |
| Zobel et al. | Storage Management for Files of Dynamic Records. | |
| KR20190089420A (en) | Data construction and management system of sub index storage method | |
| Tomasic | Distributed queries and incremental updates in information retrieval systems | |
| Scheuermann et al. | Heuristic reorganization of clustered files |
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 |