Managing data stored in memory locations having size limitations

Described herein are storage systems, computer readable mediums, and methods for overcoming size limit storage limitations associated with storage systems. Processed transactions may be removed from an object so that input data may be stored at the object. In some implementations, the storage system removes the processed transactions from the object once a section of the object includes a threshold amount of data, and stores the processed transactions at a transaction datastore. Once the processed transactions have been removed from the object, the storage system may store the input data at the object.

BACKGROUND

Storage systems may provide memory having locations configured to store data for users. However, the locations may be configured to have particular size limitations for various reasons, such as maintaining consistent performance.

Certain implementations and embodiments will now be described more fully below with reference to the accompanying figures, in which various aspects are shown. However, various aspects may be implemented in many different forms and should not be construed as limited to the implementations set forth herein. Like numbers refer to like elements throughout.

DETAILED DESCRIPTION

This disclosure relates to storage systems and methods for overcoming size limitations associated with storage systems. The storage systems may comprise database services configured to store and retrieve data. In one implementation, a particular storage system is implemented as a service executing on one or more servers, such as in a distributed computing environment.

The storage system may include one or more objects, which are data stored at locations in memory. In one example, the one or more objects may include at least one computer-readable storage media (“CRSM”) which stores data for retrieval. The object may comprise data stored as an aggregate data structure. The objects, or sections within these objects, may have data storage size limitations. For example, the objects may be configured to store no more than 64 kilobytes (“KB”) of data. As discussed in more detail below, the storage system may use the data storage size limitations to determine whether to perform an update process.

The objects may include data indicating the quantity of data stored in the objects. For example, at a first point in time, a particular object may include data having a size of 10 KB, and at a second point in time, the particular object may include data having a size of 20 KB. Over time, the size of a particular object may increase, approaching the size limitation of the object.

The objects may have one or more sections of data. For example, a particular object may include a processed transaction section configured to store one or more processed transactions. The processed transaction(s) may comprise data representing a unit of data processing resulting from a transaction request. For example, the processed transaction may represent a deposit of money to a user account in response to a user requesting to deposit money in the user account. The money may comprise data which represents value. For example, the money may comprise data representative of frequent fly points, bitcoins, and so forth. In another example, the processed transaction may represent a withdrawal of money to the user account in response to a user purchasing a good from a merchant. The processed transaction may have a state indicating whether the processed transaction is immutable. For example, a particular processed transaction may cause a first service of the storage system to make a call to another service (e.g. an internal or external payment processor), wait for a response, and then update the state. If the first service receives the response and updates the state, the processed transaction becomes immutable. If the first service does not receive the response, the processed transaction remains mutable.

The object may include a section configured to store other data which is associated with the processed transactions. In one example, the other data may comprise data representing an account balance which is determined based on one or more processed transactions. In another example, the other data comprises data representing a value of $100 which indicates that a particular user account has a balance of $100.

The storage system may include a transaction datastore comprising a data structure which is stored on one or more memory devices. In some implementations, the storage system moves the processed transactions from the object to the transaction datastore and stores the processed transactions as historical transactions. In other implementations, the historical transactions may be copies of the processed transactions.

In some implementations, the storage system receives input data from one or more systems (e.g., a server). The input data may represent a new transaction. For example, the new transaction may represent a deposit of money to the user account, or a withdrawal of money from the user account.

In some implementations, the storage system performs an update process once the input data is received. In one example, the update process includes moving processed transactions from the object to a transaction datastore, so that the input data may be inserted into the object. That is, the object may have insufficient space for the input data, and the storage system may create space in the object by moving some processed transactions from the object to a transaction datastore or other datastore. The transaction datastore may comprise a data structure which is stored on one or more memory devices, and may be included within the storage system. In some implementations, the update process includes generating copies of the processed transactions. In these implementations, the update process may include storing the copies of the processed transactions at the transaction datastore as historical transactions. After the copied transactions have been stored at the transaction datastore as the historical transactions, as part of the update process, the storage system may remove the processed transactions from the object, so the input data (e.g., new transactions) may be stored at the object.

In some implementations, the update process includes updating the value located at the object using the input data. In one example, the input data represents a debit of $10 to a user's money account which has a current balance of $40. In this example, the storage system may update the $40 balance using the debit of $10, such that the money balance is $30.

