JP2014075089A - Image management device, image management method, and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a technology to reduce loads on a disk device storing image files.SOLUTION: In converting reading tasks of an image file accumulated in a standby queue so that execution time is reduced, an image management device determines whether or not an alternative image file is present that can be an alternative to an object image file of the reading tasks, on the basis of an edition history of the image files. The image management device converts the reading tasks to read the alternative image file to convert the reading tasks in the standby queue.

Description

  The present invention relates to an image management apparatus, an image management method, and a program for reading an image file stored in a disk device in response to a request from an application.

  In recent years, there has been provided an image management service for transmitting an image file generated by a digital camera or the like to a server and managing the image file on the server. Many image management services create thumbnails of multiple sizes in advance for index display and distribution to mobile terminals. An image management service having an image editing function creates an edited image file based on an instruction from the user. As described above, in image management services, not only original image files but also thumbnails and edited image files (hereinafter referred to as related image files) are often created and stored.

  The image management service system includes a group of content servers that store image files. The content server stores a large number of image files in the disk device, and performs reading processing and writing processing of the image file requested by the application on the client. The disk device can efficiently process any access to a continuous data area. However, if random access to a non-contiguous data area is performed, the performance will be significantly reduced due to seek time and rotation waiting time. Since the content server sequentially receives requests for a plurality of different image files from a large number of clients, random access frequently occurs to the disk device, resulting in performance degradation. Further, although the capacity of disk devices in recent years has been increasing, the larger the capacity, the wider the data area to be accessed, so that such performance degradation becomes more conspicuous.

  As a method for optimizing inefficient access to a disk device, a technique for controlling the execution order of I / O commands in consideration of data arrangement in the disk device is disclosed.

  For example, in Patent Document 1, the I / O command processing time is reduced by rearranging the I / O commands stored in the standby queue so as to access continuous data areas. Further, by rearranging so that multiple executions can be performed, even if an access wait occurs in one disk device, other disk devices can be accessed.

  Further, in Patent Document 2, even in a situation where an I / O command can be immediately executed, the I / O command is actively accumulated in a standby queue and executed in a rearranged order. Thereby, the throughput when accessing a large amount of data can be improved.

Japanese Patent No. 3250861 Japanese Patent No. 4804175

  However, the data stored in the disk device is an image file, and optimal efficiency may not be realized as access control to the disk device when reading it.

  As described above, it is assumed that the disk device in the content server stores not only the original image file but also the related image file. The related image file can be generated by editing the original image file or another related image file. Further, depending on the editing contents applied to the related image file, the same image file as the original image file can be generated from the related image file. That is, these image files have a replaceable relationship.

  In a disk device, an image file and another target image file are stored in a non-continuous data area, and an image file that can be substituted for a certain image file is stored in a data area continuous with another target image file. There may be. That is, when a plurality of image files are sequentially read from the disk device, more efficient access can be achieved by controlling the execution order in consideration of the possibility of substitution of the original image file and each related image file. It was not done.

  According to the above-described prior art documents, the target of execution order control is an I / O command to data constituting a requested file, and optimization in units of files is not performed.

  The present invention has been made in view of the above problems, and when the data stored in the disk device is, for example, an image file, the access control can be performed more efficiently by considering the possibility of substitution between files. An object of the present invention is to provide an image management apparatus. Moreover, it aims at providing the method and program.

An image management apparatus according to the present invention has the following configuration. That is, an image management apparatus that reads an image file stored in a storage medium in response to a request from an application, and a file information management unit that manages an editing history of the image file stored in the storage medium; Request accepting means for accepting a request from the application, a standby queue for accumulating a read task generated for reading the requested image file from the storage medium, and a task for converting the read task in the standby queue Execution control means, and data input / output means for reading from the storage medium the image file specified by the read task taken out from the standby queue,
The task execution control means converts the reading task so as to read the substitute image file when there is a substitute image file that replaces the image file specified in the request based on the editing history. It is characterized by.

  According to the present invention, when an image file is read from the disk device, the execution order is controlled in consideration of the possibility of substitution of the image file, so that the load on the disk device can be efficiently reduced.

