Background

[001] Databases may be part of modern day computing. Whether it is a small start-up or a large enterprise, organizations may have to deal with a vast amount of data these days, which could range from a few terabytes to multiple petabytes of data. Databases provide a useful way of organizing data. Such data may be accessed via a database management system that may allow entry, storage and retrieval of data from a database.

Brief Description of the Drawings

[002] The following detailed description references the drawings, wherein:

[003] FIG. 1 is a block diagram of an example system for managing a database index file;

[004] FIG. 2 is a block diagram of an example computer system for managing a database index file;

[005] FIG. 3 is a flowchart of an example method of managing a database index file;

[006] FIGS. 4A to 4G are conceptual block diagrams of an example method of managing a database index file; and

[007] FIG. 5 is a block diagram of an example computer system for managing a database index file. Detailed Description

[008] Data management may be used by an organization. Whether it is a private company, a government undertaking, an educational institution, or a new start-up, managing data in an appropriate manner may be important of an enterprise especially in a business environment (for example, e-commerce) where a database may be growing rapidly. This may lead to many challenges in managing a database. Once of such challenges is to manage an index of the columns in a database. With large databases, indexing may be important to quick data access. As the size of a database grows, the size of an index file may also grow in proportion to the database size. This may make updating an index file challenging if the indexed field changes. For example, changing value of one index field may result in rewriting the whole index file as the field may have to be deleted from its old location and placed in another location in order to maintain sort order of the indexed field in the index file. In addition, an index file update may involve acquiring various types of locks to synchronize between various readers and the process that manages the index. This may not only impact performance but also require a complex algorithm to achieve synchronization.

[009] To address this issue, the present disclosure describes various examples for managing a database index file. In an example, upon receiving an update for a database index file, a duplicate inode of an inode of the database index file may be generated, wherein the duplicate inode also points to blocks pointed to by the inode of the database index file. In an instance, a new block may be allocated to write the update, wherein the new block is linked to last unmodified block of the blocks pointed to by the inode and the duplicate inode. The update may be written to the new block. Further, the position of file pointer in the blocks pointed to by the inode and the duplicate inode may be determined. If the file pointer is not at an end of a block in the blocks pointed to by the inode and the duplicate inode, unmodified content may be copied from the block to the new block till the file pointer is at the end of the block. Furthermore, the position of file pointer in the new block may be determined. If the file pointer is at end of the new block, the blocks that are further to the block in the blocks pointed to by the inode and the duplicate inode may be included in the duplicate inode of the database index file.

[0010] FIG. 1 is a block diagram of a system 100 for managing a database index file, according to an example. In an example, system 100 may represent any type of computing system capable of reading machine-executable instructions. Examples of system 100 may include, without limitation, a server, a desktop computer, a notebook computer, a tablet computer, a thin client, a mobile device, a personal digital assistant (PDA), a phablet, and the like. In an example, system 100 may be a database server.

[0011] In an example, system 100 may include a file system 102, a database 104, a database index file 106, and an index manager module 108. In an example, system 100 may be a distributed computer system. In other words, "system" 100 may include multiple computing devices that may host one or more of the aforementioned components (for example, file system 102) that may interact with each other in order to achieve a common goal. The multiple computing devices may be in communication, for example, via a computer network. Such a computer network may be a wireless or wired network. Such a computer network may include, for example, a Local Area Network (LAN), a Wireless Local Area Network (WAN), a Metropolitan Area Network (MAN), a Storage Area Network (SAN), a Campus Area Network (CAN), or the like. Further, such a computer network may be a public network (for example, the Internet) or a private network (for example, an intranet).

[0012] The term "module" may refer to a software component (machine readable instructions), a hardware component or a combination thereof. A module may include, by way of example, components, such as software components, processes, tasks, co-routines, functions, attributes, procedures, drivers, firmware, data, databases, data structures, Application Specific Integrated Circuits (ASIC) and other computing devices. A module may reside on a volatile or non-volatile storage medium and configured to interact with a processor of a system (e.g. 100).

[0013] In general, file system 102 may be used for storage and retrieval of data from system 100. In an example, a computer file or "file" may be considered as the basic component of file system 102. Each piece of data on a storage device may be called a "file". A file may contain data, such as text files, image files, video files, and the like, or it may be an executable file or program. Files in file system 102 may be organized by storing related files in a directory or sub-directory.

[0014] In an example, an inode may be associated with each file of the file system 102.

