CN114676139A

CN114676139A - Index data storage method, system, equipment and storage medium

Info

Publication number: CN114676139A
Application number: CN202210318308.5A
Authority: CN
Inventors: 王腾飞; 高传集; 李超; 孙思清; 肖雪
Original assignee: Inspur Cloud Information Technology Co Ltd
Current assignee: Inspur Cloud Information Technology Co Ltd
Priority date: 2022-03-29
Filing date: 2022-03-29
Publication date: 2022-06-28

Abstract

The application discloses an index data storage method, which is applied to an object storage system comprising a plurality of fragments and comprises the following steps: receiving the uploaded object; determining a fragment corresponding to the object; and storing the index data of the object in the determined fragment. By applying the scheme of the application, the situation that the disk resource of the node where the OSD is located is greatly consumed in the traditional scheme can not occur, and the stability of the object storage system can be guaranteed. The application also discloses an index data storage system, equipment and a storage medium, which have corresponding technical effects.

Description

Index data storage method, system, equipment and storage medium

Technical Field

The present invention relates to the field of storage technologies, and in particular, to a method, a system, a device, and a storage medium for storing index data.

Background

The object storage is object/file oriented mass cloud storage. An object store does not have a multi-level file structure like a file system, but rather has the concept of only one "bucket," i.e., storage space, otherwise known as a bucket. A "bucket" is a container for storing objects, i.e. objects, and is a very flat storage way. It is now common to employ Ceph as a back-end distributed object store.

Ceph is a unified, distributed storage system with excellent performance, high reliability and high scalability. The user uploads the object to the object storage bucket, and some metadata of the object needs to be stored in the bucket index, so that the object is convenient to search. In the current scheme, the index data of the bucket is stored in the form of an omap (Object-map) in the rockdb database of the node where the OSD (Object Storage Device) is located, so when the number of objects stored in a single bucket reaches a certain number, and when the operation of bucket list or Ceph silence check program deep-scrub is performed, the disk resource of the node where the OSD is located will be greatly consumed, thereby causing the OSD to be abnormal. In addition, too long deep-scrub time of the bottom layer may also cause slow request of the cluster, thereby causing performance jitter and affecting the stability of the storage system.

In summary, how to effectively store the index data and ensure the reliability of the storage is a technical problem that those skilled in the art are urgently required to solve.

Disclosure of Invention

The invention aims to provide an index data storage method, system, equipment and storage medium, which are used for effectively storing index data and ensuring the reliability of storage.

In order to solve the technical problems, the invention provides the following technical scheme:

an index data storage method applied to an object storage system comprising a plurality of fragments comprises the following steps:

receiving the uploaded object;

determining a fragment corresponding to the object;

and storing the index data of the object in the determined fragment.

Preferably, the determining the segment corresponding to the object includes:

calculating a hash value of the object name of the object;

the hash value is added to 2ⁿ-1, performing an and operation, and taking the fragment number and the fragment consistent with the value obtained by the and operation as the determined fragment corresponding to the object;

wherein n is a positive integer, and 2ⁿM denotes the current number of slices in the object storage system.

Preferably, the method further comprises the following steps:

and when the number of index data stored in any fragment in the object storage system reaches a preset number threshold, performing fragment expansion of the object storage system to increase the number of fragments in the object storage system.

Preferably, the performing fragmented expansion of the object storage system includes:

doubling the number of the fragments in the object storage system, and migrating the index data in each fragment before capacity expansion according to a preset migration rule;

wherein the migration rule comprises:

aiming at any index data stored in any fragment before capacity expansion, judging whether the (p + 1) th bit of a hash value of an object name of an object corresponding to the index data is 0 or not;

if so, keeping the index data in the current fragment of the index data;

if not, migrating the index data to a target fragment corresponding to the index data, wherein the number of the target fragment corresponding to the index data is equal to the fragment number + k of the index data at present;

wherein the number of the fragments in the object storage system is k before capacity expansion, and k is 2^pAfter the capacity expansion of the fragments is performed, the number of the fragments in the object storage system is 2 k.

Preferably, the migration of the index data in each segment before capacity expansion is performed in a circular traversal manner, and when the migration of the index data in any segment is performed, a read-write lock is applied to the segment.

Preferably, the method further comprises the following steps:

