WO2014157275A1 - ストレージシステム、情報処理装置の制御プログラム及びストレージシステムの制御方法 - Google Patents

ストレージシステム、情報処理装置の制御プログラム及びストレージシステムの制御方法 Download PDF

Info

Publication number
WO2014157275A1
WO2014157275A1 PCT/JP2014/058417 JP2014058417W WO2014157275A1 WO 2014157275 A1 WO2014157275 A1 WO 2014157275A1 JP 2014058417 W JP2014058417 W JP 2014058417W WO 2014157275 A1 WO2014157275 A1 WO 2014157275A1
Authority
WO
WIPO (PCT)
Prior art keywords
time
section
data
divided data
storage
Prior art date
Application number
PCT/JP2014/058417
Other languages
English (en)
French (fr)
Inventor
宗則 前田
年弘 小沢
Original Assignee
富士通株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Publication of WO2014157275A1 publication Critical patent/WO2014157275A1/ja
Priority to US14/844,483 priority Critical patent/US10268398B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/061—Improving I/O performance
    • G06F3/0613—Improving I/O performance in relation to throughput
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
    • G06F16/2477—Temporal data queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/40—Information retrieval; Database structures therefor; File system structures therefor of multimedia data, e.g. slideshows comprising image and additional audio data
    • G06F16/44—Browsing; Visualisation therefor
    • G06F16/447—Temporal browsing, e.g. timeline
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/951—Indexing; Web crawling techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/061—Improving I/O performance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0629—Configuration or reconfiguration of storage systems
    • G06F3/0635—Configuration or reconfiguration of storage systems by changing the path, e.g. traffic rerouting, path reconfiguration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/064—Management of blocks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G06F3/0658—Controller construction arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0683—Plurality of storage devices
    • G06F3/0689—Disk arrays, e.g. RAID, JBOD