The update process may include updating the object using an optimistic locking process. For example, the object may include a balance table which includes data representative of a version number. The storage system may read the object and the version number, and once the storage system is ready to update the balance, the storage system checks that the version number of the object has not changed. If the version number has been changed, the storage system may abort the update, and may restart the process of updating the object using the optimistic locking process. If the version number has not changed, the storage system continues to perform the update process and updates the balance.

The object may have a one-to-many relationship with at least one of the processed transactions stored at the object or the historical transactions stored at the transaction datastore. For example, using an object ID, the object may be associated with many processed transactions located at the object, or historical transactions located at the transaction datastore. The one-to-many-relationship between the object and the historical transactions may allow users (e.g., system administrators) to query all of the transactions (i.e., the processed transactions and the historical transactions) associated with the object.

The storage system may insert the input data into the object contemporaneously with an update to a particular value (e.g., the balance of a user account) of the object. The contemporaneous insertion and update may allow for the input data to be inserted and the particular value to be updated in an atomic fashion. That is, the insertion and update may each be committed, and if any issues occur during the contemporaneous insertion and update, the storage system may perform a rollback function. The rollback function returns the storage system to a previous state and restores the storage system such that any issues which may have occurred during the contemporaneous insertion and update do not affect the data stored at the storage system.

By performing the update process various benefits are provided to users such as administrative users and software developers. In one example, by moving processed transactions from objects which reach a certain storage capacity, new space is provided for new transactions, and developers may enforce size limits associated with the objects, which may be desired to optimize an application.

Illustrative System

FIG. 1is a block diagram100of a storage system102configured to store the historical transactions at the transaction datastore, so that the input data may be stored at the object. InFIG. 1, the storage system102is depicted at the following two points in time: before the processed transactions are removed from the object104; and after the processed transactions are removed from the object106. In this illustration, time increases across the page, as indicated by the arrow108. The storage system102may comprise one or more database services configured to store and retrieve data. In some implementations, the storage system102is implemented as a service executing on one or more servers, such as in a distributed computing environment.

InFIG. 1, the storage system102includes one or more objects110. The one or more objects110may comprise locations in memory configured to store data. The object110may be associated with a user account which is associated with a user. In one example, the user account comprises data representing a money balance and information about the associated user. The information about the user may include data representative of the user's name, address, phone number, and so forth.

In some implementations, the object110includes one or more sections. For example, inFIG. 1, the object110includes a processed transaction section112configured to store one or more processed transactions114(1),114(2), . . .114(P). The processed transactions114(1),114(2), . . .114(P) may comprise data representing units of data processing resulting from transaction requests. For example, the processed transaction114may represent a deposit of money to a particular user account in response to a user requesting to deposit money in the user account. In another example, the processed transaction114may represent a withdrawal of money to the user account in response to the user purchasing a good from a vendor. The processed transaction114may have a state indicating whether the processed transaction114is immutable or mutable. For example, a particular processed transaction114may cause the storage system102, or a service of the storage system102, to make a call to another service (e.g. an internal or external payment processor), wait for a response, and then update the state. If the storage system102receives the response and updates the state, the processed transaction114becomes immutable. If the storage system102does not receive the response, the processed transaction114remains mutable. The immutable processed transaction114may be described as having a state that cannot be modified, and the mutable processed transaction114may be described as having a state that may be modified.

InFIG. 1, the object110includes other section116configured to store other data which is associated with the processed transactions114(1),114(2), . . .114(P). In one example, the other data comprises data representing the money balance associated with the user account.

The object110may include data representing a size118which indicates the quantity of data stored at the object110. In this example, before the processed transactions114are removed from the object110, the size118indicates that the quantity of data stored at the object is 60 KB. In some implementations, the storage system102may determine the quantity of the data stored at the object110by adding the quantity of data stored at the processed transaction section112and the quantity of data stored at the other section116. In other implementations, the storage system102may determine the quantity of the data stored at the object110by adding the quantity of data stored at the processed transaction section112, the quantity of data stored at the other section116, and the quantity of data stored at any other sections of the object110.

The processed transaction section112may include data representing a size120which indicates the quantity of data stored at the processed transaction section112. In this example, before the processed transactions114are removed from the object110, the size120indicates that the quantity of data stored at the processed transaction section112is 56 KB.

The other section116may include data representing a size122which indicates the quantity of data stored at the other section116. In this example, before the processed transactions114are removed from the object110, the size122indicates that the quantity of data stored at the other section116is 4 KB.

In some implementations, the object110, or one or more sections of the object110(e.g., the processed transaction section112, and the other section116), may be associated with data storage size limitations. As described in more detail below, the storage system102may use the data storage size limitations to determine whether to perform an update process. In one example, the object110may have a data storage size limitation of 64 KB (not shown). In another example, the processed transaction section112may have a data storage size limitation (e.g., 50 KB).