when receiving a write bucket index operation in the process of expanding the fragments, determining the fragments corresponding to the object according to the object appointed by the write bucket index operation;

judging whether the determined fragment is a source fragment before capacity expansion;

if the fragment is not the source fragment, determining that the fragment is a target fragment after capacity expansion, and performing write operation on the target fragment;

if the source fragment is the source fragment, judging whether the read-write lock is added to the source fragment;

if not, writing the source fragment;

and if so, performing write operation on the cache object, and performing write operation of the source fragment based on the cache object after the capacity expansion process is finished.

Preferably, the method further comprises the following steps:

when receiving a read bucket index operation in the process of expanding the fragments, determining the fragments corresponding to the objects according to the objects appointed by the write bucket index operation;

if the target fragment is not the source fragment, determining that the fragment is the target fragment after capacity expansion, and judging whether index data to be read exists in the target fragment;

if the index data to be read exists in the target fragment, performing reading operation;

if the index data to be read does not exist in the target fragment, judging whether a read-write lock is added to a source fragment corresponding to the target fragment;

if the source fragment corresponding to the target fragment is not provided with the read-write lock, returning an error prompt;

if the source fragment corresponding to the target fragment is added with a read-write lock, judging whether index data to be read exists in the source fragment corresponding to the target fragment, if so, performing read operation, otherwise, returning an error prompt;

if the source fragment exists, judging whether index data to be read exists in at least one position in the source fragment and the cache object; if so, performing read operation, otherwise, returning an error prompt.

An object storage system comprising a plurality of shards, the object storage system comprising:

the object receiving module is used for receiving the uploaded objects;

the fragment determining module is used for determining fragments corresponding to the object;

and the storage module is used for storing the index data of the object in the determined fragments.

An object storage device, comprising:

a memory for storing a computer program;

a processor for executing the computer program to implement the steps of the index data storage method as claimed in any one of the above.

A computer-readable storage medium, having stored thereon a computer program which, when executed by a processor, carries out the steps of the index data storage method of any one of the preceding claims.

By applying the technical scheme provided by the embodiment of the invention, the plurality of fragments are arranged in the object storage system, and after the uploaded object is received, the index data is not stored in the OSD node as in the traditional scheme, but the fragments corresponding to the object are determined, so that the index data of the object is stored in the determined fragments, namely, the index data is stored by utilizing the plurality of fragments, namely, the fragments are stored in a distributed manner, so that the condition that the disk resource of the node where the OSD is located is greatly consumed in the traditional scheme is avoided, and the stability of the object storage system is favorably ensured.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.

FIG. 1 is a flow chart of an embodiment of a method for storing index data according to the present invention;

FIG. 2 is a flowchart illustrating an implementation of receiving a write bucket index operation during a fragmentation expansion process according to an embodiment of the present invention;

fig. 3 is a flowchart illustrating an implementation of receiving a read bucket index operation during a fragment expansion process according to an embodiment of the present invention;

FIG. 4 is a schematic diagram of an index data storage system according to the present invention.

Detailed Description

The core of the invention is to provide an index data storage method, which does not greatly consume the disk resource of the node where the OSD is positioned in the traditional scheme and is beneficial to ensuring the stability of the object storage system.

In order that those skilled in the art will better understand the disclosure, the invention will be described in further detail with reference to the accompanying drawings and specific embodiments. It is to be understood that the described embodiments are merely exemplary of the invention, and not restrictive of the full scope of the invention. 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 invention.

Referring to fig. 1, fig. 1 is a flowchart illustrating an implementation of an index data storage method according to the present invention, where the index data storage method is applied in an object storage system including multiple segments, and the index data storage method includes the following steps:

step S101: and receiving the uploaded object.

Specifically, when a user uploads an object, i.e., an object, to a bucket of the object storage system, the user needs to record related metadata, including information such as the name of the object, the size of the object, the modification time, and ETAG, which are collectively referred to as index data.

Step S102: a slice corresponding to the object is determined.

According to the scheme of the application, the index data is stored by using the plurality of fragments, so that for any received object, the fragment corresponding to the object, namely the fragment used for storing the index data of the object, needs to be determined. Of course, the specific fragmentation rule corresponding to the object may be set and adjusted according to actual needs, for example, the fragmentation may be determined by modulo operation of the hash value of the object name.