Definitions

  • the present invention relates to a storage system, a control program for an information processing apparatus, and a storage system.
  • RTAP real-time analysis processing
  • n storage devices As described above, as one technique for simultaneously recording each collected information and simultaneously reproducing each recorded information, for example, n storage devices (n is a natural number of 2 or more) are operated in parallel.
  • a recording / reproducing apparatus that performs simultaneous recording / reproducing of m channels (m is a natural number of 2 to n).
  • the recording / reproducing apparatus separates the stream data of m channels and divides the data into k (k is a natural number between m and n) image units, and allocates the divided blocks of each channel to n storage devices. Record in order.
  • the recording / reproducing apparatus In the recording / reproducing apparatus described above, it has been described that data constituting a stream is divided into n and recorded in n recording means, but it is unclear how to divide the data. In addition, the recording / reproducing apparatus is not clearly different from a disk array technology in which a plurality of disks are combined and used as a single virtual disk, particularly RAID-0 (striping). Further, the recording / reproducing apparatus does not consider the speeding up of reading of the divided data.
  • a technique for speeding up reading of time series data stored in a storage unit is provided.
  • the storage system includes a data storage unit, a section storage unit, a search unit, and a reading unit.
  • the data storage unit stores divided data indicating data obtained by dividing time-series data.
  • the section storage unit stores information in which identification information for identifying the divided data is associated with information on the section indicating the start time and end time of the divided data.
  • the search unit obtains the first time, searches the section storage unit for a section that overlaps the section between the first time and the second time after the first time has elapsed, and performs a search.
  • the identification information of the divided data with respect to the section in which is performed is acquired.
  • the reading unit acquires the divided data corresponding to the acquired identification information from the data storage unit, and reads the acquired divided data in order of time.
  • An example of the storage system in this embodiment is shown.
  • An example of the stream data in this embodiment is shown.
  • 1 shows an example of a stream storage system related to accumulation of stream data in the present embodiment. It is a block diagram regarding the initialization process of the storage proxy in this embodiment. It is a block diagram regarding the write / sweep process of the storage proxy in this embodiment. It is a block diagram of the metadata server in this embodiment.
  • An example of the area management table in this embodiment is shown. 1 shows an example of a stream storage system related to reproduction of stream data in the present embodiment. It is a block diagram of the reproduction
  • An example of the node structure of the merge tree in this embodiment is shown.
  • An example of the read processing flow of the event block from the merge tree in this embodiment is shown.
  • An example of the processing flow when reading of an event block is completed for a node that has been added to the merge tree with a delay state flag of “with delay” in the present embodiment is shown.
  • An example of the section search processing flow of the metadata server in this embodiment is shown.
  • An example of the detailed flow of S43 of FIG. 16 is shown.
  • An example of the detailed flow of S54 of FIG. 17 is shown.
  • An example of the detailed flow of S58 of FIG. 17 is shown. It is a figure for demonstrating the determination method of the "next start time" in this embodiment.
  • An example of the processing flow for determining the “next start time” in the present embodiment is shown. It is a block diagram of a hardware environment of a computer that executes a program according to the present embodiment.
  • an in-memory database In-Memory Database
  • a column-oriented DB may be used for high-speed reproduction of a data stream by utilizing the fact that high-speed reading can be performed by reading a column of data of interest.
  • storage products that specialize in stream processing, such as reproducing a large amount of accumulated data at high speed have not yet been found.
  • the data stream processing execution environment is able to perform processing with parallelism that matches the available resources at that time, with the use in an environment where the amount of hardware used can be changed on demand, such as in the cloud.
  • it is necessary to be able to accumulate and reproduce with a parallel degree commensurate with the resource at that time.
  • Stream data is a data string arranged in a line in time.
  • RAID Redundant Arrays of Inexpensive Disks
  • n the necessary resource amount (for example, the disk amount) cannot be dynamically changed by changing the flow rate of the stream data.
  • this embodiment provides a storage system that can speed up the reading of the time-series data stored in the storage unit.
  • FIG. 1 shows an example of a storage system in this embodiment.
  • the storage system 1 includes a data storage unit 2, a section storage unit 3, a search unit 4, and a reading unit 5.
  • the data storage unit 2 stores divided data indicating data obtained by dividing time-series data.
  • An example of the data storage unit 2 is a storage node 16.
  • the section storage unit 3 stores information that associates identification information for identifying divided data with section information indicating the start time and end time of the divided data.
  • An example of the section storage unit 3 is a section management table 44.
  • the search unit 4 acquires the first time, and searches the section storage unit 3 for a section that overlaps the section between the first time and the second time after the first time has elapsed.
  • the identification information of the divided data with respect to the searched section is acquired.
  • An example of the search unit 4 is a metadata server 15.
  • the reading unit 5 acquires the divided data corresponding to the acquired identification information from the data storage unit 2, and reads the acquired divided data in order of time.
  • An example of the reading unit 5 is a reproduction client 50.
  • the search unit 4 obtains the earliest start time among the divided data that is not included in the overlapping sections and is later than the second time and before the end time, and uses the obtained start time to Search for.
  • the reading unit 5 reads out the divided data specified by the identification information corresponding to the earliest start time among the divided data that has been acquired from the data storage unit 2.
  • the storage system 1 further includes a distribution unit that distributes time-series data using a load balancing algorithm.
  • a distribution unit that distributes time-series data using a load balancing algorithm.
  • load balancer that distributes stream data to multiple destination nodes.
  • the distributed stream data is attached with at least one of the transmission time of the transmission source, the reception time of the load balancer, the transmission time, or the time stamp of the reception time at the destination node.
  • a distributed object storage that can freely scale the capacity and performance is used.
  • FIG. 2 shows an example of stream data in the present embodiment.
  • the stream data is time-series data divided at predetermined intervals.
  • Each divided data includes a header including a time stamp and a data body.
  • the time stamp may be substituted with the event serial number.
  • information for identifying the stream is given to the stream data.
  • FIG. 3 shows an example of a stream storage system related to accumulation of stream data in this embodiment.
  • the stream storage system 11 includes a load balancer 12, a storage proxy 13, a metadata server 15, and a storage node 16.
  • the client 10 is a device such as a sensor.
  • the client 10 is connected to the load balancer 12 via a communication network such as the Internet.
  • the load balancer 12 is connected so as to be able to communicate with each storage proxy 13.
  • Each storage proxy 13 is connected to be able to communicate with the metadata server 15.
  • Each storage proxy 13 is connected so that it can communicate with each storage node 16.
  • the load balancer 12 distributes the access request from the client 10 to different storage proxies 13 using a load balancing algorithm while showing a single URL (Uniform Resource Locator) to the client 10.
  • a load balancing algorithm When the storage proxy 13 is configured to have only one node or when the storage proxy 13 is equally accessed on the client 10 side, the load balancer 12 can be omitted.
  • the load distribution algorithm a round robin method, a minimum connection method, a fastest response method, or the like can be used.
  • the storage node 16 is an information processing apparatus corresponding to an object server that constitutes a distributed object storage.
  • the storage proxy 13 is a thread, process, or information processing device corresponding to a proxy server that constitutes the distributed object storage.
  • distributed object storage for example, Amazon S3 (Amazon Simple Storage Service) and OpenStack Swift are well known.
  • the storage proxy 13 has an internal buffer memory area 14 that temporarily holds data (events) transmitted from the client 10 with a predetermined capacity.
  • the storage proxy 13 receives the request from the client 10 and returns a response to the request.
  • the storage proxy 13 holds a table in which the data transmitted from the client 10 and the storage node 16 that stores the data are associated with each other in the storage device.
  • One or more storage proxies 13 may exist for one stream.
  • the metadata server 15 has a function of absorbing the dynamic increase / decrease of the storage proxy 13 during recording, and a function of reproducing the stream data by designating time.
  • the storage node 16 is an information processing apparatus having an area for storing data.
  • FIG. 4 is a block diagram relating to the initialization processing of the storage proxy in the present embodiment.
  • One or more storage proxies 13 may exist for one stream.
  • Each storage proxy 13 includes an internal component 21, an API (Application Program Interface) dispatch unit 22, an initialization processing unit 23, and a unique name determination unit 24.
  • an internal component 21, an API (Application Program Interface) dispatch unit 22, an initialization processing unit 23, and a unique name determination unit 24 perform the following processing.
  • the API dispatch unit 22 manages various APIs included in the storage proxy 13 and calls the APIs according to a request or at a predetermined timing.
  • the internal component 21 is a component on the upper middleware side that operates on the storage proxy 13 and calls an appropriate API in storage initialization, stream recording, and playback.
  • the initialization processing unit 23 initializes, for each stream, an area for temporarily holding an event in the internal buffer memory area 14 by calling the initialization API by the API dispatch unit 22 for each stream.
  • the internal buffer management unit 31 When read by the stream name setting API, the internal buffer management unit 31 reads the stream name of the stream from the received stream data and sets it in the stream name storage area in the internal buffer memory area 14.
  • the initialization processing unit 23 initializes the start time and end time stored in the internal buffer memory area 14.
  • the initialization processing unit 23 initializes the serial number (sequence number) of the event block stored in the internal buffer memory area 14 with “0”.
  • the initialization processing unit 23 calls the unique name determination unit 24.
  • the unique name determination unit 24 stores a unique name that does not suffer from the names of other storage proxies 13 in an area for storing the unique name in the internal buffer memory area 14.
  • one of the following methods can be selected.
  • As a first method when the metadata server 15 manages the names of all the storage proxies 13 that are currently operating, each storage proxy 13 requests the metadata server 15 for naming at the time of activation. The metadata server 15 generates a unique name and returns the generated unique name.
  • the storage proxy 13 may set a name that may be considered practically unique by a random number having a sufficiently large number of digits.
  • the IP (Internet Protocol) address of the storage proxy 13 may be used as the unique name.
  • FIG. 5 is a block diagram relating to the write / sweep process of the storage proxy in this embodiment.
  • the internal component 21, the API dispatch unit 22, the internal buffer management unit 31, and the event block name generation unit 32 perform the following processing.
  • the internal buffer management unit 31 operates when an event write API or a flush API is called from the API dispatch unit 22 when an event is received.
  • the internal buffer management unit 31 buffers the writing of stream data from the load balancer 12 in the internal buffer memory area 14 and packs it into an appropriately sized event block. Increasing the event block length increases the throughput, but increases the time required for writing. Conversely, if the event block length is reduced, the throughput is reduced, but the time required for writing is shortened.
  • the internal buffer management unit 31 When writing an event to the internal buffer memory area 14 when the internal buffer memory area 14 is empty, the internal buffer management unit 31 sets the time stamp of the event as the start time and end time. When an event is written when an event has already been written in the internal buffer memory area 14, the internal buffer management unit 31 sets the time stamp of the event as the end time. When the internal buffer described below is swept out, the internal buffer memory area 14 and the start / end time information are erased. Alternatively, the start time and the end time can be collectively set at the time of sweeping. Details will be described later.
  • the total data amount of the event block is fixed in advance, and when writing exceeds the upper limit of the total data amount of the event block, the internal buffer management unit 31 There is a way to sweep out.
  • the upper limit of the stay time of the event is set in advance, and when the upper limit stay time has elapsed from the reception time of the first event, the internal buffer management unit 31 sweeps the block. There is a way to do.
  • the internal buffer management unit 31 inquires of the event block name generation unit 32 about the event block name. Then, the event block name generation unit 32 assigns a unique name to the event block.
  • the event block name generation unit 32 reads the stream name, the unique name of the storage proxy itself, and the sequence number for the event block from the internal buffer memory area 14.
  • the event block name generation unit 32 sets unique information obtained by combining the read stream name, unique name, and sequence number as an event block name.
  • the event block name generation unit 32 returns the event block name to the internal buffer management unit 31. Further, the event block name generation unit 32 increments the sequence number stored in the internal buffer memory area 14.
  • the internal buffer management unit 31 When receiving a data transfer request, the internal buffer management unit 31 transmits the event block name and the event block held in the internal buffer memory area 14 to the storage node 16 determined from the event block name, Ask for writing.
  • the internal buffer management unit 31 updates the start time and end time of the internal buffer memory area 14 using the start time and end time of the event data constituting the event block as section information.
  • the internal buffer management unit 31 transmits [section information, event block name] to the metadata server 15. When the start and end of a section are designated by event numbers during playback, the time may be read as the event number.
  • FIG. 6 is a block diagram of the metadata server in the present embodiment.
  • the metadata server 15 includes a reception / response unit 41, a section tree search unit 42, a section tree management unit 43, and a section management table 44.
  • the section tree management table 44 is managed for each stream.
  • the reception / response unit 41 receives a request from the reproduction client 50 via a LAN (Local Area Network). In response to the request, the reception / response unit 41 requests the interval tree search unit 42 to search for overlapping intervals or inquires about the next start time.
  • the overlapping section refers to a section including event blocks that overlap within a time section (start time to end time) when a search request is made.
  • the reception / response unit 41 sends back the request result to the reproduction client 50 as a response to the request. Further, the reception / response unit 41 requests the section tree management unit 43 to add or delete sections in response to a request from the reproduction client 50.
  • the section tree search unit 42 acquires the stream name included in the request or inquiry transmitted from the reception / response unit 41, and selects the section management table 44 corresponding to the stream name. In response to the request or inquiry transmitted from the reception / response unit 41, the section tree search unit 42 reads the body information of the entry designating the reading position from the selected section management table 44 ("end time” in FIG. Information such as “event block name” and “data structure for management”).
  • the section tree management unit 43 acquires the stream name included in the request transmitted from the reception / response unit 41, and selects the section management table 44 corresponding to the stream name. The section tree management unit 43 adds an entry to the selected section management table 44 or updates the management data structure in response to the request transmitted from the reception / response unit 41.
  • FIG. 7 shows an example of the section management table in the present embodiment.
  • the interval tree is managed separately for each stream.
  • the section tree management unit 43 registers “event block name” 44-4, “start time” 44-2, and “end time” 44-3 in the section management table managed in a tree structure using time information as a key. to manage.
  • An example of the section management table 44 is a “section tree” represented by a data structure that employs a kind of tree structure.
  • the entries in the section management table include “record number” 44-1, “start time” 44-2, “end time” 44-3, “event block name” 44-4, and “management data structure” 44-5. Including.
  • Data structure for management 44-5 differs depending on the algorithm that realizes section management.
  • the “management data structure” 44-5 includes binary color information, a record number for the left subtree, a record structure for the right subtree, and the parent record number. , Including the minimum start time including myself and left and right subtrees, and the maximum end time including self and left and right subtrees.
  • an interval addition / deletion operation is implemented in the interval tree management unit 43, and an interval search is implemented in the interval tree search unit 42.
  • the section tree management unit 43 adds the entry shown in FIG. 7 when (start time, end time, event block name) is given, and also manages the section tree management data structure Is set to satisfy the following two-color tree condition. If the binary search tree satisfies the following two-color tree condition, it becomes a two-color tree. (1) Each node is either red or black. (2) All leaves (leaf value is empty (NIL)) are black. (3) If a contact is red, both of its children are black. (4) Any simple path from one node to its descendants contains the same number of black nodes.
  • the section tree management unit 43 when given the record number of the entry to be deleted, specifies the specified entry while satisfying the two-color tree condition for the management data structure of the other entries. Is deleted.
  • the procedure related to the section search will be described in detail in the search process of the metadata server 15.
  • the addition and deletion of sections can be executed with an execution time of O (log n) (where n is the total number of sections), and the search for sections is O (klog n) (where k is the section that is the answer) This is desirable as a section management method.
  • FIG. 8 shows an example of a stream storage system related to reproduction of stream data in the present embodiment.
  • the CEP (Complex Event Processing) engine is a core program of RTAP processing.
  • An application program such as a CEP engine or a user application acquires the stream data stored in the stream storage system 11 through the components of the stream storage 11.
  • An information processing apparatus that reproduces stream data in this way is referred to as a reproduction client 50.
  • An external application program such as a CEP engine or user application program is hereinafter referred to as an external application. These external applications operate on the playback client 50.
  • the playback client 50 can specify stream data distributed to each storage node 16 via the storage proxy 13 using stream data corresponding to the identification information using a predetermined API.
  • FIG. 9 is a block diagram of the playback client in this embodiment.
  • the stream playback process using the playback client 50 is as follows.
  • the external application 54 requests the playback client 50 to acquire an event of stream data to be played back.
  • the external application 54 calls the API by the API dispatch unit 51 of the reproduction client 50 and designates the stream name to be reproduced, the start time, and the end time.
  • the start time and end time can be omitted.
  • the time stamp of the first data of the stream and the time stamp of the last data of the stream are used instead.
  • the playback client 50 has, for example, the following APIs, and can use these APIs to acquire events required by the external application 54 without omission.
  • API that sets the range of playback time (start time and end time) API that checks whether all events in the specified time interval have been read API that checks whether the end of the stream ⁇ API to acquire one event
  • the merge tree management unit 52 operates with these APIs.
  • the merge tree management unit 52 inquires of the metadata server 15 about the overlapping section of the stream data to be reproduced and the next start time.
  • the metadata 15 returns a list of searched overlapping sections and the next start time to the merge tree management unit 52 as a search result.
  • the merge tree management unit 52 issues an event block read request to the storage node 16 via the storage proxy 13 based on the overlapping section list.
  • the event block read from the storage node 16 is stored in the merge tree storage area 53 of the playback client 50 via the storage proxy 13.
  • the merge tree is a data structure formed by a binary tree. A tree-like data structure for adding event blocks read from the storage node 16 to nodes of the binary tree and arranging them in order of time keys. Show. In this embodiment, a bicolor tree is used as an example of a binary tree.
  • the playback client 50 stores the event block read from the storage node 16 on the node of the merge tree.
  • the merge tree management unit 52 adds / deletes nodes and searches for nodes in the merge tree stored in the merge tree storage area 53, and reads events from the merge tree.
  • the playback client 50 makes an inquiry to the stream storage system 11 step by step by dividing the time range of the specified range. This will be described with reference to FIG.
  • FIG. 10 shows an example of a playback sequence in the present embodiment.
  • the playback client 50 requests the metadata server 15 to search for a section of stream data to be played back via the load balancer 12 and the storage proxy 13 (S1).
  • the playback client 50 makes an inquiry to the metadata server 15 with the playback start time and the section after the lapse of ⁇ time from the start time as inputs.
  • the metadata server 15 performs a section search process for stream data to be reproduced (S2).
  • the metadata server 15 returns to the playback client 50 an event block set (that is, an overlapping section) having section information that overlaps within the time section of the stream data to be played that has been queried.
  • the metadata server 15 includes “next start time” information in the response.
  • the playback client 50 receives a response from the metadata server 15. Then, the playback client 50 reads the event block from the storage node 16 using the event block name obtained from the response (S3, S4).
  • the process of reading a plurality of event blocks and integrating them into the merge tree may be performed sequentially or in parallel (asynchronously).
  • the playback client 50 integrates the event block read from the storage node 16 into the merge tree (S5).
  • the reading of the event block and the addition of the event block to the merge tree can be performed asynchronously using delayed execution.
  • the delayed execution will be described later.
  • the playback client 50 sets the “next start time” obtained in the response to the inquiry to the metadata server 15 as the start time, and when the start time is less than the end time, Furthermore, a search for a section of stream data to be reproduced is requested (S1).
  • FIG. 11 shows an example of an inquiry flow for reproduction by the reproduction client in this embodiment.
  • the external application 54 calls the API of the playback client 50 and designates the stream name to be played, the start time, and the end time.
  • the playback client 50 sets the start time to the parameter START_TIME (S11). If START_TIME ⁇ end time (“Yes” in S12), the playback client 50 sets a time obtained by adding ⁇ time to START_TIME as a parameter END_TIME (S13).
  • ⁇ is the minimum time width for inquiry.
  • the playback client 50 inquires the metadata server 15 about the section (START_TIME, END_TIME) (corresponding to S1 in FIG. 10).
  • the metadata server 15 replies to the reproduction client 50 with a set of event block names having section information that overlaps within the queried time section.
  • the metadata server 15 includes “next start time” information in the response (corresponding to S2 in FIG. 10).
  • the playback client 50 sets a set of event block names in the parameter RESULT_LIST and sets “next start time” in the parameter NEXT_START_TIME (S14). A method of determining the “next start time” will be described later with reference to FIGS.
  • the playback client 50 extracts one element (event block) from the RESULT_LIST and sets it in the parameter BLOCK_NAME.
  • the playback client 50 sets the remaining elements of RESULT_LIST to RESULT_LIST (S16).
  • the playback client 50 reads the event block corresponding to BLOCK_NAME from the storage node 16 (corresponding to S3 in FIG. 10). The playback client 50 sets the event block read from the storage node 16 in the parameter BLOCK (S17). The playback client 50 registers the BLOCK in the merge tree (S18).
  • the playback client 50 repeats S12 to S19.
  • START_TIME ⁇ end time is satisfied (S12)
  • the playback client 50 ends the event block read processing.
  • the event blocks read from the storage node 16 are merged into a data structure such as a merge tree shown in FIG.
  • white squares indicate event blocks
  • circles indicate time keys
  • hatched squares indicate event blocks during delayed reading.
  • the nodes of the merge tree have a data structure as shown in FIG.
  • the node structure 61 of the merge tree includes data items (fields) of “time key”, “delay state flag”, “index of array in event block”, and “event block”.
  • the field inside the node is represented by “field name”.
  • the type of the field is not specified, it can be easily guessed from the name.
  • an “event block” represents an event block field on a node, and becomes a reference type to the entity of the event block read into the memory.
  • the process of adding a new node to the merge tree is performed in the event block reading process described with reference to FIGS.
  • the playback client 50 initializes the node on the assumption of the following A1 to A4.
  • the time key is the time stamp of the first event in the block.
  • the “delay status flag” is set to “no delay”.
  • A3) “Event block array index” is set to 0 (first). (Special handling is required for the first rotation of the read loop of the event block in FIG. 11, and the index is advanced to an event having a time stamp equal to or later than the start time.)
  • A4 In the “event block”, a reference to the read event block entity is set.
  • the playback client 50 performs processing as shown in (B1) and (B2) below.
  • the time key is the start time of the section information obtained from the metadata server 15.
  • the “delay status flag” is “delayed”.
  • the time key is set both when adding a node to the merge tree after reading the event block and when adding a node to the merge tree before the block is read. Therefore, the playback client 50 can place additional nodes at appropriate positions in the merge tree.
  • FIG. 14 shows an example of a process flow for reading an event block from the merge tree in the present embodiment.
  • the playback client 50 reads the node A using the minimum time of the merge tree as a key, and deletes the contact A from the merge tree (S21).
  • the playback client 50 determines the magnitude relationship from the name of the event block. Since the name of the event block is guaranteed to be unique, if the order of the names is determined, the magnitude relationship between the nodes is uniquely determined.
  • the playback client 50 determines the event block corresponding to the node until the delay state flag is changed to “no delay”. Reading is temporarily stopped (S23).
  • the reproduction client 50 since the event block corresponding to the node A is being read from the storage node 16 as shown in FIG. 12, the reproduction client 50 reads the event block corresponding to the node A until the reading is completed. Absent.
  • the playback client 50 reads the event block pointed to by the “index in the event block array” at the node A. The playback client 50 writes this event block to the output stream (S24).
  • the playback client 50 increases the “index of the array in the event block” of the node A by 1 (S25).
  • the playback client 50 returns to the process of S21.
  • the playback client 50 When the “index of the array in the event block” does not exceed the number of events in the event block (“No” in S26), the playback client 50 performs the following process. That is, the playback client 50 reads the time stamp K of the event block indicated by the “event block index” at the node A (S27).
  • the playback client 50 adds a node having the read time stamp K as a key and a value as a node A (after update) to the merge tree (S28).
  • the playback client 50 repeats the processing of S21 to S28 while the merge tree is not empty (“No” in S29).
  • the playback client 50 When the reading of the event block is completed for the node that is added to the merge tree with the delay state flag “delayed”, the playback client 50 performs the process shown in FIG. That is, the playback client 50 updates the node delay state flag “with delay” to “without delay” (S31).
  • the playback client 50 sets “index in the event block array” to 0 (S32). Further, the playback client 50 sets a reference to the event block in the “event block” (S33).
  • the playback client 50 does not read the event block being read from the storage node 16 until the reading is completed.
  • the playback client 50 sequentially reads the read-completed event blocks from the earlier time. Therefore, a delay occurs for the event block being read from the storage node 16.
  • the node of the event block that has been read is read out and deleted from the merge tree independently of the delayed event block, and the event block is added to the merge tree.
  • the asynchronous execution of reading the event block and adding the event block to the merge tree is called delayed execution.
  • FIG. 16 shows an example of the section search processing flow of the metadata server in this embodiment.
  • the interval tree search unit 42 performs an interval search in response to a request or inquiry from the reception / response unit 41. At this time, the start time s and the end time e are passed from the reception / response unit 41 to the section tree search unit 42.
  • the section tree search unit 42 searches the root index of the tree from the section management table 44 and sets the root index to the index variable v. Further, the section tree search unit 42 initializes the index list variable L (S41).
  • the section tree search unit 42 uses the section management table 44 to determine whether or not the reference destination of the index variable v is a leaf (NIL).
  • a leaf is a node having no value (NIL).
  • the interval tree search unit 42 returns an empty index list variable L to the reception / response unit 41.
  • the interval tree search unit 42 calls the function serchAllFromNode (s, e, v) to search for all nodes (S43). ), And returns the search result to the reception / response unit 41. Details of S43 will be described with reference to FIG.
  • FIG. 17 shows an example of a detailed flow of S43 in FIG.
  • the section tree search unit 42 passes the start time s, end time e, and index variable v to the function serchAllFromNode (s, e, v).
  • the section tree search unit 42 initializes the index list variable L (S51).
  • the section tree search unit 42 determines whether or not the entry referred to by the index variable v overlaps the section [start time s, end time e] from the section management table 44 (S52). If the entry referenced by the index variable v does not overlap the section [start time s, end time e] (“No” in S52), the process proceeds to S54.
  • the section tree search unit 42 sets the union of the index variable v and the index list variable L. Is set in the index list variable L (S53).
  • the section tree search unit 42 calls the function checkOverlapOnLeftSubtree to check whether the tree on the left side of the index variable v overlaps the section [start time s, end time e] (S54). Details of S54 will be described with reference to FIG. If the left side of the index variable v does not overlap with the section [start time s, end time e] (“No” in S55), the section tree search unit 42 proceeds to the process of S58.
  • the section tree search unit 42 sets the left subtree index of the reference destination entry of the index variable v to the variable vL. (S56).
  • the interval tree search unit 42 calls the function serchAllFromNode, passes the start time s, end time e, and variable vL, searches for a node, and searches the left subtree index of the reference destination entry of the index variable v in FIG. Perform processing recursively.
  • the interval tree search unit 42 sets the union of the result of serchAllFromNode (s, e, vL) and the index list variable L to the index list variable L (S57).
  • the section tree search unit 42 checks whether the right side of the index variable v overlaps the section [start time s, end time e] (S58). Details of S58 will be described with reference to FIG. When the right side of the index variable v does not overlap with the section [start time s, end time e] (“No” in S59), the section tree search unit 42 ends this flow.
  • the section tree search unit 42 sets the right subtree index of the reference destination entry of the index variable v to the variable vR. (S60).
  • the section tree search unit 42 calls the function serchAllFromNode, passes the start time s, end time e, and variable vR to search for a node, and searches the left subtree index of the reference destination entry of the index variable v for the search processing of FIG. Is done recursively.
  • the interval tree search unit 42 sets the union of the result of serchAllFromNode (s, e, vR) and the index list variable L to the index list variable L (S61).
  • FIG. 18 shows an example of a detailed flow of S54 in FIG.
  • the index variable v, start time s, and end time e are passed.
  • the interval tree search unit 42 sets the index of the left subtree of the index variable v to the index variable p (S71).
  • the section tree search unit 42 determines whether or not the reference destination of the index variable p is a leaf (NIL node) (S72).
  • the section tree search unit 42 When the reference destination of the index variable p is a leaf (NIL node) (“Yes” in S72), the section tree search unit 42 performs the following process. That is, the interval tree search unit 42 returns “false” as a check result of whether the left side of the index variable v overlaps with [start time s, end time e] by the function checkOverlapOnLeftSubtree.
  • the interval tree search unit 42 sets the maximum end time of the reference destination entry of the index variable p to the variable max, and the index variable p Is set to the variable min (S73).
  • variable min> end time e or start time s> variable max (“No” in S74) the section tree search unit 42 performs the following processing. That is, the interval tree search unit 42 returns “false” as a check result of whether the left side of the index variable v overlaps with [start time s, end time e] by the function checkOverlapOnLeftSubtree.
  • variable min ⁇ end time e and start time s ⁇ variable max (“Yes” in S74), the following processing is performed. That is, the interval tree search unit 42 returns “True” as a check result of whether the left side of the index variable v overlaps with [start time s, end time e] by the function checkOverlapOnLeftSubtree.
  • FIG. 19 shows an example of a detailed flow of S58 of FIG.
  • the function checkOverlapOnRightSubtree is called, the index variable v, start time s, and end time e are passed.
  • the interval tree search unit 42 sets the index variable p to the index of the right subtree of the index variable v (S81). The interval tree search unit 42 determines whether the reference destination of the index variable p is a leaf (NIL node) (S82).
  • the section tree search unit 42 When the reference destination of the index variable p is a leaf (NIL node) (“Yes” in S82), the section tree search unit 42 performs the following process. That is, the section tree search unit 42 returns “false” as a check result by the function checkOverlapOnRightSubtree as to whether the right side of the index variable v overlaps with [start time s, end time e].
  • the interval tree search unit 42 sets the maximum end time of the reference destination entry of the index variable p to the variable max, and the index variable p Is set to the variable min (S83).
  • variable min> end time e or start time s> variable max (“No” in S84) the section tree search unit 42 performs the following processing. That is, the section tree search unit 42 returns “false” as a check result by the function checkOverlapOnRightSubtree as to whether the right side of the index variable v overlaps with [start time s, end time e].
  • variable min ⁇ end time e and start time s ⁇ variable max (“Yes” in S84), the following processing is performed. That is, the interval tree search unit 42 returns “True” as a check result by the function checkOverlapOnRightSubtree as to whether the right side of the index variable v overlaps with [start time s, end time e].
  • the playback client 50 has transmitted an inquiry message including (playback start time, playback end time) as parameters to the metadata server 15 in advance.
  • the metadata server 15 executes the section tree search unit 42.
  • the section tree search unit 42 executes searchAllFromRoot (playback start time, playback end time), and obtains an index list (list) of entries that overlap the section.
  • the section tree search unit 42 reads the triplet data of (entry name, start time, end time) of each entry from the index list (list), and generates a triplet data list L1.
  • the section tree search unit 42 executes searchMinAfter (reproduction end time) and determines the “next start time”.
  • the metadata server 15 returns the list L1 and the determined “next start time” as a pair to the reproduction client 50.
  • FIG. 20 is a diagram for explaining a method of determining the “next start time” in the present embodiment.
  • searchMinAfter is a function that returns “next start time”.
  • Thick horizontal lines 71, 72, 73, 74, and 75 indicate event blocks.
  • the “next start time” will be described with reference to (1) the inquiry section in FIG. 20 as an example.
  • the event blocks 71 to 75 are event blocks before the inquiry end time END_TIME.
  • a set S of event blocks that overlap the section (START_TIME, START_TIME + ⁇ ) is event blocks 71 and 72.
  • event blocks that are not included in the set S and that have a start time greater than START_TIME + ⁇ and before the inquiry end time END_TIME are event blocks 73 to 75.
  • this minimum start time is determined as the “next start time”.
  • FIG. 21 shows an example of a processing flow for determining the “next start time” in the present embodiment.
  • the section tree search unit 42 searches for the root index of the tree from the section management table 44, and sets the root index to the index variable v.
  • the section tree search unit 42 initializes the time variable t with “ ⁇ ” (S91).
  • the section tree search unit 42 determines whether or not the reference destination of the index variable v is a leaf (NIL) using the section management table 44 (S92). When the reference destination of the index variable v is not a leaf (NIL) (“No” in S92), the section tree search unit 42 sets the start time of the entry of the reference destination of the index variable v to the variable u (S93).
  • the interval tree search unit 42 sets the right subtree index of the reference destination entry of the index variable v to the index variable v (S95).
  • interval tree search unit 42 sets the left subtree index of the reference destination entry of the index variable v to the index variable v (S96).
  • time variable t> variable u (“Yes” in S97)
  • interval tree search unit 42 sets the start time set in variable u to time variable t (S98).
  • FIG. 22 is a configuration block diagram of a hardware environment of a computer that executes a program according to the present embodiment.
  • the computer 80 is a load balancer 12, a storage proxy 13, a metadata server 15, a storage node 16, a client 10, and a playback client 50.
  • the computer 80 includes a CPU 82, ROM 83, RAM 86, communication I / F 84, storage device 87, output I / F 81, input I / F 85, reading device 88, bus 89, output device 91, and input device 92.
  • CPU indicates a central processing unit.
  • ROM indicates a read-only memory.
  • RAM indicates random access memory.
  • I / F indicates an interface.
  • a CPU 82, a ROM 83, a RAM 86, a communication I / F 84, a storage device 87, an output I / F 81, an input I / F 85, and a reading device 88 are connected.
  • the reading device 88 is a device that reads a portable recording medium.
  • the output device 91 is connected to the output I / F 81.
  • the input device 92 is connected to the input I / F 85.
  • the storage device 87 various types of storage devices such as a hard disk, a flash memory, and a magnetic disk can be used.
  • the storage device 87 or the ROM 83 stores a program according to the present embodiment.
  • the storage device 87 has, for example, an internal buffer memory area 14.
  • the section management table 44 is stored in the storage device 87 or the ROM 83.
  • the storage device 87 has an area for storing event blocks, for example.
  • the storage device 87 has, for example, a merge tree storage area 53.
  • the CPU 82 reads out a program that realizes the processing described in the above embodiment, stored in the storage device 87 or the like, and executes the program.
  • the program that realizes the processing described in the above embodiment may be stored in, for example, the storage device 87 from the program provider side via the communication network 90 and the communication I / F 84.
  • achieves the process demonstrated by the said embodiment may be stored in the portable storage medium marketed and distribute
  • the portable storage medium may be set in the reading device 88 and the program read by the CPU 82 and executed.
  • a portable storage medium various types of storage media such as a CD-ROM, a flexible disk, an optical disk, a magneto-optical disk, an IC card, and a USB memory device can be used.
  • the program stored in such a storage medium is read by the reading device 88.
  • the input device 92 can be a keyboard, mouse, electronic camera, web camera, microphone, scanner, sensor, tablet, or the like.
  • the output device 91 can be a display, a printer, a speaker, or the like.
  • the network 90 may be a communication network such as the Internet, a LAN, a WAN, a dedicated line, a wired line, and a wireless line.
  • variable large flow rate stream data can be stored and reproduced at high speed.
  • variable large flow rate stream data can be accumulated at high speed as follows.
  • the stream is distributed to the plurality of storage proxies 13 by the load balancer 12. Therefore, the load balancer 12 can distribute the stream data to the performance limit of the network. Therefore, accumulation of stream data can be achieved up to the network performance limit of the load balancer if a sufficient number of storage nodes are prepared.
  • the storage proxy 13 packs event data in a block called event block.
  • the storage can be written in a size that can achieve the maximum throughput of the storage.
  • the storage writing can be performed in parallel by the plurality of storage proxies 13, a writing performance proportional to the number of storage nodes 16 can be obtained. That is, the number of storage proxies and storage nodes can be changed according to the flow rate of the stream.
  • the number of storage nodes 16 dynamically expands and contracts by managing where the event block containing the data is stored on the storage by the metadata server 15.
  • the management targets of the metadata server 15 are event block names and section information.
  • the playback client 50 can reconstruct the original stream from the data divided into event blocks. By acquiring event blocks necessary for reproduction through the load balancer 12, network resources can be used effectively.
  • the stream can be played from that time (or event sequence number).
  • the stream can be played from that time (or event sequence number).
  • a minimum set of event blocks that may include data at that time can be obtained.
  • the playback client 50 does not read event blocks in the playback time range at once.
  • An event block for ⁇ hours is read from the reproduction start time, and a merge tree that holds data for at least ⁇ hours is created. Reconstruct the partial stream from the merge tree and play it back.
  • the next time is not the previous reproduction time + ⁇ time, but the “next start time” is determined from the interval tree. As a result, even when ⁇ is short, the next partial stream can be reconstructed without reducing efficiency. In this way, incremental (incremental) processing is possible and system resources are not wasted.
  • the playback client 50 does not read the event blocks being read from the storage node 16 until the reading is completed, and sequentially reads the event blocks that have been read.
  • the read processing using the merge tree is parallel processing, and high speed can be realized in that the unit of processing is extremely fine granularity of reading data from nodes. Therefore, the reproduction of stream data is accelerated by parallel reading of the storage nodes.
  • the present invention is not limited to the embodiment described above, and various configurations or embodiments can be taken without departing from the gist of the present invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Mathematical Physics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Software Systems (AREA)
  • Computational Linguistics (AREA)
  • Fuzzy Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

