Patent Application
20160125022
The structure of database management systems that are efficient for processing transactional data may at times be in opposition to those structures efficient for processing analytical queries. As a result, there may at times be architectural distinctions between database management systems designed for use in processing transactional data and data warehouse systems designed for performing analytical queries. Various systems, sometimes referred to as operational data warehouses, may comprise mechanisms adapted for use in scenarios where both transactional data processing and analytical queries are to be performed.
A system and method for database management is disclosed herein. The system may include one or more computing devices that, when activated, maintain a table in a plurality of structures stored on one or more memories. The plurality of structures may include a row store and a column store, and the row store may include a row of the table associated with an identifier indicative of a location in the column store corresponding to the row The column store may include a subset of values for a column of the table. The system may include one or more memories having computer readable instructions that, upon execution by a computing device, cause the one or more computing devices to receive a request to store a modified version of the row. The instructions may cause the system to add, to a first plurality of records, a first record indicative of a logically deleted state for values in the column store corresponding to the row. The instructions may further cause the system to add the modified version of the row to the row store and modify the identifier to indicate that the column store does not contain a location corresponding to the modified version of the row. Finally, the instructions may cause the system to add, to a second plurality of records, a second record indicative of the modified version of the row not having been propagated to the column store.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
The foregoing Summary, as well as the following Detailed Description, is better understood when read in conjunction with the appended drawings. In order to illustrate the present disclosure, various aspects of the disclosure are shown. However, the disclosure is not limited to the specific aspects discussed. The following figures are included:
A memory optimized storage mechanism may be used for efficient online transaction processing (“OLTP”). Another storage mechanism may be used for efficient data warehousing and analytics-related processing. In some cases the shared data sets may need to be processed efficiently with the simultaneous usage of both mechanisms. An Operational Data Warehouse (“ODW”) may be described as a system that may be used for efficient processing of both transactional and analytical operations. A system comprising both mechanisms is described herein. The system may further include a mechanism for maintenance of data contained in the system, which may include hybrid storage mechanisms adapted for ODW scenarios.
Maintenance may include transfer of rows stored in a structure held in volatile memory to another structure held in non-volatile memory, or from structures held in row-oriented data stores to column-oriented data stores.
In the following description, operational terms such as “update,” “delete,” “insert,” “scan,” and “seek” are used in the following description for the purpose of providing relative reference only, and are not intended to suggest any limitations. Thus, these descriptions are merely general database operational processing terms and it is well known that other terms may also be used to depict similar operational meaning in a database system.
Referring now to
The system 100 may be also be comprised of one or more memories having computer readable instructions stored thereon (not shown) that may be executed by the one or more computing devices, cause the system 100 to perform steps of an example operational procedure 260 as illustrated in
Operation 253 illustrates adding the modified version of the row to the row store. Operation 254 illustrates modifying the identifier to indicate that the column store does not contain a location corresponding to the modified version of the row. Operation 255 illustrates causing the addition, to a second plurality of records, of a second record indicative of the modified version of the row not having been propagated to the column store. The second plurality of records may, for example, comprise an index referring to a tail of the row store. Rows in the row store may be in an unpropagated state. When a row is propagated, those columns of the row that are to be stored in the column store may be physically copied to a location within the column store. Those records referred to by the tail may, however, be treated by system 100 as logically included in the column store, even though not yet propagated.
In some aspects, the second plurality of records may comprise a row-oriented structure and may be indicative of a plurality of rows that are logically included in the column store but have not been propagated to the column store. Examples of a row-oriented store include tables or indexes which may be optimized for row-oriented retrieval.
In some aspects, system 100 may include instructions that cause the system 100 to identify a propagation state of the modified version of the row in the row store based at least in part on locating the modified version of row in the second plurality of records. Furthermore, the instructions may cause the system 100 to store the modified version of the row in the column store. The modified version of the row in the column store may be associated with information indicative of an invisible state for the modified version of the row in the column store. The invisible state may refer to the accessibility, in response to scan or seek operations, of the copy of the modified version of the row in the column store. Note that when used in the context of the column store, the term row may refer to whatever subset of columns of a row are to be stored in the column store, and may not in all cases refer to the row in its entirety. Certain columns of a row may, in various aspects, be excluded from storage in the column store.
The instructions may cause the system 100 to store, in the first plurality of records, a second record comprising a second identifier indicative of a location in the column store corresponding to the modified version of the row. The second record in the first plurality of records may be indicative of a logically deleted state of the modified version of the row in the column store. The instructions may cause the system 100 to associate the modified version of the row in the column store with information indicative of a visible state in the column store in response to completion of a transaction pending at a time the second record was stored in the first plurality of records. The instructions may also cause the system 100 to associate the modified version of the row in the row store with the second identifier indicative of a location in the column store corresponding to the modified version of the row. The instructions may also cause the system 100 to remove the second record from the first plurality of records. In some aspects the second record may be removed, thereby reverting the logically deleted state of the modified version of the row in the column store.
In some aspects, system 100 may include instructions that cause the system 100 to select the row for propagation to the column store based at least in part on a frequency of requests associated with modifying the row, and to determine the frequency based at least in part on performing a linear regression performed on variables comprising a timestamp and a time value corresponding to the timestamp. Additionally, in another aspect, associating the modified version of the row in the row store with the second identifier indicative of a location in the column store may not be logged, and the system 100 may include instructions that cause the system 100 to recover the second identifier based at least in part on locating the modified version of the row in the column store and associating the modified version of the row in the row store with the recovered second identifier.
In one aspect, the first record may comprise information indicative of a range of values in the column store that are in a logically deleted state. This may, for example, be done to reduce the number of entries needed to represent rows in the column store that are in the logically deleted state, which may in turn reduce logging overhead where additions to the first plurality of records, i.e., the deleted rows table, are logged.
In some aspects, system 100 may include instructions that cause the system 100 to associate an operation performed on at least one of the row store, the column store, the first plurality of records, or the second plurality of records with a first transaction. The first transaction may be associated with information indicative of the first transaction being initiated by the system. Furthermore, the first transaction may be caused to abort in response to receiving a request to access the row in a context of a second transaction initiated by a client and it may be determined that the first transaction has not been committed.
In some aspects, system 100 may include instructions that cause the system 100 to, in response to a determination to scan the column store, perform a merge operation based at least in part on merging values in the column store, information in the first plurality of records indicative of logically deleted states, and information in the second plurality of records indicative of rows that have not been propagated to the column store, wherein the merge operation is performed relative to a timestamp. The merge operation may combine performing a join operation between the column store and the deleted rows table, in order to subtract deleted rows, and combining the result of the join with the tail portion of the row store, since that portion represents rows not yet propagated to the column store.
In another aspect, system 100 may be comprised of one or more volatile memories 101 and one or more non-volatile memories 102. The system 100 may further be comprised of one or more memories having computer readable instructions stored thereon that may be executed by one or more computing devices (not pictured). The instructions may cause the system 100 to select a row from a plurality of rows stored in the volatile memory 101. The selected row may be in a ready state for migration from the volatile memory 101 to the non-volatile memory 102. In an alternative aspect, the instructions may instruct the system 100 to select more than one row at a time.
Further, the system 100 may store the selected row in the non-volatile memory 102 such that the row is associated with information that is indicative of an invisible state for the row. An identifier may be formed by the system 100 and may be used subsequently to locate the row in the non-volatile memory 102. In at least one of the volatile memories 101 or non-volatile memories 102, information may be stored that is indicative of a deleted state for the row. The deleted state may, however, be described as a pseudo-deleted state, because the row or a subset of columns from the row is to be propagated from volatile memories 101 to non-volatile memories 102, rather than deleted from the table. More generally, the row or a subset of columns from the row may be propagated from a row store to a column store. Propagating a row or a subset of columns from a row may comprise a copying of the row from the row store to the column store. In various cases, the row-oriented store may be maintained in volatile memories 101 and the column store may be maintained in non-volatile memories 102. Propagation may also be referred to as or include migrating, copying, compressing, or duplicating the row or a subset of columns from the row. The information indicative of the pseudo-deleted state may be comprised of both the identifier and a timestamp. The information may be stored in a context of a first transaction.
The system 100 may modify the volatile memory 101 to associate the row with the identifier and further may delete the information indicative of a deleted state for the row. In various aspects, a delta store and a delete bitmap may be present in a database management system similar to the system 100 as described herein. However, a delta store and delete bitmap may be omitted in some cases. Further details depicting the system 100 with improved update performance may be described in
In another particular aspect, a method is disclosed with improved update performance in transactional and data warehouse applications. The method may be implemented, in some aspects, in system 100 comprising one or more volatile memories 101 and one or more non-volatile memories 102. The one or more memories may further have stored thereon computer readable instructions that may be executed by one or more computing devices (not pictured). The method may include selection of a row from a plurality of rows stored in the volatile memory 101. The selected row may be in a ready state for migration from the volatile memory 101 to the non-volatile memory 102. In an alternative aspect, more than one row may be selected at a time.
Further, the method may include storing the selected row in the non-volatile memory 102 such that the row is associated with information that is indicative of an invisible state for the row. An identifier may be generated and may be used to locate the row in the non-volatile memory 102. In at least one of the volatile memories 101 or non-volatile memories 102, information may be stored that is indicative of the deleted state for the row. The information may be comprised of both the identifier and a timestamp. The information may be stored in a context of a first transaction. In response to a completed first transaction, an additional transaction may be pending at a time the first transaction was committed. The additional transaction may be allowed to complete. This may be described as allowing pending transactions to drain prior to making the row visible in the non-volatile memory. Subsequent to the drain, the row may then be associated with information indicative of a visible state for the row.
The method may include modifying the volatile memory 101 to associate the row with the identifier. Furthermore, the information indicative of a deleted state for the row may be deleted. In some aspects, a delta store and a delete bitmap may be present in a database management system. However, in other aspects, the delta store and delete bitmap may be omitted. Further details depicting the method with improved update performance may be described in
In another aspect, a computer readable storage medium for improved update performance in transactional and data warehouse applications is disclosed. The computer readable storage medium may store thereon computer readable instructions that, when executed by one or more processors of a computing system, cause the selection of a row from a plurality of rows stored in the volatile memory 101. The selected row may be in a ready state for migration from the volatile memory 101 to the non-volatile memory 102. In some aspects, more than one row may be selected at a time.
Further, the medium may include instructions for storing the selected row in the non-volatile memory 102 such that the row is associated with information that is indicative of an invisible state for the row. An identifier may be generated and may be used to locate the row in the non-volatile memory 102. In at least one of the volatile memories 101 or non-volatile memories 102, information may be stored that is indicative of the deleted state for the row. The information may comprise the identifier and a timestamp. The information may be stored in a context of a first transaction. When the first transaction is complete, an additional transaction may be pending at a time the first transaction was committed. Accordingly, the row may then be associated with information indicative of a visible state for the row.
The medium may include instructions for modifying the volatile memory 101 to associate the row with the identifier. The medium may also include instructions for deleting the information indicative of a deleted state for the row. In some aspects, a delta store and a delete bitmap may be present in a database management system similar to the medium as described herein. However, in some aspects, the additions of a delta store and delete bitmap may not be implemented. Further details depicting the medium with improved update performance may be described in
Referring now to
In block 201, the selection of the row in the volatile memory 101 may be selected based on the row being associated with information that may indicate the row is in a non-propagated state. In an aspect, the information may include a timestamp along with an identifier. Block 204 describes the content of the information that the row is associated with.
Referring again to block 201, the selection of the row may be based on the frequency of updates. In the system 100, the selected row may be in a state where it has not been frequently updated. In an aspect, the rows that have not been frequently updated may be best suited to be selected by the system 100 for migration from the volatile memory 101 to the non-volatile memory 102. In this way, the system 100 may implement a threshold value that approximately identifies the cold rows from the plurality of rows in the volatile memory 101. A threshold value may be represented by a value (e.g., one million rows). The cold rows may be described in the system 100 as rows that have not been changed for a predetermined time. These cold rows may be the selected rows used in block 201 to propagate from the volatile memory 101 to the non-volatile memory 102. The migration of rows from the volatile memory 101 to the non-volatile memory 102 may be triggered by several events beyond a threshold value. In another example, the migration may be triggered by determining that a time period has elapsed (e.g., one hour), or receiving a user command (e.g., database administrator command) to perform the migration. The above examples of the triggering events for causing the migration are not intended to suggest any limitations. It may be possible to include other triggering events to replace the examples outlined above.
Block 202 includes storing the selected row in the non-volatile memory 102. The selected row may be associated with information that indicates an invisible state for the row. An invisible state for the row may create a scenario where concurrent scans may not locate or identify the selected row. In other words, the selected row may be prevented or withheld from visibility to any concurrent scans by the system 100. In an instance where a crash occurs in the system 100, the invisibly selected row may stay hidden. The selected row and one or more additional rows may be combined to form a record, where the record may be compressed when stored in the non-volatile memory 102. Similar to the selected row, the one or more additional rows may also be selected from the plurality of rows stored in the volatile memory 101. The compressed record which includes the selected row and the one or more additional rows may be stored in a column store 104 in the non-volatile memory 102. The column store 104 may store the record in a column-wise fashion.
Block 203 illustrates forming an identifier that may be used to locate the row in the non-volatile memory 102. The identifier may indicate a position of the row within a column group. For example, the identifier may be a key value that indicates the position of the row in the column store 104. As another example, the identifier may also be a row identifier (RID). In some aspects, the RID may be a physical row identifier consisting of a row group identifier and a Tuple identifier. The RID may, in some aspects, be represented by a numerical value that may indicate the position of the row in the column store 104. The RID values may be stored in a hidden column in table 103 and thus, may be hidden from user visibility. The hidden column may be referred to as RID column 105. For example, if the RID value in the RID column 105 is “−1,” the system 100 may find the value to be invalid. However, the invalid indication allows the system 100 to recognize that the selected row is not yet compressed or migrated from the volatile memory 101 to the non-volatile memory 102. In other words, the invalid RID value may indicate that the row is in the non-propagated state. In another example, an internally constructed index 108 in the system 100 may also assist the system 100 in locating the rows with the RID value of “−1.” The internally constructed index 108 may be a filtered hash index. A filtered hash index may construed to be just one example and is not intended to suggest any limitations of the type of index that may be used for the internally constructed index 108.
Block 204 illustrates storing information indicative of a deleted state for the row in at least one or both the volatile 101 and non-volatile memory 102. The information may include the identifier and also a timestamp. A timestamp may be indicated by a numerical value. For example, the value of “10” may be assigned and associated with the row as the timestamp. The value of the timestamp may assist the system 100 during scans. The rows associated with a timestamp value that may not meet a certain or predicated value as set forth by a user or by the system itself may be filtered out or disregarded during the scan. As a further example, a scan as of timestamp “10’ will not see a delete of the row that occurred as of timestamp “11.” Further, the information may be stored in a context of a first transaction. If the first transaction has not yet been committed, the system 100 may cause the first transaction to abort in the instance where a second transaction is initiated by a user or client. A second transaction may occur when the request is initiated by the user or client requesting access to the same selected row. Referring again to block 204, the information indicative of a deleted state for the row may be stored in an additional table 107 that may not be user-visible. In other words, the system 100 is performing a pseudo-delete. The pseudo-delete may occur when the row is being moved or deleted from the table 103 and being inserted into the additional table 107. This additional table 107 may contain identifiers of rows in the column store 104 that have been logically deleted from the first table 103. As described above, the identifier may be a key value or a RID value. In other words, the additional table 107 may be a deleted rows table 107. The deleted rows table 107 may act similarly to a delete bitmap from prior aspects of a database warehouse system and store identifiers of the rows that are logically deleted from the table 103. Thus, in an aspect, the deleted rows table 107 or a portion of the deleted rows table 107 may still be converted to a delete bitmap and function similarly as a delete bitmap. In some aspects, instead of utilizing a delete bitmap where timestamps associated with each row are not saved, the use of a deleted rows table 107 may allow the system 100 to identify versions or saved states of each row. In this way, snapshot semantics may be implemented.
Block 205 illustrates responding after the completion of the first transaction and while an additional transaction is pending. With the first transaction committed, an additional transaction may be pending, and when the first transaction is completed, information indicative of a visible state for the row may be associated with the selected row. The selected row may transform or change from the invisible state to a visible compressed state. For further example, the first transaction may be committed when information indicative of a deleted state of a row includes information comprising the identifier and a timestamp is stored in the deleted rows table 107. An additional transaction may be pending until the latest active timestamp of the additional transaction reaches the commit timestamp of the first transaction. The waiting or pending period may be accomplished by establishing a transaction drain—any transaction that may be active when the first transaction commits may be associated with a dependency from the transaction drain. When the additional transaction or the last such transaction commits, aborts, or enters validation, the system 100 may make a call back to a drain object. The system 100 may then queue a new thread to change the state of the row from invisible to visible and to perform the functions of block 206 and 207 below. This example may be accomplished such that no transaction can observe data in the new row group(s).
Block 206 illustrates modifying the volatile memory 101 to associate the row with the identifier. The identifier may assist the system 100 to identify the row to be modified.
Block 207 illustrates performing a delete of the information indicative of a deleted state for the row.
Certain aspects may cause large amounts of log data to be written. For example, the migration of one million rows may result in the generation of three million log records. One record may be generated per row during inserts into the deleted row table 107. One record may be generated per row during deletes from the deleted row table 107. One record may be generated per row during updates to the RID column of the table 103. Aspects may improve log efficiency through the system 100 by optimizing away almost all of this logging overhead. Log records for the deleted row table 107 may be optimized by identifying that both inserts and deletes during data migration happen in ranges of Tuple IDs within the same Row Group ID. For example, inserts occur for all Tuple IDs between 1 and N (for N around 1,000,000) within a given row group and deletes may occur in the range around 1 and 1000 tuples.
Thus, in an aspect, the system 100 may be altered to apply a schema to the deleted rows table 107. Instead of storing RIDs, the system 100 may include three columns: a Row Group ID, a begin tuple ID within the row group, and an end tuple ID within the row group.
The range index on the deleted rows table 107 becomes an index on the first two columns. The meaning of a row in the deleted rows table 107 is that every RID with specified Row Group ID and with Tuple ID within the specified range of IDs may be considered deleted.
Inserts of one record may occur into the deleted rows table 107 for each portion of RIDs that one transaction will operate on. Furthermore, a delete of one record may occur from then deleted rows table 107 when the row is changed from the invisible to the compressed visible state. The corresponding one record may include a range and the RID values in the table 103 may be updated with the most up to date RID values that correspond to the range of the record. If any write-write conflicts happen, a single record will be inserted into deleted rows table 107 to re-hide the row that could not be propagated because of such a conflict.
Hence, the above described optimization may assist in the reduction of the number of log records on deleted rows table 107. In some aspects, optimization may decrease the amount from two million to about two thousand log records.
Referring now to
A temporal histogram (not depicted) may be built such that the histogram approximately specifies how many rows in the tail of the table 103 are within a particular period. All periods younger than N time ago may be lumped together. When a new row is inserted into the tail of the table 103, an increment of one is added into the latest period of the histogram. On the other hand, when a row is deleted from the tail of the table 103, the created timestamp may be translated into the time period using the linear approximation mentioned above. Hence, a decrease of one is subtracted from that period in the histogram. When the periodic background thread described above is run, the histogram may be shifted by one period (such that the two oldest periods may be combined and a newest period may be introduced with initially zero rows). The implementation may use a circular array to keep track of periods, such that each array element may be a partitioned counter. Partitioning may allow reducing contention on the counter between different threads.
As described in block 201, when a data migration background task checks whether data migration is warranted, the background task may receive information from the above histogram regarding the number of rows in the oldest period. Thus, if the number exceeds a threshold (e.g., one million), migration of the selected row may be invoked from the volatile memory 101 to the non-volatile memory 102. In an alternative embodiment, if the size of the histogram is N and the time period for the background task that advances the histogram is T seconds, then In one aspect, T=30 seconds and N=120 may result in a one hour threshold for row migration.
The begin timestamp 301 of each row may be checked and the rows that are visible to it may not be migrated and compressed unless it is older than the oldest timestamp saved in the manner described above. In addition, any row with a non-infinite end timestamp 302 may be skipped, even if it is visible to the data migration transaction and has a very old begin timestamp value. It may not be beneficial to the system 100 to propagate such a row because it may end up causing a write-write conflict. A write-write conflict may occur when the data migration transaction updates the row before the user transaction may access the row. In some aspects, propagating a row with a write-write conflict may be avoided. For one example, the system 100 may add a bit 310 to the end timestamp of the table 103 which will identify whether the update was done by background data migration.
Thus, if a user transaction requests an update to a row R but discovers that its end timestamp is set to a timestamp E which has the above bit 310 turned on, the user transaction may seek the row again, using E as the visibility timestamp. This will allow the system 100 to find the new row R′ that the data migration transaction inserted when it deleted the row R. The user transaction may then update R′ instead. The background transaction does not change anything except the hidden RID field, so R and R′ may contain the same user data.
Further, if a user transaction requests an update to a row R but discovers that its end timestamp is in doubt, (e.g., R was updated by a transaction T that has not yet been committed) the system 100 may check whether T is a system data migration transaction. If T is a system data migration transaction, there may be two instances for the system 100 to perform.
The first instance may occur if T already obtained a commit timestamp, the user transaction may then proceed as described above, using the commit timestamp of T instead of the end timestamp of the row. This will cause the user transaction to take a commit dependency on T, but otherwise function the same way as described above. However, if T aborts, the user transaction may still abort.
The second instance may occur if T has not yet obtained a commit timestamp, the user transaction may force T to abort. In an aspect, the system 100 can wait for T to abort before proceeding; however, in other aspects, if non-blocking is desired, the system 100 may proceed with its own update (overriding what T did). With this alternate aspect, the system 100 data migration code may include post-processing logic to handle the race condition between T undoing its own changes and the user transaction undoing them.
The computing device 410 includes at least one processor 420 and a system memory 430. Depending on the configuration and type of computing device, the system memory 430 may be volatile (such as random access memory or “RAM”), non-volatile (such as read-only memory or “ROM,” flash memory, and similar memory devices that maintain stored data even when power is not provided), or some combination of the two. The system memory 430 typically includes an operating system 432, one or more application platforms 434, one or more applications, and program data. For example, the system memory 430 may include a database application 436 and database indices 438 (e.g., columnar indices and row-wise indices).
In an illustrative aspect, the database application 436 may include a data transfer component. In another illustrative aspect, the processor 420 may be configured to execute a query processing engine to execute database queries of the database application 436 that reference both columnar database indices and row-wise database indices.
The computing device 410 may also have additional features or functionality. For example, the computing device 410 may also include removable and/or non-removable additional data storage devices such as magnetic disks, optical disks, tape, and standard-sized or flash memory cards. Such additional storage is illustrated in
The computing device 410 may also have input device(s) 460, such as a keyboard, mouse, pen, voice input device, touch input device, etc. Output device(s) 470, such as a display, speakers, printer, etc. may also be included. The computing device 410 also contains one or more communication connections 480 that allow the computing device 410 to communicate with other computing devices 490 over a wired or a wireless network.
It will be appreciated that not all of the components or devices illustrated in
The illustrations of the aspects described herein are intended to provide a general understanding of the structure of the various aspects. The illustrations are not intended to serve as a complete description of all of the elements and features of apparatus and systems that utilize the structures or methods described herein. Many other aspects may be apparent to those of skill in the art upon reviewing the disclosure. Other aspects may be utilized and derived from the disclosure, such that structural and logical substitutions and changes may be made without departing from the scope of the disclosure. Accordingly, the disclosure and the figures are to be regarded as illustrative rather than restrictive.
It should be understood that the various techniques described herein may be implemented in connection with hardware or software or, where appropriate, with a combination of both. The subject matter presented herein may be implemented as a computer process, a computer-controlled apparatus or a computing system or an article of manufacture, such as a computer-readable storage medium.
The techniques, or certain aspects or portions thereof, may, for example, take the form of program code (i.e., instructions) embodied in tangible storage media or memory media implemented as storage devices, such as magnetic or optical media, volatile or non-volatile media, such as RAM (e.g., SDRAM, DDR SDRAM, RDRAM, SRAM, etc.), ROM, etc., that may be included in computing devices or accessible by computing devices. When the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the disclosure. In the case of program code execution on programmable computers, the computing device generally includes a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. One or more programs that may implement or utilize the processes described in connection with the disclosure, e.g., through the use of an application programming interface (“API), reusable controls, or the like. Such programs are preferably implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the program(s) can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and combined with hardware implementations.
Although the subject matter has been described in language specific to structural features and/or acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as examples of implementing the claims and other equivalent features and acts are intended to be within the scope of the claims.
The previous description of the aspects is provided to enable a person skilled in the art to make or use the aspects. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects without departing from the scope of the disclosure. Thus, the present disclosure is not intended to be limited to the aspects shown herein but is to be accorded the widest scope possible consistent with the principles and novel features as defined by the following claims.