Step S103: and storing the index data of the object in the determined fragment.

After the segment corresponding to the object is determined, the index data of the object may be saved in the determined segment. In practical applications, the index data may be stored in the form of a key-value in the omap of the board object. In addition, in some cases, each of the shard objects may be stored as multiple copies, for example, as 3 copies, and the corresponding index data also stores 3 copies, thereby ensuring the reliability of the metadata.

In an embodiment of the present invention, step S102 may specifically include:

calculating a hash value of an object name of the object;

the hash value is added to 2ⁿ-1 performing an and operation, and taking the fragment number and the fragment corresponding to the value obtained by the operation as the determined fragment corresponding to the object;

In this embodiment, the hash value of the object name of the object is calculated, and in one case, for example, n is 4, that is, the number m of slices currently in the object storage system is 16, and the hash value of the object name of the object calculated is 111111111111111110011101111010110. The hash value is compared with 2ⁿ-1 anding, i.e. anding 00000000000000000000000000001111, the result obtained being 0110, i.e. in this example, the slice number obtained after anding is 6, the determined corresponding to the objectThe fragment is a 6 th fragment, that is, the index data of the object is stored in the 6 th fragment in the following.

And it can be seen that the hash value of the object name is summed to 2ⁿ-1 and, which is equivalent to taking the last n bits of the hash value of the object name.

In this embodiment, the number m of fragments in the object storage system is set to the nth power of 2, and the fragment corresponding to the object is determined through the and operation, so that compared with performing a modulo operation on the hash value of the object name, the efficiency of the fragmentation is greatly improved.

In an embodiment of the present invention, the method may further include:

when the number of index data stored in any fragment in the object storage system reaches a preset number threshold, fragment expansion of the object storage system is carried out to increase the number of fragments in the object storage system.

In the scheme of the application, the index data is stored by using the plurality of fragments, namely, the index data is stored in a distributed manner, so that the condition that the disk resources of the nodes where the OSD is located are greatly consumed in the traditional scheme is avoided, and the stability of the object storage system is favorably ensured.

With the increase of uploaded objects, the situation that index data stored in each segment is more may occur, and for this reason, the capacity expansion of the segments may also be performed in the scheme of the present application, so that the index data in each segment is not excessive. Specifically, when it is detected that the number of index data stored in any 1 segment in the object storage system reaches a preset number threshold, segment expansion of the object storage system may be performed.

The specific way of performing the fragmented expansion may be various, as long as it is satisfied that the number of the fragments in the object storage system after the fragmented expansion exceeds the number before the expansion, for example, a specified number of fragments are added.

In a specific embodiment of the present invention, performing fragmented expansion of an object storage system may specifically include:

doubling the number of fragments in the object storage system, and migrating the index data in each fragment before capacity expansion according to a preset migration rule;

wherein the migration rule comprises:

if yes, the index data is kept in the current fragment of the index data;

wherein the number of the fragments in the object storage system is k before capacity expansion, and k is 2^pAfter the capacity expansion of the shards is performed, the number of shards in the object storage system is 2 k.

The implementation mode is beneficial to quickly migrating the index data. Specifically, in this embodiment, before the fragmentation, the number k of fragments in the object storage system is set to the power p of 2, and after the fragmentation expansion, the number of fragments is doubled, so that after the fragmentation expansion, the number of fragments in the object storage system is 2 k.

Each fragment before capacity expansion is a source fragment, each source fragment has a corresponding target fragment, and the correspondence relationship can be expressed as: the number + k of a source slice is the number of the target slice corresponding to that source slice.

After the fragmentation expansion is performed in this way, when any index data stored in any fragment is migrated, the storage location of the index data does not need to be determined through mapping operation, that is, the fragment to which the index data needs to be migrated does not need to be determined through the operation of step S102, but is directly determined according to the value of the (p + 1) th bit of the hash value of the object name of the object corresponding to the index data, so that the time consumption of the fragmentation expansion can be greatly reduced in this implementation manner. And because partial index data does not need to be migrated, the migration time of the index data can be reduced.