　ストレージシステムは、時系列のデータが分割されたデータを示す分割データを格納するデータ格納部と、分割データを識別する識別情報と、分割データの開始時刻及び終了時刻を示す区間の情報とを関連付けた情報を格納する区間格納部と、第１の時刻を取得し、区間格納部から、第１の時刻と第１の時刻を所定時間経過した第２の時刻との間の区間に重複する区間の検索を行い、検索を行った区間に対する分割データの識別情報を取得する検索部と、データ格納部から、取得した識別情報に対応する分割データを取得し、取得した分割データを時刻順に読み出す読出部と、を含む。

Description

ストレージシステム、情報処理装置の制御プログラム及びストレージシステムの制御方法
　本発明は、ストレージシステム、情報処理装置の制御プログラム及びストレージシステムに関する。
　センサ情報や各種ログなどを対象に実時間分析処理（ＲＴＡＰ(REAL TIME ANALYTICAL PROCESSING))の市場が拡大しており、その入力となる時系列データの効率的な蓄積・利用が重要になっている。時系列データの情報収集解析サービスをクラウド上で行う場合、多数のセンサ、多数のログの入力が束ねられ、膨大なデータ列を蓄積し、全データまたは部分系列が必要に応じて再生される。
　このように、収集された各情報を同時に記録したり、記録した各情報を同時に再生する技術の１つとして、例えば、ｎ個（ｎは２以上の自然数）の記憶装置を並列に動作させてｍチャンネル（ｍは２以上ｎ以下の自然数）の同時記録再生を行う記録再生装置がある。記録再生装置は、ｍチャンネルのストリームデータを分離してｋ個（ｋはｍ以上ｎ以下の自然数）の画像単位のブロックに分割し、各チャンネルの分割したブロックをｎ個の記憶装置に割り振って順番に記録する。
特開２００１－１４８８３２号公報
　上述した記録再生装置において、ストリームを構成するデータをｎ分割し、ｎ個の記録手段に記録することは述べられているが、具体的にどのように分割するのか不明である。また、当該記録再生装置は、複数のディスクを組み合わせて１台の仮想ディスクとして使用するディスクアレイ技術、特に、ＲＡＩＤ－０（ストライピング）との差異が明確でない。また、当該記録再生装置においては、分割したデータの読み出しの高速化については考慮されていない。
　本発明では、一側面として、格納部に格納された時系列データの読み出しの高速化を図る技術を提供する。
　ストレージシステムは、データ格納部、区間格納部、検索部、読出部を含む。データ格納部は、時系列のデータが分割されたデータを示す分割データを格納する。区間格納部は、分割データを識別する識別情報と、分割データの開始時刻及び終了時刻を示す区間の情報とを関連付けた情報を格納する。検索部は、第１の時刻を取得し、区間格納部から、第１の時刻と第１の時刻を所定時間経過した第２の時刻との間の区間に重複する区間の検索を行い、検索を行った区間に対する分割データの識別情報を取得する。読出部は、データ格納部から、取得した識別情報に対応する分割データを取得し、取得した分割データを時刻順に読み出す。
　本発明によれば、一側面として、格納部に格納された時系列データの読み出しの高速化を図ることができる。
本実施形態におけるストレージシステムの一例を示す。 本実施形態におけるストリームデータの一例を示す。 本実施形態におけるストリームデータの蓄積に関するストリームストレージシステムの一例を示す。 本実施形態におけるストレージプロキシの初期化処理に関するブロック図である。 本実施形態におけるストレージプロキシの書き込み・掃出し処理に関するブロック図である。 本実施形態におけるメタデータサーバのブロック図である。 本実施形態における区間管理表の一例を示す。 本実施形態におけるストリームデータの再生に関するストリームストレージシステムの一例を示す。 本実施形態における再生クライアントのブロック図である。 本実施形態における再生シーケンスの一例を示す。 本実施形態における再生クライアントによる再生のための問合せフローの一例を示す。 本実施形態におけるマージツリーの一例を示す。 本実施形態におけるマージツリーの節点構造の一例を示す。 本実施形態におけるマージツリーからのイベントブロックの読み出し処理フローの一例を示す。 本実施形態における、遅延状態フラグが「遅延あり」としてマージツリーに追加されている節点について、イベントブロックの読み出しが完了した場合の処理フローの一例を示す。 本実施形態におけるメタデータサーバの区間検索処理フローの一例を示す。 図１６のＳ４３の詳細フローの一例を示す。 図１７のＳ５４の詳細フローの一例を示す。 図１７のＳ５８の詳細フローの一例を示す。 本実施形態における「次の開始時刻」の決定方法について説明するための図である。 本実施形態における「次の開始時刻」の決定する処理フローの一例を示す。 本実施形態に係るプログラムを実行するコンピュータのハードウェア環境の構成ブロック図である。
　ＲＴＡＰ向けストレージには、インメモリデータベース（Ｉｎ－Ｍｅｍｏｒｙ　Ｄａｔａｂａｓｅ）やカラム指向ＤＢ（Ｄａｔａｂａｓｅ）が使用されている。特にカラム指向ＤＢは、注目しているデータのカラムを読み出すことで高速読み出しができる点を利用して、データストリームの高速再生に用いられる場合がある。しかし、大量に蓄積したデータを丸ごと高速に再生するといった、ストリーム処理に特化したストレージ製品は今のところまだ見られない。
　データストリーム処理実行環境は、クラウドのように利用ハードウェア量をオンデマンドで変更できる環境での活用を念頭に、その時々の利用可能リソースに見合った並列度で処理ができるようにしている。蓄積データにおいても、この特徴を活かすためには、その時々のリソースに見合った並列度で蓄積・再生できることが必要になる。
　ストリームデータは時間的に一列に並んだデータ列である。この時間的な順序を保存するため、ファイルに追記する場合、書き込みが逐次化されてしまい、ストレージの書き込み性能に制約される。複数のディスク（ｎ台）を束ねて使用するＲＡＩＤ（Redundant Arrays of Inexpensive Disks）技術は、ディスク単体の書き込み速度のｎ倍を実現するものである。しかし、ストリームデータの流量の変化によって必要な資源量（例えば、ディスク量）を動的に変化させることはできない。
　ストリームデータの流量が増大した場合には、負荷分散器（ロードバランサ）で受け口となるサーバを増やすことが考えられる。そこで、負荷分散器と組み合わせた場合において、データの受け口が別々のサーバとなった場合にもストリームデータが適切に蓄積できることが求められる。また、蓄積技術と対となる技術として、蓄積形態に応じたデータの再構成技術が必要である。
　また、全データをメモリ上に一括して配置し、ストリーム順に整列させることは、莫大なシステムリソース（メモリ、ＣＰＵパワー）を必要とするため現実的ではない。したがって、ストリームの一部分を成すデータを増加的に再構成して整列させることで、現実的なシステムリソースの元でデータを出力していくことが必要である。
　上記ストリームの一部分を成すデータを増加的に再構成して整列させる処理を高速に行うことも求められる。
　そこで、本実施形態では、格納部に格納された時系列データの読み出しの高速化を図ることができるストレージシステムを提供する。
　図１は、本実施形態におけるストレージシステムの一例を示す。ストレージシステム１は、データ格納部２、区間格納部３、検索部４、読出部５を含む。
　データ格納部２は、時系列のデータが分割されたデータを示す分割データを格納する。データ格納部２の一例として、ストレージノード１６が挙げられる。
　区間格納部３は、分割データを識別する識別情報と、分割データの開始時刻及び終了時刻を示す区間の情報とを関連付けた情報を格納する。区間格納部３の一例として、区間管理表４４が挙げられる。
　検索部４は、第１の時刻を取得し、区間格納部３から、第１の時刻と第１の時刻を所定時間経過した第２の時刻との間の区間に重複する区間の検索を行い、検索を行った区間に対する分割データの識別情報を取得する。検索部４の一例として、メタデータサーバ１５が挙げられる。
　読出部５は、データ格納部２から、取得した識別情報に対応する分割データを取得し、取得した分割データを時刻順に読み出す。読出部５の一例として、再生クライアント５０が挙げられる。
　このように構成することにより、格納部に格納された時系列データの読み出しの高速化を図ることができる。
　検索部４は、重複する区間に含まれない分割データであって第２の時刻より遅く、終了時刻以前の分割データのうち、最も早い開始時刻を取得し、取得した開始時刻を用いて、次の検索を行う。
　このように構成することにより、並列処理を実現することができる。
　読出部５は、データ格納部２からの取得が完了した分割データのうち、最も早い開始時刻に対応する識別情報で特定される分割データを読み出す。
　このように構成することにより、より開始時間の早い分割データから順に読出しを行うことができる。
　ストレージシステム１は、さらに、負荷分散アルゴリズムを用いて、時系列のデータを振り分ける振分部を含む。このように構成することにより、大流量のストリームデータを分散して並列に格納することができるので、ストリームデータの蓄積処理の高速化を図ることができる。
　本実施形態の一例では、大流量のストリームを捌くために以下の仕組みを前提とする。
　負荷分散器（ロードバランサ）が存在し、ストリームのデータを複数の宛先ノードに分配する。
　分配されたストリームのデータには、送信元の送信時刻、負荷分散器の受信時刻、送信時刻、または宛先ノードでの受信時刻のタイムスタンプの少なくとも１つが付けられる。また、本実施形態では、容量、性能を自在に拡縮できる分散オブジェクトストレージを用いる。
　図２は、本実施形態におけるストリームデータの一例を示す。ストリームデータは、所定間隔で区切られた時系列のデータである。この区切られた各データ（イベント）は、タイムスタンプを含むヘッダと、データ本体を含む。なお、タイムスタンプは、イベントの通番で代用してもよい。また、ストリームデータには、ストリームを識別する情報（ストリーム名）が付与されている。
　図３は、本実施形態におけるストリームデータの蓄積に関するストリームストレージシステムの一例を示す。ストリームストレージシステム１１は、負荷分散器１２、ストレージプロキシ１３、メタデータサーバ１５、ストレージノード１６を含む。
　クライアント１０は、センサ等のデバイスである。クライアント１０は、負荷分散器１２とインターネット等の通信ネットワークを介して接続されている。負荷分散器１２は、各ストレージプロキシ１３と通信可能なように接続されている。各ストレージプロキシ１３は、メタデータサーバ１５と通信可能なように接続されている。各ストレージプロキシ１３は、各ストレージノード１６と通信可能なように接続されている。
　負荷分散器１２は、クライアント１０に単一のＵＲＬ（Uniform Resource Locator）を見せつつ、クライアント１０からのアクセス要求を、負荷分散アルゴリズムを用いて、異なるストレージプロキシ１３に分散させる。ストレージプロキシ１３が１ノードだけの構成またはクライアント１０側で均等にストレージプロキシ１３をアクセスする場合、負荷分散器１２を省略することができる。負荷分散アルゴリズムとしては、ラウンドロビン方法、最小コネクション方法、最速レスポンス方法等を用いることができる。
　ストレージノード１６は、分散オブジェクトストレージを構成するオブジェクトサーバに相当する情報処理装置である。ストレージプロキシ１３は、分散オブジェクトストレージを構成するプロキシサーバに相当するスレッド、プロセスまたは情報処理装置である。分散オブジェクトストレージとしては、例えば、Amazon S3（Amazon Simple Storage Service）やOpenStack Swiftがよく知られている。
　ストレージプロキシ１３は、クライアント１０から送信されたデータ（イベント）を、一時的に、所定の容量保持する内部バッファメモリ領域１４を有する。ストレージプロキシ１３は、クライアント１０の要求を受信し、その要求に対する応答を返す。また、ストレージプロキシ１３は、クライアント１０から送信されたデータと、その格納する先のストレージノード１６との対応付けたテーブルを記憶装置に保持している。ストレージプロキシ１３は、１つのストリームに対して、１以上存在してもよい。
　メタデータサーバ１５は、記録時の動的なストレージプロキシ１３の増減を吸収する機能、及びストリームデータに対して時刻を指定して再生する機能を有する。
　ストレージノード１６は、データを格納する領域を有する情報処理装置である。
　図４は、本実施形態におけるストレージプロキシの初期化処理に関するブロック図である。ストレージプロキシ１３は、１つのストリームに対して、１つでもよいし、複数存在してもよい。各ストレージプロキシ１３は、内部コンポーネント２１、ＡＰＩ（Application Program Interface）ディスパッチ部２２、初期化処理部２３、ユニーク名決定部２４を含む。ストレージプロキシ１３毎に、内部コンポーネント２１、ＡＰＩ（Application Program Interface）ディスパッチ部２２、初期化処理部２３、ユニーク名決定部２４は以下の処理を行う。
　ＡＰＩディスパッチ部２２は、ストレージプロキシ１３が有する種々のＡＰＩを管理し、要求に応じてまたは所定のタイミング等でＡＰＩを呼び出す。内部コンポーネント２１は、ストレージプロキシ１３上で動作する、上位ミドルウェア側のコンポーネントであり、ストレージの初期化、ストリームの記録、再生において適切なＡＰＩを呼び出すものである。
　初期化処理部２３は、ストリーム毎に、ＡＰＩディスパッチ部２２により初期化ＡＰＩが呼び出されることにより、内部バッファメモリ領域１４のうち、イベントを一時的に保持する領域をストリーム毎に初期化する。
　内部バッファ管理部３１は、ストリーム名設定ＡＰＩにより読み出されると、受信したストリームデータからそのストリームのストリーム名を読み出し、内部バッファメモリ領域１４内のストリーム名格納領域に設定する。
　また、初期化処理部２３は、内部バッファメモリ領域１４に格納された開始時刻、終了時刻を初期化する。また、初期化処理部２３は、内部バッファメモリ領域１４に格納されたイベントブロックについての通番（シーケンス番号）を“０”で初期化する。
　初期化処理部２３は、ユニーク名決定部２４を呼び出す。ユニーク名決定部２４は、他のストレージプロキシ１３の名前と被らないユニークな名前を内部バッファメモリ領域１４内のユニーク名を格納する領域に格納する。このとき、ユニークな名前の設定には、以下の方法のいずれかを選択することができる。第１の方法として、メタデータサーバ１５が現在動作中の全てのストレージプロキシ１３の名前を管理する場合、各ストレージプロキシ１３は起動時にメタデータサーバ１５に名付けを要求する。メタデータサーバ１５は、ユニークな名前を生成し、その生成したユニーク名を返す。第２の方法として、ストレージプロキシ１３は、十分大きな桁数を持つ乱数によって、実用上ユニークと考えてよい名前を自ら設定してもよい。第３の方法として、ストレージプロキシ１３のＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）アドレスをユニーク名に用いてもよい。
　図５は、本実施形態におけるストレージプロキシの書き込み・掃出し処理に関するブロック図である。ストレージプロキシ１３毎に、内部コンポーネント２１、ＡＰＩディスパッチ部２２、内部バッファ管理部３１、イベントブロック名生成部３２は以下の処理を行う。
　内部バッファ管理部３１は、イベント受信時において、ＡＰＩディスパッチ部２２からイベント書き込みＡＰＩまたは掃出しＡＰＩが呼び出されることにより動作する。内部バッファ管理部３１は、イベント受信時において、負荷分散器１２からのストリームデータの書き込みを内部バッファメモリ領域１４にバッファリングし、適切なサイズのイベントブロックにパッキングする。イベントブロック長を大きくするとスループットは増大するが、書き込みに要する時間が長くなる。逆に、イベントブロック長を小さくすると、スループットが減少するが、書き込みに要する時間は短くなる。
　内部バッファメモリ領域１４が空のときに、内部バッファメモリ領域１４へのイベントの書き込みを行う場合、内部バッファ管理部３１は、そのイベントのタイムスタンプを開始時刻と終了時刻に設定する。内部バッファメモリ領域１４に既にイベントが書き込まれているときに、イベントの書き込みを行う場合、内部バッファ管理部３１は、そのイベントのタイムスタンプを終了時刻に設定する。以下で述べる内部バッファの掃出しが行われると、内部バッファメモリ領域１４と開始・終了時刻情報は消去される。あるいは、開始時刻と終了時刻は掃出し時に一括して設定されることもできる。詳細は後述する。
　イベントブロックへのパッキングと掃出しの仕方は以下の方法があり、仕様に応じて組み合わせることができる。
　第１のパッキング・掃出し方法としては、イベントブロックの総データ量を予め固定しておき、イベントブロックの総データ量の上限を超える書き込みが来た場合に、内部バッファ管理部３１は、イベントブロックの掃き出しを行う方法がある。
　第２のパッキング・掃出し方法としては、イベント数を予め固定しておき、イベント数の上限に達した場合に、内部バッファ管理部３１は、ブロックの掃出しを行う方法がある。
　第３のパッキング・掃出し方法としては、イベントの滞在時間の上限を予め設定しておき、先頭のイベントの受信時間から上限の滞在時間が経過した場合に、内部バッファ管理部３１は、ブロックの掃出しを行う方法がある。
　第４のパッキング・掃出し方法としては、外部のアプリケーションからＡＰＩを用いて明示的に掃出し要求が来た場合に、内部バッファ管理部３１は、イベントブロックの掃出しを行う方法がある。
　内部バッファ管理部３１は、イベントブロック名生成部３２にイベントブロック名を問い合わせる。すると、イベントブロック名生成部３２は、イベントブロックにユニークな名前を付ける。ここで、イベントブロック名生成部３２は、イベントブロックの名前を付ける場合、内部バッファメモリ領域１４から、ストリーム名と、ストレージプロキシ自身のユニーク名と、イベントブロックについてのシーケンス番号とを読み出す。イベントブロック名生成部３２は、その読み出したストリーム名とユニーク名とシーケンス番号とを組にしたユニークな情報を、イベントブロック名とする。イベントブロック名生成部３２は、そのイベントブロック名を内部バッファ管理部３１に返信する。さらに、イベントブロック名生成部３２は、内部バッファメモリ領域１４に格納されているシーケンス番号をインクリメントする。
　内部バッファ管理部３１は、データ転送要求を受けた場合には、イベントブロック名から定まるストレージノード１６に対して、イベントブロック名と内部バッファメモリ領域１４に保持していたイベントブロックを送信して、書き込みを依頼する。
　内部バッファ管理部３１は、イベントブロックを構成するイベントデータの開始時刻と終了時刻を区間情報とし、内部バッファメモリ領域１４の開始時刻と終了時刻を更新する。内部バッファ管理部３１は、［区間情報、イベントブロック名］をメタデータサーバ１５に送信する。なお、再生時に、区間の開始と終了をイベント番号で指定する場合には、時刻をイベント番号に読み替えればよい。
　図６は、本実施形態におけるメタデータサーバのブロック図である。メタデータサーバ１５は、受信・応答部４１、区間木検索部４２、区間木管理部４３、区間管理表４４を含む。区間木管理表４４は、ストリーム毎に管理されている。
　受信・応答部４１は、ＬＡＮ（Local Area Network）を介して、再生クライアント５０からの要求を受信する。その要求に応じて、受信・応答部４１は、区間木検索部４２に対して、重なり区間の検索を要求したり、次の開始時刻の問い合わせをする。ここで、重なり区間とは、検索要求のあった時刻区間内（開始時刻～終了時刻）にオーバラップするイベントブロックを含む区間をいう。受信・応答部４１は、その依頼結果を、要求に対する応答として再生クライアント５０に返信する。また、受信・応答部４１は、再生クライアント５０からの要求に応じて、区間の追加または削除を区間木管理部４３に要求する。
　区間木検索部４２は、受信・応答部４１から送信された要求または問い合わせに含まれるストリーム名を取得し、そのストリーム名に対応する区間管理表４４を選択する。区間木検索部４２は、受信・応答部４１から送信された要求または問い合わせに応じて、その選択した区間管理表４４から、読み取り位置を指定したエントリのボディ情報（図７の「終了時刻」、「イベントブロック名」、「管理用データ構造」等の情報）を取得する。
　区間木管理部４３は、受信・応答部４１から送信された要求に含まれるストリーム名を取得し、そのストリーム名に対応する区間管理表４４を選択する。区間木管理部４３は、受信・応答部４１から送信された要求に応じて、その選択した区間管理表４４にエントリの追加または管理データ構造の更新を行う。
　図７は、本実施形態における区間管理表の一例を示す。区間木は、ストリーム毎に別々に管理される。区間木管理部４３は、時刻情報をキーとしてツリー構造で管理される区間管理表に「イベントブロック名」４４－４、「開始時刻」４４－２、「終了時刻」４４－３を登録して管理する。区間管理表４４の一例は、木構造の一種を採用したデータ構造で示される「区間木」である。区間管理表のエントリは、「レコード番号」４４－１、「開始時刻」４４－２、「終了時刻」４４－３、「イベントブロック名」４４－４、「管理用データ構造」４４－５を含む。
　「管理用データ構造」４４－５は、区間管理を実現するアルゴリズムによって異なる。区間木が２色木（または赤黒木ともいう）の場合、「管理用データ構造」４４－５は、二値の色情報、左部分木用レコード番号、右部分木用レコード構造、親レコード番号、自分と左右部分木を含めた最少開始時刻、自分と左右部分木を含めた最大終了時刻を含む。
　区間管理表４４に対する操作として、区間木管理部４３には区間の追加、削除操作が実装され、区間木検索部４２には区間の検索が実装されている。
　区間の追加の場合には、区間木管理部４３は、（開始時刻、終了時刻、イベントブロック名）が与えられたときに、図７で示すエントリを追加し、かつ、区間木の管理データ構造が以下の二色木条件を満たすように設定する。二分探索木が以下の二色木条件を満たす場合、二色木となる。
（１）各節点は、赤または黒のどちらかである。
（２）葉（葉の値は空（ＮＩＬ）である）は全て黒である。
（３）ある接点が赤であれば、その子供は両方とも黒である。
（４）１つの節点からその子孫までのどの単純な経路も、同じ数だけ黒の節点を含む。
　区間の削除の場合には、区間木管理部４３は、削除対象となるエントリのレコード番号が与えられたときに、他のエントリの管理データ構造について二色木条件を満たしつつ、指定されたエントリを削除する。
　区間の検索の場合には、区間木検索部４２は、（開始時刻、終了時刻）が与えられたときに、区間木の管理データ構造から、この区間に重なる全ての区間情報（＝レコード番号のリスト）を求める。
　区間検索に関する手続きについては、メタデータサーバ１５の検索処理で詳述する。なお、区間の追加と削除は、Ｏ（ｌｏｇ　ｎ）（ここでｎは区間の総数）の実行時間で実行でき、区間の検索は、Ｏ（ｋｌｏｇ　ｎ）（ここで、ｋは答えとなる区間の総数）の実行時間で実行できるため、区間の管理方法として望ましい。
　次に、ストリームストレージシステム１１の再生処理について詳述する。
　図８は、本実施形態におけるストリームデータの再生に関するストリームストレージシステムの一例を示す。ＣＥＰ（Complex Event Processing）エンジンは、ＲＴＡＰ処理の中核的なプログラムである。ＣＥＰエンジンまたはユーザアプリケーション等のアプリケーションプログラムは、ストリームストレージシステム１１に蓄積されたストリームデータを、ストリームストレージ１１のコンポーネントを通して取得する。このようにストリームデータを再生する情報処理装置を再生クライアント５０と称する。また、ＣＥＰエンジンまたはユーザアプリケーションプログラム等の外部アプリケーションプログラムを、以下、外部アプリと称する。これらの外部アプリは、再生クライアント５０上で動作する。
　外部アプリがストリームを識別する情報を指定する。すると、再生クライアント５０は、所定のＡＰＩを用いて、その識別する情報に対応するストリームデータを、ストレージプロキシ１３を介して、各ストレージノード１６に分散されたストリームデータを特定することができる。
　図９は、本実施形態における再生クライアントのブロック図である。再生クライアント５０を用いたストリーム再生処理は、次のようになる。外部アプリ５４は、再生クライアント５０に対し、再生すべきストリームデータのイベントの取得を要求する。このとき、外部アプリ５４は、再生クライアント５０のＡＰＩディスパッチ部５１により、ＡＰＩを呼び出して、再生すべきストリーム名、開始時刻、終了時刻を指定する。開始時刻と終了時刻は省略することができ、開始時刻と終了時刻を省略した場合には、ストリームの先頭データのタイムスタンプ、ストリームの最終データのタイムスタンプが代用される。
　再生クライアント５０は、例えば、以下のようなＡＰＩを有しており、これらのＡＰＩを用いて外部アプリ５４が必要とするイベントを漏れなく取得することができる。
・再生する時刻の範囲（開始時刻と終了時刻）を設定するＡＰＩ
・指定した時刻区間内の全イベントを読み出したかをチェックするＡＰＩ
・ストリームの終端かどうかをチェックするＡＰＩ
・イベントを１つ取得するＡＰＩ
・ストリームの終端の時刻情報を更新するＡＰＩ（このＡＰＩはストリームが非同期に書き込まれている状況で有用である。）
　これらのＡＰＩにより、マージツリー管理部５２が動作する。マージツリー管理部５２は、メタデータサーバ１５に対して、再生すべきストリームデータの重なり区間及び次の開始時刻を問い合わせる。メタデータ１５は、検索結果として、検索された重なり区間のリストと、次の開始時刻をマージツリー管理部５２に返信する。
　マージツリー管理部５２は、ストレージプロキシ１３を介して、重なり区間のリストに基づいて、ストレージノード１６へイベントブロックの読み出し要求を行う。ストレージノード１６から読み出したイベントブロックは、ストレージプロキシ１３を介して、再生クライアント５０のマージツリー格納領域５３に格納される。マージツリーとは、二分木で形成されるデータ構造であって、ストレージノード１６から読み出したイベントブロックをその二分木の節点に追加し、時刻キー順に整列させていくためのツリー状のデータ構造を示す。本実施形態では、二分木の一例として、二色木を利用している。再生クライアント５０は、ストレージノード１６から読み出したイベントブロックをマージツリーの節点上に格納する。
　マージツリー管理部５２は、マージツリー格納領域５３に格納されたマージツリーについて節点の追加、削除、節点の検索を行なったり、マージツリーからイベントの読み出しを行う。
　まずは、イベントブロックの読み出しについて説明する。外部アプリ５４より再生の開始時刻と終了時刻が指定された場合、再生クライアント５０は、その指定された範囲の時刻区間を区切って段階的にストリームストレージシステム１１に問合せを行う。これについて、図１０を用いて説明する。
　図１０は、本実施形態における再生シーケンスの一例を示す。再生クライアント５０は、メタデータサーバ１５に、負荷分散器１２、ストレージプロキシ１３を介して、再生すべきストリームデータの区間の検索を要求する（Ｓ１）。ここでは、再生クライアント５０は、再生の開始時刻と開始時刻からΔ時刻経過後の区間を入力として、メタデータサーバ１５に問い合わせる。
　メタデータサーバ１５は、再生クライアント５０からの問い合わせに応じて、再生すべきストリームデータの区間検索処理を行う（Ｓ２）。ここでは、メタデータサーバ１５は、問合せのあった再生すべきストリームデータの時刻区間内にオーバラップする区間情報を持つイベントブロック集合（すなわち、重なり区間）を、再生クライアント５０に返答する。このとき、メタデータサーバ１５は「次の開始時刻」の情報を、その返答に含める。
　再生クライアント５０は、メタデータサーバ１５からの応答を受信する。すると、再生クライアント５０は、その応答により得られたイベントブロック名を用いて、イベントブロックをストレージノード１６から読み出す（Ｓ３、Ｓ４）。複数のイベントブロックを読み出し、マージツリーに統合する処理（以下に詳述）は逐次に行ってもよいし、並列（非同期）に行ってもよい。
　再生クライアント５０は、ストレージノード１６から読み出したイベントブロックをマージツリーに統合する（Ｓ５）。ここで、イベントブロックの読み出しと、マージツリーへのイベントブロックの追加とは、遅延実行を用いて非同期に行うことができる。遅延実行については、後述する。
　再生クライアント５０は、メタデータサーバ１５への問合せに対する応答において得られた「次の開始時刻」を開始時刻に設定し、開始時刻が終了時刻に満たない場合は、メタデータサーバ１５に対して、さらに、再生すべきストリームデータの区間の検索を要求する（Ｓ１）。
 　図１１は、本実施形態における再生クライアントによる再生のための問合せフローの一例を示す。上述したように、外部アプリ５４は、再生クライアント５０のＡＰＩを呼び出して、再生すべきストリーム名、開始時刻、終了時刻を指定する。