The storage system102may reconfigure the data storage size limitations associated with the object110. For example, at a first point in time, the object110may be configured to store no more than 64 KB of data, and at a second point in time, the storage system102may increase the data storage size limitation of the object110such that the object may store no more than 100 KB of data. In another example, the storage system102may decrease the data storage size limitation of the object110such that the object may store no more than 40 KB of data. By enabling the data storage size limitations to be configurable, users (e.g., developers) may enforce specified data storage limitations for various reasons, such as maintaining consistent performance.

The storage system102may include one or more transaction datastores124comprising a data structure which is stored on one or more memory devices. In some implementations, the storage system102does not include the transaction datastore124, but rather the transaction datastore124is communicatively connected to the storage system102. As discussed in more detail below, to provide space in the object110, the storage system102may move the processed transactions114(1),114(2), . . .114(P) from the object110, and store the processed transactions114(1),114(2), . . .114(P) as historical transactions126(1),126(2), . . .126(L), respectively.

The transaction datastore124may include data representing a size128which indicates the quantity of data stored at the transaction datastore124. In this example, before the storage system102removes the processed transactions114(1),114(2), . . .114(P) from the object110, the size128indicates that the quantity of data stored at the transaction datastore124is 0 KB.

InFIG. 1, the storage system102receives input data130. The input data130may represent a new transaction comprising data representing units of data processing resulting from transaction requests. For example, the input data130may represent a deposit of money to a particular user account in response to a user requesting to deposit money in the user account. In another example, the input data130may represent a request to check a balance of the particular user account associated with the object110.

In some implementations, the storage system102receives the input data130from a system (e.g., a server) communicatively coupled using one or more networks. The network facilitating communication between the storage system102and the system may include a variety of networks, such as a local network, a wide area network (“WAN”), broadcast network, a personal area network, a wired and wireless local area network (“LAN”), and so forth. In some implementations, the network includes at least one of Ethernet, Wi-Fi™ as promulgated by the Wi-Fi Alliance, 3G and 4G, Bluetooth as promulgated by the Bluetooth Special Interest Group, and so forth. In some implementations, the devices and systems described herein are configured to directly connect to each other. The system may include additional servers which communicate with the storage system102.

The input data130may include data representing a size132which indicates the quantity of data stored by the input data130. In this example, the size132indicates that the quantity of data stored by the input data130is 8 KB.

InFIG. 1, the storage system102includes a processing module134which is configured to perform an update process. The update process may include various steps. For example, the update process may include moving the processed transactions114(1),114(2), . . .114(P) from the object110to the transaction datastore124, so that the input data130may be inserted into the object110as processed transaction114(3). In this example, the storage system102stores the processed transactions114(1),114(2), . . .114(P) at the transaction datastore124as historical transactions126(1),126(2), . . .126(L).

In some implementations, the storage system102performs the update process in response to a determination that the object110, or a section of the object110, includes a threshold amount of data. InFIG. 1, the storage system102may perform the update process if the object110were to include at least 64 KB of data if the input data130is inserted into the object110. For example, as shown inFIG. 1, the storage system102receives the input data130having a size132of 8 KB of data. The storage system102is configured to insert the input data130into the object110, however, the object110already has 60 KB of data. Because the object110has a size limit of 64 KB, the storage system102cannot store the input data130at the object110because if the input data130was stored in the object110before removing any of the processed transactions114, the object110would include 68 KB of data which is more than the 64 KB size limit. InFIG. 1, during the update process, the storage system102may remove the processed transactions114(1),114(2), . . .114(P) and store the processed transactions114(1),114(2), . . .114(P) as the historical transactions126(1),126(2), . . .126(L) at the transaction datastore124. In some implementations, the historical transactions126(1),126(2), . . .126(L) are copies of the processed transactions114(1),114(2), . . .114(P), respectively.

In some other implementations, the storage system102determines to perform the update process once the processed transaction section112includes the threshold amount of data, or once the other section116includes the threshold amount of data. In other implementations, the storage system102may perform the update process at one or more predetermined times. For example, the storage system102may be configured to perform the update process once every twelve hours.

Once the processed transactions114(1),114(2), . . .114(P) are removed from the object, the storage system102may store the input data130at the object110. As shown inFIG. 1, the storage system102stores the input data130at the object110as the processed transaction114(3).