An inode is a data structure, which may be used to represent a file system object (for example, directory, file, etc.). Each file or directory may be associated with an inode, which may be identified by an integer number (i.e. an inode number). An inode may store the attributes and disk block location(s) of a file system object's data. In other words, an inode may store information about data blocks associated with a file or directory, or it may point to a data block map that points to the data blocks. In an instance, an "inode block map" may hold page to disk block mapping for a file or directory. In other words, an inode block map may provide mapping information between a page of a file (or directory) and a Logical Block Number (LBN) on a storage system.

[0015] File system 102 may be a local file system or a scale-out file system such as a shared file system or a network file system. Examples of a shared file system may include a Storage Area Network (SAN) file system or a cluster file system. Examples of a network file system may include a distributed file system or a distributed parallel file system. Some non-limiting examples of file systems that may be used on storage device (example, 102) may include FAT (FAT12, FAT16, FAT32), NTFS, HFS and HFS+, HPFS, UFS, ext2, ext3, and ext4. In an example, file system 102 may be an online file system.

[0016] Database 104 may be a repository that stores an organized collection of data, for instance, in form of data records. System 100 may perform a task or function related to data records stored in database 104. System 100 may, for example, store, modify, retrieve, query, and delete data records in database. In an instance, system may access data records from database 104 by using a query language such as Structured Query Language (SQL). In an example, database 104 may be a relational database, wherein data may be organized into one or more tables of rows and columns. Each entity type described in a database 104 may have its own table. The rows in table may represent instances of that type of entity and the columns may represent values attributed to that instance. In an instance, each data record in database 104 may include a key field, which helps it to be recognized uniquely.

[0017] System 100 may include a database index file 106. In another example, system 100 may include multiple database index files. In an instance, database index file 106 may be generated on data stored in database 104, and may include one or more entries, where each entry may correspond to a data record in database 104. The index entry associated with a data record may be a pair consisting of a value of the key attribute for that record and a pointer to the location where the data record is stored in database. Database index file 106 may be used to efficiently retrieve records from the database 104 based on an attribute(s) on which the indexing may be done. Database index file 106 may help quickly locate data in database without having to search every row in a database table every time a database table is accessed. In an instance, database index file 106 may be created by using one or more columns of a table in database 104. [0018] Some of the example functionalities performed by file system 102, database index file 106, and index manager module 108 are described in reference to FIG. 2 below.

[0019] FIG. 2 is a block diagram of an example computing system 200 for managing a database index file. In an example, computing system 200 may be similar to system 100 of FIG. 1, in which like reference numerals correspond to the same or similar, though perhaps not identical, components. For the sake of brevity, components or reference numerals of FIG. 2 having a same or similarly described function in FIG. 1 are not being described in connection with FIG. 2. Said components or reference numerals may be considered alike.

[0020] Computing system 200 may be a server, a desktop computer, a notebook computer, a tablet computer, a mobile phone, a personal digital assistant (PDA), and the like.

[0021] In an example, computing system 200 may include a file system 102, a database index file 106, and an index manager module 108.

[0022] Index manager module 108 may generate a duplicate inode of the inode of a database index file (for example, 106). Index manager module 108 may create a copy of the inode of a database index file (for example, 106) upon receiving an update for the database index file (for example, 106). In an instance, each time an update for a database index file (for example, 106) is received, the index manager module 108 may create a copy of the inode of the database index file (for example, 106). The duplicate inode may have the attributes of the original inode. For example, the duplicate inode may also point to the blocks pointed to by the original inode of the database index file (for example, 106). [0023] File system 102 may provide an interface to the index manager module 108 to create a copy of the inode. For example, the interface may include an ioctl system call or a Remote Procedure Call (RPC). In an instance, file system 102 may mark the duplicate inode of the database index file (for example, 106) as a "special" inode to indicate that any update to such inode may require specific processing. Once index manager module 108 creates a copy of the inode of a database index file, file system 102 may allocate a new block to write an update received for the database index file (for example, 106). The new block may be linked to the last unmodified block of the blocks pointed to by the inode and the duplicate inode of the database index file (for example, 106).

