Tối ưu hóa database của WordPress theo cách thủ công

Có đôi điều tôi muốn nói về vấn đề CSDL (database) trong WordPress.

  • Thứ nhất, quả thật đúng khi ai đó nói rằng: ngay cả những người có kinh nghiệm sử dụng WordPress và quan tâm đến tối ưu tốc độ cũng thường quên mất vấn đề này!
  • Hai là: tối ưu hóa database bằng các công cụ tự động có nhiều tiện lợi, nhưng không phải là biện pháp đem lại hiệu quả cao nhất.

Tôi từng rất vui mừng khi khám phá ra plugin chuyên sâu để tối ưu CSDL cho WordPress, nó có tên: Advanced Database Cleaner. Plugin này giúp phát hiện các bảng dữ liệu dư thừa, các cron jobs không cần thiết và cả options không còn có ích nữa.

Nhưng tôi nhanh chóng nhận ra rằng, Advanced Database Cleaner có khả năng phân loại dữ liệu dư thừa không tốt đến mức đủ để bạn an tâm dựa hoàn toàn vào nó. Đặc biệt là ở chiều dữ liệu đó thực tế là dư thừa nhưng Advanced Database Cleaner lại cho rằng nó thuộc về plugin nào đó hoặc của WordPress Core (lõi của WordPress, các tài nguyên quan trọng không được phép xóa). Chiều ngược lại nó ít lỗi hơn, nghĩa là nếu nó xác định dữ liệu nào đấy là dư thừa (orphaned), khả năng cao nó là dư thừa thật.

Có lý do cho điều này:

  • Việc đánh giá ”dữ liệu dư thừa” là “không dư thừa” ít nguy hiểm hơn nhiều so với đánh giá nhầm từ ”không dư thừa” thành “dư thừa”.
  • Số lượng plugin hiện có, và các dữ liệu của chúng vô cùng lớn, ngoài ra còn chuyện cập nhật, thay đổi thường xuyên. Rất khó có một công cụ nào có khả năng nhận biết chính xác theo cách tự động để biết dữ liệu nào đấy là thuộc về plugin nào.

Để tôi đưa ra ví dụ dễ hiểu hơn.

Dữ liệu dư thừa giống như đồ đạc dư thừa trong nhà chúng ta vậy. Việc mua sắm đồ đạc cho căn nhà cũng không khác gì ta cài cắm rất nhiều plugin, thử cái nọ cái kia trên website. Qua thời gian, nhiều đồ đạc trong nhà trở nên vô dụng và chiếm mất không gian, tương tự, các plugin không dùng cũng thế, thậm chí còn tệ hơn ở khía cạnh là ngay cả khi bạn đã gỡ bỏ bản cài đặt của nó thì vẫn còn hàng tá dữ liệu dư thừa trong CSDL (đa số các plugin không tự dọn dẹp chính nó sau khi được gỡ cài đặt).

Nhưng tại sao các plugin không chịu xóa (một số) bảng nó đã tạo trong database?

Có ít nhất hai lý do giải thích vì sao plugin nào đấy không xóa sạch CSDL của nó:

  • Lý do đầu tiên mà người ta thường gán cho, đó là do các plugin đó chưa được thiết kế chuyên nghiệp. Người lập trình viên chỉ nghĩ đến công năng của sản phẩm, mà quên đi mất chuyện nên làm gì sau khi ai đó gỡ plugin của anh/cô ta.
  • Thế nhưng bạn sẽ thấy rằng, nhiều plugin có chất lượng tốt, được cộng đồng đánh giá rất cao, và thậm chí một số còn phải bỏ tiền ra mua cũng không hề dọn dẹp sạch sẽ CSDL của họ. Ví dụ plugin GravityForm (một trong các plugin thuộc hàng xịn xò nhất trong lĩnh vực form) để lại các bảng dữ liệu khá cồng kềnh cho nội dung mà người dùng nhập vào form của họ. Wordfence- plugin bảo mật cực kỳ có tiếng cũng để lại nhiều bảng dữ liệu không hề nhỏ. Lý do cho việc họ không xóa các dữ liệu này tôi nghĩ rằng không phải do họ không nghĩ đến hoặc không có khả năng dọn dẹp sạch sẽ, mà nằm ở chỗ các dữ liệu cũ ấy sẽ có ích khi người dùng cài lại plugin. Chẳng hạn một số cài đặt phức tạp vẫn được giữ nguyên, các dữ liệu quan trọng ngày xưa khách viếng thăm nhập vào vẫn còn đó, vân vân. Ngoài ra cũng rất chính đáng để giữ lại vài phần dữ liệu quan trọng trong giả định có thao tác nhầm lẫn, nghĩa là có thể ai đó sơ ý gỡ cài đặt plugin, và nhờ giữ lại như vậy, sự sơ ý này không gây ra hậu quả tai hại.
Đọc thêm:  Nhập database/cơ sở dữ liệu WordPress vào hosting mới bằng SSH

OK, giờ thì ta đã hiểu nguyên nhân của việc không thể dựa hoàn toàn vào công cụ tự động. Nhưng tối ưu CSDL theo cách thủ công cũng không hề đơn giản, nó đòi hỏi bạn một số thứ như:

  • Bạn phải khá quen thuộc với WordPress rồi, thường là có kinh nghiệm vài năm. Nếu bạn mới làm quen với WP thì nên quên chuyện tối ưu hóa thủ công database!
  • Nắm được chút ít về kỹ thuật, chẳng hạn biết database là gì, các bảng trong đó có vai trò như thế nào?
  • Bạn là người quản trị chính của trang mà bạn định tối ưu thủ công (*)

(*): Tôi gặp phải rất nhiều khó khăn khi tối ưu CSDL thủ công cho trang không phải do bản thân là người quản trị chính. Lý do khó khăn nằm ở chỗ bạn không biết chính xác website này từng cài plugin nào, vì trong nhiều trường hợp đây là thông tin cần phải có để ra quyết định chính xác có nên loại bỏ dữ liệu nào hay không.

So sánh giữa tối ưu bằng công cụ tự động và tối ưu thủ công: thực ra, đây không phải so sánh thuần túy đối lập nhau, mà nó nói lên rằng tối ưu thủ công nên được kết hợp với công cụ tự động để cho kết quả tốt nhất (**). Tối ưu thủ công hoàn toàn thì sẽ rất vất vả:

Tối ưu bằng công cụ tự độngTối ưu theo cách thủ công
Cần ít nền tảng kỹ thuật hơnCần nhiều nền tảng kỹ thuật hơn
Chỉ có khả năng tối ưu được khoảng 50% so với khả năng tốt nhất có thểKhi kết hợp với công cụ tự động, tối ưu theo cách thủ công có thể đạt được 80 – 90% tiềm năng tối đa
Giao diện trực quan dễ quan sát hơnGiao diện khó quan sát hơn
Có nhiều bộ lọc dễ dùngNếu không am hiểu dòng lệnh sẽ không lọc được
Độ chính xác khi phân loại tự động không caoPhân loại có độ chính xác tương đối cao khi kiên trì tìm kiếm nguồn gốc của dữ liệu. Kết hợp với công cụ tự động làm công việc đỡ nặng nhọc hơn nhiều

(**): Tôi có nói rõ hơn ý này trong phần Một số kinh nghiệm.

Một số kinh nghiệm

  • Luôn có bản backup: Dù bạn tối ưu CSDL tự động bằng plugin hay theo cách thủ công hãy luôn tạo một bản backup trước. Không có gì đảm bảo là bạn sẽ làm chính xác mọi thao tác xóa 100%, và nếu nhẫm lẫn chúng ta có cơ hội quay lại thay vì tự dằn vặt vì thao tác sai nào đó.
  • Cẩn trọng, kiểm tra kỹ lưỡng: Xóa dữ liệu cần rất cẩn trọng, bởi vì nếu nhầm lẫn và thứ bạn xóa lại có vai trò quan trọng trên trang thì hậu quả là rất tai hại. Đôi khi vai trò đó dễ phát hiện, và bạn nhanh chóng nhận ra mình vừa làm điều gì đấy không đúng. Nhưng cũng có trường hợp vai trò quan trọng lại rất khó nhận biết, và bạn bỏ lỡ cơ hội sửa sai vì không nhận ra vấn đề.
  • Tích cực sử dụng các công cụ tìm kiếm: Các dữ liệu không rõ thuộc về đâu, cần được tìm kiếm để truy ra nguồn gốc của nó. Đôi khi việc này khá dễ dàng, với các trang như plugintests.com cung cấp thông tin tên các bảng, các options và các file của rất nhiều plugin phổ biến. Nhưng cũng không hiếm trường hợp khó tìm, nhất là khi plugin đó không phổ biến, hoặc các phiên bản cập nhật mới hơn của nó đã thay đổi tên các bảng, file.
  • Các công cụ tự động tối ưu hóa vẫn cực kỳ có ích: Nó nhanh chóng cho bạn cái nhìn tổng quan về database, khả năng lọc, sắp xếp theo tên, vân vân. Ngoài ra thao tác trên công cụ, ví dụ như xóa bảng sẽ ít nhầm lẫn hơn, vì giao diện của nó dễ dùng hơn sao với việc bạn thao tác trực tiếp trên PHPMyAdmin (tất nhiên trừ khi bạn là người thành thạo PHP). Một điều đáng nói nữa, đấy là tối ưu database theo cách thủ công tập trung vào việc xóa các bảng, dòng dữ liệu dư thừa. Trong khi các công cụ còn can thiệp được vào cron jobs và options.
  • Xem dữ liệu của các bảng cụ thể là gì có thể hữu ích: Nó có thể giúp bạn biết được bảng này từng dùng vào việc gì và thậm chí thời gian sử dụng nó. Tôi từng rất đắn đo không biết có nên xóa một bảng hay không cho đến khi xem dữ liệu của nó. Bảng cho thấy tôi chỉ dùng plugin này 2 ngày, và cách thời điểm tôi đang kiểm tra những 3 năm! Nó thuộc về một plugin mà tôi thử nghiệm cách đây đã lâu.
  • Các bảng thuộc về cùng một plugin thường có tiền tố giống nhau: Ví dụ, wp_ig_cache; wp_ig_rate, wp_ig_emails. Nhờ vậy khi bạn phát hiện ra một bảng vô ích, hoặc một options vô ích, bạn sẽ nhanh chóng tìm ra các “bạn bè cùng hội cùng thuyền” của nó. Nhưng điều này không chính xác 100%, dù hiếm khi xảy ra. Do vậy bỏ thêm một chút thời gian để kiểm tra cũng không thừa.
  • Các bảng có rất ít dữ liệu hoặc không có dữ liệu có thể là dư thừa: Bạn có khả năng thấy nhiều bảng chẳng có hàng dữ liệu nào, nó có thể thuộc về plugin cũ kỹ nào đấy đã gỡ bỏ từ lâu. Tuy nhiên, lúc nào cũng có ngoại lệ, một bảng của plugin đang dùng cũng có thể không chứa dữ liệu, vì bảng đó đại diện cho một chức năng mà bạn không dùng đến.
  • Luôn kiểm tra lại thật kỹ website sau khi tối ưu: Chỉ có vậy mới đảm bảo được rằng bạn không xóa nhầm những thứ hữu ích. Trang của bạn càng phức tạp, thời gian cần bỏ ra kiểm tra càng nhiều hơn.
  • Tránh lưu giữ những dữ liệu không cần thiết: Các plugin quiz, plugin affiliate, plugin form, bảo mật hay nói chung là các plugin có áp dụng việc thu thập dữ liệu có thể dễ dàng làm gia tăng nhanh chóng database của bạn. Nhất là khi bạn có lưu lượng truy cập lớn. Tôi mới phát hiện ra plugin Shortlinks by Pretty Links lưu một lượng dữ liệu lớn như thế nào. Hơn 70MB dữ liệu (chiếm gần một nửa CSDL của toàn trang lúc đó). Nguyên nhân kết hợp từ hai thứ, nó lưu giữ quá nhiều trường thông tin (trình duyệt người dùng, thời gian click, IP, click trên trang nào, số lượt bấm, vân vân) và lưu lượng truy cập đến nó đủ lớn để tạo ra rất nhiều hàng dữ liệu. Trong khi lưu lượng truy cập tăng là điều mừng rỡ, do vậy để giảm dữ liệu lưu trên database giải pháp khả dĩ là ta chỉ nên lưu lại trường thông tin quan trọng thôi. Chẳng hạn trong ví dụ trên, tôi chẳng bao giờ xem thời gian click, IP hay trình duyệt người dùng (mặc dù mới đầu tôi nghĩ tôi sẽ phân tích chúng kỹ lắm!), tôi ưu tiên hơn xem link có bao nhiêu lượt click, và tôi chỉ chọn lưu dữ liệu này. Tất nhiên cái này phụ thuộc vào bạn, nếu dữ liệu là quan trọng, bạn cần phải lưu lại dù nó chiếm dung lượng lớn.
  • Xóa dữ liệu đã lưu thông qua chính plugin đó: Các plugin lưu giữ dữ liệu cũng thường cho phép xóa dữ liệu từ giao diện người dùng của chính nó (đây là một dấu hiệu cho thấy plugin nào đó có được lập trình tốt hay không). Điều này có ích. Các dữ liệu không phải lúc nào cũng quan trọng, chẳng hạn khi phân tích xong dữ liệu cũ bạn có thể xóa được chúng. Hãy tận dụng tính năng này để database không phình to.
  • Vài tháng một lần hãy kiểm tra CSDL để xem có gì bất thường không: Bạn hãy sắp xếp theo dung lượng hoặc theo số bản ghi (hàng dữ liệu) để phát hiện ra các bảng bất thường. Nhưng bảng có giá trị quá lớn có thể cho thấy có điều gì không đúng hoặc ít nhất là chưa tối ưu.
  • Khuynh hướng ưa dùng kiểu bảng InnoDB hơn là so với MyISAM: Tôi chỉ biết về hiện tượng là như vậy, chưa nghiên cứu đủ sâu để bàn kỹ lưỡng. Nhưng có vẻ InnoDB cho hiệu suất cân bằng hơn ở cả đọc lẫn ghi, cũng như tính ổn định cao hơn của nó khi phải xử lý với lượng dữ liệu lớn.
  • Kết quả đạt được có thể khiến bạn ngạc nhiên đấy: Cá nhân tôi đã giảm được khoảng 75% dung lượng database- từ hơn 160MB xuống chỉ còn chưa đến 40MB bằng cách kết hợp cả plugin tối ưu tự động, và tiến hành phân loại thủ công sau đó. Một trong những lý do tôi có được con số ấn tượng trên là vì đây là trang tương đối động (thường lưu lại database) và đã 5 năm rồi chưa can thiệp sâu đến nó (ngoài việc chỉ lớt phớt loại bỏ các revisions – đây là một trong những thứ đơn giản nhất khi đề cập đến tối ưu CSDL).
  • Cuối cùng: Tối ưu database không chỉ giúp bạn có được tốc độ website tốt hơn, ở nhiều khía cạnh nó còn giúp duy trì tính ổn định và liền mạch của trang nhờ tránh được quá tải.
Đọc thêm:  Tối ưu database WordPress: Hướng dẫn toàn diện

Leave a Comment