Base: An Acid-replacing solution

Original link: Base:an Acid alternative
PDF download Link: Base

Database ACID, are not unfamiliar: atomicity, consistency, isolation and durability, which can be done in a single server era, it is easy to achieve, but now, in the face of such a huge amount of traffic and data, a single server is impossible to adapt, and ACID in the cluster environment, almost impossible to achieve our expectations, To ensure the ACID, efficiency will be greatly reduced, and, more importantly, so high requirements, bad expansion ~ then the CAP principle (consistency (consistency), availability (availability), Partition tolerance (partition fault tolerance)) and Base principles (basically Available (basic available), Soft State (soft), eventually consistent (final), see them in English, availability/basically Available,consistency/eventually consistent, basically, the BASE principle further interprets the CAP principle.

This article is an article published by the ebay architect in 2008 to ACM, a classic article explaining the base principle, or eventual consistency. In this article, Dan discusses the fundamental differences between the base and acid principles and how to design large Web sites to meet growing scalability requirements, and how to adjust and compromise the business during the period. And the introduction of some specific compromise techniques.

After partitioning the database, sacrificing partial consistency (consistency) for usability (availability) can significantly increase the scalability of the system (Scalability).

--by DAN PRITCHETT, EBAY, translated by Jametong

Web applications have become increasingly popular over the last 10 years. Whether it's for end users or app developers, it's likely that this app will be used by the widest range of users-with a wide range of uses that can lead to increased trading. If a business relies on persistence, data storage is likely to be a bottleneck.

There are two strategies for extending any application. The first and simplest of these is vertical scaling : Migrating applications to larger and stronger computers. The largest machine available today can not meet its capacity is the most obvious limitation. Vertical expansion is also expensive, and increasing trading capacity usually requires buying the next larger machine. Vertical scaling also typically results in a dependency on the vendor, which further increases costs.

Horizontal Scaling (horizontal Scaling) provides more flexibility, but also significantly increases complexity. Horizontal data expansion may evolve in two directions. Scaling by Function (functional scaling) involves grouping data by function, Different functional groups are distributed across multiple databases. Splits data across multiple databases within a feature, which is a shard (sharding), which adds a new dimension to scale-out. Figure 1 briefly illustrates the horizontal data extension strategy.

Figure 1

1, the two methods of scale-out can be applied simultaneously. User information (users), product information (products) and transaction information (transactions) can be stored in different databases. In addition, each functional area is based on its trading capacity ( Transactional capacity) can be split into multiple databases. Functional areas can be expanded independently of each other.

Functional partitioning (functional partitioning)

Functional partitioning is important for achieving high scalability. Each good database schema breaks down the profile (schema) into multiple tables based on functionality. The user (users), products, transactions (transactions), and communications are all examples of functional partitioning. A common approach is to use database concepts such as foreign key (foreign key) to maintain data consistency between these functional areas.

Database-dependent constraints guarantee consistency among functional groups, resulting in a highly coupled database profile (schema) on the deployment strategy. To support constraints, the table must exist on a single database server when the transaction rate (transaction) Growth cannot scale horizontally. In many cases, migrating different functional groups of data to separate database servers is the easiest to implement scale-out (scale-out) scenario.

An overview that scales to very high volumes will place data for different functions on different database servers. This requires migrating the constraints between data from the database to the application. This will also introduce some new challenges, which will be explored in further detail in this article.

Cap theorem (Cap theorem)

Eric Brewer, a professor at the University of California, Berkeley, co-founder and chief scientist of Inktomi, made the following speculation that Web services could not meet the following 3 attributes at the same time (consisting of the initials of the acronym CAP):

• Consistency (consistency). The client knows that a series of operations will occur simultaneously (in effect).
• Availability (availability). Each operation must end with an expected response.
• Partition fault tolerance (Partition tolerance). The operation can still be completed even if a single component is unavailable.

Specifically, in any database design, a web app can support up to two properties at a time. Obviously, any scale-out strategy relies on data partitioning, so designers must choose between consistency and availability.

Acid Solutions

Acid database transactions greatly simplifies the work of application developers. As its initials indicate, the ACID transaction provides the following guarantees:

• atomicity (atomicity). All operations in a transaction are either successful or not.
• Consistency (consistency). At the beginning and end of the transaction, the database is in a consistent state.
• Isolation (Isolation). The transaction is just like this one operation is performed by the database.
• persistence (Durability). This operation will be irreversible at the end of the transaction. (That is, as long as the transaction commits, the system will ensure that the data is not lost, even if the system crash, the translator added).

Database vendors have long recognized the need for database partitioning and introduced a technology called 2PC (two-phase commit) to provide acid assurance across multiple DB instances. This agreement is divided into the following two phases:

• In the first phase, the transaction Coordinator requires a database pre-commit (Precommit) for each transaction involved, and reflects whether it can be committed.
• In the second phase, the transaction coordinator requires each database to submit data.

If any database rejects this commit, then all databases are required to roll back the part of their information in this transaction. What is the flaw in this? We can get consistency between partitions. If Brewer's guess is right, then we'll definitely affect usability, but how can that be?

The availability of any system is the product of the availability of the related components that perform the operation. The second half of this statement is particularly important. Components that may be used but not required in the system will not degrade the system's availability. Transactions involving two databases in a two-phase commit Its usability is the product of the availability of each of these two databases. For example, if we assume that each database has 99.9% availability, then the availability of this transaction is 99.8%, or 43 minutes of additional downtime per month.

For the two-phase commit, you can look at the "Change the future of the nine algorithms", there is an incisive explanation ~

An acid-replacement solution

If acid is a partitioned database that provides a consistent choice, how do you achieve availability? The answer is base (basically available, soft (weak) state, final consistency).
Base is the opposite of acid. Acid is pessimistic, forcing consistency at the end of each operation, while base is optimistic that accepting database consistency is in a volatile state. Although, it sounds difficult to cope with, in fact it's quite good to manage, And can bring a higher level of scalability that acid cannot reach.

Base availability is achieved by supporting local failures rather than system global failures. Here is a simple example: if the user partitions on 5 database servers, the base design encourages similar processing, so that a failure of a user database will only affect the 20% on this particular host User. There is no magic involved here, but it does bring a higher level of perceived system availability.

So, so far, you've decomposed the data into multiple functional groups and partitioned the busiest feature groups into multiple databases, how do you apply the base principle to your application? Compared to the typical application scenarios of acid, Base requires a more in-depth analysis of the operations in the logical transaction. How do you analyze it? The following sections will provide some guidelines.

Consistency mode (consistency Patterns)

Along Brewer's speculation, if base chooses to retain availability (availability) in the partitioned database, weakening a certain degree of consistency becomes an inevitable choice. This is often difficult to make because business investors and developers tend to think of consistency (consistency ) is critical to the success of your application. Even temporary inconsistencies can be kept from the end user, so both the technical and product sectors need to be involved in deciding how to weaken consistency.

Figure 2 is a simple summary that illustrates what consistency in base is about. user Tables store user information, along with total sales and total purchases. These are statistics at run time. The trading table stores each transaction, and the buyer, The seller and the transaction amount are linked together. These are the results of an over-simplification of the tables that are actually used, but it already contains the necessary elements to illustrate several aspects of consistency.

Figure 2

In general, the consistency between functional groups is much more likely to weaken than the consistency within the functional group. This sample summary contains two functional groups: User and transaction. Whenever an item is sold, a record is added to the transaction table, and the counter for both the buyer and the seller is updated. Use acid-style transactions, The SQL statement can be as follows-3.

Figure 3

The column of total sales in the user table and the column of total purchase amount can be considered as a cache of the transaction table. It exists to improve the efficiency of the system. In view of this, consistency constraints can be weakened. You can adjust the expectations of buyers and sellers so that their running balances (running balance) do not immediately reflect the results of the transaction. This is common, and in fact, people often encounter this delay between trading and running balances (for example, ATM withdrawals or cell phone calls).

How to modify SQL statements to weaken consistency depends on how the running balances are defined, and if they are simply estimates, that is, some transactions can be missed without statistics, the SQL changes are very simple, as shown in 4.

Figure 4

We are now decoupling the user table from the update of the transaction table. Consistency between the two tables will no longer be guaranteed. In fact, the failure of the first transaction with the second transaction interval will cause the user table to persist in an inconsistent state, but if the contract is run-time rollup (running total is an estimate, this is enough.

What if an estimate cannot be accepted? How do I continue to decouple the update of the user table from the transaction table? A persistent message queue is introduced to resolve this issue. There are a number of options to implement persistent messages. However, the most critical factor in implementing this message queue is to ensure that the queue's persistence supports the same resources as the database. It is necessary to implement a queue that commits by transaction without involving 2PC. Now the SQL operation looks a little different,-5 shows.

Figure 5

The syntax in this example is a bit arbitrary, and the logic has been simplified to illustrate the concept. By queuing persistent messages in the same transaction in the INSERT statement, you can crawl the information that is required to update the user's running balance. This transaction is contained in the same database instance, so it does not affect the availability of the system.

A stand-alone message processing component that extracts each message from the queue and applies this information to the user table. This example seems to solve all the problems, but there is still one problem that is not solved. In order to avoid 2PC in the queue, The message is persisted on the host of the transaction. If you remove a message from a queue in a transaction that involves a user's host, we will still encounter a 2PC scenario.

A solution for 2PC in the message processing component is to do nothing. The availability of client-facing components can be maintained by decoupling the update operation into a separate back-end (back-end) component. Business needs may be acceptable for lower message processor availability.

However, suppose your system is completely unacceptable to 2PC. How to solve this problem? First, you need to understand the idempotent concept. If an operation is applied once or multiple times to achieve the same result, it is considered to be idempotent. Idempotent operations are useful because they allow for local failures, Executing them repeatedly does not change the final state of the system.

From an idempotent point of view, the selected example is problematic. The update operation is usually unequal to a power. This example has an operation that adds an account column. Repeating this operation will obviously result in an incorrect account balance. However, even if the update operation that only sets a value is not idempotent, Because it also involves the order in which the operations are executed. If the system cannot guarantee that the update operation is applied in the order received, the final state of the system will also be incorrect. This issue is discussed further in the following sections.

In the account update example, you need a way to track which updates have been successfully applied and which ones are still unresolved. One technique is to use a table to record the unique identification number of those transactions that have been applied.

The table shown in Figure 6 records the transaction ID, which account was updated, and the user ID that applied the account. Now, our sample pseudo code-7 shows.

Figure 6

Figure 7

This example depends on the ability to peek at a message in the queue and delete the message as soon as it is successfully processed. If necessary, it can be handled by two separate transactions: the previous transaction on the message queue, the previous transaction in the user database. The database operation was submitted successfully before the queue operation was submitted. The current algorithm can support local failures, It can also provide guaranteed transactions that do not depend on 2PC.

If you are just looking at the order of updates, there is a simpler technique to ensure idempotent updates. Let's tweak our sample summary to illustrate the challenges and the corresponding solutions (see Figure 8).

Figure 8

Assuming that two purchase transactions occur within a short window of time, our messaging system is unable to ensure sequential operation. The situation you are facing now is that depending on the order in which the messages are processed, last_purchase may have an incorrect value. Fortunately, You can solve this kind of update problem by making some simple adjustments to the SQL statement, as described in 9.

Figure 9

Simply by not allowing the last_purchase time to do the reverse adjustment, you can do the update operation sequence is irrelevant. You can also use this method to protect any updates from an out-of-order update (Out-of-order update). You can also try to replace the time with a monotonically increasing transaction ID.

Order of Message queues

For sequential message posting, this brief, subsidiary note may be useful. The messaging system can provide the ability to ensure that the message is sent in the same order as it was received. However, support for this feature can be expensive, often unnecessary, and in fact, sometimes it just gives a false sense of security.

The examples provided here illustrate how to weaken the order of messages and ultimately still provide a consistent view of the database. The overhead required to weaken message ordering is nominally, and in most cases, this overhead is significantly less than the overhead of ensuring message order in the messaging system.

Further, Web applications are semantically an event-driven system, regardless of the interaction style. Client requests reach the system in any order. The processing time requirements required for each request are also different. The request scheduling of different components of the whole system is also indeterminate, resulting in the uncertainty of Message Queuing. The order in which messages are kept is a false sense of security. The simple fact is that an indeterminate input results in an indeterminate output.

Weak state/FINAL consistency (Soft state/eventually consistent)

To this end, the focus has been on the tradeoff between sacrificing partial consistency for usability. The other side of the coin is understanding how soft states and eventual consistency affect the design of the application.
Because software engineers tend to think of the system as a closed loop (closed loop). We can think of the predictability of their behavior in this way from anticipating inputs to produce predictable outputs. This is essential for creating the right software system. The good news is, Using base in most cases does not change the predictability of a closed-loop system, but it does need to be looked at as a whole.

A simple example can help explain this. Consider a system where users can transfer assets to another user. What type of asset is not related, it can be money or in-game equipment. For this example, we assume that a message queue has been used for decoupling, Learn about the following two operations: remove an asset from one user and assign the asset to another user.

Soon, the system will feel the problem and uncertainty. There is a period of delay between an asset leaving one user and reaching another. The size of this time window is determined by the design of the messaging system. In any case, there will always be a time interval between the start and end states, and during that time, it appears that no user is entitled to this asset.

However, if we consider this issue from a user's perspective, this interval may be irrelevant or nonexistent at all. Neither the receiving user nor the issuing user may know when the asset will arrive. If the time interval between sending and receiving is a few seconds, for a specific communication asset transfer It will be concealed or indeed tolerable. In this situation, this system behavior is consistent and acceptable to the user, even though we rely on the soft state and eventual consistency in the implementation.

Event-Driven Architecture (Event-driven Architecture)

If you do need to know, when will the system reach a consistent state? You may need an algorithm to apply to this state, but it will only be applied if it reaches a consistent state associated with subsequent requests.

Continue to discuss the previous example, what if you need to notify the user when the asset arrives? Creating an event within the transaction that delivers the asset to the receiving user can provide a mechanism for further processing when a predetermined state is reached. EDA (event-driven architecture, Event-driven Architecture) can significantly improve scalability and decoupling of architectures. Further discussion of EDA applications is beyond the scope of this article.

Conclusion

Significantly expanding the trading rate of the system requires a new way to consider how to manage resources. Traditional transaction models are riddled with holes when the load needs to be distributed across a large number of components. Decoupling operations and processing them in turn may provide better usability and scalability, but at the expense of consistency . Base provides a model to consider this decoupling.

Reference

• Http://highscalability.com/unorthodox-approach-database-design-coming-shard.
• Http://citeseer.ist.psu.edu/544596.html.

Dan Pritchett, a technician at ebay, has been a member of the ebay architecture team for the past 4 years. In this role, he works with ebay marketing, PayPal and Skype's strategic, business, product and technology teams. He has 20 years of experience in technology companies, The company he served includes sun,hp and Silicon Valley graphics (Silicon graphics), Pritchett has a wealth of technical experience, from network layer protocols and operating systems to system design and software models. He holds a Bachelor of Science degree in computer sciences from Missouri State Rolla University.

Base: An Acid-replacing solution