[0024] In an instance, prior to allocating a new block for writing the update to the database index file (for example, 106), file system 102 may determine whether a write request for writing the update is a first write request. If the write request for writing the update is the first write request, file system 102 may allocate a new block to write the update. On the other hand, if the write request for writing the update is not the first write request, file system 102 may determine whether a new block is needed for writing the update. In other words, in such case, the file system 102 may determine whether a current write request may be written on a block previously allocated by it. In case, upon such determination, the file system 102 determines that an additional block is needed for writing the update, file system may allocate an additional new block for writing the update. Once the file system 102 makes the appropriate determination i.e. whether to allocate a new block or use a previously allocated block for writing the current update, file system may write the update to the new block or an earlier block, as the case may be. File system 102 may keep allocating new blocks to honor write requests until the update is completed.

[0025] Once the update is complete, file system 102 may determine position of file pointer in the blocks that are pointed to by the inode and the duplicate inode of the database index file (for example, 106). If the file pointer is not at an end of a block in the blocks pointed to by the inode and the duplicate inode, file system 102 may copy unmodified content from the current file pointer position in the block to the new block (or a previously allocated block, as the case may be) till the file pointer is at the end of the block.

[0026] In an instance, file system 102 may further determine position of file pointer in the new block (or a previously allocated block, as the case may be) that received the update. If the file pointer is at end of the new block (or a previously allocated block, as the case may be) that received the update, file system 102 may include blocks that are further to the block (i.e. block with file pointer at the end) in the blocks pointed to by the inode and the duplicate inode of the database index file, in the duplicate inode of the database index file. In other words, if the file pointer is at end of the new block or a previously allocated block that received the update, file system 102 may reuse the remaining blocks in the blocks pointed to by the inode and the duplicate inode, instead of copying data from the remaining blocks to the duplicate index file. The remaining blocks may be included in the duplicate inode of the database index file. File system 102 may then choose to close the file pointers.

[0027] Index manager module 108 may now determine whether an application is using the inode of the database index file. In other words if there's a "reader" for the original inode of the database index file. If no application is using the inode of the database index file, the index manager module 108 may delete the original inode of the database index file. However, if an application is reading the inode of the database index file, index manager module 108 may mark the inode of the database index file for deletion, and delete the inode of the database index file after the application completes reading the inode of the database index file. In an instance, the original inode of the database index file may be deleted by the application that last reads the original inode. Once the original inode is deleted, file system 102 may use the duplicate inode of the database index file for reading the database index file in future.

[0028] FIG. 3 is a flowchart of an example method 300 for managing a database index file. The method 300, which is described below, may at least partially be executed on system 100 of FIG. 1 or computing system 200 of FIG. 2. However, other computing devices may be used as well. At block 302, a duplicate inode of an inode of a database index file may be generated upon receiving an update for a database index file, wherein the duplicate inode also points to blocks pointed to by the inode of the database index file. This is illustrated in FIG. 4A, according to an example. FIG. 4A shows a duplicate inode 402 of an inode 404 of a database index file, wherein the duplicate inode 402 points to blocks 406, 408, 410 and 412 pointed to by the inode 404 of the database index file. At block 304, a new block may be allocated to write the update, wherein the new block is linked to last unmodified block of the blocks pointed to by the inode and the duplicate inode. This is illustrated in FIG. 4B, according to an example. FIG. 4B shows that a new block 414 is allocated to write an update, wherein the new block 414 is linked to last unmodified block 406 of the blocks 408, 410, and 412 pointed to by the inode 404 and the duplicate inode 402. At block 306, the update may be written to the new block 414. In an example, additional new blocks 416 and 418 may be allocated, if needed, to complete all write requests related to the update. At block 308, the position of file pointer in the blocks pointed to by the inode and the duplicate inode may be determined. This is illustrated in FIG. 4B, according to an example. FIG. 4B shows the position of file pointer 420 in the blocks pointed to by the inode and the duplicate inode. At block 310, if the file pointer is not at an end of a block in the blocks pointed to by the inode and the duplicate inode, unmodified content may be copied from the block to the new block till the file pointer is at the end of the block. This is illustrated in FIGS. 4C and 4D, according to an example. FIGS. 4C and 4D show that if the file pointer 420 is not at an end of a block in the blocks pointed to by the inode and the duplicate inode, unmodified content may be copied from block 410 to the new block 418 till the file pointer is at the end of the block 410. At block 312, the position of file pointer in the new block 418 may be determined. At block 314, if the file pointer is at the end of the new block 418, blocks that are further to the block in the blocks pointed to by the inode and the duplicate inode may be included in the duplicate inode of the database index file. This is illustrated in FIG. 4E, according to an example. FIG. 4E shows that the file pointer 422 is at the end of the new block 418. In this case, block 412, which is further to the block 410 in the blocks pointed to by the inode and the duplicate inode, may be included in the duplicate inode 404 of the database index file. On the other hand, if the file pointer 422 is not at the end of the last allocated new block 418 then beginning from the existing position of file pointer in the inode, remaining data of the inode may be copied to the duplicate inode of the database index file. The remaining data may be copied to the duplicate inode commencing from the existing position of file pointer in the duplicate inode. This is illustrated in FIGS. 4F and 4G, according to an example. In FIG. 4F, file pointer 422 is not at the end of the last new block 418. In this case, beginning from the existing position of file pointer 420 in the inode 404, remaining data (in blocks 410 and 412) of the inode 404 is copied to the duplicate inode 402 of the database index file. The remaining data may be copied to a new block(s) 418 and 424 of the duplicate inode 402 commencing from the existing position of file pointer 422 (as shown in FIG. 4F) in the duplicate inode 402. FIG. 4G reflects the current position of file pointer 422 in the duplicate inode 402 after the remaining data (in blocks 410 and 412) of the inode 404 is copied to the duplicate inode 402.

