Kích thước cơ sở dữ liệu ảnh hưởng đến hiệu suất như thế nào: Lý thuyết và thực tế

Có rất nhiều điều nói rằng kích thước cơ sở dữ liệu sẽ không ảnh hưởng đến hiệu suất ở bất kỳ mức độ lớn nào. Miễn là các chỉ mục trên các bảng phù hợp với bộ nhớ, cơ sở dữ liệu sẽ vẫn hoạt động.

Tuy nhiên thực tế là gì? Nếu kiến ​​trúc cơ sở dữ liệu không phải là tốt nhất, các chỉ mục không phù hợp với bộ nhớ và có khả năng có nhiều dữ liệu dư thừa thì có thể đạt được mức tăng đáng kể chỉ bằng cách xóa dữ liệu dư thừa? Tôi ước tính rằng 60-80% dữ liệu trong cơ sở dữ liệu của tôi có thể bị xóa.

Tôi tin rằng việc giảm kích thước cơ sở dữ liệu và tăng RAM để các chỉ mục có thể phù hợp với bộ nhớ sẽ giúp tăng hiệu suất đáng kể, điều này sẽ tạo ra một số phòng thở trong vài tháng để nghiên cứu lại hệ thống.

Ngoài ra còn có các yếu tố khác như IO, phân mảnh, dữ liệu làm việc, vv ảnh hưởng đến hiệu suất dựa trên kích thước cơ sở dữ liệu?

Nó phụ thuộc hoàn toàn vào những gì bạn đang làm với dữ liệu.

Đối với các giao dịch chèn / cập nhật / xóa cơ bản chỉ ảnh hưởng đến một vài hàng, thì sự tăng trưởng về kích thước dữ liệu có lẽ không phải là một vấn đề lớn. Cơ sở dữ liệu sẽ sử dụng các chỉ mục trong bộ nhớ để truy cập đúng trang. Bạn nhận được nhiều bộ nhớ cache hơn khi các bảng không còn phù hợp với bộ nhớ. Tuy nhiên, chi phí hoạt động có thể nhẹ - tùy thuộc vào cơ sở dữ liệu, cấu hình cơ sở dữ liệu và cấu hình phần cứng.

Nếu bạn đang thực hiện các truy vấn yêu cầu quét toàn bộ bảng, thì hiệu suất của bạn sẽ tăng tuyến tính hoặc tệ hơn với kích thước dữ liệu. Các chỉ mục thực sự có thể làm cho tình hình tồi tệ hơn, bằng cách ngẫu nhiên truy cập trang, sau đó khá nhiều đảm bảo bộ nhớ cache bị mất.

Một thay thế cho nhiều bộ nhớ hơn là tốc độ đĩa được cải thiện - đĩa trạng thái rắn có thể cung cấp sự cải thiện to lớn.

Chỉ cần có nhiều dữ liệu sẽ không ảnh hưởng đến hiệu suất trừ khi các bảng được sử dụng trong các truy vấn. Là dữ liệu dư thừa trong một bảng hoặc trên các bảng? Có các bảng lớn không bao giờ được sử dụng là lộn xộn, nhưng có ảnh hưởng tối thiểu đến hiệu suất. Có thể tưởng tượng rằng nếu bạn có hàng trăm bảng không cần thiết, thì việc biên dịch truy vấn có thể bắt đầu mất nhiều thời gian hơn.

Quy tắc điều chỉnh số một AMM (Thêm bộ nhớ) là một quy tắc đơn giản. Nó cũng là một thứ rất tốn kém và cuối cùng là không hiệu quả khi có vấn đề về chọn lọc. Ngay cả khi một cơ sở dữ liệu phù hợp hoàn toàn trong bộ nhớ, hiệu năng của ứng dụng có thể kém. Trong trường hợp xấu nhất là do khóa và chốt trong các lần thực thi SQL rất chọn lọc. Những cái đó nên được sửa trước. Một lý do là đồng thời giống như nhấn - và giữ - phá vỡ nếu mọi SQL truy cập tất cả dữ liệu trong một bảng mỗi lần.

Hãy chắc chắn rằng không có SQL truy cập nhiều hàng hơn mức cần thiết. Đó là đưa ra cách hiệu quả nhất để giữ hiệu suất tốt. Một cơ sở dữ liệu bình thường biết cách xử lý io và thực hiện một số hình thức lưu trữ dữ liệu được sử dụng nhiều nhất.

Nếu ứng dụng của bạn đã giảm thiểu tất cả các truy cập có thể và bạn đã sử dụng các hệ thống đĩa nhanh nhất, hãy xem xét sử dụng các mảng bộ nhớ flash thực. Họ có thể tăng hiệu suất lên một cấp độ khác.

Vui lòng tham khảo các bài viết sau:

• Cơ sở dữ liệu MySQL có thể lớn đến mức nào trước khi hiệu suất bắt đầu giảm
• Tại sao MySQL có thể chậm với các bảng lớn?

Gợi ý để làm cho dữ liệu của bạn nhỏ nhất có thể:

Thiết kế các bảng của bạn để giảm thiểu không gian của chúng trên đĩa. Điều này có thể dẫn đến những cải tiến lớn bằng cách giảm lượng dữ liệu được ghi và đọc từ đĩa. Các bảng nhỏ hơn thường yêu cầu ít bộ nhớ chính hơn trong khi nội dung của chúng đang được xử lý tích cực trong quá trình thực hiện truy vấn. Bất kỳ việc giảm dung lượng nào cho dữ liệu bảng cũng dẫn đến các chỉ mục nhỏ hơn có thể được xử lý nhanh hơn.

MySQL hỗ trợ nhiều công cụ lưu trữ khác nhau (loại bảng) và định dạng hàng. Đối với mỗi bảng, bạn có thể quyết định sử dụng phương pháp lưu trữ và lập chỉ mục nào. Chọn định dạng bảng thích hợp cho ứng dụng của bạn có thể mang lại cho bạn hiệu suất lớn.

Bạn có thể có hiệu suất tốt hơn cho một bảng và giảm thiểu không gian lưu trữ bằng cách sử dụng các kỹ thuật được liệt kê ở đây: - Sử dụng các loại dữ liệu hiệu quả nhất (nhỏ nhất) có thể. MySQL có nhiều loại chuyên dụng tiết kiệm không gian đĩa và bộ nhớ. Ví dụ: sử dụng các loại số nguyên nhỏ hơn nếu có thể để có được các bảng nhỏ hơn. MEDIUMINT thường là lựa chọn tốt hơn INT vì cột MEDIUMINT sử dụng ít không gian hơn 25%.

• Khai báo các cột là KHÔNG NULL nếu có thể. Nó làm cho mọi thứ nhanh hơn và bạn tiết kiệm một bit trên mỗi cột. Nếu bạn thực sự cần NULL trong ứng dụng của mình, bạn chắc chắn nên sử dụng nó. Chỉ cần tránh có nó trên tất cả các cột theo mặc định.

• Đối với các bảng MyISAM, nếu bạn không có bất kỳ cột có độ dài thay đổi nào (cột VARCHAR, TEXT hoặc BLOB), định dạng hàng có kích thước cố định sẽ được sử dụng.

• Các bảng InnoDB sử dụng định dạng lưu trữ nhỏ gọn. Trong các phiên bản của MySQL sớm hơn 5.0.3, các hàng InnoDB chứa một số thông tin dư thừa, chẳng hạn như số lượng cột và độ dài của mỗi cột, ngay cả đối với các cột có kích thước cố định. Theo mặc định, các bảng được tạo ở định dạng nhỏ gọn (ROW_FORMAT = COMPACT). Sự hiện diện của định dạng hàng nhỏ gọn làm giảm không gian lưu trữ hàng khoảng 20% ​​với chi phí tăng sử dụng CPU cho một số hoạt động. Nếu khối lượng công việc của bạn là một công việc điển hình bị giới hạn bởi tốc độ nhấn bộ đệm và tốc độ ổ đĩa thì có khả năng sẽ nhanh hơn. Nếu đó là một trường hợp hiếm hoi bị giới hạn bởi tốc độ CPU, nó có thể chậm hơn.

Định dạng InnoDB nhỏ gọn cũng thay đổi cách các cột CHAR chứa dữ liệu UTF-8 được lưu trữ. Với ROW_FORMAT = REDUNDANT, UTF-8 CHAR (N) chiếm 3 × N byte, với điều kiện độ dài tối đa của ký tự được mã hóa UTF-8 là ba byte. Nhiều ngôn ngữ có thể được viết chủ yếu bằng các ký tự UTF-8 byte đơn, do đó, chiều dài lưu trữ cố định thường lãng phí không gian. Với định dạng ROW_FORMAT = COMPACT, InnoDB phân bổ một lượng lưu trữ thay đổi trong phạm vi từ N đến 3 × N byte cho các cột này bằng cách tước các khoảng trắng theo sau nếu cần. Độ dài lưu trữ tối thiểu được giữ dưới dạng N byte để tạo điều kiện cập nhật tại chỗ trong các trường hợp điển hình.

• Chỉ số chính của một bảng nên càng ngắn càng tốt. Điều này giúp nhận dạng từng hàng dễ dàng và hiệu quả

• Chỉ tạo các chỉ mục mà bạn thực sự cần. Các chỉ mục là tốt để truy xuất nhưng xấu khi bạn cần lưu trữ dữ liệu nhanh chóng. Nếu bạn truy cập một bảng chủ yếu bằng cách tìm kiếm trên một tổ hợp các cột, hãy tạo một chỉ mục trên chúng. Phần đầu tiên của chỉ mục nên là cột được sử dụng nhiều nhất. Nếu bạn luôn sử dụng nhiều cột khi chọn từ bảng, thì cột đầu tiên trong chỉ mục sẽ là cột có nhiều bản sao nhất để có được chỉ số nén tốt hơn.

• Trong một số trường hợp, có thể có ích khi chia thành hai bảng được quét rất thường xuyên. Điều này đặc biệt đúng nếu đó là bảng định dạng động và có thể sử dụng bảng định dạng tĩnh nhỏ hơn có thể được sử dụng để tìm các hàng có liên quan khi quét bảng.