InFIG. 1, after the storage system102removes the processed transactions114(1),114(2), . . .114(P) from the object110and inserts the input data130into the object110, the size118indicates that the quantity of data stored at the object is 12 KB. The size120indicates that the quantity of data stored at the processed transaction section112is 8 KB, the size122indicates that the quantity of data stored at the other section116is 4 KB, and the size128indicates that the quantity of data stored at the transaction datastore124is 56 KB.

InFIG. 1, the storage system102may insert the input data130into the object110contemporaneously with updating the value (e.g., the balance of a user account) which is associated with the processed transactions114(1),114(2), . . .114(P). The contemporaneous insertion and update may include both the insertion and the updating starting at or near the same time but not finishing at the same time, or both the insertion and updating starting at or near the same time and finishing at or near the same time. The contemporaneous insertion and update may allow for the input data130to be inserted and the particular value to be updated in an atomic fashion. That is, the insertion and update may each be committed, and if any issues occur during the contemporaneous insertion and update, the storage system102may perform a rollback function which returns the storage system102to a previous state and restores the storage system102such that any issues which may have occurred during the contemporaneous insertion and update do not affect the data stored at the object110.

FIG. 2is a block diagram200of the storage system102including the objects110(1),110(2), . . .110(X) which include transaction tables and balance tables. The storage system102may include at least one processor202configured to execute stored instructions. The at least one processor202may comprise one or more cores.

The storage system102includes at least one input/output (“I/O”) interface204which enables portions of the storage system102(e.g., the processor202) to communicate with other devices. The I/O interface204may include inter-integrated circuit (“I2C”), serial peripheral interface bus (“SPI”), Universal Serial Bus (“USB”), RS-232, and so forth. The at least one I/O interface204may be communicatively coupled to at least one I/O device206. In some implementations, certain I/O devices206are physically incorporated with the storage system102or externally placed.

The storage system102may include at least one communication interface208. The communication interface208may be configured to provide communications between the storage system102and other devices, such as routers, access points, other storage system102, and so forth. The communication interface208may connect to one or more networks. The storage system102may include at least one bus or other internal communications hardware or software that enables for the transfer of data between the various modules and components of the storage system102.

As illustrated inFIG. 2, the storage system102may include at least one memory210. The memory210may include at least one CRSM. The CRSM may include at least one of an electronic storage medium, a magnetic storage medium, an optical storage medium, a quantum storage medium, or a mechanical computer storage medium. The memory210may include computer readable instructions, data structures, program modules, and other data for the operation of the storage system102.

The memory210may include at least one operating system (“OS”) module212. The OS module212may be configured to manage hardware resources such as the I/O interface204, the I/O device206, the communication interface208, and provide various services to applications or modules executing on the processor202. The I/O device206may include at least one of a display device or speakers. The memory210may also store at least one of the following modules which may be executed as foreground applications, background tasks, or daemons.

In some implementations, the memory210stores a user interface module214configured to provide a user interface to a user using the I/O devices206and to accept inputs received from the I/O devices206. The user interface may include one or more visual, audible, or haptic elements. For example, the user interface may be configured to provide a graphic user interface, an audible user interface, and so forth. Also stored in the memory210may be the processing module134and other modules216.

As described above, the processing module134may be configured to perform the update process. In some implementations, the processing module134includes a move module218, an insert module220and a value update module222. The move module218may be configured to move one or more of the processed transactions114from a particular object110to the transaction datastore124. In some implementations, the move module218is configured to move the processed transactions114by copying the processed transactions114to generate copies of the processed transactions114, and storing the copies of the processed transactions at the transaction datastore124. In these implementations, after the move module218stores the copies of the processed transactions at the transaction datastore124, the move module218may be configured to remove the processed transactions114from the object110.

The insert module220may be configured to insert the input data130into the object110. In other words, the insert module220may be configured to store the input data130at the object110.

The value update module222may be configured to update the value located at the object110using the input data130. For example, the input data130may represent a credit of $100 to a user's money account which has a current balance of $200. In this example, the value update module222may update the $200 balance using the credit of $100, such that the money balance is updated to $300.

In some implementations, the memory210includes a datastore224for storing information. The datastore224may use a flat file, database, linked list, code, tree or other data structure to store the information. In some implementations, the datastore224, or a portion thereof, may be distributed across at least one other device, such as another storage system102, a server, a network storage device, and so forth. As illustrated inFIG. 2, the datastore224may include the objects110(1),110(2), . . .110(X) and the transaction datastore124.