The block diagram which shows the structural example of the system of embodiment. FIG. 2 is a block diagram illustrating an example of functional configurations of a content server 101 and a client 102. An example of file information managed by the file information management unit 208. An example of the characteristic information of the disk device 107 managed by the disk characteristic management unit 209. An example of a request message to the content server 101 for the client 102 to acquire an image file. The flowchart which shows the flow of the process which the content server 101 performs. The flowchart which shows the flow of the read process rearrangement process in step S603. The flowchart which shows the flow of the merge process of a reading task. FIG. 2 is a block diagram illustrating an example of functional configurations of a content server 101 and a client 102. An example of an image file stored in the disk device 107 by the content server 101. An example of a read task expressed in XML format.

  Hereinafter, the present invention will be described in detail based on preferred embodiments with reference to the accompanying drawings. The configurations shown in the following embodiments are merely examples, and the present invention is not limited to the illustrated configurations.

<Embodiment 1>
A configuration example of a system according to the present embodiment will be described with reference to the block diagram of FIG.

  The system includes a content server 101, a client 102, and a network 115. The client 102 can communicate with the content server 101 via the network 115. In FIG. 1, the number of content servers 101 and clients 102 is one, but the number is not limited to this.

  The content server 101 provides a function for storing an image file and distributing it to the client 102. The content server 101 includes at least a CPU (Central Processing Unit) 103, a RAM (Random Access Memory) 104, a ROM (Read Only Memory) 105, a network interface 106, and a disk device 107.

  The CPU 103 controls the operation of each unit constituting the content server 101 and performs various processes described later as what the content server 101 performs.

  The RAM 104 is a memory that temporarily stores data and control information, and serves as a work area used when the CPU 103 executes various processes.

  The ROM 105 stores fixed operation parameters and operation programs for the content server 101.

  The network interface 106 provides a function for connecting to and communicating with the network 115. The content server 101 can transmit / receive data to / from the client 102 through the network interface 106.

  The disk device 107 is a device that stores data in a disk-shaped storage medium, and has an interface that accepts an I / O command for reading and writing data. The disk device 107 is, for example, a hard disk drive (HDD) or an optical disk drive. The disk device 107 may be shared by a plurality of content servers 101 via a network. The disk device 107 stores computer programs and data for causing the CPU 103 to execute processes to be described later as performed by the content server 101.

  On the client 102, an application for processing an image file is operating. The client 102 includes at least a CPU 108, a RAM 109, a ROM 110, a network interface 111, and an external storage device 112. Further, depending on the form of the client 102, an input device 113 and an output device 114 are provided.

  The CPU 108 controls the operation of each unit constituting the client 102 and executes various processes described later as what the client 102 performs.

  The RAM 109 is a memory that temporarily stores data and control information, and serves as a work area used when the CPU 108 executes various processes.

  The ROM 110 stores fixed operation parameters and operation programs of the client 102.

  The network interface 111 provides a function for connecting to and communicating with the network 115. The client 102 can transmit / receive data to / from the content server 101 through the network interface 111.

  The external storage device 112 is a device that stores data, and has an interface that accepts an I / O command for reading and writing data. The external storage device 112 may be a hard disk drive (HDD), an optical disk drive, a semiconductor storage device, or other storage devices. The external storage device 112 stores a computer program and data for causing the CPU 108 to execute each process described later as what the client 102 performs.

  The input device 113 is, for example, a keyboard, a mouse, or a touch panel. The output device 114 is, for example, a display.

  Next, functional configuration examples of the content server 101 and the client 102 will be described with reference to the block diagram of FIG.

  The content server 101 includes a request reception unit 201, a request execution control unit 202, and a data input / output unit 203.

  The request reception unit 201 receives a request generated by the client 102 for acquiring an image file. The request receiving unit 201 includes a request receiving unit 204 for receiving a request from the client 102 and an image transmitting unit 205 for transmitting an image file corresponding to the request to the client 102.

  The request execution control unit 202 performs execution control of a request from the client 102 received by the request reception unit 201. The request execution control unit 202 includes a task rearrangement unit 206, a standby queue 207, a file information management unit 208, a disk characteristic management unit 209, and an image editing unit 210. The standby queue 207 is used to store image file reading tasks corresponding to requests received by the request receiving unit 201. The task rearrangement unit 206 rearranges the read tasks stored in the standby queue 207 so that access to the disk device 107 is performed on a continuous data area as much as possible. Even if the task order is not rearranged, the read task in the waiting queue is converted. For sorting the read tasks, file information managed by the file information management unit 208 and disk characteristic information managed by the disk characteristic management unit 209 are used. File information and disk characteristic information will be described later with reference to FIG. The image editing unit 210 edits the image file read from the disk device 107 as necessary.

  The data input / output unit 203 converts the read task specified by the request execution control unit 202 into an I / O command interpretable by the disk device 107 and executes it. As a result, the data constituting the image file is read from the disk device 107.

  Various applications 214 for processing image files are running on the client 102. The client 102 includes a request generation unit 211 for requesting the content server 101 for an image file required by the application 214. The request generation unit 211 includes a request transmission unit 212 for transmitting a request to the content server 101 and an image reception unit 213 for receiving the requested image file.

  FIG. 10 shows an example of an image file stored in the disk device 107 by the content server 101. The image file 1001 is an original image, for example, an image received from a user or the like. The image file 1002 is an image obtained by reducing the original image to a half size, and is used for thumbnail display, for example. The image file 1003 is an image obtained by rotating the original image by 90 degrees, and is generated by, for example, an editing instruction from the user. As described above, the content server 101 stores not only the original image file but also a plurality of related image files such as thumbnails and edited images in the disk device 107.

  The image file 1002 can be generated by reducing the image file 1001. Therefore, when it is desired to read the image file 1002 from the disk device 107, the image file 1001 can be a substitute image file for the image file 1002. The image file 1003 can be returned to the original image file 1001 by rotating by -90 degrees. Therefore, when it is desired to read the image file 1001 from the disk device 107, the image file 1003 can be a substitute image file for the image file 1001.

  FIG. 3 shows an example of file information managed by the file information management unit 208, and includes an image file ID 301, an editing history 302, and a physical address 303 for each image file. The image file ID 301 is an identifier for uniquely specifying an image file stored in the disk device 107. The editing history 302 is a history of editing processing applied to each image file, and includes an original image file ID 304, image processing content 305, and reversibility information 306 of the processing. The original image file ID 304 is an image file ID indicating the original file before the editing process. The reversibility information 306 indicates whether or not it is possible to return to the original image by a process reverse to the process. Based on the editing history 302 including such information, the alternative relationship between the image files as described above can be determined. The physical address 303 is information indicating the position on the disk device 107 in which the image file is stored. In the example shown in FIG. 3, the position is represented by the offset 307 from the top of the disk and the data size 308 of the image file, but the position may be represented by other information.

  FIG. 4 shows an example of the characteristic information of the disk device 107 managed by the disk characteristic management unit 209. FIG. 4A is an example of a graph showing characteristics of time required for seeking. The horizontal axis of this graph is the moving distance of the head, and the vertical axis is the expected seek time. Based on this, the seek time at an arbitrary head moving distance can be calculated. FIG. 4B is an example of a graph showing characteristics of time required for data transfer. In this graph, the horizontal axis represents the data transfer amount, and the vertical axis represents the expected data transfer time. Based on this, the data transfer time at an arbitrary data transfer amount can be calculated. For these characteristic information, values given as fixed setting information in advance may be used, or seek time and data transfer time are measured for each input / output of data, and values calculated based on the values are calculated. It may be used. Such creation and update of the disk characteristic information can be realized using a known technique, and thus will not be described here.

  FIG. 5 is a diagram illustrating a message example of a request that the client 102 makes to the content server 101 in order to acquire an image file. FIG. 5A shows a request message for request, and FIG. 5B shows a response message for request. The request message is composed of a syntax according to the HTTP (Hypertext Transfer Protocol) protocol. In the request message 501, the image file to be acquired is specified by the HTTP path unit 502. Further, meta information related to the request is added to the header portion 503. In the response message 504, the requested image file 507 is attached together with the meta information added to the header portion 506.

  Next, processing performed by the content server 101 will be described with reference to FIG. 6 showing a flowchart of the processing. The flowchart is realized by the CPU executing the control program.

  In step S <b> 601, the request reception unit 204 receives a request message for requesting acquisition of an image file stored in the disk device 107 from the client 102. In step S 602, a read task corresponding to the request is generated and stored in the standby queue 207.

  An example in which the read task is represented in the XML format is shown in FIG. The read task includes a task ID 1101, a target file 1102, a generation date and time 1103, related request information 1104, and alternative information 1105. The task ID 1101 is an identifier for uniquely identifying the read task. A target file 1102 represents an image file to be read by a reading task. The generation date and time 1103 represents the date and time when the reading task was generated. The related request information 1104 is request information from the client 102 that requests an image file read by the reading task. The replacement information 1105 is information required when another file is read as a replacement for the target file, and includes replacement file information 1106, a replacement flag 1107, and necessary editing processing information 1108. The alternative file information 1106 is a file ID of an image file that is an alternative to the target file 1102. The substitution flag 1107 is a flag indicating whether or not to read a substitution file instead of the target file. The necessary editing processing information 1108 indicates editing processing necessary for generating the target file from the alternative file. When the read task is generated in step S602, the alternative information 1105 is empty.

  Next, in step S603, the task rearrangement unit 206 rearranges the read tasks in the standby queue 207 so that the disk device 107 can be accessed as continuously as possible. At this time, if it is more efficient to read the alternative file instead of the target file, the reading task is converted to read the alternative file. This read task rearrangement process will be described later with reference to FIG.

  Subsequently, in step S604, the reading task located at the head is taken out from the waiting queue 207 rearranged in step S603. Then, the data input / output unit 203 accesses the disk device 107 and executes an I / O command in order to read the image file data targeted by the read task that has been taken out.

  In step S605, the request execution control unit 202 determines whether image editing is necessary for the read image file. The determination is made based on whether or not the conversion of the reading task into the alternative file has been performed in step S603. Specifically, the determination can be made based on the state of the read task alternative flag 1107. If it is determined that image editing is necessary, in step S606, the image editing unit 210 performs editing processing to generate the requested image file. Necessary editing processing is specified in the necessary editing processing information 1108 of the reading task.

  Finally, in step S607, the image transmission unit 205 transmits the image file read from the disk device 107 in step S604 or the image file generated in step S606 to the client 102. The client 102 to be transmitted is specified from the related request information 1104 of the reading task.

  Next, the read task rearrangement process in step S603 will be described with reference to FIG. 7 showing a flowchart of the process.

  First, in step S <b> 701, the seek distance between the target file of the read task newly input to the standby queue 207 and the target file of the read task last extracted from the standby queue 207 is calculated. The read task taken out last indicates a read task being executed or a read task that is ordered last while the execution order is fixed. The seek distance is calculated using the position on the disk device 107 of each image file held by the file information management unit 208. The difference between the start position of the target file of the new read task and the end position of the target file of the read task that was extracted last is the seek distance. In step S702, the seek time corresponding to the seek distance calculated in step S701 is calculated by referring to the seek time information held by the disk characteristic management unit 209.

  Next, in step S703, it is determined whether there is an alternative file that can replace the target file for the new read task. The determination is made based on the editing history 302 held by the file information management unit 208. If an alternative file exists, the process proceeds to step S704, and if not, the process proceeds to step S711.

  In step S704, the total execution time required to execute all the read tasks stored in the standby queue 207 is calculated. The execution time of each read task is calculated by adding the data transfer time to the seek time. The data transfer time is calculated based on the data size of the target file and the data transfer time information held by the disk characteristic management unit 209.

  Subsequently, in step S705, the seek distance of the alternative file is calculated by the same method as in step S701. In step S706, the seek time of the alternative file is calculated by the same method as in step S702. Further, in step S707, when an alternative file is read instead of the target file, the total execution time required to execute all the read tasks stored in the standby queue 207 is calculated by the same method as in step S704. To do.

  In step S708, it is determined whether the above processing has been performed for all the alternative files. If there is a remaining file, steps S705 to S707 are repeated.

  Next, in step S709, based on the total execution time calculated in steps S704 and S707, it is determined whether there is an alternative file that can reduce the total execution time. When it exists, it progresses to step S710, and when it does not exist, it progresses to step S711. In step S710, the reading task is converted so that an alternative file is read instead of the target file. The conversion is performed, for example, by setting an alternative file ID in the alternative file information 1106 of the reading task and setting true (indicating reading of an alternative file) in the alternative flag 1107.

  Finally, in step S711, the read tasks in the waiting queue 207 are rearranged so that the seek time is shortened. Here, regarding the read task converted so as to read the alternative file, the rearrangement is performed with reference to the seek time of the alternative file. By sequentially reading and executing read tasks from the rearranged standby queue 207, continuous access to the disk device 107 (including not only adjacent to each other on the disk but also a short seek distance) is performed. It can be carried out.

  Since various methods can be considered for the read task rearrangement process, the method is not limited to the above-described method, and other methods may be used.

  In the rearrangement process described above, the waiting time of the reading task accumulated in the waiting queue 207 is not taken into consideration. For this reason, there is a possibility that execution of a certain reading task may be delayed due to the rearrangement. As a countermeasure against this, if the waiting time is a certain time or more, it can be considered that the execution order is determined so that it is not subject to further rearrangement.

  In the present embodiment, for the sake of simplicity, the data constituting the image file is described as being stored in a continuous data area on the disk device 107. However, there is a possibility that the data is actually divided and stored in a discontinuous data area. In that case, it is necessary to calculate the seek time in consideration of the arrangement of each data constituting the image file. Considering efficient access to the disk device 107, it is desirable that data constituting a single file is stored in a continuous state. However, the arrangement in which the data constituting the file is in a continuous state can be realized using a known technique, and thus will not be described here.

  As described above, according to the system of the present embodiment, the read tasks in the standby queue 207 are rearranged in a continuous order on the disk device 107. Therefore, the seek time in the disk device can be shortened, and efficient access is possible.