Such as the foregoing embodimentsIn the formula, the hash value of the object name of one object is 111111111111111110011101111010110. In the foregoing embodiment, the number of slices in the object storage system before capacity expansion is 16-2⁴The index data of the object is stored in the 6 th fragment, and after the expansion of the fragment is performed, the number of the fragments is changed from 16 to 32 to 2⁵. Since the 1 st bit to 8 th bit of the index data are: 11010110, the value of bit 5 is 1, so the index data is migrated to the target slice corresponding to the index data, in this example, the target slice number 22 is the slice number 6+16 where the index data is currently located. It can be understood that, for each index data stored in the 6 th slice, the above-mentioned manner may be adopted to determine whether the corresponding index data is retained in the 6 th slice or needs to be migrated to the 22 nd slice, respectively.

It should be noted that, in practical applications, when any index data in any partition is migrated, it may be determined whether the p +1 th bit of the hash value of the object name is 0 according to the above-described embodiment, so as to determine whether the index data needs to be migrated, and when it is determined that the index data needs to be migrated, it may be further determined whether the index data already exists in the target partition, because in some cases, during the migration process of the index data of the partition, a user performs a write operation on the index data on the target partition, and therefore, when it is determined that the index data already exists in the target partition, the index data on the source partition may be directly discarded.

In a specific embodiment of the present invention, migration of index data in each segment before capacity expansion is performed in a circular traversal manner, and when migration of index data in any segment is performed, a read-write lock is applied to the segment.

In this embodiment, the migration of the index data in each segment before capacity expansion is performed in a circular traversal manner, that is, the index data in each segment is migrated sequentially. And when the index data in any one fragment is migrated, only the read-write lock is added to the fragment, that is, the fragment is only readable and not writable, the read-write lock is not required to be added to other fragments, and after the index data migration process of any one fragment is finished, the read-write lock of the fragment can be released.

Further, in an embodiment of the present invention, referring to fig. 2, an implementation flowchart of receiving a write bucket index operation during a process of expanding a fragment in an embodiment may include:

step S201: when receiving a write bucket index operation in the process of expanding the capacity of the fragments, determining the fragments corresponding to the objects according to the objects appointed by the write bucket index operation;

step S202: judging whether the determined fragment is a source fragment before capacity expansion;

if not, executing step S203: determining the fragments as target fragments after capacity expansion, and performing write operation on the target fragments;

if the source fragment is the source fragment, step S204 is executed: judging whether a read-write lock is added to the source fragment;

if not, step S205 is executed: performing write operation on the source fragment;

if so, step S206 is executed: and performing write operation on the cache object, and performing source fragmentation write operation based on the cache object after the capacity expansion process is finished.

As described above, in the scheme of the present application, the impact on the user service is also small in the process of performing fragmentation capacity expansion. The embodiment specifically describes the situation that the bucket-writing index operation is received in the process of carrying out fragment expansion, and the user service is not influenced at all.

Specifically, when receiving a write bucket index operation, the write bucket index operation designates the current write object, so that the fragment corresponding to the object can be determined, that is, the pair is determined to be storedFragmentation of index data of objects, e.g. by computing hash values of object names of objects, and then summing 2ⁿ1 AND operation, the patch corresponding to the object can be determined, and it can be understood that 2 at this timeⁿThe number of slices in the object storage system after capacity expansion should be 2 k. For example, if the number of fragments before expansion is 16, the number of fragments after expansion is 32, and the hash value of the object name and the hash value of 31 are and-operated, so as to determine the fragment corresponding to the current write object.

After determining the fragment corresponding to the object, it can be determined whether the determined fragment is the source fragment before capacity expansion. The source fragment of the present application refers to each fragment before the current capacity expansion, and correspondingly, each fragment added after the current capacity expansion is a target fragment, for example, the number of fragments before the capacity expansion is 16, then the 16 fragments are source fragments, the number of fragments after the capacity expansion is 32, and then the 17 th to 32 th fragments are target fragments of the current capacity expansion. Certainly, for example, subsequent expansion is performed once again, and the number of the fragments becomes 64, then during the expansion this time, 32 fragments before the expansion are all the source fragments, and 32 fragments added after the expansion are all the target fragments.

Whether the determined fragment is the source fragment before capacity expansion can be judged according to the fragment number, if the determined fragment is not the source fragment, the determined fragment is the target fragment, and the read-write lock cannot be added to the target fragment, so that the write operation can be directly performed on the target fragment, and the user service cannot be influenced.

