MySQL UC solid DB xact

50 %
50 %
Information about MySQL UC solid DB xact

Published on June 18, 2007

Author: Techy_Guy


Transaction Processing and Durability with solidDB for MySQLJan LindströmSenior R&D Engineer, Solid:  Transaction Processing and Durability with solidDB for MySQL Jan Lindström Senior Randamp;D Engineer, Solid Contents:  Contents Solid at a glance Transaction processing Different table types inside solidDB for MySQL Pessimistic tables Optimistic tables Multiversioning Durability Conclusions Solid At A Glance:  Solid At A Glance Business Category: Leading provider of fast, always-on and affordable database solutions for both OEM and Enterprise customers Technology Adoption: More than 3,000,000 Solid databases are deployed worldwide in communications networks, electronic devices, and enterprise applications Company Background: Founded 1992, Helsinki, Finland Technology enhanced over 12 years with €35M invested in Randamp;D Privately held Global Presence: Headquartered in Cupertino, CA USA Randamp;D in Helsinki, Finland, and Russia Sales offices across the USA, EMEA, China and Japan solidDB for MySQL:  solidDB for MySQL Built on MySQL, behaves like MySQL Designed for transactional applications Scales in multi-core/multiprocessor environments Includes online backup at no extra charge First product certified under MySQL Storage Engine Partner Program Slide5:  Solid at a glance Transaction processing Different table types inside solidDB for MySQL Pessimistic tables Optimistic tables Multiversioning Durability Conclusions Transaction processing:  Transaction processing A transaction is a logical unit of work It begins with the execution of a BEGIN transaction End with execution of a COMMIT or ROLLBACK Transaction processing schedules concurrent access to data so that each user can safely ignore the fact that others are accessing the data concurrently Transaction processing architecture:  Transaction processing architecture Transaction manager performs any required pre-processing of operations it receives from the transactions. Scheduler controls the relative order in which these operations are executed. Data manager operates directly on the database. Scheduler Transaction Manager Data Manager User thread DB Scheduler:  Scheduler A scheduler controls the concurrent execution of the transactions. It makes use of this control by deciding the order in which the data manager executes the reads, writes, commits, and aborts of different transactions. Scheduler is responsible for maintaining desired isolation level. Scheduler actions:  Scheduler actions Execute: scheduler passes the operation to the data manager (DM) and wait for a result. Reject: scheduler refuses to process the operation, in which case it tells the transaction that its operation has been rejected and transaction is aborted. Delay: scheduler delays the operation by placing it in a queue internal to the scheduler. Later, it can remove the operation from the queue and either execute it or reject it. Schedulers:  Schedulers Traditionally there are two kind of schedulers The pessimistic view that many transactions will conflict with each other The optimistic view that not too many transactions will conflict with each other. Pessimistic concurrency control is also known as ‘locking’ Locks are placed before any piece of the row is accessed. This is safe, conceptually simple approach. Optimistic concurrency control Synchronization of transactions is done in transaction termination Instead of locking every record the software looks for indications that two users actually did try to update the same record at the same time. If that evidence is found, then one user’s updates are discarded and transaction is rolled back. Transaction processing and MySQL:  Handler Transaction processing and MySQL Handlerton contains transaction interface Handler contains table interface Transaction processing is shared between handlerton and storage engine Handlerton Storage engine Slide12:  Solid at a glance Transaction processing Different table types inside solidDB for MySQL Pessimistic tables Optimistic tables Multiversioning Durability Conclusions Transaction processing on solidDB for MySQL:  Transaction processing on solidDB for MySQL solidDB for MySQL offers two different types of concurrency control mechanisms Pessimistic Optimistic Concurrency control can be selected per-table using a table type. Table type used when user does not explicitly define table type is based on configuration variable soliddb_pessimistic. Pessimistic tables are default by April release (earlier optimistic tables were default). Features for both table types:  Features for both table types Non-blocking consistent reads No locks taken for read-only selects Lock taken in pessimistic mode for select ... for update; Current release of solidDB forMySQL does not support select ... in share mode. Deferred constraint checking Unique constraint check Foreign key constraint check Check constraint check Disadvantages of pessimistic tables:  Disadvantages of pessimistic tables Unpredictable lock wait time Possibility of deadlocks Requires overhead taking a lock for every database operation whether or not two or more users are actually trying to access the same record and this has a penalty on performance. Disadvantages of optimistic tables:  Disadvantages of optimistic tables Incorrect execution order leads transaction rollback (because execution order does not obey isolation level). This rollback has penalty to performance because updates done by the transaction must be rolled back. When to use Optimistic/Pessimistic:  When to use Optimistic/Pessimistic Shortly, if you expect having many simultaneous conflicting writes (inserts/deletes/updates), pessimistic gives better performance. This is because optimistic allows those conflicting transactions to proceed 'too far'. Then, when transaction has done all what it was supposed to, it is aborted. With pessimistic, conflicting transactions are not allowed to produce conflicts. Instead, the operations they include, are ordered by the engine in a way that they will be executed successfully. This results in better transaction throughput. Small database andamp; lots of updates -andgt; lots of conflicts -andgt; choose pessimistic. Large database andamp; less updates -andgt; not many conflicting operations -andgt; choose optimistic. Implementing optimistic concurrency control:  Implementing optimistic concurrency control Each time that the server reads a record to try to update it, the server makes a copy of the version number of the record and stores that copy for later reference. When it's time to write the updated record back to the database, the server compares the original version number that it read with the version number that the database now contains. If the versions are the same then no one else has changed the record and we can write the updated record. If the versions differ then someone has changed the record and we must discard our version of the data and give user the error. Example of pessimistic table:  Example of pessimistic table create table t0(a int not null, primary key(a)) engine=soliddb comment=’MODE=PESSIMISTIC’; Insert into t0 values (0),(1),(2),(3),(4); commit; /* In session 1 */ begin; update t0 set a = 5 where a = 2; /* in session 2 */ begin; Update t0 set a = 7 where a = 2; // waits for session1 Example of optimistic table:  Example of optimistic table create table t0(a int not null, primary key(a)) engine=soliddb comment=’MODE=OPTIMISTIC’; Insert into t0 values (0),(1),(2),(3),(4); commit; /* In session 1 */ begin; update t0 set a = 5 where a = 2; /* in session 2 */ begin; update t0 set a = 7 where a = 2; ERROR 1205 (HY000): Lock wait timeout exceeded... Deferred unique constraint checking:  Deferred unique constraint checking create table t0(a int not null, primary key(a)) engine=soliddb; insert into t0 values (0),(1),(2); commit; update t0 set a = a + 1; /* success !*/ select * from t0; +---+ | a | +---+ | 1 | | 2 | | 3 | +---+ How update is implemented?:  How update is implemented? ::rnd_init(t0) ::rnd_next(t0) == (0) 0 +1 = 1 ::update_row(0, 1) ::rnd_next(t0) == (1) 1 +1 = 2 ::update_row(1,2) ::rnd_next(t0) == (2) 2 + 1 = 3 ::update_row(2,3) statement commit (at this stage there is no duplicate keys in the primary key, thus success ! ) More complicated example:  More complicated example create table t0(a int not null, b int, primary key(a)) engine=soliddb; insert into t0 values (1,1),(2,2),(3,3),(4,4); update t0 set a = 3 - a; select * from t0; +----+------+ | a | b | +----+------+ | -1 | 4 | | 0 | 3 | | 1 | 2 | | 2 | 1 | +----+------+ Slide24:  Solid at a glance Transaction processing Different table types inside solidDB for MySQL Pessimistic tables Optimistic tables Multiversioning Durability Conclusions Multiversioning:  Multiversioning Implemented in solidDB for MySQL with a feature called Bonsai Tree Bonsai Tree is comprised of recently written data interrelated by the transactions structures that they were processed with Bonsai Tree is a part of a two-level internal structure, where Bonsai Tree is a 'differential index'. The other part is a traditional disk-optimized index called the Storage Tree. Both parts are based on the B+ tree concept Bonsai Tree and multiversioning:  Bonsai Tree and multiversioning Any time new data is written, a new version is created in the Bonsai Tree This is the cornerstone of Solid's multi-version concurrency control (MVCC) All new data written by a transaction is given a version number called 'read level'. The name has to do with the fact that, when other transactions start to read that data, they operate at a given read level and may be guaranteed a consistent data snapshot, regardless of what happens to that data later on Multiple versions are maintained in the Bonsai Tree only Older versions:  Older versions Older versions are maintained for as long as they are needed by other transactions. That depends on the isolation levels used. The outdated versions are purged by a background thread. Over time, hot spot data is efficiently stored in memory by collecting only the rows that are frequently written. If a transaction is rolled back, the given read level is simply discarded. Thus, the Bonsai Tree serves as an undo log, and the rollback operation is extremely light-weight. Committed versions:  Committed versions The committed versions are migrated to the Storage Tree when they are not needed any more. This activity is called 'Bonsai Tree merge' and is performed by a background thread. In terms of page management policy, this is often called No-Steal, as the data page migration to disk lags behind the transactions that are written to the log. It might happen that the Bonsai Tree grows too large because of some irregularity like long-running transactions of high isolation level. In that case, the Bonsai Tree is swapped (by pages) to the disk. Slide29:  Solid at a glance Transaction processing Different table types inside solidDB for MySQL Pessimistic tables Optimistic tables Multiversioning Durability Conclusions Durability:  Durability Normally, when a transaction is committed, the database server writes data to two locations: the database file and the transaction log file However, the data are not necessarily written to those two locations concurrently (and in an atomic way) Thus, when a transaction is committed, the server writes the data to the transaction log file immediately. But, this data is not written to the database file immediately The server may wait until it is less busy, or until it has accumulated multiple changes, before writing data to the database file Durability levels:  Durability levels Strict durability Data is written to the disk drive before user is told that his data has been committed Relaxed durability User may be told that the data has been committed even before the data has been written to the transaction log on disk. Server may group several transactions to one log write This increases the performance but you risk losing some data if the server shuts down abnormally after it has committed some data but before it has written those data to the transaction log Thus, you should use relaxed durability only when you can afford to lose a small amount of recent data Relaxed durability:  Relaxed durability Can be used if you can afford to lose a small amount of recent data and if performance is crucial to you. Relaxed durability is appropriate when each individual transaction is not crucial. For example monitoring systems where you want to store data while monitoring the system. You may be interested in average values which will not be significantly affected if you are missing a few pieces of data. Database consistency is maintained also in relaxed durability. Slide33:  Solid at a glance Transaction processing Different table types inside solidDB for MySQL Pessimistic tables Optimistic tables Multiversioning Durability Conclusions Conclusions:  Conclusions solidDB for MySQL is the first storage engine offering both optimistic and pessimistic concurrency control methods. Transactions can access both pessimistic and optimistic tables. solidDB for MySQL supports deferred constraint checking. Multiversioning decreases effect of concurrent access to the same data. Bonsai Tree is useful because maintaining version information in main-memory is better for performance. Choice of durability allows you to take advantage of application semantics. How to Learn More:  How to Learn More Visit Solid in Booth # 401 3 different demos of solidDB for MySQL 'Meet the Experts' Sessions Job board sponsored by Proven Scaling Hear Solid in these Sessions Strengthening High Availability in MySQL Tuesday, April 24; 10:45AM - 11:45AM; Ballroom G Keynote: Battle of the Database Egos (panel session) Wednesday, April 25; 9:05AM - 9:50AM; Main Ballroom Transaction Processing and Durability with solidDB for MySQL Wednesday, April 25; 1:40PM - 2:35PM; Ballroom F Lightening Rounds: State of the Partner Engines (panel session) Thursday, April 26; 10:45AM - 11:45AM; Ballroom G solidDB Storage Engines Thursday, April 26; 2:35PM; - 3:20; Ballroom G Q & A:  Q andamp; A Thank You:  Thank You