<Embodiment 2>
In the first embodiment, the sorting process of the read tasks accumulated in the standby queue 207 is performed in step S603. In the present embodiment, an example will be described in which merge processing is performed in addition to the rearrangement processing in step S603. Merge processing refers to combining a plurality of read tasks into one. As a result, access to the disk device 107 can be reduced. Since this embodiment is basically based on the first embodiment, the difference from the first embodiment will be described below.

  The system configuration according to the present embodiment is the same as the configuration shown in FIG.

  The read task merge process will be described with reference to FIG. 8 showing a flowchart of the process. The flowchart is realized by the CPU executing the control program.

  First, in step S801, the ID of the target file of the read task newly input to the standby queue 207 is compared with the ID of the target file of the existing read task in the standby queue 207. In step S802, it is determined whether there is a read task for an image file with a matching ID. When it exists, it progresses to step S807, and when it does not exist, it progresses to step S803.

  In step S803, it is determined whether there is an alternative file that can replace the target file of the new read task. The determination is made based on the editing history 302 held by the file information management unit 208. If an alternative file exists, the process proceeds to step S804.

  In step S804, the ID of the alternative file of the read task newly input to the standby queue 207 is compared with the ID of the target file of the existing read task in the standby queue 207. In step S805, it is determined whether there is a read task for the image file with the matching ID. If it exists, the process proceeds to step S806. In step S806, the reading task is converted so that an alternative file is read instead of the target file. The conversion is performed, for example, by setting an alternative file ID in the alternative file information 1106 of the reading task and setting true (indicating reading of an alternative file) in the alternative flag 1107.

  Finally, in step S807, the new read task is merged with the existing read task in the waiting queue 207. The merge is performed, for example, by adding a request ID described in the read request information 1104 of the new read task to the related request information 1104 of the existing read task.

  As described above, in the present embodiment, not only the read task rearrangement process but also the merge process is performed in step S603. Therefore, access to the disk device 107 can be further reduced.