If the source fragment is the source fragment, whether the read-write lock is added to the source fragment needs to be further judged, and if not, the read-write lock can be directly written to the source fragment without affecting user service. If a read-write lock is added, in order not to affect user services, the embodiment may perform a write operation on the cache object first, where the cache object may specifically be a log object, for example, and of course, in other embodiments, other forms of cache objects may be selected, and index data to be written may be temporarily recorded. By writing the cache object, after the capacity expansion process is finished, the source fragment can be written based on the cache object, that is, each index data recorded in the cache object is written into the corresponding source fragment.

In an embodiment of the present invention, referring to fig. 3, an implementation flowchart of receiving a bucket reading index operation during a process of expanding a fragment in an embodiment may include:

step S301: when receiving a read bucket index operation in the process of expanding the fragments, determining the fragments corresponding to the objects according to the objects appointed by a write bucket index operation;

step S302: judging whether the determined fragment is a source fragment before capacity expansion;

if not, executing step S303: determining that the fragments are target fragments after capacity expansion, and judging whether index data to be read exist in the target fragments or not;

if the index data to be read exists in the target fragment, executing step S304: performing a read operation;

if the index data to be read does not exist in the target fragment, step S305 is executed: judging whether a read-write lock is added to a source fragment corresponding to a target fragment;

if the source fragment corresponding to the target fragment is not locked by reading and writing, step S306 is executed: returning an error prompt;

if the source fragment corresponding to the target fragment adds a read-write lock, step S307 is executed: judging whether the index data to be read exists in the source fragment corresponding to the target fragment, if so, executing the step S304: performing a read operation, otherwise executing step S306: returning an error prompt;

if the source fragment is the source fragment, step S308 is executed: judging whether index data to be read exists in at least one position in the source fragment and the cache object; if so, go to step S304: and performing a reading operation, otherwise, executing the step S306: and returning an error prompt.

The embodiment specifically describes the situation that the bucket reading index operation is received in the process of carrying out fragment expansion, and the user service is not influenced at all.

In the process of expanding the fragments, when receiving the operation of reading the bucket index, the fragments corresponding to the object can be determined according to the object specified by the operation of writing the bucket index, and then whether the determined fragments are the source fragments before expanding the capacity is judged.

If the determined fragment is not the source fragment, it is indicated that the determined fragment is the target fragment after capacity expansion, and it may be determined whether index data to be read exists in the target fragment. And if the index data to be read exists in the target fragment, directly reading, namely reading the index data in the target fragment. If the target fragment does not have the index data to be read, the index data may be in the source fragment and is not currently migrated to the target fragment, so that whether the read-write lock is added to the source fragment corresponding to the target fragment or not can be judged, and if the read-write lock is not added, the index data is not in the source fragment, the error may occur in the current bucket-reading index operation or the index data is lost, so that an error prompt can be returned. If the source fragment is added with the read-write lock, whether the index data to be read exists in the source fragment can be further judged, if so, the read operation is carried out, namely the index data is read from the source fragment and fed back to a user, otherwise, if the source fragment is added with the read-write lock but the index data to be read does not exist, an error prompt can be returned.

If the determined fragment is the source fragment, it is indicated that the index data should be stored in the source fragment or the cache object, and therefore, it is determined whether index data to be read exists at least one of the source fragment and the cache object, if so, a read operation is performed, that is, if the index data to be read exists in the cache object, the index data in the cache object is read and fed back to a user, and if the index data to be read exists in the source fragment, the index data in the source fragment is read and fed back to the user. If the two are not used, it may be that the bucket index reading operation itself is wrong or the index data is lost, so an error prompt may be returned.

Corresponding to the above method embodiments, the embodiments of the present invention further provide an object storage system, which can be referred to in correspondence with the above.

The object storage system includes a plurality of slices, and referring to fig. 4, the object storage system includes:

an object receiving module 401, configured to receive an uploaded object;

a segment determining module 402, configured to determine a segment corresponding to the object;

a saving module 403, configured to save the index data of the object in the determined segment.

In an embodiment of the present invention, the fragment determining module 402 is specifically configured to:

calculating a hash value of an object name of the object;

the hash value is added to 2ⁿ-1 performing an and operation, using the fragment number and the fragment corresponding to the value obtained by the operation as the determined fragment corresponding to the object;

In a specific embodiment of the present invention, the system further includes a fragment expansion module, configured to:

In a specific embodiment of the present invention, the fragment expansion of the fragment expansion module object storage system specifically includes:

wherein the migration rule comprises:

if so, keeping the index data in the current fragment of the index data;

In a specific embodiment of the present invention, the fragment expansion module performs migration of index data in each fragment before expansion in a circular traversal manner, and adds a read-write lock to any fragment when performing migration of index data in the fragment.

In a specific embodiment of the present invention, the apparatus further includes a write bucket index execution module, configured to:

when receiving a write bucket index operation in the process of expanding the capacity of the fragments, determining the fragments corresponding to the objects according to the objects appointed by the write bucket index operation;

if the fragment is not the source fragment, determining that the fragment is the target fragment after capacity expansion, and performing write operation on the target fragment;

if not, writing the source fragment;

In a specific embodiment of the present invention, the apparatus further includes a read bucket index execution module, configured to:

when receiving a read bucket index operation in the process of expanding the capacity of the fragments, determining the fragments corresponding to the objects according to the objects appointed by the write bucket index operation;

if the source fragment exists, judging whether index data to be read exists in at least one position in the source fragment and the cache object; if yes, reading operation is carried out, otherwise, an error prompt is returned.

Corresponding to the above method and system embodiments, the embodiments of the present invention also provide an object storage device and a computer-readable storage medium, which may be referred to in correspondence with the above.

The object storage device includes:

a memory for storing a computer program;

a processor for executing a computer program to implement the steps of the index data storage method as in any of the above embodiments.

The computer readable storage medium has stored thereon a computer program which, when executed by a processor, implements the steps of the index data storage method as in any of the above embodiments. A computer-readable storage medium as referred to herein may include Random Access Memory (RAM), memory, Read Only Memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

It is further noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.

Those of skill would further appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both, and that the various illustrative components and steps have been described above generally in terms of their functionality in order to clearly illustrate this interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the technical solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

The principle and the implementation of the present invention are explained in the present application by using specific examples, and the above description of the embodiments is only used to help understanding the technical solution and the core idea of the present invention. It should be noted that, for those skilled in the art, it is possible to make various improvements and modifications to the present invention without departing from the principle of the present invention, and those improvements and modifications also fall within the scope of the claims of the present invention.

Claims

1. An index data storage method applied to an object storage system comprising a plurality of fragments, the index data storage method comprising:

receiving the uploaded object;

determining a fragment corresponding to the object;

and storing the index data of the object in the determined fragment.

2. The method for storing index data as claimed in claim 1, wherein said determining the segment corresponding to the object comprises:

calculating a hash value of the object name of the object;

the hash value is added to 2ⁿ-1 performing an and operation, and taking the fragment number and the fragment with the same numerical value as the determined fragment corresponding to the object;

3. The index data storage method of claim 2, further comprising:

when the number of index data stored in any fragment of the object storage system reaches a preset number threshold, performing fragment expansion of the object storage system to increase the number of fragments in the object storage system.

4. The method for storing index data according to claim 3, wherein performing a sharded expansion of the object storage system comprises:

wherein the migration rule comprises:

if so, keeping the index data in the current fragment of the index data;

wherein the number of the fragments in the object storage system before capacity expansion is k, and k is 2^pAfter the capacity expansion of the fragments is performed, the number of the fragments in the object storage system is 2 k.

5. The method for storing index data according to claim 4, wherein the migration of index data in each segment before capacity expansion is performed in a circular traversal manner, and when the migration of index data in any segment is performed, a read-write lock is applied to the segment.

6. The index data storage method of claim 5, further comprising:

if not, writing the source fragment;

7. The index data storage method of claim 5, further comprising:

if the target fragment does not have the index data to be read, judging whether a source fragment corresponding to the target fragment is provided with a read-write lock or not;

8. An object storage system, wherein the object storage system comprises a plurality of shards, and wherein the object storage system comprises:

the object receiving module is used for receiving the uploaded objects;

and the storage module is used for storing the index data of the object in the determined fragment.

9. An object storage device, comprising:

a memory for storing a computer program;

a processor for executing the computer program to implement the steps of the index data storage method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that a computer program is stored thereon, which computer program, when being executed by a processor, carries out the steps of the index data storage method according to any one of claims 1 to 7.