Press enter to see results or esc to cancel.

[Note] MySQL Architecture and Concepts

MySQL’s Logical Architecture

The topmost layer contains the services that aren’t unique to MySQL. They’re services most network-based client/server tools or servers need: connection handling, authentication, security, and so forth.

The second layer is where things get interesting. Much of MySQL’s brains are here, including  the  code  for  query parsing,  analysis,  optimization,  caching,  and  all  the built-in functions (e.g., dates, times, math, and encryption). Any functionality provided across storage engines lives at this level: stored procedures, triggers, and views, for example.

The  third  layer  contains  the  storage  engines.  They  are  responsible  for  storing  and retrieving all data stored “in” MySQL

logical_mysql_architecture
logical_mysql_architecture

Connection Management and Security

Each client connection gets its own thread within the server process. The connection’s queries execute within that single thread, which in turn resides on one core or CPU. The server caches threads, so they don’t need to be created and destroyed for each new connection. X.509 certificates can also be used across an SSL (Secure Sockets Layer) connection.

Optimization and Execution

MySQL parses queries to create an internal structure (the parse tree), and then applies a variety of optimizations. These can include rewriting the query, determining the order in which it will read tables, choosing which indexes to use, and so on.

Before even parsing the query, though, the server consults the query cache, which can store only SELECT statements, along with their result sets. If anyone issues a query that’s identical to one already in the cache, the server doesn’t need to parse, optimize, or execute the query at all—it can simply pass back the stored result set.

Concurrency Control

Một phương pháp để đảm bảo tính khả tuần tự là yêu cầu việc truy xuất đến hạng mục dữ liệu được tiến hành theo kiểu loại trừ tương hỗ, có nghĩa là trong khi một giao dịch đang truy xuất một hạng mục dữ liệu, không một giao dịch nào khác có thể sửa đổi hạng mục này.

Lock Granularity (Table locks & Row locks)

Trong phần này mình sẽ giới thiệu đến các bạn một số phương pháp xử lý tranh chấp khi có 2 hay nhiều transaction đang truy xuất đồng thời trên 1 đơn vị dữ liệu.

  • Tại sao lại cần các phương thức khóa? 

Giả sử có 2 transaction đang truy xuất đồng thời trên 1 đơn vị dữ liệu. Có tất cả 4 trường hợp sau:

Trong connection C1 có một transaction như sau:

Trong connection C2 có transaction như sau:

Nhận xét

Đọc

Đọc

Không có tranh chấp

Đọc

Ghi

Xảy ra tranh chấp

Ghi

Đọc

Xảy ra tranh chấp

Ghi

Ghi

HQT chỉ cho phép có đúng 1 transaction được ghi trên đơn vị dữ liệu tại một thời điểm.

Như vậy khi có 2 transaction (của 2 connection khác nhau) có ít nhất 1 thao tác ghi trên cùng một đơn vị dữ liệu sẽ xảy ra tình trạng tranh chấp. Nếu để tình trạng tranh chấp này xảy ra sẽ dẫn đến những sai sót trên CSDL. Để giải quyết các vấn đề tranh chấp nêu trên, hệ quản trị cơ sở dữ liệu cần sử dụng các phương thức khóa, nhờ vậy mà khi có tranh chấp xảy ra hệ quản trị cơ sở dữ liệu có thể quyết định transaction nào được thực hiện và transaction nào phải chờ.

Trong môi trường truy xuất đồng thời, có thể xảy ra một số vấn đề như sau:

  • Mất dữ liệu cập nhật (lost update): Tình trạng này xảy ra khi có nhiều hơn một giao tác cùng thực hiện cập nhật trên 1 đơn vị dữ liệu. Khi đó, tác dụng của giao tác cập nhật thực hiện sau sẽ đè lên tác dụng của thao tác cập nhật trước.
  • Đọc dữ liệu chưa commit (Uncommitted data, Dirty read) :Xảy ra khi một giao tác thực hiện đọc trên một đơn vị dữ liệu mà đơn vị dữ liệu này đang bị cập nhật bởi một giao tác khác nhưng việc cập nhật chưa được xác nhận.
  • Giao tác đọc không thể lặp lại (Unrepeatable data) : Tình trạng này xảy ra khi một giao tác T1 vừa thực hiện xong thao tác đọc trên một đơn vị dữ liệu (nhưng chưa commit) thì giao tác khác (T2) lại thay đổi (ghi) trên đơn vị dữ liệu này. Điều này làm cho lần đọc sau đó của T1 không còn nhìn thấy dữ liệu ban đầu nữa.
  • Bóng ma (Phantom):Là tình trạng mà một giao tác đang thao tác trên một tập dữ liệu nhưng giao tác khác lại chèn thêm các dòng dữ liệu vào tập dữ liệu mà giao tác kia quan tâm.

Table Lock: The most basic locking strategy available in MySQL, and the one with the lowest overhead, is table locks. Although storage engines can manage their own locks, MySQL itself also uses a variety of locks that are effectively table-level for various purpose. For instance, the server uses a table-level lock for statements such as ALTER TABLE, regardless of the storage engine.

Row Lock: Row locks are implemented in the storage engine, not the server. The server is completely unaware of locks implemented in the storage engines, and the storage engines all implement locking in their own ways.


Pages:   1 2 3 4
Comments

Leave a Comment