InFIG. 2, the object110(1) includes data representing an object ID226which comprises data representing an identification of the object110(1). The objects110(1),110(2), . . .110(X) may include a unique object ID226which is used to identify the object110(1),110(2), . . .110(X).

In some implementations, the object110(1) may include the data representing the size118of the quantity of data stored at the object110(1). As discussed above, the storage system102may use the size118to determine whether to perform the update process.

The object110(1) may include the processed transaction section112. As shown inFIG. 2, the processed transaction section112may comprise one or more transaction tables228. Data stored in the transaction table228may be visualized as organized in columns and rows. In one implementation, a particular row of the transaction table228comprises a particular processed transaction114. Other examples of information in fields of data which may be included in the processed transaction section112are discussed in more detail below with regard toFIG. 3.

The processed transaction section112may include the data representing the size120which represents the quantity of data stored at the processed transaction section112. As discussed above, the storage system102may use the size120to determine whether to perform the update process.

The object110(1) may include the other section116. In one example, the other section116may comprise a balance table230. Data stored in the balance table230may be visualized as organized in columns and rows. In one implementation, a particular row of the balance table230comprises data representing the value which represents a particular balance. Other examples of information in fields of data which may be included in the balance table230are discussed in more detail below with regard toFIG. 3.

The other section116may include the data which represents the size122that indicates the quantity of data stored at the other section116. As discussed above, the storage system102may use the size120to determine whether to perform the update process.

As discussed above, the transaction datastore124may be configured to store the historical transactions126(1),126(2), . . .126(L). The transaction datastore124may comprise a data structure which is stored on one or more memory devices. In some implementations, the historical transactions126(1),126(2), . . .126(L) may be copies of the processed transactions114(1),114(2), . . .114(P), respectively. In some implementations, the historical transactions126(1),126(2), . . .126(L) may comprise the processed transactions114(1),114(2), . . .114(P) themselves, which have been moved from the object110to the transaction datastore124by the move module218.

FIG. 3illustrates examples of the transaction table228and the balance table230. The transaction table228includes data which may be characterized as being organized in columns and rows. The transaction table228may comprise information which includes the following fields: row name302; data type304; description306; and data308. In this implementation, the row name302includes data representative of a unique identifier associated with a particular row of the transaction table228. For example, inFIG. 3, the row names302of the transaction table228include: balance ID310; transaction ID312; running balance314; balance change316; and metadata318. The data type304may comprise data representative of the type of data that is stored at the data308. For example, the data type may comprise at least one of a string value, a number value, or a binary value. The description306may comprise data representing a description of the type of data stored by a particular row of the transaction table228. The data308may comprise values of the rows of the transaction table228.

The balance ID310may comprise data representing a unique identifier of the balance of a user account that is associated with a particular object110. InFIG. 3, the data308for the balance ID310includes the value “ASDF”, which is a unique identifier of the balance of a particular user account that is associated with the object110(1).

The transaction ID312may comprise data representing a unique identifier associated with a particular processed transaction114. InFIG. 3, the data308for the transaction ID312includes the value “QWE”, which represents a unique identifier of the transaction ID312.

The running balance314may comprise data representing a sum total of money that is present in the user account associated with the balance ID310. InFIG. 3, the data308for the running balance314includes the value “$150”, indicating that the sum total of money present for the user account is $150.

The balance change316may comprise data representing how much the balance has changed between designated processed transactions114or during a designated time period. InFIG. 3, the data308for the balance change316includes the value “$25”, indicating that the balance has increased $25 since the last processed transaction114.

The metadata318may comprise data associated with the processed transaction114. The value308for the metadata318includes the value “01001”. This value “01001” may represent various metadata. For example, the value “01001” may indicate a specific location of a merchant in which the last processed transaction114was conducted.

The balance table230may comprise information which includes the following fields: row name320; data type322; description324; and data326. The row name320may include data representative of a unique identifier associated with a particular row of the balance table230. For example, inFIG. 3, the row names320of the balance table230include: balance ID328; balance330; and balance version332. The data type322may comprise data representative of the type of data that is stored at the data326. For example, the data type322for the balance ID328is “String”, the data type322for the balance330is “Number”, and the data type322for the balance version332is “Number”.

The description324may comprise data representing a description of the type of data stored by a particular row of the balance table230. For example, the description324for the balance ID328includes “Identifier of the balance”, describing that the balance ID328includes a unique identification for the balance330. The description324for the balance330includes “Balance of the user account”, describing that the balance330represents the balance of money included in the user account. The description324for the balance version332includes “Value used for locking process”, describing that the balance version332represents a value that is used by the storage system102during a locking process such as the optimistic locking process described above.