　再生クライアント５０は、開始時刻をパラメータSTART_TIMEに設定する（Ｓ１１）。START_TIME＜終了時刻である場合（Ｓ１２で「Ｙｅｓ」）、再生クライアント５０は、START_TIMEにΔ時刻を加算した時刻を、パラメータEND_TIMEに設定する（Ｓ１３）。ここで、Δは問い合わせのための最少時刻幅とする。
　再生クライアント５０は、区間（START_TIME、END_TIME）について、メタデータサーバ１５に問合せをする（図１０のＳ１に対応する）。メタデータサーバ１５は、問合せのあった時刻区間内にオーバラップする区間情報を持つイベントブロックの名前の集合を、再生クライアント５０に返答する。このとき、メタデータサーバ１５は「次の開始時刻」の情報を返答に含める（図１０のＳ２に対応する）。再生クライアント５０は、メタデータサーバ１５からの応答を受信すると、イベントブロックの名前の集合を、パラメータRESULT_LISTに設定し、「次の開始時刻」をパラメータNEXT_START_TIMEに設定する（Ｓ１４）。「次の開始時刻」の決定方法については、図２０、図２１において後述する。
　RESULT_LISTが空集合φでない場合（Ｓ１５で「Ｙｅｓ」）、再生クライアント５０は、RESULT_LISTから１つの要素（イベントブロック）を取り出し、パラメータBLOCK_NAMEに設定する。再生クライアント５０は、RESULT_LISTの残りの要素を、RESULT_LISTに設定する（Ｓ１６）。
　再生クライアント５０は、ストレージノード１６から、BLOCK_NAMEに対応するイベントブロックを読み出す（図１０のＳ３に対応する。）。再生クライアント５０は、ストレージノード１６から、読み出したイベントブロックをパラメータBLOCKに設定する（Ｓ１７）。再生クライアント５０は、そのBLOCKをマージツリーに登録する（Ｓ１８）。
　RESULT_LISTが空集合φになるまで、Ｓ１６～Ｓ１８の処理を繰り返す。RESULT_LISTが空集合φになった場合（Ｓ１５で「Ｎｏ」）、再生クライアント５０は、NEXT_START_TIMEの値を、START_TIMEに設定し（Ｓ１９）、Ｓ１２の処理へ戻る。
　START_TIME＜終了時刻の間、再生クライアント５０は、Ｓ１２～Ｓ１９を繰り返す。START_TIME≧終了時刻となる場合（Ｓ１２）、再生クライアント５０は、イベントブロックの読み出し処理を終了する。
　図１２の再生問合せ処理は、図１４の読み出し処理と非同期に実施すると再生開始時刻から再生終了時刻までの全ブロックをマージツリー、すなわち、メモリ上に保持することになる。そのため、データ量が莫大である場合にはシステムリソースを考慮したペースで当該再生問い合わせ処理を行うことが必要である。問合せのペースを調整する方法の一例として、読み出し処理で１ブロック分のデータを読み出したら、１ブロックをストレージノードから獲得するようにするものである。
　次に、マージツリーからのイベントブロックの読み出しについて説明する。ストレージノード１６から読み出されたイベントブロックは、マージツリーという、図１２に示すようなデータ構造に合流される。図１２において、白色の四角はイベントブロックを示し、丸は時刻キーを示し、ハッチングされた四角は遅延読み出し中のイベントブロックを示す。マージツリーの節点は、図１３に示すようなデータ構造である。マージツリーの節点構造６１は、「時刻キー」、「遅延状態フラグ」、「イベントブロック内配列のインデックス」、「イベントブロック」のデータ項目（フィールド）を含む。以下では、節点内部のフィールドを「フィールド名」で表す。また、そのフィールドの型は明示していない場合、名前から容易に推測できるものになる。例えば、「イベントブロック」とは、節点上のイベントブロック・フィールドのことを表し、メモリ上に読み込まれたイベントブロックの実体への参照型になる。
　マージツリーに新しい節点を追加する処理は、図１０及び図１１で説明したイベントブロックの読み出し処理において行われる。イベントブロックの読み出し後にマージツリーに節点を追加する場合には、再生クライアント５０は、以下のＡ１～Ａ４を前提として節点を初期化する。
（Ａ１）時刻キーはブロックの先頭のイベントのタイムスタンプとする。
（Ａ２）「遅延状態フラグ」は「遅延なし」とする。
（Ａ３）「イベントブロック内配列のインデクス」は０（先頭）とする。
（図１１のイベントブロックの読み出しループの１回目の回転について特別扱いが必要で、インデックスは開始時刻と同じかそれ以降のタイムスタンプを持つイベントまで進めておく。）
（Ａ４）「イベントブロック」には読み出したイベントブロック実体の参照をセットする。
　また、ブロックの読み出し完了前にマージツリーへの追加する場合には、再生クライアント５０は、以下の（Ｂ１）、（Ｂ２）のように処理する。
（Ｂ１）時刻キーは、メタデータサーバ１５から入手した区間情報のうちの開始時刻、とする。
（Ｂ２）「遅延状態フラグ」は「遅延あり」とする。
　イベントブロックの読み出し後にマージツリーに節点を追加する場合及びブロックの読み出し完了前にマージツリーへの追加する場合のいずれも、時刻キーは設定されている。そのため、再生クライアント５０は、マージツリーの適切な位置に追加節点を配置することができる。
　図１４は、本実施形態におけるマージツリーからのイベントブロックの読み出し処理フローの一例を示す。再生クライアント５０は、マージツリーの最小時刻をキーとする節点Ａを読み出し、かつ、接点Ａをマージツリーから削除する（Ｓ２１）。ここで、最小時刻が同じである節点が複数存在する場合、再生クライアント５０は、イベントブロックの名前から大小関係を決定する。イベントブロックの名前はユニークであることが保証されているので、名前の順序を定めれば、節点同士の大小関係は一意に定まる。
　節点Ａについて、遅延状態フラグが「遅延あり」である場合（Ｓ２２で「Ｙｅｓ」）、遅延状態フラグが「遅延なし」に変更されるまで、再生クライアント５０は、その節点に対応するイベントブロックの読み出しを一時停止する（Ｓ２３）。ここで、節点Ａに対応するイベントブロックは、図１２に示すように、ストレージノード１６からの読み出し中なので、再生クライアント５０はその読み出しが完了するまで、節点Ａに対応するイベントブロックの読み出しを行わない。
　遅延状態フラグが「遅延なし」である場合（Ｓ２２で「Ｙｅｓ」または、Ｓ２３の処理後）、再生クライアント５０は、節点Ａの「イベントブロック内配列のインデックス」の指しているイベントブロックを読み出す。再生クライアント５０は、このイベントブロックを出力ストリームに書き出す（Ｓ２４）。
　再生クライアント５０は、節点Ａの「イベントブロック内配列のインデックス」を１増やす（Ｓ２５）。
　「イベントブロック内配列のインデックス」が、イベントブロックのイベント数を越えた場合（Ｓ２６で「Ｙｅｓ」）、再生クライアント５０は、Ｓ２１の処理へ戻る。
　「イベントブロック内配列のインデックス」が、イベントブロックのイベント数を越えていない場合（Ｓ２６で「Ｎｏ」）、再生クライアント５０は、次の処理を行う。すなわち、再生クライアント５０は、節点Ａの「イベントブロックのインデックス」の指しているイベントブロックのタイムスタンプＫを読み出す（Ｓ２７）。
　再生クライアント５０は、読み出したタイムスタンプＫをキー、バリューを節点Ａ（更新後）とする節点をマージツリーに追加する（Ｓ２８）。
　再生クライアント５０は、マージツリーが空でない間（Ｓ２９で「Ｎｏ」）、Ｓ２１～Ｓ２８の処理を繰り返す。
　遅延状態フラグが「遅延あり」としてマージツリーに追加されている節点について、イベントブロックの読み出しが完了した場合、再生クライアント５０は、図１５に示す処理を行う。すなわち、再生クライアント５０は、節点の遅延状態フラグ「遅延あり」を「遅延なし」に更新する（Ｓ３１）。
　再生クライアント５０は、「イベントブロック内配列のインデックス」を０にする（Ｓ３２）。さらに、再生クライアント５０は、「イベントブロック」にイベントブロックへの参照を設定する（Ｓ３３）。
　このように、再生クライアント５０は、ストレージノード１６からの読み出し中のイベントブロックについては、再生クライアント５０は読み出しが完了するまで読み出しをしない。一方で、再生クライアント５０は、読み出し完了のイベントブロックを、時刻のより早い方から順に読み出す。したがって、ストレージノード１６からの読み出し中のイベントブロックについて遅延が発生する。しかし、読み出し完了のイベントブロックの節点は、その遅延しているイベントブロックとは独立して、読み出されてマージツリーから削除されつつ、マージツリーへのイベントブロックの追加が行われる。このように、イベントブロックの読み出しと、マージツリーへのイベントブロックの追加とを非同期に行うことを遅延実行という。
　次に、メタデータサーバ１５の区間木検索部４２による区間検索に関する処理について説明する。
　図１６は、本実施形態におけるメタデータサーバの区間検索処理フローの一例を示す。区間木検索部４２は、受信・応答部４１からの要求または問い合わせに応じて、区間検索を行う。このとき、受信・応答部４１から区間木検索部４２へ、開始時刻ｓ、終了時刻ｅが渡される。
　区間木検索部４２は、区間管理表４４からツリーのルートインデックスを検索し、ルートインデックスをインデックス変数ｖに設定する。また、区間木検索部４２は、インデックスリスト変数Ｌを初期化する（Ｓ４１）。
　区間木検索部４２は、区間管理表４４を用いて、インデックス変数ｖの参照先が葉（ＮＩＬ）であるか否かを判定する。ここで、２色木において、葉は、値を持たない（ＮＩＬ）ノードである。インデックス変数ｖの参照先が葉（ＮＩＬ）である場合（Ｓ４２で「Ｙｅｓ」）、区間木検索部４２は、空のインデックスリスト変数Ｌを受信・応答部４１に返す。
　インデックス変数ｖの参照先が葉（ＮＩＬ）でない場合（Ｓ４２で「Ｎｏ」）、区間木検索部４２は、関数serchAllFromNode(s, e, v)を呼び出して、全ノードを対象に検索し（Ｓ４３）、その検索結果を受信・応答部４１に返す。Ｓ４３の詳細については、図１７を用いて説明する。
　図１７は、図１６のＳ４３の詳細フローの一例を示す。区間木検索部４２は、関数serchAllFromNode(s, e, v)に、開始時刻ｓ、終了時刻ｅ、インデックス変数ｖを渡す。区間木検索部４２は、インデックスリスト変数Ｌを初期化する（Ｓ５１）。
　区間木検索部４２は、区間管理表４４から、インデックス変数ｖの参照先のエントリが区間［開始時刻ｓ，終了時刻ｅ］と重なるか否かを判定する（Ｓ５２）。インデックス変数ｖの参照先のエントリが区間［開始時刻ｓ，終了時刻ｅ］と重ならない場合（Ｓ５２で「Ｎｏ」）、Ｓ５４へ進む。
　インデックス変数ｖの参照先のエントリが区間［開始時刻ｓ，終了時刻ｅ］と重なる場合（Ｓ５２で「Ｙｅｓ」）、区間木検索部４２は、インデックス変数ｖと、インデックスリスト変数Ｌとの和集合を、インデックスリスト変数Ｌに設定する（Ｓ５３）。
　区間木検索部４２は、関数checkOverlapOnLeftSubtreeを呼び出して、インデックス変数ｖの左側のツリーが、区間［開始時刻ｓ，終了時刻ｅ］と重なるかをチェックする（Ｓ５４）。Ｓ５４の詳細については、図１８で説明する。インデックス変数ｖの左側が、区間［開始時刻ｓ，終了時刻ｅ］と重ならない場合（Ｓ５５で「Ｎｏ」）、区間木検索部４２は、Ｓ５８の処理へ進む。
　インデックス変数ｖの左側が、区間［開始時刻ｓ，終了時刻ｅ］と重なる場合（Ｓ５５で「Ｙｅｓ」）、区間木検索部４２は、インデックス変数ｖの参照先エントリの左部分木インデックスを変数ｖＬに設定する（Ｓ５６）。
　区間木検索部４２は、関数serchAllFromNodeを呼び出して、開始時刻ｓ、終了時刻ｅ、変数ｖＬを引き渡して、ノードを検索行い、インデックス変数ｖの参照先エントリの左部分木インデックスについて、図１７の検索処理を再帰的に行う。区間木検索部４２は、serchAllFromNode(s, e, vL)の結果と、インデックスリスト変数Ｌとの和集合を、インデックスリスト変数Ｌに設定する（Ｓ５７）。
　区間木検索部４２は、インデックス変数ｖの右側が、区間［開始時刻ｓ，終了時刻ｅ］と重なるかをチェックする（Ｓ５８）。Ｓ５８の詳細については、図１９で説明する。インデックス変数ｖの右側が、区間［開始時刻ｓ，終了時刻ｅ］と重ならない場合（Ｓ５９で「Ｎｏ」）、区間木検索部４２は、本フローを終了する。
　インデックス変数ｖの右側が、区間［開始時刻ｓ，終了時刻ｅ］と重なる場合（Ｓ５９で「Ｙｅｓ」）、区間木検索部４２は、インデックス変数ｖの参照先エントリの右部分木インデックスを変数ｖＲに設定する（Ｓ６０）。
　区間木検索部４２は、関数serchAllFromNodeを呼び出して、開始時刻ｓ、終了時刻ｅ、変数ｖＲを引き渡してノードを検索行い、インデックス変数ｖの参照先エントリの左部分木インデックスについて、図１７の検索処理を再帰的に行う。区間木検索部４２は、serchAllFromNode(s, e, vR)の結果と、インデックスリスト変数Ｌとの和集合を、インデックスリスト変数Ｌに設定する（Ｓ６１）。
　図１８は、図１７のＳ５４の詳細フローの一例を示す。checkOverlapOnLeftSubtreeの呼び出し時には、インデックス変数ｖ, 開始時刻ｓ, 終了時刻ｅが引き渡される。
　区間木検索部４２は、インデックス変数ｖの左部分木のインデックスを、インデックス変数ｐに設定する（Ｓ７１）。区間木検索部４２は、インデックス変数ｐの参照先が葉（ＮＩＬノード）か否かを判定する（Ｓ７２）。
　インデックス変数ｐの参照先が葉（ＮＩＬノード）である場合（Ｓ７２で「Ｙｅｓ」）、区間木検索部４２は、次の処理を行う。すなわち、区間木検索部４２は、関数checkOverlapOnLeftSubtreeによる、インデックス変数ｖの左側は［開始時刻ｓ，終了時刻ｅ］と重なるかというチェック結果として、「ｆａｌｓｅ」を返す。
　インデックス変数ｐの参照先が葉（ＮＩＬノード）でない場合（Ｓ７２で「Ｎｏ」）、区間木検索部４２は、インデックス変数ｐの参照先エントリの最大終了時刻を変数ｍａｘに設定し、インデックス変数ｐの参照先エントリの最小開始時刻を変数ｍｉｎに設定する（Ｓ７３）。
　変数ｍｉｎ＞終了時刻ｅまたは開始時刻ｓ＞変数ｍａｘである場合（Ｓ７４で「Ｎｏ」）、区間木検索部４２は、次の処理を行う。すなわち、区間木検索部４２は、関数checkOverlapOnLeftSubtreeによる、インデックス変数ｖの左側は［開始時刻ｓ，終了時刻ｅ］と重なるかというチェック結果として、「ｆａｌｓｅ」を返す。
　変数ｍｉｎ≦終了時刻ｅかつ開始時刻ｓ≦変数ｍａｘである場合（Ｓ７４で「Ｙｅｓ」）、次の処理を行う。すなわち、区間木検索部４２は、関数checkOverlapOnLeftSubtreeによる、インデックス変数ｖの左側は［開始時刻ｓ，終了時刻ｅ］と重なるかというチェック結果として、「Ｔｒｕｅ」を返す。
　図１９は、図１７のＳ５８の詳細フローの一例を示す。関数checkOverlapOnRightSubtreeの呼び出し時には、インデックス変数ｖ, 開始時刻ｓ, 終了時刻ｅが引き渡される。
　区間木検索部４２は、インデックス変数ｖの右部分木のインデックスを、インデックス変数ｐに設定する（Ｓ８１）。区間木検索部４２は、インデックス変数ｐの参照先が葉（ＮＩＬノード）か否かを判定する（Ｓ８２）。
　インデックス変数ｐの参照先が葉（ＮＩＬノード）である場合（Ｓ８２で「Ｙｅｓ」）、区間木検索部４２は、次の処理を行う。すなわち、区間木検索部４２は、関数checkOverlapOnRightSubtreeによる、インデックス変数ｖの右側は［開始時刻ｓ，終了時刻ｅ］と重なるかというチェック結果として、「ｆａｌｓｅ」を返す。
　インデックス変数ｐの参照先が葉（ＮＩＬノード）でない場合（Ｓ８２で「Ｎｏ」）、区間木検索部４２は、インデックス変数ｐの参照先エントリの最大終了時刻を変数ｍａｘに設定し、インデックス変数ｐの参照先エントリの最小開始時刻を変数ｍｉｎに設定する（Ｓ８３）。
　変数ｍｉｎ＞終了時刻ｅまたは開始時刻ｓ＞変数ｍａｘである場合（Ｓ８４で「Ｎｏ」）、区間木検索部４２は、次の処理を行う。すなわち、区間木検索部４２は、関数checkOverlapOnRightSubtreeによる、インデックス変数ｖの右側は［開始時刻ｓ，終了時刻ｅ］と重なるかというチェック結果として、「ｆａｌｓｅ」を返す。
　変数ｍｉｎ≦終了時刻ｅかつ開始時刻ｓ≦変数ｍａｘである場合（Ｓ８４で「Ｙｅｓ」）、次の処理を行う。すなわち、区間木検索部４２は、関数checkOverlapOnRightSubtreeによる、インデックス変数ｖの右側は［開始時刻ｓ，終了時刻ｅ］と重なるかというチェック結果として、「Ｔｒｕｅ」を返す。
　次に、図１０のＳ２において、再生クライアント５０への応答に含めた「次の開始時刻」、具体的には、図１１のＳ１４において、決定した「次の開始時刻」の取得方法について、図２０、図２１を用いて説明する。
　予め、再生クライアント５０がメタデータサーバ１５に（再生開始時刻、再生終了時刻）をパラメータとして含む問い合せメッセージを送信したとする。このとき、メタデータサーバ１５は、メッセージを受信したとき、そのメッセージが区間検索に関するものである場合、区間木検索部４２の実行を行う。
　区間木検索部４２は、searchAllFromRoot（再生開始時刻、再生終了時刻）を実行し、その区間にオーバラップするエントリのインデックス一覧（リスト）を求める。区間木検索部４２は、そのインデックス一覧（リスト）から、各エントリの（ブロック名、開始時刻、終了時刻）の３つ組データを全エントリ分読み出し、３つ組みデータのリストＬ１を生成する。
　区間木検索部４２は、searchMinAfter（再生終了時刻）を実行し、「次の開始時刻」を決定する。メタデータサーバ１５は、リストＬ１と、決定した「次の開始時刻」をペアとして、再生クライアント５０に返答する。
　図２０は、本実施形態における「次の開始時刻」の決定方法について説明するための図である。図２０において、searchMinAfterは、「次の開始時刻」を返す関数である。横方向の太線７１，７２，７３，７４，７５は、イベントブロックを示す。
　区間（START_TIME，START_TIME+Δ）にオーバラップするイベントブロックの集合をＳとする。集合Ｓに含まれないイベントブロックであって、開始時刻がSTART_TIME+Δより大きく、かつ問合せの終了時刻END_TIME以前のイベントブロックが存在するとき、このようなイベントブロックのうち最少の開始時刻を問合せの「次の開始時刻」として定義する。
　「次の開始時刻」について、例えば、図２０の（１）問い合わせ区間を例に説明する。ここで、イベントブロック７１～７５はいずれも、問合せの終了時刻END_TIME以前のイベントブロックであるとする。区間（START_TIME，START_TIME+Δ）にオーバラップするイベントブロックの集合Ｓは、イベントブロック７１，７２である。このとき、集合Ｓに含まれないイベントブロックであって、開始時刻がSTART_TIME+Δより大きく、かつ問合せの終了時刻END_TIME以前のイベントブロックは、イベントブロック７３～７５である。このうち、最小の開始時刻を有するのはイベントブロック７３であるから、この最小の開始時刻が「次の開始時刻」と決定される。
　このようにすることにより、「次の開始時刻」より前の時刻で問合せを行っても、集合Ｓのサブセットしか得られないため、問合せ回数を最適化することができる。
　図２１は、本実施形態における「次の開始時刻」の決定する処理フローの一例を示す。区間木検索部４２は、区間管理表４４からツリーのルートインデックスを検索し、ルートインデックスをインデックス変数ｖに設定する。また、区間木検索部４２は、時刻変数ｔを“∞”で初期化する（Ｓ９１）。
　区間木検索部４２は、区間管理表４４を用いて、インデックス変数ｖの参照先が葉（ＮＩＬ）であるか否かを判定する（Ｓ９２）。インデックス変数ｖの参照先が葉（ＮＩＬ）でない場合（Ｓ９２で「Ｎｏ」）、区間木検索部４２は、インデックス変数ｖの参照先のエントリの開始時刻を変数ｕに設定する（Ｓ９３）。
　変数ｕ＞入力時刻ｑの場合（Ｓ９４で「Ｎｏ」）、区間木検索部４２は、インデックス変数ｖの参照先エントリの右部分木インデックスをインデックス変数ｖに設定する（Ｓ９５）。
　変数ｕ≦入力時刻ｑの場合（Ｓ９４で「Ｙｅｓ」）、区間木検索部４２は、インデックス変数ｖの参照先エントリの左部分木インデックスをインデックス変数ｖに設定する（Ｓ９６）。ここで、時刻変数ｔ＞変数ｕの場合（Ｓ９７で「Ｙｅｓ」）、区間木検索部４２は、変数ｕに設定されている開始時刻を時刻変数ｔに設定する（Ｓ９８）。
　インデックス変数ｖの参照先が葉（ＮＩＬ）になるまで、Ｓ９３～Ｓ９８の処理を繰り返す。インデックス変数ｖの参照先が葉（ＮＩＬ）になった場合（Ｓ９２で「Ｙｅｓ」）、区間木検索部４２は、時刻変数ｔを受信・応答部４１に返す。
　図２２は、本実施形態に係るプログラムを実行するコンピュータのハードウェア環境の構成ブロック図である。コンピュータ８０は、負荷分散器１２、ストレージプロキシ１３、メタデータサーバ１５、ストレージノード１６、クライアント１０、再生クライアント５０である。コンピュータ８０は、ＣＰＵ８２、ＲＯＭ８３、ＲＡＭ８６、通信Ｉ／Ｆ８４、記憶装置８７、出力Ｉ／Ｆ８１、入力Ｉ／Ｆ８５、読み取り装置８８、バス８９、出力機器９１、入力機器９２によって構成されている。
　ここで、ＣＰＵは、中央演算装置を示す。ＲＯＭは、リードオンリメモリを示す。ＲＡＭは、ランダムアクセスメモリを示す。Ｉ／Ｆは、インターフェースを示す。バス８９には、ＣＰＵ８２、ＲＯＭ８３、ＲＡＭ８６、通信Ｉ／Ｆ８４、記憶装置８７、出力Ｉ／Ｆ８１、入力Ｉ／Ｆ８５、及び読み取り装置８８が接続されている。読み取り装置８８は、可搬型記録媒体を読み出す装置である。出力機器９１は、出力Ｉ／Ｆ８１に接続されている。入力機器９２は、入力Ｉ／Ｆ８５に接続にされている。
　記憶装置８７としては、ハードディスク、フラッシュメモリ、磁気ディスクなど様々な形式の記憶装置を使用することができる。記憶装置８７またはＲＯＭ８３には、本実施形態に係るプログラム等が格納されている。ストレージプロキシ１３の場合、記憶装置８７には、例えば、内部バッファメモリ領域１４がある。また、メタデータサーバ１５の場合、記憶装置８７またはＲＯＭ８３には、例えば、区間管理表４４が格納されている。ストレージノード１６の場合、記憶装置８７には、例えば、イベントブロックを格納する領域がある。再生クライアント５０の場合、記憶装置８７には、例えば、マージツリー格納領域５３がある。
　ＣＰＵ８２は、記憶装置８７等に格納した上記実施形態で説明した処理を実現するプログラムを読み出し、当該プログラムを実行する。
　上記実施形態で説明した処理を実現するプログラムは、プログラム提供者側から通信ネットワーク９０、および通信Ｉ／Ｆ８４を介して、例えば記憶装置８７に格納されてもよい。また、上記実施形態で説明した処理を実現するプログラムは、市販され、流通している可搬型記憶媒体に格納されていてもよい。この場合、この可搬型記憶媒体は読み取り装置８８にセットされて、ＣＰＵ８２によってそのプログラムが読み出されて、実行されてもよい。可搬型記憶媒体としてはＣＤ－ＲＯＭ、フレキシブルディスク、光ディスク、光磁気ディスク、ＩＣカード、ＵＳＢメモリ装置など様々な形式の記憶媒体を使用することができる。このような記憶媒体に格納されたプログラムが読み取り装置８８によって読み取られる。
　また、入力機器９２には、キーボード、マウス、電子カメラ、ウェブカメラ、マイク、スキャナ、センサ、タブレットなどを用いることが可能である。また、出力機器９１には、ディスプレイ、プリンタ、スピーカなどを用いることが可能である。また、ネットワーク９０は、インターネット、ＬＡＮ、ＷＡＮ、専用線、有線、無線等の通信網であってよい。
　本実施形態によれば、可変大流量のストリームデータを高速に蓄積・再生することができる。まず、以下のようにして、可変大流量のストリームデータを高速に蓄積することができる。ストリームは、負荷分散器１２によって複数のストレージプロキシ１３に分配される。したがって、負荷分散器１２はネットワークの性能限界までストリームのデータを捌くことができる。したがって、ストリームデータの蓄積は、ストレージノードの台数を十分に用意すれば負荷分散器のネットワーク性能限界まで達成できる。
　また、ストレージプロキシ１３は、イベントブロックという塊にイベントデータをパックする。これによって、ストレージの最大スループットを達成できるサイズでストレージへの書き込みを行える。また、ストレージの書き込みは複数のストレージプロキシ１３によって並列して行えるため、ストレージノード１６の台数に比例する書き込み性能が得られる。すなわち、ストレージプロキシとストレージノードの台数はストリームの流量に応じて変化させることができる。
　また、データを固めたイベントブロックがストレージ上のどこに存在しているかをメタデータサーバ１５によって管理することでストレージノード１６の台数が動的に拡縮することに対応している。メタデータサーバ１５の管理対象は、イベントブロック名と区間情報である。
　次に、高速に再生する技術上の利点は以下の通りである。再生クライアント５０は、イベントブロックに分割されたデータから元のストリームを再構成することができる。再生に必要なイベントブロックは負荷分散器１２を通して獲得することで、ネットワークリソースを有効に利用することができる。
　また、以下のようにして、時刻（または、イベント通番）が指定されたとき、その時刻（またはイベント通番）からストリームを再生することができる。具体的には、時刻が指定されたとき、その時刻のデータを含む可能性のあるイベントブロックの最小集合を求めることができる。
　また、以下のようにして、再生に必要なシステムリソース量を適切に制御し、現実的なシステムリソースの元で再生処理を行うことができる。再生クライアント５０は、再生時間が長い場合には、再生時刻範囲にあるイベントブロックを一括して読み出すことは行わない。再生開始時刻からΔ時間分のイベントブロックを読み出し、少なくともΔ時間分のデータを保持するマージツリーを作る。マージツリーから部分ストリームを再構成し、再生する。次の時刻は、前の再生時刻＋Δ時間とするのではなく、「次の開始時刻」を区間木から決定される。これによって、Δが短い場合でも効率を落とさずに、次の部分ストリームを再構成できる。このように増加的（インクリメンタル）処理ができ、かつ、システムリソースに無駄がない点は新規かつ優位である。
　また、本実施形態のマージツリーを用いることにより、ストレージノード１６からの読み出し中のイベントブロックについては、再生クライアント５０は読み出しが完了するまで読み出しをせず、読み出し完了のイベントブロックを次々と読み出す。このようにマージツリーを用いた読み出し処理は並列処理であり、処理の単位は節点からのデータの読み出しという極めて粒度の細かいものである点で高速性を実現することができる。したがって、ストリームデータの再生は、ストレージノードの並列読み出しにより高速化される。
　なお、本発明は、以上に述べた実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内で種々の構成または実施形態を取ることができる。
　１　　　ストレージシステム
　２　　　データ格納部
　３　　　区間格納部
　４　　　検索部
　５　　　読出部
　１０　　クライアント
　１１　　ストリームストレージシステム
　１２　　負荷分散器
　１３　　ストレージプロキシ
　１４　　内部バッファメモリ領域
　１５　　メタデータサーバ
　１６　　ストレージノード