<Embodiment 3>
In the first embodiment, when a substitute file is read from the disk device 107, an image editing process for generating a target file is performed in the content server 101. In the present embodiment, an example in which image editing processing is performed in the client 102 will be described.

  An example of functional configurations of the content server 101 and the client 102 in this embodiment is shown in FIG. The client 102 includes an image editing unit 901 that performs image editing processing.

  The response message transmitted from the image transmission unit 205 of the content server 101 to the client 102 is as shown in FIG. The header part 510 includes the contents of the editing process to be executed on the attached substitute file 511. By performing this editing process in the image editing unit 901, an image file requested by the application 214 is generated.

  As described above, in this embodiment, the image editing process required when the alternative file is read is performed by the client 102. Therefore, it is effective when it is not appropriate to perform image editing processing in the content server 101, such as when the CPU usage rate is high in the content server 101. On the other hand, when the substitute file is larger than the target file, the amount of network transfer between the content server 101 and the client 102 increases.

<Other embodiments>
Although the embodiment has been described in detail above, the present invention can take an embodiment as a system, apparatus, method, program, recording medium (storage medium), or the like. Specifically, the present invention may be applied to a system composed of a plurality of devices (for example, a host computer, an interface device, an imaging device, a Web application, etc.), or may be applied to a device composed of a single device. good.

  Needless to say, the object of the present invention can be achieved as follows. That is, a recording medium (or storage medium) that records a program code (computer program) of software that implements the functions of the above-described embodiments is supplied to the system or apparatus. Needless to say, such a storage medium is a computer-readable storage medium. Then, the computer (or CPU or MPU) of the system or apparatus reads and executes the program code stored in the recording medium. In this case, the program code itself read from the recording medium realizes the functions of the above-described embodiment, and the recording medium on which the program code is recorded constitutes the present invention.