The data326may comprise values of the rows of the balance table230. For example, the data326for the balance ID328is “ASDF”, the data326for the balance330is “$150”, and the data326for the balance version is332is “4”.

The balance ID310may comprise data representing a unique identifier of the balance of a user account that is associated with a particular object110. InFIG. 3, the information associated with the balance ID328is the same information associated with the balance ID310illustrated above at the transaction table228.

The balance330may comprise data representing an available amount of money in the user account that is available for immediate withdrawal. The balance version332may comprise data representing a version associated with the balance330. The balance version332may be used during the optimistic locking process described above.

FIG. 4illustrates certain objects110having a one-to-many relationship with certain historical transactions126. In this example, an object table402includes the objects110(1),110(2) and110(3) which are associated with a particular unique object ID226and a particular unique object name404. The object110(1) is associated with the object ID226having a value of “50”. The object110(1) is also associated with an object name404which provides a description of the object110(1). InFIG. 4, the object name404of the object110(1) includes “User 1 Balance”, indicating that the object110(1) is associated with a first user's account balance. In this example, the object110(2) is associated with the object ID226having a value of “60”. The object110(2) is also associated with the object name404“User 2 Balance”, indicating that the object110(2) is associated with a second user's account balance. In this example, the object110(3) is associated with the object ID226having a value of “70”. The object110(3) is also associated with the object name404“User 3 Balance”, indicating that the object110(3) is associated with a third user's account balance.

InFIG. 4, the transaction datastore124includes data which may be characterized as being organized in columns and rows. In this example, each row represents a particular historical transaction126. The transaction datastore124includes the historical transactions126(1),126(2),126(3),126(4),126(5), . . .126(L).

InFIG. 4, the historical transactions126(1),126(2),126(3),126(4),126(5), . . .126(L) are associated with the transaction ID312, the description406and the object ID226. The transaction ID312for the historical transaction126(1) has a unique identifier value of “RTC”. The description406for the historical transaction126(1) has a value of “Deposit—$100”, indicating that the storage system102deposited $100 into the user 1 balance associated with the object110(1) by referring to the object ID226of “50”.

The transaction ID312for the historical transaction126(2) has a unique identifier value of “KJD”. The description406for the historical transaction126(2) has a value of “Withdrawal—$20”, indicating that the storage system102withdrew $20 from the user 1 balance associated with the object110(1).

The transaction ID312for the historical transaction126(3) has a unique identifier value of “LHT”. The description406for the historical transaction126(3) has a value of “Withdrawal—$30”, indicating that the storage system102withdrew $30 from the user 1 balance associated with the object110(1).

The transaction ID312for the historical transaction126(4) has a value of “RPV”, which is a unique identifier for the historical transaction126(4). The description406for the historical transaction126(4) has a value of “Withdrawal—$40” indicating that the storage system102withdrew $40 from the user 2 balance associated with the object110(2).

The transaction ID312for the historical transaction126(5) has a value of “TYQ”, which is a unique identifier for the historical transaction126(5). The description406for the historical transaction126(5) has a value of “Deposit—$10” indicating that the storage system102deposited $10 into the user 2 balance associated with the object110(2)

The one-to-many-relationship between the object and the historical transactions may allow users (e.g., system administrators) to query the processed transactions114and the historical transactions126which are associated with a particular object110. InFIG. 4, the historical transactions126(1),126(2) and126(3) are associated with the object110(1) because the historical transactions126(1),126(2) and126(3) and the object110(1) include the same object ID226(i.e., “50”). The historical transactions126(4) and126(5) are associated with the object110(2) because the historical transactions126(4) and126(5) and the object110(2) include the same object ID226(i.e., “60”).

FIG. 5is a flow diagram500illustrating a process of determining a size associated with the object110and removing one or more processed transactions114in response to the size associated with the object110being equal to or greater than a threshold amount. Although the process500is described with reference to the flow diagram illustrated inFIG. 5, many other methods performing the acts associated with the process500may be used. For example, the order of many of the steps may be changed, some of the steps described may be optional, and additional steps may be included.

At block502, the storage system102accesses the input data130. The input data130may comprise a unit of data processing resulting from a transaction request. In one example, the input data130comprises data representative of: a first credit of money to a particular user account; or a first debit of money to the user account.

At block504, the storage system102determines a size associated with the object110, the object110including the processed transaction114and the value associated with the processed transaction114. The object110may comprise data stored at a location in memory210. The object110may include a first section including the processed transaction114, and a second section including the value associated with the processed transaction114. In one example, the processed transaction114comprises data representative of: a deposit of money to the user account; or a withdrawal of money to the user account. The storage system102may determine the size associated with the object110by adding amounts of data stored at different sections of the object110. The size associated with the object110may comprise data representing at least one of: the total size of the object (e.g., 60 KB); the size of the first section of the object (e.g., 40 KB); or the size of the second section of the object (e.g., 5 KB).

At decision diamond506, the storage system102determines whether the size is equal to or greater than a threshold amount. In some implementations, the threshold amount is configurable. For example, at a first point in time, the threshold amount may be 64 KB. At a second point in time, based on a user request, the threshold amount may be 100 KB.

At block508, the storage system102generates the historical transaction126based on the processed transaction114. In some implementations, the storage system102generates the historical transaction126by copying the processed transaction114. In other implementations, the historical transaction126is the processed transaction114, the difference being that the historical transaction126is stored at the transaction datastore124and the processed transaction114is stored at the object.

At block510, in response to the determination that the size is equal to or greater than the threshold amount, the storage system102stores the historical transaction126at the transaction datastore124. The transaction datastore124may be located within the storage system102. In some implementations, the storage system102is communicatively coupled to the transaction datastore124.

At block512, in response to the determination that the size is equal to or greater than the threshold amount, the storage system102removes the processed transaction114from the object110. In some implementations, the storage system102removes the processed transaction114by deleting the processed transaction114from the object110. The storage system102may be configured to remove the processed transaction114only after the processed transaction114is stored as the historical transaction126or copied into the transaction datastore124.

In some implementations, the storage system102may be configured to determine which processed transactions114to remove from the object. In one example, the storage system102determines to remove the oldest processed transactions114. In another example, the storage system102determines to remove the processed transactions114which are less frequently updated or processed when compared to the other processed transactions114in the object110.

At block514, after the processed transaction114is removed from the object110, or in response to the determination that size is less than the threshold amount, the storage system102inserts the input data130into the object110. In some implementations, the storage system102inserts the input data130by copying the input data130into the object110. The input data130may be inserted into the object110by saving the input data110at the object110.

At block516, using the input data130, the storage system102updates the value associated with the processed transaction114. In one example, the input data130represents a deposit of $100 into a particular user account which includes a balance of $300. In this example, using the deposit of $100, the storage system102updates the balance of $300 such that after the update the balance is $400. In this example, once the storage system102stores the input data130into the object110, the input data130becomes the processed transaction114.

In some implementations, using the input data130, the storage system102may update one or more historical transactions126. For example, a particular historical transaction126may include data representing a previous purchase of an item. The storage system102may remove the particular historical transaction126from the transaction datastore124and cause the object110to store the particular historical transaction126. Causing the object110to store the particular historical transaction126, may cause the storage system102to remove one or more processed transactions114from the object110and insert the removed processed transactions114into the transaction datastore124to make space for the particular historical transaction126. Once the object110stores the particular historical transaction126, the storage system102may update the particular historical transaction126using the input data130. The input data130may comprise data representing a refund of the purchase price associated with the particular historical transaction126. The storage system102may update the particular historical transaction126by updating the particular historical transaction126to include data representing that the purchase price associated with the particular historical transaction126has been refunded.

FIG. 6is a flow diagram illustrating a process600of generating a copy of the processed transaction114, and storing the copy of the processed transaction114at the transaction datastore124. Although the process600is described with reference to the flow diagram illustrated inFIG. 6, many other methods performing the acts associated with the process600may be used. For example, the order of many of the steps may be changed, some of the steps described may be optional, and additional steps may be included.

At block602, the storage system102accesses the input data130. In one example, the storage system102accesses the input data130from the memory210. At block604, the storage system102accesses the object110which is associated with a data storage size limit, the object110including the processed transaction114and the value associated with the processed transaction114. The data storage size limit may comprise data representing a data storage size limit of the object110, the transaction section112, or the other section116. As described above, the storage system102may use the data storage size limit to determine whether to perform the update process. In one example, the value associated with the processed transaction114comprises data representative of the balance330.

At block606, the storage system102generates a copy of the processed transaction114. The storage system102may generate the copy of the processed transaction114once the amount of data stored at the object110is equal to or greater than a predetermined threshold size. For example, the predetermined threshold size may be 60 KB. In this example, the storage system102generates the copy of the processed transaction114once the amount of data stored at the object is equal to or greater than 60 KB.

At block608, the storage system102stores the copy of the processed transaction114at the transaction datastore124. When the object110includes more than one processed transaction114, the storage system102may store copies of each of the processed transactions114at the transaction datastore124. The transaction datastore124may be located separate from the object110.

In some implementations, the storage system102stores the copy of the processed transaction114at a reliable or durable queue rather than the transaction datastore124. The reliable or durable queue may be described as a data structure used to transmit information to the transaction datastore124. The copy of the processed transaction114may be stored at the reliable or the durable queue because the transaction datastore124may be unavailable. After the copy of the processed transaction114is stored at the reliable or durable queue, at a later point in time, the copy of the processed transaction114may be moved to the transaction datastore124. Storing the copy of the processed transaction114at a reliable or durable queue may reduce the dependency on the availability of the transaction datastore124.

At block610, the storage system102removes the processed transaction114from the object110. In some implementations, the storage system102removes the processed transaction114from the object110after the copy of the processed transaction is stored at the transaction datastore124. The object110may include more than one processed transaction114, and the storage system102may be configured to remove each processed transaction114within the object110. The storage system102may be configured to remove the processed transaction114in response to the storage system102receiving the input data130.

At block612, the storage system102stores the input data130at the object110. The storage system102may store the input data130at the object110by inserting the input data130into the object110. At block614, using the input data130, the storage system102updates the value associated with the object110. For example, the input data130may represent a withdrawal of $50 from a user account having a balance of $300. In this example, the storage system102may use the withdrawal of $50 to update the balance, such that the balance is $250. In some implementations, the object110includes more than one balance table230each having different values associated with the object110. In these implementations, the storage system102may update the different values using the input data130.

In some implementations, the object110includes a first section storing the processed transaction114. In one example, the first section may include the transaction table228which includes a plurality of processed transactions114. In this example, the storage system102may generate copies of the processed transactions114, and store the copies of the processed transactions114at the transaction datastore124. After storing the copies of the processed transactions114at the transaction datastore124, the storage system102may remove the plurality of processed transactions114from the object110.

The object110may include a second section storing the value associated with the processed transaction114. In one example, the second section may include the balance table230which includes the value associated with the processed transaction114, data representative of the balance ID328, and data representative of the balance version332.

The storage system102may be configured to perform an optimistic locking process when the storage system102performs the update process. In one example, the optimistic locking process includes reading the balance version332which is associated with a particular object110when storing one or more processed transactions114at the transaction datastore124. In this example, the optimistic locking process also includes checking the balance version332before updating the value of the balance table230.

The storage system102may store the object110at one or more slave devices which are communicatively coupled to the storage system102. The one or more slave devices may be configured to synchronize to the storage system at predetermined time periods. For example, once a day at midnight local time the one or more slave devices may be configured to synchronize with the storage system102.

In some implementations, the update process comprises: accessing the object110associated with the data storage size limit; generating the copy of the processed transaction114; storing the copy of the processed transaction114at the transaction datastore124; removing the processed transaction114from the object110; storing the input data130at the processed transaction section114; and using the input data130, updating the value of the other section116of the of the object110. The update process may also include determining the size associated with the object110.

The storage system102may be configured to perform the update process based on various events. In one example, the storage system102performs the update process in response to the receiving the input data130. In another example, the storage system102performs the update process in response to a determination that the input data130has failed to be written to the object110.

Those having ordinary skill in the art will readily recognize that certain steps or operations illustrated in the figures above can be eliminated or taken in an alternate order. Moreover, the methods described above may be implemented as one or more software programs for a computer system and are encoded in a computer readable storage medium as instructions executable on one or more processors.

The computer readable storage medium can be any one of an electronic storage medium, a magnetic storage medium, an optical storage medium, a quantum storage medium and so forth. Separate instances of these programs can be executed on or distributed across separate computer systems. Thus, although certain steps have been described as being performed by certain devices, software programs, processes, or entities, this need not be the case and a variety of alternative implementations will be understood by those having ordinary skill in the art.

Additionally, those having ordinary skill in the art readily recognize that the techniques described above can be utilized in a variety of devices, environments and situations.

Although the present disclosure is written with respect to specific embodiments and implementations, various changes and modifications may be suggested to one skilled in the art and it is intended that the present disclosure encompass such changes and modifications that fall within the scope of the appended claims.