Claims (11)

  1. 　時系列のデータが分割されたデータを示す分割データを格納するデータ格納部と、
    　前記分割データを識別する識別情報と、前記分割データの開始時刻及び終了時刻を示す区間の情報とを関連付けた情報を格納する区間格納部と、
    　第１の時刻を取得し、前記区間格納部から、該第１の時刻と該第１の時刻を所定時間経過した第２の時刻との間の区間に重複する区間の検索を行い、該検索を行った該区間に対する前記分割データの識別情報を取得する検索部と、
    　前記データ格納部から、取得した前記識別情報に対応する前記分割データを取得し、取得した分割データを時刻順に読み出す読出部と、
    　を備えることを特徴とするストレージシステム。
  2. 　前記検索部は、前記重複する区間に含まれない前記分割データであって前記第２の時刻より遅く、前記終了時刻以前の該分割データのうち、最も早い開始時刻を取得し、取得した該開始時刻を用いて、次の前記検索を行う
    　ことを特徴とする請求項１に記載のストレージシステム。
  3. 　前記読出部は、前記データ格納部からの取得が完了した前記分割データのうち、最も早い前記開始時刻に対応する前記識別情報で特定される前記分割データを読み出す
    　ことを特徴とする請求項１または２に記載のストレージシステム。
  4. 　前記ストレージシステムは、さらに、
    　負荷分散アルゴリズムを用いて、前記時系列のデータを振り分ける振分部
    　を備えることを特徴とする請求項１～３のうちいずれか１項に記載のストレージシステム。
  5. 　ストレージ装置に接続された情報処理装置の制御プログラムにおいて、
    　前記情報処理装置に、
    　第１の時刻を取得させ、
    　時系列のデータが分割されたデータを示す分割データを識別する識別情報と、前記分割データの開始時刻及び終了時刻を示す区間の情報とを関連付けた情報を格納する区間格納部から、該第１の時刻と該第１の時刻を所定時間経過した第２の時刻との間の区間に重複する区間の検索を要求させ、
    　前記要求に応じて、前記ストレージ装置が、前記区間格納部から、該第１の時刻と該第１の時刻を所定時間経過した第２の時刻との間の区間に重複する区間の検索を行った該区間に対する前記分割データの識別情報を取得させ、
    　前記分割データを格納するデータ格納部から、取得した前記識別情報に対応する前記分割データを取得し、取得した分割データを時刻順に読み出させることを特徴とする情報処理装置の制御プログラム。
  6. 　前記検索を行った前記区間に対する前記分割データの識別情報を取得する場合、前記重複する区間に含まれない前記分割データであって前記第２の時刻より遅く、前記終了時刻以前の該分割データのうち、最も早い開始時刻を取得し、取得した該開始時刻を用いて、次の前記検索を行う
    　ことを特徴とする請求項５に記載の検索プログラム。
  7. 　前記取得した分割データを時刻順に読み出す場合、前記データ格納部からの取得が完了した前記分割データのうち、最も早い前記開始時刻に対応する前記識別情報で特定される前記分割データを読み出す
    　ことを特徴とする請求項５または６に記載の検索プログラム。
  8. 　ストレージ装置と、前記ストレージ装置に接続された情報処理装置を有するストレージシステムの制御方法において、
    　前記情報処理装置が、第１の時刻を取得し、
    　前記情報処理装置が、時系列のデータが分割されたデータを示す分割データを識別する識別情報と、前記分割データの開始時刻及び終了時刻を示す区間の情報とを関連付けた情報を格納する区間格納部から、該第１の時刻と該第１の時刻を所定時間経過した第２の時刻との間の区間に重複する区間の検索を要求し、
    　前記要求に応じて、前記ストレージ装置が、前記区間格納部から、該第１の時刻と該第１の時刻を所定時間経過した第２の時刻との間の区間に重複する区間の検索を行った該区間に対する前記分割データの識別情報を応答し、
    　前記情報処理装置が、前記分割データを格納するデータ格納部から、取得した前記識別情報に対応する前記分割データを取得し、取得した分割データを時刻順に読み出すことを特徴とするストレージシステムの制御方法。
  9. 　前記ストレージ装置は、前記検索を行った前記区間に対する前記分割データの識別情報を取得する場合、前記重複する区間に含まれない前記分割データであって前記第２の時刻より遅く、前記終了時刻以前の該分割データのうち、最も早い開始時刻を取得し、取得した該開始時刻を用いて、次の前記検索を行う
    　ことを特徴とする請求項８に記載のストレージシステムの制御方法。
  10. 　前記情報処理装置は、前記取得した分割データを時刻順に読み出す場合、前記データ格納部からの取得が完了した前記分割データのうち、最も早い前記開始時刻に対応する前記識別情報で特定される前記分割データを読み出す
    　ことを特徴とする請求項８または９に記載のストレージシステムの制御方法。
  11. 　前記ストレージシステムの制御方法において、
    　振分部は、負荷分散アルゴリズムを用いて、前記時系列のデータを振り分ける
    　を備えることを特徴とする請求項８～１０のうちいずれか１項に記載のストレージシステムの制御方法。