Claims (7)

An image management apparatus that reads an image file stored in a storage medium in response to a request from an application,
File information management means for managing an editing history of the image file stored in the storage medium;
Request accepting means for accepting a request from the application;
A standby queue for accumulating read tasks generated to read the requested image file from the storage medium;
Task execution control means for converting the read task in the waiting queue;
Data input / output means for reading from the storage medium the image file specified by the read task retrieved from the standby queue;
With
The task execution control means converts the reading task so as to read the substitute image file when there exists a substitute image file that replaces the image file specified in the request based on the editing history. An image management apparatus characterized by the above. The apparatus according to claim 1, further comprising: a generation unit configured to generate the requested image file by editing the alternative image file when the alternative image file is read from the storage medium. Image management device. 2. The task execution control unit, when there are a plurality of read tasks for the same image file in the standby queue, combine the read tasks into one. Image management device. The task execution control means calculates the execution time of the read task in the standby queue from the characteristics of the time required for seeking the storage medium and the characteristics of the time required for data transfer, and reads the substitute image file 2. The image management apparatus according to claim 1, wherein when the execution time of the read task accumulated in the standby queue becomes shorter, the read task is converted to read the substitute image file. 3. .   The image management apparatus according to claim 1, wherein the task execution control unit does not convert the reading task when the waiting time of the reading task is a predetermined time or more. An image management method for reading an image file stored in a storage medium in response to a request from an application,
A management step of managing an editing history of the image file stored in the storage medium;
A reception process for receiving a request from the application;
An accumulation step of accumulating in a waiting queue a read task generated to read the requested image file from the storage medium;
A control step of converting the read task in the waiting queue;
A reading step of reading from the storage medium an image file specified by the reading task taken out from the waiting queue;
With
The control step converts the reading task so as to read the substitute image file when there is a substitute image file that can replace the image file specified in the request based on the editing history. Image management method.   The computer program for functioning a computer as each means of the image management apparatus of any one of Claim 1 to 5.

Images