Chuyện của dev's blog

Hệ thống Tiki 3 năm trước như thế nào - P3 - Tập 1

 06/07/2018  3445

Sau Phần 2 được khá nhiều bạn bè, đồng nghiệp và gia đình quan tâm, nay mình xin chia sẻ đến các bạn phần 3 của loạt bài "Hệ thống Tiki 3 năm trước như thế nào".
Nhưng phần 3 này gồm nhiều tập, chủ yếu nói về MySQL để giúp các bạn có cái nhìn sâu và cơ bản nhất để có thể tối ưu Database 1 cách hợp lý nhất.

MySQL’s Architecture

MySQL gồm 3 lớp chính:

  • Lớp đầu tiên chịu trách nhiệm xử lý các vấn đề liên quan đến kết nối, xác thực, bảo mật
  • Lớp thứ 2 rất quan trọng vì nó bao gồm các chức năng chính như: phân tích câu SQL, tối ưu, caching và tất cả các hàm chức năng liên quan đến Datetime, Math, Stored procedures, Triggers, Views...
  • Lớp thứ 3 là nơi của các "Storage Engine", cung cấp các API cho lớp thứ 2 sử dụng
    (Các bạn có thể tham khảo thêm tại link https://www.sisense.com/blog/beginners-guide-to-mysql-storage-engines)

Hard disk (HDD not SSD)

Database cần một nơi để lưu trữ dữ liệu an toàn kể cả khi khởi động lại server, vì vậy Hard disk được sử dụng cho việc lưu trữ này.

Nhìn hình trên thì các bạn có thể thấy Hard disk gồm có 1 trục (Spindle), trên đó gắn nhiều đĩa (Platter).
Mỗi đĩa như vậy được chia thành nhiều vòng tròn gọi là Track, trên từng Track sẽ được chia thành nhiều ô nhỏ là Sector (chính là nơi chứa dữ liệu của các bạn).
Bên cạnh đó còn có 1 trục khác là Arm assembly và trên đó gắn với nhiều đầu đọc/ghi gọi là Head. Như vậy để đọc/ghi được dữ liệu thì đầu đọc Head phải đến được vị trí của từng Sector cụ thể.

Thời gian đọc/ghi là tổng thời gian của 3 bước sau:

  • Di chuyển Head đến đúng Track trên các đĩa Platter
  • Chờ đến khi Spindle xoay đến đúng vị trí của các Sector
  • Đọc/ghi dữ liệu trên các Sector

Trong 3 bước trên thì bước trên thì bước 1 và 2 là tốn thời gian nhất. Và tổng thời gian này phụ thuộc vào tốc độ quay của Spindle. Đó là lý do vì sao các HDD với tốc độ vòng quay (RPM) lớn sẽ truy xuất dữ liệu nhanh hơn.

Memory

Vấn đề của Hard disk là tốc độ truy xuất còn chậm cho nên cần có 1 cách cải thiện tốc độ là sử dụng Memory (RAM).
Việc truy xuất dữ liệu trên RAM là ngay tức thời nhưng các dữ liệu này sẽ bị mất khi khởi động lại server.
Vì vậy để vừa tối ưu được Tốc độ, vừa đảm bảo an toàn cho dữ liệu thì Dữ liệu sẽ được chuyển từ Hard disk lên Memory và ngược lại (Để làm được việc này thì Database phải gọi tập hợp các API **Buffer management **của hệ điều hành).

Trước khi dữ liệu được đưa lên RAM thì Hard disk phải mất thời gian truy xuất trên nhiều Sector, và nếu nhiều Sector nằm trên các Track hay trên nhiều Platter khác nhau thì sẽ chậm hơn rất nhiều. Vì vậy nếu có 1 cách nào đó để "gom" các dữ liệu liên quan vào các Sector liền kề nhau thì Spindle sẽ không phải xoay quá nhiều.

Trong MySQL có 1 command là OPTIMIZE TABLE sẽ sắp xếp lại các RecordIndex data vào các Sector liền kề nhau. Quá trình này được gọi là "Defragmenting".

Index

Một khi đã có dữ liệu trên Memory thì chúng ta có thể tìm kiếm chúng theo 1 hay nhiều điều kiện nào đó.
Nhưng không lẽ chúng ta phải load hết dữ liệu lên RAM thì mới có thể tìm kiếm được???

Vì vậy Index ra đời nhằm giải quyết 2 vấn đề chính:

  • Giảm số lượng dữ liệu mà database phải duyệt qua (Chỉ load lên Memory và tìm kiếm trong các dữ liệu thỏa mãn điều kiện mà thôi)
  • Tránh SortingTemporary table

Index là 1 cấu trúc dữ liệu để Database có thể tìm kiếm nhanh dữ liệu trong 1 Table nào đó. Nói cách khác nó cung cấp nhiều thông tin hơn về dữ liệu bên trong Table, Database biết nhiều thông tin hơn thì sẽ tìm kiếm nhanh hơn và hiệu quả hơn.

Tuy nhiên cũng có nhiều loại Index như: B-Tree, Hash, Full-text, Spatial (R-Tree). Mỗi Storage Engine hỗ trợ các loại Index khác nhau và mỗi loại Index đều có ưu và nhược điểm riêng.

P/s: Tập 2 mình sẽ nói rõ hơn về cách sử dụng Index cho đúng trong từng trường hợp. Vì việc tạo nhiều Index dư thừa sẽ ảnh hưởng đến Performance, tốn dung lượng lưu trữ.
Các bạn có thắc mắc gì cứ comment bên dưới nhé. Have fun at #chuyencuadev.