[0029] FIG. 5 is a block diagram of an example system 500 for managing a database index file. System 500 includes a processor 502 and a machine-readable storage medium 504 communicatively coupled through a system bus. Processor 502 may be any type of Central Processing Unit (CPU), microprocessor, or processing logic that interprets and executes machine-readable instructions stored in machine-readable storage medium 504. Machine-readable storage medium 504 may be a random access memory (RAM) or another type of dynamic storage device that may store information and machine-readable instructions that may be executed by processor 502. For example, machine-readable storage medium 504 may be Synchronous DRAM (SDRAM), Double Data Rate (DDR), Rambus DRAM (RDRAM), Rambus RAM, etc. or a storage memory media such as a floppy disk, a hard disk, a CD-ROM, a DVD, a pen drive, and the like. In an example, machine-readable storage medium 504 may be a non-transitory machine-readable medium. Machine-readable storage medium 504 may store instructions 506, 508, 510, 512, 514, 516, and 518.

[0030] In an example, instructions 506 may be executed by processor 502 to create, upon receiving an update for a database index file, a duplicate inode of an inode of the database index file, wherein the duplicate inode also points to data blocks pointed to by the inode of the database index file. Instructions 508 may be executed by processor 502 to allocate a new data block to write the update, wherein the new data block is linked to last unmodified data block of the blocks pointed to by the inode and the duplicate inode. Instructions 510 may be executed by processor 502 to write the update to the new data block. Instructions 512 may be executed by processor 502 to determine position of file pointer in the data blocks pointed to by the inode and the duplicate inode. Instructions 514 may be executed by processor 502 to copy, if the file pointer is not at an end of a current data block in the data blocks pointed to by the inode and the duplicate inode, unmodified content from the current data block to the new data block till the file pointer is at the end of the data block. Instructions 516 may be executed by processor 502 to determine position of file pointer in the new data block. Instructions 518 may be executed by processor 502 to include, if the file pointer is at end of the new data block, data blocks that are further to the current data block in the data blocks pointed to by the inode and the duplicate inode, in the duplicate inode of the database index file.

[0031] For the purpose of simplicity of explanation, the example method of FIG. 3 is shown as executing serially, however it is to be understood and appreciated that the present and other examples are not limited by the illustrated order. The example systems of FIGS. 1, 2 and 5, and method of FIG. 3 may be implemented in the form of a computer program product including computer-executable instructions, such as program code, which may be run on any suitable computing device in conjunction with a suitable operating system (for example, Microsoft Windows, Linux, UNIX, and the like). Examples within the scope of the present solution may also include program products comprising non-transitory computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer. By way of example, such computer- readable media can comprise RAM, ROM, EPROM, EEPROM, CD-ROM, magnetic disk storage or other storage devices, or any other medium which can be used to carry or store desired program code in the form of computer-executable instructions and which can be accessed by a general purpose or special purpose computer. The computer readable instructions can also be accessed from memory and executed by a processor.

[0032] It should be noted that the above-described examples of the present solution is for the purpose of illustration only. Although the solution has been described in conjunction with a specific example thereof, numerous modifications may be possible without materially departing from the teachings and advantages of the subject matter described herein. Other substitutions, modifications and changes may be made without departing from the spirit of the present solution. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive.