MariaDB
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> MariaDB

MySQL &MariaDB Query Caching Với ProxySQL &ClusterControl

Các truy vấn phải được lưu vào bộ nhớ đệm trong mọi cơ sở dữ liệu được tải nhiều, đơn giản là không có cách nào để cơ sở dữ liệu có thể xử lý tất cả lưu lượng truy cập với hiệu suất hợp lý. Có nhiều cơ chế khác nhau trong đó bộ đệm truy vấn có thể được triển khai. Bắt đầu từ bộ đệm truy vấn MySQL, được sử dụng chỉ hoạt động tốt cho hầu hết các khối lượng công việc đồng thời thấp, chỉ đọc và không có chỗ trong khối lượng công việc đồng thời cao (đến mức Oracle đã loại bỏ nó trong MySQL 8.0), đến các cửa hàng khóa-giá trị bên ngoài như Redis, memcached hoặc CouchBase.

Vấn đề chính với việc sử dụng một kho dữ liệu chuyên dụng bên ngoài (vì chúng tôi không khuyên bất kỳ ai sử dụng bộ nhớ cache truy vấn MySQL) là đây vẫn là một kho dữ liệu khác cần quản lý. Nó là một môi trường khác để duy trì, mở rộng các vấn đề cần xử lý, các lỗi cần gỡ lỗi, v.v.

Vậy tại sao không giết hai con chim bằng một viên đá bằng cách tận dụng proxy của bạn? Giả định ở đây là bạn đang sử dụng proxy trong môi trường sản xuất của mình, vì nó giúp các truy vấn cân bằng tải giữa các phiên bản và che giấu cấu trúc liên kết cơ sở dữ liệu cơ bản bằng cách cung cấp một điểm cuối đơn giản cho các ứng dụng. ProxySQL là một công cụ tuyệt vời cho công việc này, vì nó cũng có thể hoạt động như một lớp bộ nhớ đệm. Trong bài đăng trên blog này, chúng tôi sẽ chỉ cho bạn cách lưu vào bộ nhớ cache các truy vấn trong ProxySQL bằng ClusterControl.

Bộ nhớ đệm truy vấn hoạt động như thế nào trong ProxySQL?

Trước hết, một chút nền tảng. ProxySQL quản lý lưu lượng truy cập thông qua các quy tắc truy vấn và nó có thể hoàn thành bộ nhớ đệm truy vấn bằng cách sử dụng cùng một cơ chế. ProxySQL lưu trữ các truy vấn được lưu trong bộ nhớ cache trong một cấu trúc bộ nhớ. Dữ liệu được lưu trong bộ nhớ cache sẽ bị loại bỏ bằng cách sử dụng cài đặt thời gian tồn tại (TTL). TTL có thể được xác định cho từng quy tắc truy vấn riêng lẻ, do đó, người dùng quyết định xem có phải xác định các quy tắc truy vấn cho từng truy vấn riêng biệt hay không, với TTL riêng biệt hay họ chỉ cần tạo một vài quy tắc sẽ phù hợp với phần lớn lưu lượng truy cập.

Có hai cài đặt cấu hình xác định cách sử dụng bộ đệm truy vấn. Đầu tiên, mysql-query_cache_size_MB xác định giới hạn mềm về kích thước bộ đệm truy vấn. Nó không phải là một giới hạn cứng nên ProxySQL có thể sử dụng nhiều bộ nhớ hơn một chút, nhưng nó đủ để kiểm soát việc sử dụng bộ nhớ. Cài đặt thứ hai mà bạn có thể chỉnh sửa là mysql-query_cache_stores_empty_result . Nó xác định xem một tập kết quả trống có được lưu vào bộ nhớ đệm hay không.

Bộ đệm ẩn truy vấn ProxySQL được thiết kế như một kho lưu trữ khóa-giá trị. Giá trị là tập hợp kết quả của một truy vấn và khóa được tạo từ các giá trị được nối như:người dùng, lược đồ và văn bản truy vấn. Sau đó, một băm được tạo ra từ chuỗi đó và băm đó được sử dụng làm khóa.

Thiết lập ProxySQL làm Bộ đệm truy vấn bằng ClusterControl

Như thiết lập ban đầu, chúng tôi có một cụm sao chép của một chủ và một nô lệ. Chúng tôi cũng có một ProxySQL duy nhất.

Đây hoàn toàn không phải là thiết lập ở cấp sản xuất vì chúng tôi sẽ phải triển khai một số loại tính sẵn sàng cao cho lớp proxy (ví dụ:bằng cách triển khai nhiều phiên bản ProxySQL và sau đó giữ nguyên trên chúng cho IP ảo nổi), nhưng nó sẽ là quá đủ cho các thử nghiệm của chúng tôi.

Đầu tiên, chúng tôi sẽ xác minh cấu hình ProxySQL để đảm bảo cài đặt bộ đệm truy vấn là những gì chúng tôi muốn.

256 MB bộ nhớ cache truy vấn phải ở mức vừa phải và chúng tôi cũng muốn lưu vào bộ nhớ cache các bộ kết quả trống - đôi khi truy vấn không trả về dữ liệu vẫn phải thực hiện rất nhiều công việc để xác minh không có gì để trả lại.

Bước tiếp theo là tạo các quy tắc truy vấn sẽ phù hợp với các truy vấn bạn muốn lưu vào bộ nhớ cache. Có hai cách để thực hiện điều đó trong ClusterControl.

Thêm quy tắc truy vấn theo cách thủ công

Cách đầu tiên yêu cầu các thao tác thủ công hơn một chút. Sử dụng ClusterControl, bạn có thể dễ dàng tạo bất kỳ quy tắc truy vấn nào bạn muốn, bao gồm cả các quy tắc truy vấn thực hiện bộ nhớ đệm. Trước tiên, hãy xem danh sách các quy tắc:

Tại thời điểm này, chúng ta có một tập hợp các quy tắc truy vấn để thực hiện phân tách đọc / ghi. Quy tắc đầu tiên có ID là 100. Quy tắc truy vấn mới của chúng tôi phải được xử lý trước quy tắc đó, vì vậy chúng tôi sẽ sử dụng ID quy tắc thấp hơn. Hãy tạo quy tắc truy vấn sẽ thực hiện việc lưu vào bộ nhớ đệm các truy vấn tương tự như quy tắc này:

SELECT DISTINCT c FROM sbtest8 WHERE id BETWEEN 5041 AND 5140 ORDER BY c

Có ba cách đối sánh truy vấn:Thông báo, Thông báo đối sánh và Mẫu đối sánh. Hãy nói một chút về chúng ở đây. Đầu tiên, Match Digest. Chúng ta có thể đặt ở đây một biểu thức chính quy sẽ khớp với một chuỗi truy vấn tổng quát đại diện cho một số loại truy vấn. Ví dụ:đối với truy vấn của chúng tôi:

SELECT DISTINCT c FROM sbtest8 WHERE id BETWEEN 5041 AND 5140 ORDER BY c

Đại diện chung sẽ là:

SELECT DISTINCT c FROM sbtest8 WHERE id BETWEEN ? AND ? ORDER BY c

Như bạn có thể thấy, nó loại bỏ các đối số cho mệnh đề WHERE, do đó tất cả các truy vấn thuộc loại này được biểu diễn dưới dạng một chuỗi duy nhất. Tùy chọn này khá hay khi sử dụng vì nó phù hợp với toàn bộ loại truy vấn và điều quan trọng hơn nữa là nó loại bỏ mọi khoảng trắng. Điều này giúp bạn viết một biểu thức chính quy dễ dàng hơn rất nhiều vì bạn không phải tính đến các ngắt dòng kỳ lạ, khoảng trắng ở đầu hoặc cuối chuỗi, v.v.

Thông báo về cơ bản là một hàm băm mà ProxySQL tính toán qua biểu mẫu Thông báo đối sánh.

Cuối cùng, Mẫu đối sánh đối sánh với văn bản truy vấn đầy đủ, vì nó được gửi bởi khách hàng. Trong trường hợp của chúng tôi, truy vấn sẽ có dạng:

SELECT DISTINCT c FROM sbtest8 WHERE id BETWEEN 5041 AND 5140 ORDER BY c

Chúng tôi sẽ sử dụng Match Digest vì chúng tôi muốn tất cả các truy vấn đó được bao phủ bởi quy tắc truy vấn. Nếu chúng tôi chỉ muốn lưu vào bộ nhớ cache của truy vấn cụ thể đó, thì một lựa chọn tốt là sử dụng Mẫu đối sánh.

Biểu thức chính quy mà chúng tôi sử dụng là:

SELECT DISTINCT c FROM sbtest[0-9]+ WHERE id BETWEEN \? AND \? ORDER BY c

Chúng tôi đang đối sánh theo đúng nghĩa đen của chuỗi truy vấn tổng quát chính xác với một ngoại lệ - chúng tôi biết rằng truy vấn này truy cập vào nhiều bảng, do đó chúng tôi đã thêm một biểu thức chính quy để khớp với tất cả chúng.

Sau khi hoàn tất, chúng tôi có thể xem quy tắc truy vấn có hiệu lực hay không.

Chúng ta có thể thấy rằng 'Lượt truy cập' đang tăng lên, có nghĩa là quy tắc truy vấn của chúng ta đang được sử dụng. Tiếp theo, chúng ta sẽ xem xét một cách khác để tạo quy tắc truy vấn.

Sử dụng ClusterControl để tạo quy tắc truy vấn

ProxySQL có một chức năng hữu ích là thu thập số liệu thống kê của các truy vấn mà nó định tuyến. Bạn có thể theo dõi dữ liệu như thời gian thực thi, số lần một truy vấn nhất định đã được thực thi, v.v. Dữ liệu này cũng có trong ClusterControl:

Điều tuyệt vời hơn nữa, nếu bạn trỏ vào một loại truy vấn nhất định, bạn có thể tạo quy tắc truy vấn liên quan đến nó. Bạn cũng có thể dễ dàng lưu vào bộ nhớ cache loại truy vấn cụ thể này.

Như bạn có thể thấy, một số dữ liệu như Rule IP, Cache TTL hoặc Schema Name đã được điền. ClusterControl cũng sẽ điền dữ liệu dựa trên cơ chế đối sánh mà bạn đã quyết định sử dụng. Chúng ta có thể dễ dàng sử dụng hàm băm cho một loại truy vấn nhất định hoặc chúng ta có thể sử dụng Thông báo kết hợp hoặc Mẫu đối sánh nếu chúng ta muốn tinh chỉnh biểu thức chính quy (ví dụ:làm giống như chúng ta đã làm trước đó và mở rộng biểu thức chính quy để khớp với tất cả bảng trong lược đồ sbtest).

Đây là tất cả những gì bạn cần để dễ dàng tạo quy tắc bộ nhớ cache truy vấn trong ProxySQL. Tải xuống ClusterControl để dùng thử ngay hôm nay.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Cách ACOS () hoạt động trong MariaDB

  2. Định dạng một số dưới dạng tiền tệ trong MariaDB

  3. So sánh RDS và EC2 để quản lý MySQL hoặc MariaDB trên AWS

  4. Cách DEGREES () hoạt động trong MariaDB

  5. Cách CONVERT () hoạt động trong MariaDB