PCT/JP2014/058417 2013-03-29 2014-03-26 ストレージシステム、情報処理装置の制御プログラム及びストレージシステムの制御方法 WO2014157275A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US14/844,483 US10268398B2 (en) 2013-03-29 2015-09-03 Storage system, recording medium for storing control program and control method for storage system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2013-074802 2013-03-29
JP2013074802A JP6011421B2 (ja) 2013-03-29 2013-03-29 ストレージシステム、情報処理装置の制御プログラム及びストレージシステムの制御方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/844,483 Continuation US10268398B2 (en) 2013-03-29 2015-09-03 Storage system, recording medium for storing control program and control method for storage system

Publications (1)

Publication Number Publication Date
WO2014157275A1 true WO2014157275A1 (ja) 2014-10-02

Family

ID=51624241

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2014/058417 WO2014157275A1 (ja) 2013-03-29 2014-03-26 ストレージシステム、情報処理装置の制御プログラム及びストレージシステムの制御方法

Country Status (3)

Country Link
US (1) US10268398B2 (ja)
JP (1) JP6011421B2 (ja)
WO (1) WO2014157275A1 (ja)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9723054B2 (en) 2013-12-30 2017-08-01 Microsoft Technology Licensing, Llc Hierarchical organization for scale-out cluster
US9430508B2 (en) 2013-12-30 2016-08-30 Microsoft Technology Licensing, Llc Disk optimized paging for column oriented databases
US9898398B2 (en) 2013-12-30 2018-02-20 Microsoft Technology Licensing, Llc Re-use of invalidated data in buffers
US9672082B2 (en) * 2015-10-21 2017-06-06 Oracle International Corporation Guaranteeing the event order for multi-stage processing in distributed systems
JP2017182665A (ja) * 2016-03-31 2017-10-05 富士通株式会社 情報処理装置、データ提供システム、データ提供方法、及びデータ提供プログラム
US10216688B2 (en) * 2016-05-27 2019-02-26 Avago Technologies International Sales Pte. Limited Systems and methods for accurate transfer margin communication
JP6691302B2 (ja) 2017-01-20 2020-04-28 富士通株式会社 情報処理装置、情報処理方法および情報処理プログラム
WO2018169430A1 (en) 2017-03-17 2018-09-20 Oracle International Corporation Integrating logic in micro batch based event processing systems
WO2018169429A1 (en) 2017-03-17 2018-09-20 Oracle International Corporation Framework for the deployment of event-based applications
US10402241B1 (en) 2017-04-27 2019-09-03 EMC IP Holding Company LLC Forwarding metadata proxy server for asynchronous metadata operations
US11120908B2 (en) 2018-09-20 2021-09-14 Abiomed, Inc. Data storage and retrieval system for non-contiguous medical device operational data
US11151104B2 (en) 2019-05-16 2021-10-19 Microsoft Technology Licensing, Llc Time systems as data
US11061525B2 (en) 2019-05-16 2021-07-13 Microsoft Technology Licensing, Llc Digital map calendar user interface
US11645628B2 (en) 2019-05-16 2023-05-09 Microsoft Technology Licensing, Llc Translation of time between calendar systems
US11120407B2 (en) * 2019-05-16 2021-09-14 Microsoft Technology Licensing, Llc Real time collaboration in calendar
US11514405B1 (en) 2021-05-14 2022-11-29 Microsoft Technology Licensing, Llc Map calendar graphical user interface with dynamic time mold functionality
US11681424B2 (en) 2021-05-14 2023-06-20 Microsoft Technology Licensing, Llc Map calendar graphical user interface with content-variable view levels
US11928336B2 (en) * 2022-03-03 2024-03-12 Samsung Electronics Co., Ltd. Systems and methods for heterogeneous storage systems
JP2024011011A (ja) 2022-07-13 2024-01-25 富士通株式会社 エントリ作成方法およびエントリ作成プログラム
CN116089437B (zh) * 2022-11-30 2023-10-03 荣耀终端有限公司 一种数据处理方法及服务器

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003134435A (ja) * 2001-10-30 2003-05-09 Matsushita Electric Ind Co Ltd 映像データ送信方法及び映像データ受信方法、並びに映像監視システム
JP2006515450A (ja) * 2002-11-15 2006-05-25 シーメンス　アクチエンゲゼルシヤフト インデクスツリーからビットストリームを形成する方法
JP2007288299A (ja) * 2006-04-13 2007-11-01 Hitachi Ltd 配信システム、情報処理装置、配信方法及びプログラム
JP2010277289A (ja) * 2009-05-28 2010-12-09 Fujitsu Ltd 管理プログラム、管理装置および管理方法

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5222235A (en) * 1990-02-01 1993-06-22 Bmc Software, Inc. Databases system for permitting concurrent indexing and reloading of data by early simulating the reload process to determine final locations of the data
CA2067576C (en) * 1991-07-10 1998-04-14 Jimmie D. Edrington Dynamic load balancing for a multiprocessor pipeline
JP2001148832A (ja) 1999-11-22 2001-05-29 Victor Co Of Japan Ltd 記録再生装置
US7000026B2 (en) * 2000-12-22 2006-02-14 Nortel Networks Limited Multi-channel sharing in a high-capacity network
JP5423553B2 (ja) * 2010-04-09 2014-02-19 株式会社日立製作所 データベース管理方法、計算機、センサネットワークシステム及びデータベース検索プログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003134435A (ja) * 2001-10-30 2003-05-09 Matsushita Electric Ind Co Ltd 映像データ送信方法及び映像データ受信方法、並びに映像監視システム
JP2006515450A (ja) * 2002-11-15 2006-05-25 シーメンス　アクチエンゲゼルシヤフト インデクスツリーからビットストリームを形成する方法
JP2007288299A (ja) * 2006-04-13 2007-11-01 Hitachi Ltd 配信システム、情報処理装置、配信方法及びプログラム
JP2010277289A (ja) * 2009-05-28 2010-12-09 Fujitsu Ltd 管理プログラム、管理装置および管理方法