Add a comment

Related presentations

Related pages

solidDB for MySQL download |

solidDB for MySQL download. solidDB for MySQL 2012 ... MySQL Plugin based on the Solid ... Optimizations being added/fixed such as exact ...
Read more


La Base de Données Open Source la plus ... SERNAV Group Dispatches Containers with MySQL Enterprise ... AVST UC Solutions Provide High ...
Read more

IBM - solidDB Divesture Exit - IBM - United States

IBM solidDB Divestiture. Notice: You are now leaving the IBM Web site, ...
Read more

MySQL Lists: mysql: where is my data?

This might be coz I ran mysql_install_db ... /var/lib/mysql/www.eh3.uc ... I will really appreciate if someone could just point out the exact problem ...
Read more

MySQL :: MySQL 5.7 Reference Manual :: 3.3.1 Creating and ...

... as shown in the example. Alternatively, you can select the database on the command line when you invoke mysql. Just ...
Read more

PHP: mysqli::query - Manual - PHP: Hypertext Preprocessor

The exact type returned by a successful query is mysqli_result. up. ... or die ('Error connecting to mysql: ' . mysqli_error ... mysqli_select_db ($link ...
Read more

mysql - SSD vs HDD for databases - Database Administrators ...

I am trying to purchase a new Server to run MySQL Server on. ... SSD vs HDD for databases. ... The exact amount of memory you need won't be immediately ...
Read more

MySQL :: Why MySQL?

Top Reasons to Use MySQL; ISV/OEM Corner; ... AVST UC Solutions Provide ... Symantec Benefits from MySQL Embedded Server's Rock-Solid Quality and Low ...
Read more