US20150032701A1 - Enforcing temporal uniqueness of index keys utilizing key-valued locking in the presence of pseudo-deleted keys - Google Patents
Enforcing temporal uniqueness of index keys utilizing key-valued locking in the presence of pseudo-deleted keys Download PDFInfo
- Publication number
- US20150032701A1 US20150032701A1 US14/486,064 US201414486064A US2015032701A1 US 20150032701 A1 US20150032701 A1 US 20150032701A1 US 201414486064 A US201414486064 A US 201414486064A US 2015032701 A1 US2015032701 A1 US 2015032701A1
- Authority
- US
- United States
- Prior art keywords
- key
- temporal
- prospective
- keys
- index
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2365—Ensuring data consistency and integrity
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/22—Indexing; Data structures therefor; Storage structures
- G06F16/2228—Indexing structures
-
- G06F17/30371—
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
-
- 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
Definitions
- Embodiments presented in this disclosure generally relate to database indexes and, more particularly, to techniques for identifying conflicts with temporal keys in a database index.
- Databases are computerized information storage and retrieval systems.
- a relational database management system is a computer database management system (“DBMS”) that uses relational techniques for storing and retrieving data.
- An object-oriented programming database is a database that is congruent with the data defined in object classes and subclasses.
- a requesting entity e.g., an application or the operating system
- requests may include, for instance, simple catalog lookup requests or transactions and combinations of transactions that operate to read, change and add specified records in the database.
- These requests i.e., queries
- SQL Structured Query Language
- the DBMS may execute the request against a corresponding database, and return any result of the execution to the requesting entity.
- a query usually specifies conditions that apply to one or more columns of the database and may specify logical operations to be performed that involve multiple columns.
- the DBMS In processing such a query, the DBMS generally searches the database for records that satisfy the conditions specified by the query and returns those records as query results for the query.
- One way to improve the performance of a query is to use a database index.
- a database index is generally a data structure that allows data in the database (e.g., in a table) to be located and accessed more efficiently.
- a query optimizer within the DBMS may evaluate a query and determine that building an index for a table will help the query run faster. The query optimizer could then generate the index, which could be used in both the processing of the current query and in processing subsequent queries against the table as well.
- Embodiments of the present invention provide a method, computer program product and system for identifying conflicts between a prospective temporal key and an index of temporal keys, where the temporal keys in the index are sorted based at least in part on a time value associated with each of the temporal keys.
- the method, computer program product and system also include determining whether a first range of time specified by a first temporal key overlaps with a prospective range of time specified by the prospective temporal key. Additionally, the method, computer program product and system include determining whether the first temporal key is a pseudo-deleted key.
- the method, computer program product and system further include determining whether the prospective temporal key conflicts with any temporal keys in the index of temporal keys, based at least in part on the determination of whether the first range of time overlaps with the prospective range of time and whether the first temporal key is a pseudo-deleted key.
- Another embodiment provides a method for identifying conflicts between a prospective temporal key and an index of temporal keys, where the temporal keys in the index are sorted based at least in part on a time value associated with each of the temporal keys.
- the method includes scanning the index of temporal keys to identify a next temporal key that potentially conflicts with the prospective temporal key.
- the method also includes determining whether the prospective temporal key conflicts with the next key, based at least in part on a determination of whether the prospective temporal key conflicts with the next temporal key and whether the next temporal key is a pseudo-deleted key.
- the method includes continuing the scanning and determining steps until (i) a first temporal key with a different principal key value from the prospective temporal key is found, (ii) a non-overlapping temporal key that is not pseudo-deleted is found, the non-overlapping temporal key having an ending time after a starting time of the prospective temporal key, or (iii) no potentially conflicting keys remain in the index.
- FIG. 1 is a block diagram illustrating a system configured to run a temporal key indexing component, according to one embodiment presented in this disclosure.
- FIGS. 2A-2D depict an index containing temporal keys, according to embodiments presented in this disclosure.
- FIGS. 3A-3B depict page files for an index containing temporal keys, according to embodiments presented in this disclosure.
- FIG. 4 is a flow diagram illustrating a method of inserting a temporal key into an index, according to one embodiment presented in this disclosure.
- FIG. 5 is a flow diagram illustrating a method of inserting a temporal key into an index, according to one embodiment presented in this disclosure.
- FIG. 6 is a block diagram illustrating a system configured to run a temporal key indexing component, according to one embodiment presented in this disclosure.
- a temporal key is a key specifying a principal key value and a period of time (e.g., by specifying when the period of time begins and when it ends).
- an index for a conference room booking system could include temporal keys that include a principal key value specifying which conference room is being reserved and a time range specifying the period of time in which the conference room is reserved.
- an index for a scheduling system for a doctor's office could include temporal keys specifying a doctor with which the appointment is being scheduled (i.e., the principal key) and the period of time that the appointment with the specified doctor is scheduled for.
- the temporal keys should be unique such that no two temporal keys for a particular principal key specify an overlapping window of time. For instance, consider an index containing temporal keys relating to appointments at a doctor's office. In such an index, no doctor should have more than one appointment scheduled for any particular period of time. For example, assume the index contains a temporal key specifying an appointment for Dr. Smith (i.e., the principal key) at 9:00 am-10:00 am on Jan. 1, 2011. If a user attempts to insert a new temporal key specifying an appointment for Dr. Smith from 9:30 am-10:30 am on Jan. 1, 2011 into the index, this new key would create a conflict because the two keys overlap from 9:30 am until 10:00 am.
- Dr. Smith i.e., the principal key
- a uniqueness conflict would be created because the period of time from 9:30 am to 10:00 am would not be unique within the index with respect to the principal key (i.e., Dr. Smith), which violates the fundamental design requirement of the unique index that every key in the index be unique.
- the new key should not be inserted into the index, so as to ensure uniqueness between the keys in the index and thereby helping to ensure proper functionality of the index.
- embodiments of the present invention provide techniques for identifying conflicts between a prospective temporal key and an index of temporal keys.
- the temporal keys may be sorted based on a time value associated with each of the temporal keys. For instance, the temporal keys could be sorted based on the ending time of a time range specified by each of the keys.
- Embodiments may then scan the sorted index to identify a first temporal key within the index of temporal keys that potentially conflicts with the prospective temporal key. Once the first temporal key is identified, embodiments determine whether the first temporal key conflicts with the prospective temporal key.
- a conflict may be identified by comparing a first time value (e.g., a beginning time value) associated with the first temporal key and a prospective time value (e.g., an ending time value) associated with the prospective key. For example, a conflict could exist where an existing key in the index specifies a beginning time value that is after the beginning time value of the prospective key but is before the ending time of the prospective key.
- a conflict could exist where an existing key in the index specifies a beginning time value that is after the beginning time value of the prospective key but is before the ending time of the prospective key.
- the index may contain at least one pseudo-deleted temporal key.
- a pseudo-deleted key is a key for which a deletion operation has been performed for the corresponding entry (e.g., a row) in the database, but for which the deletion operation may not have yet been committed. As such, until the deletion operation is confirmed to have been committed, the key may be designated as pseudo-deleted.
- embodiments may further determine whether the aforementioned first temporal key is a pseudo-deleted key.
- embodiments may then confirm whether the deletion operation for the corresponding database entry for the first temporal key has been committed. Upon determining that the deletion operation was committed, embodiments may continue scanning the index to identify a second temporal key that potentially conflicts with the prospective temporal key. That is, since the first temporal key was found to be deleted from the index, embodiments may continue scanning the index to identify other potential conflicts. If instead embodiments determine that the deletion operation was rolled back, embodiments may designate the prospective temporal key as conflicting with at least one existing key in the index. That is, since the deletion operation was rolled back and since the first temporal key was found to conflict with the prospective temporal key, embodiments may determine that an actual conflict exists between the prospective temporal key and the first temporal key in the index.
- FIG. 1 is a block diagram illustrating a system configured to run a temporal key indexing component, according to one embodiment presented in this disclosure.
- the system 100 includes a client system 110 and a database system 130 , communicatively connected via a network 120 .
- the client system includes a database client 115 .
- the database client 115 represents any software application capable of submitting a database query to a DBMS 135 .
- the database client 115 could be a software application configured to allow users to generate and submit database queries.
- the database client 115 could be a software application configured to submit one or more predefined database queries to the DBMS 135 .
- the DBMS 135 contains a database 140 , database index 145 and a temporal key indexing component 150 .
- the database 140 is a data store capable of containing a plurality of records (i.e., data) and is managed by the DBMS 135 .
- the database index 145 is generally a data structure used to ensure rapid lookups and accesses of records in the database 140 .
- the database index 145 contains at least one temporal key.
- a temporal key refers to any key specifying a period of time (e.g., by specifying a beginning time and an ending time).
- the temporal key indexing component 150 generally manages the temporal keys in the database index 145 .
- the temporal key indexing component 150 may insert new temporal keys into the database index 145 . Since, as discussed above, each key in the database index 145 should be unique, the temporal key indexing component 150 generally ensures that the new temporal key does not conflict with any existing temporal keys in the index before inserting the new temporal key.
- the temporal keys in the index could be sorted based on a time value associated with each of the temporal keys.
- the temporal keys could be sorted based on the ending time of a time range specified by each of the keys and then based on the starting time of the time range.
- the temporal key indexing component 150 may then scan the sorted index to identify a first temporal key within the index of temporal keys that potentially conflicts with the prospective temporal key.
- the temporal key indexing component 150 could scan the keys in the index in order and identify the first temporal key having an ending time value that is after the beginning time value of the prospective new key. Once the first temporal key is identified, embodiments determine whether the first temporal key conflicts with the prospective temporal key.
- a conflict may be identified by comparing a first time value associated with the first temporal key and a prospective time value associated with the prospective key. For example, a conflict could exist where an existing key in the index specifies a beginning time value (i.e., the first time value) that is after the beginning time value (i.e., a first prospective time value) of the prospective key but is before the ending time (i.e., a second prospective time value) of the prospective key.
- the temporal key indexing component 150 could designate the prospective temporal key as conflicting with at least one existing temporal key in the index of temporal keys.
- the temporal key indexing component 150 determines that the first temporal key does not conflict with the prospective temporal key, the temporal key indexing component 150 could conclude that the prospective temporal key does not conflict with any keys in the index and accordingly insert the prospective key into the index.
- the index may contain at least one pseudo-deleted temporal key.
- a pseudo-deleted key is a key for which a deletion operation has been performed for the corresponding entry (e.g., a row) in the database. However, such a deletion operation may not have yet been committed, and the database management system may designate the key as pseudo-deleted until the deletion operation is confirmed.
- the temporal key indexing component 150 may confirm whether the deletion operation for the corresponding database entry for the first temporal key has been committed.
- the temporal key indexing component 150 may continue scanning the index to identify a second temporal key that potentially conflicts with the prospective temporal key. That is, since the first temporal key was found to be deleted from the index, temporal key indexing component 150 could continue scanning the index to identify other potential conflicts. If instead the temporal key indexing component 150 determines that the deletion operation was rolled back, the temporal key indexing component 150 could designate the prospective temporal key as conflicting with at least one existing key in the index. That is, since the deletion operation was rolled back and since the first temporal key was found to conflict with the prospective temporal key, the temporal key indexing component 150 could determine that an actual conflict exists between the prospective temporal key and the first temporal key in the index.
- An example of pseudocode that could be used for managing insertions into an index containing pseudo-deleted temporal keys is shown below in Table I.
- FIGS. 2A-2D depict an index containing temporal keys, according to embodiments presented in this disclosure.
- the database relates to a conference room booking system in which each conference room can only be booked once per any moment in time. Thus, for example, two different people would not be allowed to reserve the same conference room during the same period of time.
- the database is configured to use time data values with “CLOSED, OPEN” semantics, meaning that the time period represented includes the MEETING_BEGIN point in time and every other point in time up to, but not including, the MEETING_END time.
- a time value of (1:00 PM, 2:00 PM) includes 1:00 PM and every point in time up to, but not including, 2:00 PM.
- FIG. 2A depicts an index 200 containing a plurality of keys, with each key having a key #data value 202 , a room data value 204 , a meeting end time data value 206 , a meeting begin time data value 208 and a pseudo-delete flag 210 indicating whether the key is a pseudo-deleted key.
- the keys in the index 200 have been sorted in ascending order primarily by the room data value 204 and then secondarily by the meeting end and start time data values 206 and 208 .
- the temporal key indexing component 150 is attempting to insert a key specifying a meeting for room A100 between “2010-01-01-09:00:00” and “2010-01-01-10:00:00.”
- the temporal key indexing component 150 could scan the index in sorted order to identify the first key having a meeting end time 206 after the starting time of the prospective new key.
- FIG. 2B shows that the temporal key indexing component 150 has scanned the index 220 and identified that the key 222 is the first key for the room number A100 224 having an ending time subsequent to the starting time of the prospective key.
- the temporal key indexing component 150 would identify the key 222 having a meeting end time 226 of “2010-01-01-10:01:00” and begin time 228 of “2010-01-01-09:01:00” as the first key having an ending time that is after the starting time of “2010-01-01-09:00:00” of the prospective new key.
- the temporal key indexing component 150 would then determine whether the key 222 is a pseudo-deleted key, which is indicated by the pseudo-deleted flag 230 . Upon determining that the key 222 is indeed a pseudo-deleted key, the temporal key indexing component 150 could then determine whether the key 222 overlaps with the prospective new key. In one embodiment, the temporal key indexing component 150 could determine whether the keys overlap based on whether the following condition is true: (start_time1 ⁇ end_time2) & (start_time2 ⁇ end_time1).
- the values start_time1 and end_time1 refer to the start and end times for the prospective new key to be inserted into the index, while the values start_time2 and end_time2 correspond to the existing key in the index being considered (i.e., the key 222 in the present example).
- the temporal key indexing component 150 would determine that the key 222 does overlap with the prospective new key.
- the temporal key indexing component 150 could then confirm whether the key 222 has actually been deleted. That is, the temporal key indexing component 150 could confirm whether the database management system has committed the deletion operation. Upon determining that the deletion operation for the key 222 was rolled back, the temporal key indexing component 150 could conclude that an actual conflict exists for the prospective new key. However, if the temporal key indexing component 150 instead confirms that the deletion operation for the key 222 was committed, the temporal key indexing component 150 would continue scanning the index to identify the next potentially conflicting key.
- the diagram 240 in FIG. 2C shows that the temporal key indexing component 150 has identified the key 242 as the next key in the index having a room value 244 of “A100” that has an ending time value 246 after the beginning time value of the prospective new key.
- the temporal key indexing component 150 could then determine the key 242 is a pseudo-deleted key, based on the pseudo-deleted flag 250 for the key 242 .
- the temporal key indexing component 150 could determine that the key 242 does not conflict with the prospective new key by comparing the starting time 248 and ending time 246 with the starting and ending times for the prospective new key.
- the temporal key indexing component 150 could continue scanning the index to identify the next potentially conflicting key.
- the diagram 260 shows that the temporal key indexing component 150 has determined that the key 262 is the next key in the index for the room A100 (as indicated by the room value 264 ) with an ending time value 266 after the starting time of the prospective new key.
- the temporal key indexing component 150 could determine that the key 262 is not a pseudo-deleted key, based on the value 270 .
- the temporal key indexing component 150 could then determine whether the key 262 overlaps with the prospective new key, based on the starting time 268 and ending time 266 of the key 262 and the corresponding times for the prospective new key.
- the temporal key indexing component 150 would determine that the prospective new key does not conflict with any keys in the index. Accordingly, the temporal key indexing component 150 could proceed to insert the prospective new key into the index at the appropriate spot (i.e., at a position that maintains the sorted order of the index).
- a database index may span across multiple page files.
- the temporal key indexing component 150 scans the index serially in sorted order, potential problems could arise if another entity (e.g., a separate thread or process) modified values in the index at a position that the temporal key indexing component 150 has already scanned past.
- the temporal key indexing component 150 may be configured to lock particular values in the index while scanning to prevent any serialization problems from arising. For instance, if the temporal key indexing component 150 scans keys on a first page file and then detects that keys on a second page file should also be analyzed, the temporal key indexing component 150 could be configured to obtain a key value lock on all keys related to the prospective new key in both page files.
- the temporal key indexing component 150 could acquire a key value lock only for the room number associated with the prospective key (i.e., room number “A100”).
- FIGS. 3A-3B depict page files for an index containing temporal keys, according to embodiments presented in this disclosure.
- the temporal key indexing component 150 is attempting to insert the aforementioned prospective key specifying a meeting for room A100 between “2010-01-01-09:00:00” and “2010-01-01-10:00:00.”
- the temporal key indexing component 150 could begin scanning the first page file 300 of the index as shown in FIG. 3A .
- the temporal key indexing component 150 could scan the index to identify the first key having an ending time value that is subsequent to the starting time value of the prospective new key.
- the temporal key indexing component 150 could consider the key in page file 300 and determine that the key has the room value 302 of A100 and that the ending time 304 of “2010-01-01-09:30:00” falls after the starting time of the prospective key (i.e., “2010-01-01-09:00:00.” However, the temporal key indexing component 150 could further determine that the depicted key is a pseudo-deleted key. The temporal key indexing component 150 could then confirm that the deletion operation associated with the depicted key was deleted and thus could continue scanning the index.
- the temporal key indexing component 150 could determine that a second page file for the index should be scanned. For instance, the temporal key indexing component 150 could determine that the page file 320 shown in FIG. 3B should also be scanned to identify any keys that conflict with the prospective new key. In order to avoid any serialization problems (e.g., another thread inserting a new conflicting key into the page file 300 ), the temporal key indexing component 150 could place a key value lock on all the keys in the first page file 300 and the second page file 320 related to the prospective new key.
- the temporal key indexing component 150 could place a key value lock all the value part of the keys in the page files 300 and 320 relating to the value part of the prospective new key (i.e., room number “A100”). Upon acquiring the key value lock on the values within the related keys, the temporal key indexing component 150 could continue scanning the page file 320 to determine whether any of the keys 330 conflict with the prospective new key.
- FIG. 4 is a flow diagram illustrating a method of inserting a temporal key into an index, according to one embodiment presented in this disclosure.
- the method 400 begins at step 410 , where the temporal key indexing component 150 receives a temporal key to insert into an index of temporal keys (step 410 ).
- the keys within the index are sorted based on time values associated with each of the keys. For purposes of this example, assume that the keys in the index are sorted in ascending order by their ending times.
- the temporal key indexing component 150 then scans the index to identify a first key that potentially conflicts with the received temporal key (step 415 ).
- the temporal key indexing component 150 may be able to determine whether any keys in the index conflict with the prospective temporal key based on the first potentially conflicting key identified when scanning the index. In other words, because of the manner in which the index is sorted, in some situations, the temporal key indexing component 150 may be able to conclude that if the prospective temporal key does not conflict with the first temporal key, then the prospective temporal key does not conflict with any of the keys in the index.
- the temporal key indexing component 150 determines whether the first key is a pseudo-deleted key (step 420 ).
- a key in an index may be a pseudo-deleted key if the database entry corresponding to the key has been marked deleted, but that deletion operation has not yet been confirmed. That is, certain database management systems may mark a key as pseudo-deleted until the committal (or rollback) of the deletion operation has been confirmed. If the temporal key indexing component 150 determines the first potentially conflicting key is a pseudo-deleted key, the temporal key indexing component 150 then determines whether the first key conflicts with the prospective key (step 430 ).
- the temporal key indexing component 150 determines that no conflict exists between first temporal key and the prospective temporal key, the temporal key indexing component 150 continues scanning the index and processes the next potentially conflict key (step 455 ) and the method 400 returns to step 420 .
- the temporal key indexing component 150 determines that the first key conflicts with the prospective key, the temporal key indexing component 150 then confirms whether the deletion operation has been committed (step 445 ). That is, the temporal key indexing component 150 determines whether the deletion operation has been finalized, based on whether the deletion operation was committed or rolled back.
- the temporal key indexing component 150 determines whether the next potentially conflict key is a pseudo-deleted key. If instead the temporal key indexing component 150 determines that the deletion operation was rolled back and not finalized, the temporal key indexing component 150 generates a key conflict error (step 440 ) and the method 400 ends. That is, upon determining that the first temporal key actually conflicts with the prospective temporal key and that the first temporal key has not been deleted, the temporal key indexing component 150 determines that a conflict actually exists and generates the key conflict error.
- the temporal key indexing component 150 determines whether the first temporal key conflicts with the prospective temporal key (step 425 ). Upon determining that the first temporal key does conflict with the prospective key, the temporal key indexing component 150 generates a key conflict error (step 440 ) and the method 400 ends. If instead the temporal key indexing component 150 determines that there is no conflict between the first temporal key and the prospective temporal key, the temporal key indexing component 150 inserts the prospective temporal key into the index (step 435 ) and the method 400 ends.
- the temporal key indexing component 150 may determine that the prospective temporal key does not conflict with any keys in the index if the prospective key does not conflict with the first potentially conflicting key in the index. For example, the index could be sorted at least in part in ascending order based on the ending time values of the temporal keys. In such an example, the temporal key indexing component 150 could scan the sorted index to identify the first key having an ending time that is after the starting time of the prospective temporal key.
- the temporal key indexing component 150 determines that this first key does not conflict with the prospective temporal key and further determines that this first key has not been deleted (or that any such deletion operation has been rolled back), then the temporal key indexing component 150 could conclude that no key in the index conflicts with the prospective temporal key.
- the temporal key indexing component 150 could conclude that no key in the index conflicts with the prospective temporal key.
- doing so allows the temporal key indexing component 150 to avoid comparing all the keys in the index with the prospective temporal key.
- FIG. 5 is a flow diagram illustrating a method of inserting a temporal key into an index, according to one embodiment presented in this disclosure.
- the method 500 begins at step 510 , where the temporal key indexing component 150 determines that a conflicting pseudo-deleted key exists in the first page file for an index. Thus, the temporal key indexing component 150 could determine that more keys in the index should be processed before concluding that no conflict exists for the prospective temporal key (e.g., as in step 455 of the method 400 ).
- the temporal key indexing component 150 then identifies a second page file for the index that contains one or more potentially conflicting keys for the prospective temporal key (step 515 ).
- the temporal key indexing component 150 Upon identifying the second page file for the index, the temporal key indexing component 150 places a key value lock on the principal key value for the prospective new key (step 520 ).
- certain indexes may contain temporal keys relating to more than one principal key value.
- a particular index could contain temporal keys relating to scheduling appointments for multiple doctors, where each doctor is represented using a different principal key value.
- the primary value could be the name of the doctor that each appointment is scheduled with and the index could enforce uniqueness amongst the temporal keys for a particular doctor. That is, while two 9:00 am-10:00 am appointments could be scheduled for two different doctors, overlapping appointments should generally not be allowed to exist for the same doctor.
- the temporal key indexing component 150 obtains a key value lock only on the unique key value of the prospective temporal key.
- the key value lock prevents any insertions or modifications of temporal keys having the locked principal value.
- the temporal key indexing component 150 could obtain a key value lock on the principal key value of “Dr. Smith”, thereby preventing any insertions or deletions of temporal keys within the index relating to the principal key value of “Dr. Smith”.
- a key value lock may prevent key modifications or insertions across a single page file of the index, or may prevent such modifications or insertions across a plurality of page files of the index.
- the temporal key indexing component 150 determines if the second page file contains any keys that conflict with the prospective temporal key (step 525 ). If the temporal key indexing component 150 determines the second page file contains a conflicting key, the temporal key indexing component 150 generates a key conflict error (step 540 ). If instead the temporal key indexing component 150 determines that the second page file does not contain any conflicting keys, the temporal key indexing component 150 inserted the received prospective key into the index (step 535 ). Once the prospective key is inserted into the index or once the key conflict error is generated, the temporal key indexing component 150 unlocks the key value lock on the principal key value of the prospective key (step 545 ) and the method 500 ends.
- the method 500 prevents a situation where another entity (e.g., another process or thread) alters the keys at a location in the index the temporal key indexing component 150 has already scanned.
- another entity e.g., another process or thread
- FIG. 5 deals with an index containing only two page files
- the temporal key indexing component 150 considered only the second page file
- the temporal key indexing component 150 could continue scanning any number of subsequent page files to identify any conflicting keys in the index.
- the temporal key indexing component 150 is configured to continue scanning until (i) the temporal key indexing component 150 finds a key with a different principal key value (e.g., when the temporal key indexing component 150 finds a key relating to “Dr.
- the temporal key indexing component 150 finds a key with the same principal key value but that does not temporally overlap with the prospective key and is not pseudo-deleted, or (iii) there are no more keys in the index.
- FIG. 6 is a block diagram illustrating a system configured to run a temporal key indexing component, according to one embodiment presented in this disclosure.
- the system 600 includes a plurality of client systems 610 and a database system 660 , communicatively coupled via a network 695 .
- the client systems 610 may include existing computer systems, e.g., desktop computers, server computers, laptop computers, tablet computers, mobile devices (e.g., mobile phones), gaming consoles, hand-held gaming devices and the like.
- the client systems 610 illustrated in FIG. 6 are merely examples of computer systems in which embodiments of the present invention may be used.
- Embodiments of the present invention may be implemented differently, regardless of whether the computer systems are complex multi-user computing systems, such as a cluster of individual computers connected by a high-speed network, single-user workstations, or network appliances lacking non-volatile storage. Moreover, it is explicitly contemplated that embodiments of the invention may be implemented using any device or computer system capable of performing the functions described herein.
- each client system 610 includes, without limitation, a processor 615 , which obtains instructions and data via a bus 620 from a memory 630 and storage 625 .
- Processor 615 is a programmable logic device that performs instruction, logic, and mathematical processing, and may be representative of one or more CPUs.
- Storage 625 is representative of hard-disk drives, flash memory devices, optical media and the like. Generally, the storage 625 stores application programs and data for use by the client system 610 .
- the client systems 610 are operably connected to the network 695 , e.g., via network interfaces.
- the memory 630 is any memory sufficiently large to hold the necessary programs and data structures. Memory 630 could be one or a combination of memory devices, including Random Access Memory, nonvolatile or backup memory (e.g., programmable or Flash memories, read-only memories, etc.). In addition, memory 630 and storage 625 may be considered to include memory physically located elsewhere; for example, on another computer coupled to the client system 610 via bus 620 .
- the memory 630 includes a database client 640 and an operating system (“OS”) 635 .
- Operating system 635 is software used for managing the operation of the client system 610 . Examples of OS 635 include UNIX, versions of the Microsoft Windows® operating system and distributions of the Linux® operating system. (Note: Linux is a trademark of Linus Torvalds in the United States and other countries.) More generally, any operating system 635 capable of performing the functions described herein may be used.
- the client systems 610 are each coupled to display devices 645 and input devices 650 .
- the display devices 645 may include output devices such as monitors, touch screen displays, and so on.
- the display devices 645 may include a display device used to visually depict a user interface through which a user may form database queries to submit to the DBMS 690 .
- the input devices 650 represent a wide variety of input devices, including keyboards, mice, controllers, microphones, and so on.
- the database system 660 includes, without limitation, a processor 665 , which obtains instructions and data via a bus 670 from a memory 680 and storage 675 .
- Processor 665 is a programmable logic device that performs instruction, logic, and mathematical processing, and may be representative of one or more CPUs.
- Storage 675 is representative of hard-disk drives, flash memory devices, optical media and the like. Generally, the storage 675 stores application programs and data for use by the database system 660 .
- the database system 660 is operably connected to the network 695 , e.g., via a network interface.
- the memory 680 is any memory sufficiently large to hold the necessary programs and data structures.
- Memory 680 could be one or a combination of memory devices, including Random Access Memory, nonvolatile or backup memory (e.g., programmable or Flash memories, read-only memories, etc.).
- memory 680 and storage 675 may be considered to include memory physically located elsewhere; for example, on another computer coupled to the database system 660 via bus 670 .
- the memory 680 includes a DBMS 690 and an OS 685 .
- Operating system 685 is software used for managing the operation of the database system 660 . Examples of OS 685 include UNIX, versions of the Microsoft Windows® operating system and distributions of the Linux® operating system. More generally, any operating system 685 capable of performing the functions described herein may be used.
- the DBMS 690 contains a database 692 , a database index 694 and a temporal key indexing component 150 .
- the database index 694 is generally a data structure used to ensure rapid lookups and efficient access of records in the database 692 .
- the database 692 is shown as contained entirely in memory 680 , such a depiction is for illustrative purposes only.
- the database 692 could be contained not only in memory 680 but in a variety of locations, including, for example, storage 675 , another storage device altogether (e.g., a remote storage device via bus 670 ), or a mix thereof.
- the temporal key indexing component 150 generally manages the database index 694 that contains temporal keys. For instance, the temporal key indexing component 150 could add an entry (i.e., a key) to the database index 694 that contains timestamp and time zone data. In doing so, the temporal key indexing component 150 could ensure that there is not an overlapping temporal key in the database index 694 before inserting the new entry into the index 694 . For instance, the temporal key indexing component 150 could scan the index to identify a first potentially conflicting key. The temporal key indexing component 150 could then compare the prospective new key with the first potentially conflicting key to determine whether a conflict exists between the two. Upon determining no conflict exists, the temporal key indexing component 150 could insert the new entry into the index. Advantageously, doing so ensures that the database index 694 will not contain any overlapping temporal keys.
- aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
- the computer readable medium may be a computer readable signal medium or a computer readable storage medium.
- a computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.
- a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
- a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof.
- a computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
- Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
- Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages.
- the program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server.
- the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
- LAN local area network
- WAN wide area network
- Internet Service Provider for example, AT&T, MCI, Sprint, EarthLink, MSN, GTE, etc.
- These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
- the computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
- Embodiments of the invention may be provided to end users through a cloud computing infrastructure.
- Cloud computing generally refers to the provision of scalable computing resources as a service over a network.
- Cloud computing may be defined as a computing capability that provides an abstraction between the computing resource and its underlying technical architecture (e.g., servers, storage, networks), enabling convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction.
- cloud computing allows a user to access virtual computing resources (e.g., storage, data, applications, and even complete virtualized computing systems) in “the cloud,” without regard for the underlying physical systems (or locations of those systems) used to provide the computing resources.
- cloud computing resources are provided to a user on a pay-per-use basis, where users are charged only for the computing resources actually used (e.g. an amount of storage space consumed by a user or a number of virtualized systems instantiated by the user).
- a user can access any of the resources that reside in the cloud at any time, and from anywhere across the Internet.
- a user could submit a database query (e.g., using the database client 640 ) specifying a new temporal key to be inserted into an index for a database or other data store available in the cloud.
- a DBMS configured with a temporal key indexing component 150 could execute on a computing system in the cloud and maintain a database index containing temporal keys.
- the temporal key indexing component 150 Upon receiving the database query specifying the prospective new temporal key, the temporal key indexing component 150 could determine if a conflict exists between the new temporal key and the temporal keys within the index and, if not, could insert the new temporal key into the index. Doing so allows users to submit queries relating to temporal keys from any computing system attached to a network connected to the cloud (e.g., the Internet).
- a network connected to the cloud e.g., the Internet
- each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s).
- the functions noted in the block may occur out of the order noted in the figures.
- two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.
- Each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations can be implemented by special-purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- General Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Software Systems (AREA)
- Mathematical Physics (AREA)
- Computational Linguistics (AREA)
- Probability & Statistics with Applications (AREA)
- Fuzzy Systems (AREA)
- Computer Security & Cryptography (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Description
- This application is a continuation of co-pending U.S. patent application Ser. No. 13/249,973, filed Sep. 30, 2011. The aforementioned related patent application is herein incorporated by reference in its entirety.
- Embodiments presented in this disclosure generally relate to database indexes and, more particularly, to techniques for identifying conflicts with temporal keys in a database index.
- Databases are computerized information storage and retrieval systems. A relational database management system is a computer database management system (“DBMS”) that uses relational techniques for storing and retrieving data. An object-oriented programming database is a database that is congruent with the data defined in object classes and subclasses. Regardless of the particular architecture, a requesting entity (e.g., an application or the operating system) in a DBMS requests access to a specified database by issuing a database access request. Such requests may include, for instance, simple catalog lookup requests or transactions and combinations of transactions that operate to read, change and add specified records in the database. These requests (i.e., queries) are often made using high-level query languages such as the Structured Query Language (“SQL”). Upon receiving such a request, the DBMS may execute the request against a corresponding database, and return any result of the execution to the requesting entity.
- Information is typically retrieved from a database using database queries. A query usually specifies conditions that apply to one or more columns of the database and may specify logical operations to be performed that involve multiple columns. In processing such a query, the DBMS generally searches the database for records that satisfy the conditions specified by the query and returns those records as query results for the query. One way to improve the performance of a query is to use a database index. A database index is generally a data structure that allows data in the database (e.g., in a table) to be located and accessed more efficiently. A query optimizer within the DBMS may evaluate a query and determine that building an index for a table will help the query run faster. The query optimizer could then generate the index, which could be used in both the processing of the current query and in processing subsequent queries against the table as well.
- Embodiments of the present invention provide a method, computer program product and system for identifying conflicts between a prospective temporal key and an index of temporal keys, where the temporal keys in the index are sorted based at least in part on a time value associated with each of the temporal keys. The method, computer program product and system also include determining whether a first range of time specified by a first temporal key overlaps with a prospective range of time specified by the prospective temporal key. Additionally, the method, computer program product and system include determining whether the first temporal key is a pseudo-deleted key. The method, computer program product and system further include determining whether the prospective temporal key conflicts with any temporal keys in the index of temporal keys, based at least in part on the determination of whether the first range of time overlaps with the prospective range of time and whether the first temporal key is a pseudo-deleted key.
- Another embodiment provides a method for identifying conflicts between a prospective temporal key and an index of temporal keys, where the temporal keys in the index are sorted based at least in part on a time value associated with each of the temporal keys. The method includes scanning the index of temporal keys to identify a next temporal key that potentially conflicts with the prospective temporal key. The method also includes determining whether the prospective temporal key conflicts with the next key, based at least in part on a determination of whether the prospective temporal key conflicts with the next temporal key and whether the next temporal key is a pseudo-deleted key. Additionally, the method includes continuing the scanning and determining steps until (i) a first temporal key with a different principal key value from the prospective temporal key is found, (ii) a non-overlapping temporal key that is not pseudo-deleted is found, the non-overlapping temporal key having an ending time after a starting time of the prospective temporal key, or (iii) no potentially conflicting keys remain in the index.
- So that the manner in which the above recited aspects are attained and can be understood in detail, a more particular description of embodiments of the invention, briefly summarized above, may be had by reference to the appended drawings.
- It is to be noted, however, that the appended drawings illustrate only typical embodiments of this invention and are therefore not to be considered limiting of its scope, for the invention may admit to other equally effective embodiments.
-
FIG. 1 is a block diagram illustrating a system configured to run a temporal key indexing component, according to one embodiment presented in this disclosure. -
FIGS. 2A-2D depict an index containing temporal keys, according to embodiments presented in this disclosure. -
FIGS. 3A-3B depict page files for an index containing temporal keys, according to embodiments presented in this disclosure. -
FIG. 4 is a flow diagram illustrating a method of inserting a temporal key into an index, according to one embodiment presented in this disclosure. -
FIG. 5 is a flow diagram illustrating a method of inserting a temporal key into an index, according to one embodiment presented in this disclosure. -
FIG. 6 is a block diagram illustrating a system configured to run a temporal key indexing component, according to one embodiment presented in this disclosure. - Generally, unique database indexes are designed such that each key in a database index is unique, so as to ensure the database index functions properly and to facilitate efficient lookups and accesses using the database index. Additionally, some database indexes contain temporal keys. Generally, a temporal key is a key specifying a principal key value and a period of time (e.g., by specifying when the period of time begins and when it ends). For example, an index for a conference room booking system could include temporal keys that include a principal key value specifying which conference room is being reserved and a time range specifying the period of time in which the conference room is reserved. As another example, an index for a scheduling system for a doctor's office could include temporal keys specifying a doctor with which the appointment is being scheduled (i.e., the principal key) and the period of time that the appointment with the specified doctor is scheduled for.
- In the context of a unique database index containing temporal keys, the temporal keys should be unique such that no two temporal keys for a particular principal key specify an overlapping window of time. For instance, consider an index containing temporal keys relating to appointments at a doctor's office. In such an index, no doctor should have more than one appointment scheduled for any particular period of time. For example, assume the index contains a temporal key specifying an appointment for Dr. Smith (i.e., the principal key) at 9:00 am-10:00 am on Jan. 1, 2011. If a user attempts to insert a new temporal key specifying an appointment for Dr. Smith from 9:30 am-10:30 am on Jan. 1, 2011 into the index, this new key would create a conflict because the two keys overlap from 9:30 am until 10:00 am. In other words, a uniqueness conflict would be created because the period of time from 9:30 am to 10:00 am would not be unique within the index with respect to the principal key (i.e., Dr. Smith), which violates the fundamental design requirement of the unique index that every key in the index be unique. Thus, in this example, the new key should not be inserted into the index, so as to ensure uniqueness between the keys in the index and thereby helping to ensure proper functionality of the index.
- As such, embodiments of the present invention provide techniques for identifying conflicts between a prospective temporal key and an index of temporal keys. In such an index, the temporal keys may be sorted based on a time value associated with each of the temporal keys. For instance, the temporal keys could be sorted based on the ending time of a time range specified by each of the keys. Embodiments may then scan the sorted index to identify a first temporal key within the index of temporal keys that potentially conflicts with the prospective temporal key. Once the first temporal key is identified, embodiments determine whether the first temporal key conflicts with the prospective temporal key. A conflict may be identified by comparing a first time value (e.g., a beginning time value) associated with the first temporal key and a prospective time value (e.g., an ending time value) associated with the prospective key. For example, a conflict could exist where an existing key in the index specifies a beginning time value that is after the beginning time value of the prospective key but is before the ending time of the prospective key. Upon determining that the first temporal key conflicts with the prospective temporal key, embodiments designate the prospective temporal key as conflicting with at least one existing temporal key in the index of temporal keys.
- In a particular embodiment, the index may contain at least one pseudo-deleted temporal key. Generally, a pseudo-deleted key is a key for which a deletion operation has been performed for the corresponding entry (e.g., a row) in the database, but for which the deletion operation may not have yet been committed. As such, until the deletion operation is confirmed to have been committed, the key may be designated as pseudo-deleted. In such an index containing at least one pseudo-deleted temporal key, embodiments may further determine whether the aforementioned first temporal key is a pseudo-deleted key. If embodiments determine that the first temporal key conflicts with the prospective temporal key and that the first temporal key is further a pseudo-deleted key, embodiments may then confirm whether the deletion operation for the corresponding database entry for the first temporal key has been committed. Upon determining that the deletion operation was committed, embodiments may continue scanning the index to identify a second temporal key that potentially conflicts with the prospective temporal key. That is, since the first temporal key was found to be deleted from the index, embodiments may continue scanning the index to identify other potential conflicts. If instead embodiments determine that the deletion operation was rolled back, embodiments may designate the prospective temporal key as conflicting with at least one existing key in the index. That is, since the deletion operation was rolled back and since the first temporal key was found to conflict with the prospective temporal key, embodiments may determine that an actual conflict exists between the prospective temporal key and the first temporal key in the index.
-
FIG. 1 is a block diagram illustrating a system configured to run a temporal key indexing component, according to one embodiment presented in this disclosure. As shown, thesystem 100 includes aclient system 110 and adatabase system 130, communicatively connected via anetwork 120. The client system includes adatabase client 115. Generally, thedatabase client 115 represents any software application capable of submitting a database query to aDBMS 135. For instance, thedatabase client 115 could be a software application configured to allow users to generate and submit database queries. As another example, thedatabase client 115 could be a software application configured to submit one or more predefined database queries to theDBMS 135. - The
DBMS 135 contains adatabase 140,database index 145 and a temporalkey indexing component 150. Thedatabase 140 is a data store capable of containing a plurality of records (i.e., data) and is managed by theDBMS 135. Thedatabase index 145 is generally a data structure used to ensure rapid lookups and accesses of records in thedatabase 140. For purposes of this example, assume that thedatabase index 145 contains at least one temporal key. As discussed above, a temporal key refers to any key specifying a period of time (e.g., by specifying a beginning time and an ending time). The temporalkey indexing component 150 generally manages the temporal keys in thedatabase index 145. For instance, the temporalkey indexing component 150 may insert new temporal keys into thedatabase index 145. Since, as discussed above, each key in thedatabase index 145 should be unique, the temporalkey indexing component 150 generally ensures that the new temporal key does not conflict with any existing temporal keys in the index before inserting the new temporal key. - For instance, the temporal keys in the index could be sorted based on a time value associated with each of the temporal keys. As an example, the temporal keys could be sorted based on the ending time of a time range specified by each of the keys and then based on the starting time of the time range. The temporal
key indexing component 150 may then scan the sorted index to identify a first temporal key within the index of temporal keys that potentially conflicts with the prospective temporal key. For instance, the temporalkey indexing component 150 could scan the keys in the index in order and identify the first temporal key having an ending time value that is after the beginning time value of the prospective new key. Once the first temporal key is identified, embodiments determine whether the first temporal key conflicts with the prospective temporal key. A conflict may be identified by comparing a first time value associated with the first temporal key and a prospective time value associated with the prospective key. For example, a conflict could exist where an existing key in the index specifies a beginning time value (i.e., the first time value) that is after the beginning time value (i.e., a first prospective time value) of the prospective key but is before the ending time (i.e., a second prospective time value) of the prospective key. Upon determining that the first temporal key conflicts with the prospective temporal key, the temporalkey indexing component 150 could designate the prospective temporal key as conflicting with at least one existing temporal key in the index of temporal keys. On the other hand, if the temporalkey indexing component 150 determines that the first temporal key does not conflict with the prospective temporal key, the temporalkey indexing component 150 could conclude that the prospective temporal key does not conflict with any keys in the index and accordingly insert the prospective key into the index. - In a particular embodiment, the index may contain at least one pseudo-deleted temporal key. As discussed above, a pseudo-deleted key is a key for which a deletion operation has been performed for the corresponding entry (e.g., a row) in the database. However, such a deletion operation may not have yet been committed, and the database management system may designate the key as pseudo-deleted until the deletion operation is confirmed. When considering such a pseudo-deleted key that conflicts with the prospective temporal key, the temporal
key indexing component 150 may confirm whether the deletion operation for the corresponding database entry for the first temporal key has been committed. Upon determining that the deletion operation was committed, the temporalkey indexing component 150 may continue scanning the index to identify a second temporal key that potentially conflicts with the prospective temporal key. That is, since the first temporal key was found to be deleted from the index, temporalkey indexing component 150 could continue scanning the index to identify other potential conflicts. If instead the temporalkey indexing component 150 determines that the deletion operation was rolled back, the temporalkey indexing component 150 could designate the prospective temporal key as conflicting with at least one existing key in the index. That is, since the deletion operation was rolled back and since the first temporal key was found to conflict with the prospective temporal key, the temporalkey indexing component 150 could determine that an actual conflict exists between the prospective temporal key and the first temporal key in the index. An example of pseudocode that could be used for managing insertions into an index containing pseudo-deleted temporal keys is shown below in Table I. -
TABLE I Exemplary Pseudocode Loop: IF the found key is for a different key value OR there are no more keys in the index THEN Goto NoDuplicateFound IF the found key is pseudo deleted THEN IF the found key Overlaps the key to be inserted THEN Lock to ensure deleted entry is committed/wait for deletion to commit IF key is still deleted THEN Move to next index entry Goto Loop ELSE (Key no longer deleted, deletion must have rolled back) Goto DuplicateFound IF the found key does not overlap the key to be inserted THEN Move to next index entry Goto Loop ELSE (found key is not a pseudo delete) IF the found key Overlaps the key to be inserted THEN Lock to ensure entry is committed/wait for insertion to commit IF key is still present and not a pseudo delete THEN Goto DuplicateFound ELSE Move to next index entry Goto Loop ELSE (non-pseudo-delete and it doesn't overlap) Goto NoDuplicateFOund DuplicateFound: Code to handle duplicate Here NoDuplicateFound: Code to handle ‘No Duplicate’ Here - An example using such pseudocode is discussed below with respect to
FIGS. 2A-2D , which depict an index containing temporal keys, according to embodiments presented in this disclosure. For purposes of this example, assume that the database relates to a conference room booking system in which each conference room can only be booked once per any moment in time. Thus, for example, two different people would not be allowed to reserve the same conference room during the same period of time. Additionally, for this example, assume that the database is configured to use time data values with “CLOSED, OPEN” semantics, meaning that the time period represented includes the MEETING_BEGIN point in time and every other point in time up to, but not including, the MEETING_END time. Thus, a time value of (1:00 PM, 2:00 PM) includes 1:00 PM and every point in time up to, but not including, 2:00 PM. As shown,FIG. 2A depicts anindex 200 containing a plurality of keys, with each key having a key #data value 202, aroom data value 204, a meeting endtime data value 206, a meeting begintime data value 208 and apseudo-delete flag 210 indicating whether the key is a pseudo-deleted key. In the depicted example, the keys in theindex 200 have been sorted in ascending order primarily by theroom data value 204 and then secondarily by the meeting end and start time data values 206 and 208. - For purposes of this example, assume that the temporal
key indexing component 150 is attempting to insert a key specifying a meeting for room A100 between “2010-01-01-09:00:00” and “2010-01-01-10:00:00.” Upon receiving the prospective key to insert into the index, the temporalkey indexing component 150 could scan the index in sorted order to identify the first key having ameeting end time 206 after the starting time of the prospective new key. Thus, in this example,FIG. 2B shows that the temporalkey indexing component 150 has scanned theindex 220 and identified that the key 222 is the first key for theroom number A100 224 having an ending time subsequent to the starting time of the prospective key. Here, the temporalkey indexing component 150 would identify the key 222 having ameeting end time 226 of “2010-01-01-10:01:00” and begintime 228 of “2010-01-01-09:01:00” as the first key having an ending time that is after the starting time of “2010-01-01-09:00:00” of the prospective new key. - The temporal
key indexing component 150 would then determine whether the key 222 is a pseudo-deleted key, which is indicated by thepseudo-deleted flag 230. Upon determining that the key 222 is indeed a pseudo-deleted key, the temporalkey indexing component 150 could then determine whether the key 222 overlaps with the prospective new key. In one embodiment, the temporalkey indexing component 150 could determine whether the keys overlap based on whether the following condition is true: (start_time1<end_time2) & (start_time2<end_time1). In this condition, the values start_time1 and end_time1 refer to the start and end times for the prospective new key to be inserted into the index, while the values start_time2 and end_time2 correspond to the existing key in the index being considered (i.e., the key 222 in the present example). Thus, here the temporalkey indexing component 150 would determine that the key 222 does overlap with the prospective new key. - Upon determining that prospective new key overlaps with the key 222 and having already confirmed that the key 222 is a pseudo-deleted key, the temporal
key indexing component 150 could then confirm whether the key 222 has actually been deleted. That is, the temporalkey indexing component 150 could confirm whether the database management system has committed the deletion operation. Upon determining that the deletion operation for the key 222 was rolled back, the temporalkey indexing component 150 could conclude that an actual conflict exists for the prospective new key. However, if the temporalkey indexing component 150 instead confirms that the deletion operation for the key 222 was committed, the temporalkey indexing component 150 would continue scanning the index to identify the next potentially conflicting key. - Thus, the diagram 240 in
FIG. 2C shows that the temporalkey indexing component 150 has identified the key 242 as the next key in the index having aroom value 244 of “A100” that has an endingtime value 246 after the beginning time value of the prospective new key. The temporalkey indexing component 150 could then determine the key 242 is a pseudo-deleted key, based on thepseudo-deleted flag 250 for the key 242. However, unlike the key 222, the temporalkey indexing component 150 could determine that the key 242 does not conflict with the prospective new key by comparing the startingtime 248 and endingtime 246 with the starting and ending times for the prospective new key. That is, since the ending time of the prospective new key “2010-01-01-10:00:00” is non-inclusive, meaning that the time range expressed by the prospective new key captures every point in time from the beginning time up until the ending time, the prospective new key does not conflict with the key 242 having a starting time of “2010-01-01-10:00:00”. As such, the temporalkey indexing component 150 could continue scanning the index to identify the next potentially conflicting key. - Continuing the example with reference to
FIG. 2D , the diagram 260 shows that the temporalkey indexing component 150 has determined that the key 262 is the next key in the index for the room A100 (as indicated by the room value 264) with an endingtime value 266 after the starting time of the prospective new key. Here, the temporalkey indexing component 150 could determine that the key 262 is not a pseudo-deleted key, based on thevalue 270. The temporalkey indexing component 150 could then determine whether the key 262 overlaps with the prospective new key, based on the startingtime 268 and endingtime 266 of the key 262 and the corresponding times for the prospective new key. Thus, in this example, since the prospective new key specifies a meeting time from 9:00 until 10:00 and the key 262 specifies a meeting between the hours of 12:00 until 13:00, the temporalkey indexing component 150 would determine that the prospective new key does not conflict with any keys in the index. Accordingly, the temporalkey indexing component 150 could proceed to insert the prospective new key into the index at the appropriate spot (i.e., at a position that maintains the sorted order of the index). - In particular embodiments, a database index may span across multiple page files. As the temporal
key indexing component 150 scans the index serially in sorted order, potential problems could arise if another entity (e.g., a separate thread or process) modified values in the index at a position that the temporalkey indexing component 150 has already scanned past. Accordingly, the temporalkey indexing component 150 may be configured to lock particular values in the index while scanning to prevent any serialization problems from arising. For instance, if the temporalkey indexing component 150 scans keys on a first page file and then detects that keys on a second page file should also be analyzed, the temporalkey indexing component 150 could be configured to obtain a key value lock on all keys related to the prospective new key in both page files. Thus, in the current example, rather than locking all the key values in the page files, the temporalkey indexing component 150 could acquire a key value lock only for the room number associated with the prospective key (i.e., room number “A100”). - An example of this will now be discussed with respect to
FIGS. 3A-3B , which depict page files for an index containing temporal keys, according to embodiments presented in this disclosure. For purposes of this example, assume that the temporalkey indexing component 150 is attempting to insert the aforementioned prospective key specifying a meeting for room A100 between “2010-01-01-09:00:00” and “2010-01-01-10:00:00.” In doing so, the temporalkey indexing component 150 could begin scanning thefirst page file 300 of the index as shown inFIG. 3A . For instance, the temporalkey indexing component 150 could scan the index to identify the first key having an ending time value that is subsequent to the starting time value of the prospective new key. Thus, the temporalkey indexing component 150 could consider the key inpage file 300 and determine that the key has theroom value 302 of A100 and that theending time 304 of “2010-01-01-09:30:00” falls after the starting time of the prospective key (i.e., “2010-01-01-09:00:00.” However, the temporalkey indexing component 150 could further determine that the depicted key is a pseudo-deleted key. The temporalkey indexing component 150 could then confirm that the deletion operation associated with the depicted key was deleted and thus could continue scanning the index. - However, since there are no more keys for the room A100 in the
page file 300, the temporalkey indexing component 150 could determine that a second page file for the index should be scanned. For instance, the temporalkey indexing component 150 could determine that thepage file 320 shown inFIG. 3B should also be scanned to identify any keys that conflict with the prospective new key. In order to avoid any serialization problems (e.g., another thread inserting a new conflicting key into the page file 300), the temporalkey indexing component 150 could place a key value lock on all the keys in thefirst page file 300 and thesecond page file 320 related to the prospective new key. Thus, for example, the temporalkey indexing component 150 could place a key value lock all the value part of the keys in the page files 300 and 320 relating to the value part of the prospective new key (i.e., room number “A100”). Upon acquiring the key value lock on the values within the related keys, the temporalkey indexing component 150 could continue scanning thepage file 320 to determine whether any of thekeys 330 conflict with the prospective new key. -
FIG. 4 is a flow diagram illustrating a method of inserting a temporal key into an index, according to one embodiment presented in this disclosure. As shown, themethod 400 begins atstep 410, where the temporalkey indexing component 150 receives a temporal key to insert into an index of temporal keys (step 410). Generally, the keys within the index are sorted based on time values associated with each of the keys. For purposes of this example, assume that the keys in the index are sorted in ascending order by their ending times. The temporalkey indexing component 150 then scans the index to identify a first key that potentially conflicts with the received temporal key (step 415). Of note, because the keys are in a sorted order, the temporalkey indexing component 150 may be able to determine whether any keys in the index conflict with the prospective temporal key based on the first potentially conflicting key identified when scanning the index. In other words, because of the manner in which the index is sorted, in some situations, the temporalkey indexing component 150 may be able to conclude that if the prospective temporal key does not conflict with the first temporal key, then the prospective temporal key does not conflict with any of the keys in the index. - To this end, upon identifying the first potentially conflicting key, the temporal
key indexing component 150 determines whether the first key is a pseudo-deleted key (step 420). As discussed above, a key in an index may be a pseudo-deleted key if the database entry corresponding to the key has been marked deleted, but that deletion operation has not yet been confirmed. That is, certain database management systems may mark a key as pseudo-deleted until the committal (or rollback) of the deletion operation has been confirmed. If the temporalkey indexing component 150 determines the first potentially conflicting key is a pseudo-deleted key, the temporalkey indexing component 150 then determines whether the first key conflicts with the prospective key (step 430). If the temporalkey indexing component 150 determines that no conflict exists between first temporal key and the prospective temporal key, the temporalkey indexing component 150 continues scanning the index and processes the next potentially conflict key (step 455) and themethod 400 returns to step 420. On the other hand, if the temporalkey indexing component 150 determines that the first key conflicts with the prospective key, the temporalkey indexing component 150 then confirms whether the deletion operation has been committed (step 445). That is, the temporalkey indexing component 150 determines whether the deletion operation has been finalized, based on whether the deletion operation was committed or rolled back. - If the temporal
key indexing component 150 determines the deletion was finalized, then the temporalkey indexing component 150 continues scanning the index and processes the next potentially conflicting key (step 455) and themethod 400 returns to step 420, where the temporalkey indexing component 150 determines whether the next potentially conflict key is a pseudo-deleted key. If instead the temporalkey indexing component 150 determines that the deletion operation was rolled back and not finalized, the temporalkey indexing component 150 generates a key conflict error (step 440) and themethod 400 ends. That is, upon determining that the first temporal key actually conflicts with the prospective temporal key and that the first temporal key has not been deleted, the temporalkey indexing component 150 determines that a conflict actually exists and generates the key conflict error. - If, at
step 420, the temporalkey indexing component 150 determines that the first temporal key is not a pseudo-deleted key, then the temporalkey indexing component 150 determines whether the first temporal key conflicts with the prospective temporal key (step 425). Upon determining that the first temporal key does conflict with the prospective key, the temporalkey indexing component 150 generates a key conflict error (step 440) and themethod 400 ends. If instead the temporalkey indexing component 150 determines that there is no conflict between the first temporal key and the prospective temporal key, the temporalkey indexing component 150 inserts the prospective temporal key into the index (step 435) and themethod 400 ends. - Of note, in the
method 400, because the index is sorted at least in part by the time values for the temporal keys, the temporalkey indexing component 150 may determine that the prospective temporal key does not conflict with any keys in the index if the prospective key does not conflict with the first potentially conflicting key in the index. For example, the index could be sorted at least in part in ascending order based on the ending time values of the temporal keys. In such an example, the temporalkey indexing component 150 could scan the sorted index to identify the first key having an ending time that is after the starting time of the prospective temporal key. If the temporalkey indexing component 150 determines that this first key does not conflict with the prospective temporal key and further determines that this first key has not been deleted (or that any such deletion operation has been rolled back), then the temporalkey indexing component 150 could conclude that no key in the index conflicts with the prospective temporal key. Advantageously, doing so allows the temporalkey indexing component 150 to avoid comparing all the keys in the index with the prospective temporal key. -
FIG. 5 is a flow diagram illustrating a method of inserting a temporal key into an index, according to one embodiment presented in this disclosure. As shown, themethod 500 begins atstep 510, where the temporalkey indexing component 150 determines that a conflicting pseudo-deleted key exists in the first page file for an index. Thus, the temporalkey indexing component 150 could determine that more keys in the index should be processed before concluding that no conflict exists for the prospective temporal key (e.g., as instep 455 of the method 400). The temporalkey indexing component 150 then identifies a second page file for the index that contains one or more potentially conflicting keys for the prospective temporal key (step 515). - Upon identifying the second page file for the index, the temporal
key indexing component 150 places a key value lock on the principal key value for the prospective new key (step 520). As discussed above, certain indexes may contain temporal keys relating to more than one principal key value. For example, a particular index could contain temporal keys relating to scheduling appointments for multiple doctors, where each doctor is represented using a different principal key value. For instance, in such an index, the primary value could be the name of the doctor that each appointment is scheduled with and the index could enforce uniqueness amongst the temporal keys for a particular doctor. That is, while two 9:00 am-10:00 am appointments could be scheduled for two different doctors, overlapping appointments should generally not be allowed to exist for the same doctor. Thus, since there may be keys relating to multiple primary values in the index, the temporalkey indexing component 150 obtains a key value lock only on the unique key value of the prospective temporal key. Here, the key value lock prevents any insertions or modifications of temporal keys having the locked principal value. Thus, continuing the example, if the prospective temporal key specifies a new appointment with “Dr. Smith” (i.e., the principal key value), the temporalkey indexing component 150 could obtain a key value lock on the principal key value of “Dr. Smith”, thereby preventing any insertions or deletions of temporal keys within the index relating to the principal key value of “Dr. Smith”. Of note, such a key value lock may prevent key modifications or insertions across a single page file of the index, or may prevent such modifications or insertions across a plurality of page files of the index. - Once the key value lock is obtained, the temporal
key indexing component 150 determines if the second page file contains any keys that conflict with the prospective temporal key (step 525). If the temporalkey indexing component 150 determines the second page file contains a conflicting key, the temporalkey indexing component 150 generates a key conflict error (step 540). If instead the temporalkey indexing component 150 determines that the second page file does not contain any conflicting keys, the temporalkey indexing component 150 inserted the received prospective key into the index (step 535). Once the prospective key is inserted into the index or once the key conflict error is generated, the temporalkey indexing component 150 unlocks the key value lock on the principal key value of the prospective key (step 545) and themethod 500 ends. Advantageously, doing so prevents any serialization problems that may arise while the temporalkey indexing component 150 is processing keys in subsequent page files (i.e., the second page file in the depicted example). That is, by acquiring the key value lock, themethod 500 prevents a situation where another entity (e.g., another process or thread) alters the keys at a location in the index the temporalkey indexing component 150 has already scanned. - Of note, although
FIG. 5 deals with an index containing only two page files, one of ordinary skill in the art will appreciate that embodiments of the present invention may be used with indexes containing any number of page files. Thus, although instep 525 of the above example the temporalkey indexing component 150 considered only the second page file, in other embodiments, the temporalkey indexing component 150 could continue scanning any number of subsequent page files to identify any conflicting keys in the index. For instance, in a particular embodiment, the temporalkey indexing component 150 is configured to continue scanning until (i) the temporalkey indexing component 150 finds a key with a different principal key value (e.g., when the temporalkey indexing component 150 finds a key relating to “Dr. Jones”, if the prospective key specifies a new appointment with “Dr. Smith”), (ii) the temporalkey indexing component 150 finds a key with the same principal key value but that does not temporally overlap with the prospective key and is not pseudo-deleted, or (iii) there are no more keys in the index. -
FIG. 6 is a block diagram illustrating a system configured to run a temporal key indexing component, according to one embodiment presented in this disclosure. As shown, thesystem 600 includes a plurality ofclient systems 610 and adatabase system 660, communicatively coupled via anetwork 695. In one embodiment, theclient systems 610 may include existing computer systems, e.g., desktop computers, server computers, laptop computers, tablet computers, mobile devices (e.g., mobile phones), gaming consoles, hand-held gaming devices and the like. Theclient systems 610 illustrated inFIG. 6 , however, are merely examples of computer systems in which embodiments of the present invention may be used. Embodiments of the present invention may be implemented differently, regardless of whether the computer systems are complex multi-user computing systems, such as a cluster of individual computers connected by a high-speed network, single-user workstations, or network appliances lacking non-volatile storage. Moreover, it is explicitly contemplated that embodiments of the invention may be implemented using any device or computer system capable of performing the functions described herein. - As shown, each
client system 610 includes, without limitation, aprocessor 615, which obtains instructions and data via a bus 620 from amemory 630 andstorage 625.Processor 615 is a programmable logic device that performs instruction, logic, and mathematical processing, and may be representative of one or more CPUs.Storage 625 is representative of hard-disk drives, flash memory devices, optical media and the like. Generally, thestorage 625 stores application programs and data for use by theclient system 610. Theclient systems 610 are operably connected to thenetwork 695, e.g., via network interfaces. - The
memory 630 is any memory sufficiently large to hold the necessary programs and data structures.Memory 630 could be one or a combination of memory devices, including Random Access Memory, nonvolatile or backup memory (e.g., programmable or Flash memories, read-only memories, etc.). In addition,memory 630 andstorage 625 may be considered to include memory physically located elsewhere; for example, on another computer coupled to theclient system 610 via bus 620. Thememory 630 includes adatabase client 640 and an operating system (“OS”) 635.Operating system 635 is software used for managing the operation of theclient system 610. Examples ofOS 635 include UNIX, versions of the Microsoft Windows® operating system and distributions of the Linux® operating system. (Note: Linux is a trademark of Linus Torvalds in the United States and other countries.) More generally, anyoperating system 635 capable of performing the functions described herein may be used. - Additionally, the
client systems 610 are each coupled to displaydevices 645 andinput devices 650. Thedisplay devices 645 may include output devices such as monitors, touch screen displays, and so on. For instance, thedisplay devices 645 may include a display device used to visually depict a user interface through which a user may form database queries to submit to theDBMS 690. Theinput devices 650 represent a wide variety of input devices, including keyboards, mice, controllers, microphones, and so on. - As shown, the
database system 660 includes, without limitation, aprocessor 665, which obtains instructions and data via abus 670 from amemory 680 andstorage 675.Processor 665 is a programmable logic device that performs instruction, logic, and mathematical processing, and may be representative of one or more CPUs.Storage 675 is representative of hard-disk drives, flash memory devices, optical media and the like. Generally, thestorage 675 stores application programs and data for use by thedatabase system 660. Thedatabase system 660 is operably connected to thenetwork 695, e.g., via a network interface. - The
memory 680 is any memory sufficiently large to hold the necessary programs and data structures.Memory 680 could be one or a combination of memory devices, including Random Access Memory, nonvolatile or backup memory (e.g., programmable or Flash memories, read-only memories, etc.). In addition,memory 680 andstorage 675 may be considered to include memory physically located elsewhere; for example, on another computer coupled to thedatabase system 660 viabus 670. Thememory 680 includes aDBMS 690 and anOS 685.Operating system 685 is software used for managing the operation of thedatabase system 660. Examples ofOS 685 include UNIX, versions of the Microsoft Windows® operating system and distributions of the Linux® operating system. More generally, anyoperating system 685 capable of performing the functions described herein may be used. - As shown, the
DBMS 690 contains adatabase 692, adatabase index 694 and a temporalkey indexing component 150. Thedatabase index 694 is generally a data structure used to ensure rapid lookups and efficient access of records in thedatabase 692. Furthermore, although thedatabase 692 is shown as contained entirely inmemory 680, such a depiction is for illustrative purposes only. Moreover, one of ordinary skill in the art will recognize that thedatabase 692 could be contained not only inmemory 680 but in a variety of locations, including, for example,storage 675, another storage device altogether (e.g., a remote storage device via bus 670), or a mix thereof. - As discussed above, the temporal
key indexing component 150 generally manages thedatabase index 694 that contains temporal keys. For instance, the temporalkey indexing component 150 could add an entry (i.e., a key) to thedatabase index 694 that contains timestamp and time zone data. In doing so, the temporalkey indexing component 150 could ensure that there is not an overlapping temporal key in the database index 694before inserting the new entry into theindex 694. For instance, the temporalkey indexing component 150 could scan the index to identify a first potentially conflicting key. The temporalkey indexing component 150 could then compare the prospective new key with the first potentially conflicting key to determine whether a conflict exists between the two. Upon determining no conflict exists, the temporalkey indexing component 150 could insert the new entry into the index. Advantageously, doing so ensures that thedatabase index 694 will not contain any overlapping temporal keys. - In the preceding, reference is made to embodiments of the invention. However, the invention is not limited to specific described embodiments. Instead, any combination of the following features and elements, whether related to different embodiments or not, is contemplated to implement and practice the invention. Furthermore, although embodiments of the invention may achieve advantages over other possible solutions and/or over the prior art, whether or not a particular advantage is achieved by a given embodiment is not limiting of the invention. Thus, the preceding aspects, features, embodiments and advantages are merely illustrative and are not considered elements or limitations of the appended claims except where explicitly recited in a claim(s). Likewise, reference to “the invention” shall not be construed as a generalization of any inventive subject matter disclosed herein and shall not be considered to be an element or limitation of the appended claims except where explicitly recited in a claim(s).
- As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
- Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
- A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
- Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
- Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
- Aspects of the present invention are described above with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
- These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
- The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
- Embodiments of the invention may be provided to end users through a cloud computing infrastructure. Cloud computing generally refers to the provision of scalable computing resources as a service over a network. More formally, cloud computing may be defined as a computing capability that provides an abstraction between the computing resource and its underlying technical architecture (e.g., servers, storage, networks), enabling convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction. Thus, cloud computing allows a user to access virtual computing resources (e.g., storage, data, applications, and even complete virtualized computing systems) in “the cloud,” without regard for the underlying physical systems (or locations of those systems) used to provide the computing resources.
- Typically, cloud computing resources are provided to a user on a pay-per-use basis, where users are charged only for the computing resources actually used (e.g. an amount of storage space consumed by a user or a number of virtualized systems instantiated by the user). A user can access any of the resources that reside in the cloud at any time, and from anywhere across the Internet. In context of the present invention, a user could submit a database query (e.g., using the database client 640) specifying a new temporal key to be inserted into an index for a database or other data store available in the cloud. For example, a DBMS configured with a temporal
key indexing component 150 could execute on a computing system in the cloud and maintain a database index containing temporal keys. Upon receiving the database query specifying the prospective new temporal key, the temporalkey indexing component 150 could determine if a conflict exists between the new temporal key and the temporal keys within the index and, if not, could insert the new temporal key into the index. Doing so allows users to submit queries relating to temporal keys from any computing system attached to a network connected to the cloud (e.g., the Internet). - The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. Each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by special-purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
- While the foregoing is directed to embodiments of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof, and the scope thereof is determined by the claims that follow.
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/486,064 US9262467B2 (en) | 2011-09-30 | 2014-09-15 | Enforcing temporal uniqueness of index keys utilizing key-valued locking in the presence of pseudo-deleted keys |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/249,973 US8892515B2 (en) | 2011-09-30 | 2011-09-30 | Enforcing temporal uniqueness of index keys utilizing key-valued locking in the presence of pseudo-deleted keys |
US14/486,064 US9262467B2 (en) | 2011-09-30 | 2014-09-15 | Enforcing temporal uniqueness of index keys utilizing key-valued locking in the presence of pseudo-deleted keys |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/249,973 Continuation US8892515B2 (en) | 2011-09-30 | 2011-09-30 | Enforcing temporal uniqueness of index keys utilizing key-valued locking in the presence of pseudo-deleted keys |
Publications (2)
Publication Number | Publication Date |
---|---|
US20150032701A1 true US20150032701A1 (en) | 2015-01-29 |
US9262467B2 US9262467B2 (en) | 2016-02-16 |
Family
ID=47993576
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/249,973 Expired - Fee Related US8892515B2 (en) | 2011-09-30 | 2011-09-30 | Enforcing temporal uniqueness of index keys utilizing key-valued locking in the presence of pseudo-deleted keys |
US13/792,625 Expired - Fee Related US8898111B2 (en) | 2011-09-30 | 2013-03-11 | Enforcing temporal uniqueness of index keys utilizing key-valued locking in the presence of pseudo-deleted keys |
US14/486,064 Expired - Fee Related US9262467B2 (en) | 2011-09-30 | 2014-09-15 | Enforcing temporal uniqueness of index keys utilizing key-valued locking in the presence of pseudo-deleted keys |
Family Applications Before (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/249,973 Expired - Fee Related US8892515B2 (en) | 2011-09-30 | 2011-09-30 | Enforcing temporal uniqueness of index keys utilizing key-valued locking in the presence of pseudo-deleted keys |
US13/792,625 Expired - Fee Related US8898111B2 (en) | 2011-09-30 | 2013-03-11 | Enforcing temporal uniqueness of index keys utilizing key-valued locking in the presence of pseudo-deleted keys |
Country Status (1)
Country | Link |
---|---|
US (3) | US8892515B2 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20160378802A1 (en) * | 2015-06-26 | 2016-12-29 | Pure Storage, Inc. | Probabilistic data structures for deletion |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8892515B2 (en) | 2011-09-30 | 2014-11-18 | International Business Machines Corporation | Enforcing temporal uniqueness of index keys utilizing key-valued locking in the presence of pseudo-deleted keys |
CN104868991B (en) * | 2015-05-07 | 2018-09-04 | 新华三技术有限公司 | A kind of Security Parameter Index conflict processing method and group key server KS |
CN107193857B (en) * | 2016-03-15 | 2021-01-01 | 阿里巴巴集团控股有限公司 | Method and equipment for database traversal |
US10521418B2 (en) | 2016-08-18 | 2019-12-31 | International Business Machines Corporation | Enforcing temporal referential integrity |
US11205842B2 (en) * | 2017-05-19 | 2021-12-21 | Starry, Inc. | Pointing algorithm for endpoint nodes |
GB2564878B (en) * | 2017-07-25 | 2020-02-26 | Advanced Risc Mach Ltd | Parallel processing of fetch blocks of data |
US11366810B2 (en) * | 2020-04-27 | 2022-06-21 | Salesforce.Com, Inc. | Index contention under high concurrency in a database system |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5440730A (en) | 1990-08-09 | 1995-08-08 | Bell Communications Research, Inc. | Time index access structure for temporal databases having concurrent multiple versions |
JPH0756652B2 (en) | 1992-03-24 | 1995-06-14 | インターナショナル・ビジネス・マシーンズ・コーポレイション | Search for video frame sequence |
US7519924B2 (en) * | 2004-11-03 | 2009-04-14 | Research In Motion Limited | Handheld electronic device including appointment and meeting conflict notification, and associated method |
US8108355B2 (en) | 2006-10-27 | 2012-01-31 | Hewlett-Packard Development Company, L.P. | Providing a partially sorted index |
US8533256B2 (en) * | 2007-10-09 | 2013-09-10 | Cleversafe, Inc. | Object interface to a dispersed data storage network |
US8892515B2 (en) | 2011-09-30 | 2014-11-18 | International Business Machines Corporation | Enforcing temporal uniqueness of index keys utilizing key-valued locking in the presence of pseudo-deleted keys |
-
2011
- 2011-09-30 US US13/249,973 patent/US8892515B2/en not_active Expired - Fee Related
-
2013
- 2013-03-11 US US13/792,625 patent/US8898111B2/en not_active Expired - Fee Related
-
2014
- 2014-09-15 US US14/486,064 patent/US9262467B2/en not_active Expired - Fee Related
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20160378802A1 (en) * | 2015-06-26 | 2016-12-29 | Pure Storage, Inc. | Probabilistic data structures for deletion |
US10846275B2 (en) * | 2015-06-26 | 2020-11-24 | Pure Storage, Inc. | Key management in a storage device |
US20210073193A1 (en) * | 2015-06-26 | 2021-03-11 | Pure Storage, Inc. | Key management in a storage device |
US11675762B2 (en) * | 2015-06-26 | 2023-06-13 | Pure Storage, Inc. | Data structures for key management |
US20230281179A1 (en) * | 2015-06-26 | 2023-09-07 | Pure Storage, Inc. | Load Balancing For A Storage System |
Also Published As
Publication number | Publication date |
---|---|
US20130086002A1 (en) | 2013-04-04 |
US8898111B2 (en) | 2014-11-25 |
US9262467B2 (en) | 2016-02-16 |
US8892515B2 (en) | 2014-11-18 |
US20130204846A1 (en) | 2013-08-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9262467B2 (en) | Enforcing temporal uniqueness of index keys utilizing key-valued locking in the presence of pseudo-deleted keys | |
US9069832B2 (en) | Approach for modularized sychronization and memory management | |
US8903814B2 (en) | Indexing timestamp with time zone value | |
US10990628B2 (en) | Systems and methods for performing a range query on a skiplist data structure | |
EP3519986B1 (en) | Direct table association in in-memory databases | |
CN105630860A (en) | Database system with transaction control block index | |
US8996500B2 (en) | Using temporary performance objects for enhanced query performance | |
US7836022B2 (en) | Reduction of join operations when archiving related database tables | |
US10262025B2 (en) | Managing a temporal key property in a database management system | |
US9053153B2 (en) | Inter-query parallelization of constraint checking | |
US11698893B2 (en) | System and method for use of lock-less techniques with a multidimensional database | |
US11556537B2 (en) | Query plan generation and execution based on single value columns | |
US8745016B2 (en) | Managing concurrent access to data in database system | |
US20200342008A1 (en) | System for lightweight objects | |
US11853284B2 (en) | In-place updates with concurrent reads in a decomposed state | |
US20140379674A1 (en) | Providing multiple concurrent transactions on a single database schema using a single concurrent transaction database infrastructure | |
JP6202929B2 (en) | Gap detection in temporally unique indexes in relational databases | |
US9858310B2 (en) | Maintaining in-memory database consistency by parallelizing persistent data and log entries | |
US11288251B2 (en) | Supporting concurrent updates to a database page | |
US8868511B2 (en) | Archiving—safe replication of relational data | |
US8117408B2 (en) | Buffer for object information | |
US8521776B2 (en) | Accessing data in a multi-generation database |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LYLE, ROBERT W.;WANG, PING;REEL/FRAME:033738/0543 Effective date: 20130307 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
FEPP | Fee payment procedure |
Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
LAPS | Lapse for failure to pay maintenance fees |
Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |
|
FP | Lapsed due to failure to pay maintenance fee |
Effective date: 20200216 |