Also Published As

Publication number Publication date
JP2014199581A (ja) 2014-10-23
JP6011421B2 (ja) 2016-10-19
US10268398B2 (en) 2019-04-23
US20150378619A1 (en) 2015-12-31

Similar Documents

Publication Publication Date Title
JP6011421B2 (ja) ストレージシステム、情報処理装置の制御プログラム及びストレージシステムの制御方法
US10262005B2 (en) Method, server and system for managing content in content delivery network
US9305069B2 (en) Method and system for uploading data into a distributed storage system
CN105324770B (zh) 有效读出副本
US9590915B2 (en) Transmission of Map/Reduce data in a data center
US8341118B2 (en) Method and system for dynamically replicating data within a distributed storage system
CN102004760B (zh) 多媒体文件的存储和播放方法、相关装置及系统
WO2012053156A1 (ja) ストレージサービス提供装置、システム、サービス提供方法、及びサービス提供プログラム
JP2011222006A (ja) ネットワークパケットキャプチャ分散ストレージシステムの方法及び機器
JP2003216345A (ja) 複数のパーティションを利用する可動媒体ライブラリとの通信を仲介する方法
CN108776682B (zh) 基于对象存储的随机读写对象的方法和系统
CN108881942A (zh) 一种基于分布式对象存储的超融合常态录播系统
JP5236129B2 (ja) ストレージサービス提供装置、システム、サービス提供方法、及びサービス提供プログラム
CN111782134A (zh) 数据处理方法、装置、系统和计算机可读存储介质
CN105763604B (zh) 轻量级分布式文件系统及恢复下载文件原名的方法
CN104079600B (zh) 文件存储方法、装置、访问客户端及元数据服务器系统
KR101531564B1 (ko) 네트워크 분산 파일 시스템 기반 iSCSI 스토리지 시스템에서의 부하 분산 방법 및 시스템
CN110457307A (zh) 元数据管理系统、用户集群创建方法、装置、设备和介质
JP2005018100A (ja) ネットワークファイルサーバ、情報処理装置並びにプログラム
US20170262543A1 (en) Method and system for improving sessions and open files enumerations by data structures changes
JP5174255B2 (ja) ストレージサービス提供装置、システム、サービス提供方法、及びサービス提供プログラム
JP6033370B2 (ja) ストレージサービス提供装置、システム、サービス提供方法、及びサービス提供プログラム
Cicalese et al. The design of a distributed key-value store for petascale hot storage in data acquisition systems
CN202025315U (zh) 固定内容的数据资源管理系统
US11586595B1 (en) Space-efficient techniques for generating unique instances of data objects

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14775294

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14775294

Country of ref document: EP

Kind code of ref document: A1