Tại thời điểm nào cơ sở dữ liệu MySQL bắt đầu mất hiệu suất?
Tôi có những gì tôi tin là một cơ sở dữ liệu lớn, với khoảng 15 triệu bản ghi chiếm gần 2GB. Dựa trên những con số này, tôi có khuyến khích tôi làm sạch dữ liệu không, hay tôi có an toàn để cho phép nó tiếp tục nhân rộng thêm vài năm nữa không?
Câu trả lời:
Kích thước cơ sở dữ liệu vật lý không thành vấn đề. Số lượng hồ sơ không quan trọng.
Theo kinh nghiệm của tôi, vấn đề lớn nhất mà bạn sẽ gặp phải không phải là kích thước, mà là số lượng truy vấn bạn có thể xử lý tại một thời điểm. Nhiều khả năng bạn sẽ phải chuyển sang cấu hình chủ / nô lệ để các truy vấn đọc có thể chạy với các nô lệ và các truy vấn ghi chạy với chủ. Tuy nhiên, nếu bạn chưa sẵn sàng cho việc này, bạn luôn có thể điều chỉnh các chỉ mục của mình cho các truy vấn bạn đang chạy để tăng tốc thời gian phản hồi. Ngoài ra, có rất nhiều điều chỉnh mà bạn có thể thực hiện đối với ngăn xếp mạng và kernel trong Linux sẽ giúp ích.
Tôi đã có của tôi nhận được tới 10GB, chỉ với một số lượng kết nối vừa phải và nó đã xử lý các yêu cầu tốt.
Tôi sẽ tập trung đầu tiên vào các chỉ mục của bạn, sau đó yêu cầu quản trị viên máy chủ nhìn vào HĐH của bạn và nếu tất cả những điều đó không giúp ích gì thì có lẽ đã đến lúc thực hiện cấu hình chính / phụ.
Nói chung đây là một vấn đề rất tinh tế và không tầm thường gì. Tôi khuyến khích bạn đọc mysqlperformanceblog.com và MySQL hiệu suất cao . Tôi thực sự nghĩ rằng không có câu trả lời chung cho việc này.
Tôi đang làm việc trên một dự án có cơ sở dữ liệu MySQL với gần 1TB dữ liệu. Yếu tố khả năng mở rộng quan trọng nhất là RAM. Nếu các chỉ mục của bảng phù hợp với bộ nhớ và các truy vấn của bạn được tối ưu hóa cao, bạn có thể phục vụ một lượng yêu cầu hợp lý với một máy trung bình.
Số lượng hồ sơ có vấn đề, tùy thuộc vào bảng của bạn trông như thế nào. Đó là một sự khác biệt để có nhiều trường varchar hoặc chỉ một vài số nguyên hoặc dài.
Kích thước vật lý của cơ sở dữ liệu cũng quan trọng: ví dụ, nghĩ về sao lưu. Tùy thuộc vào công cụ của bạn, các tệp db vật lý của bạn sẽ phát triển, nhưng không thu nhỏ lại, ví dụ như với innodb. Vì vậy, xóa rất nhiều hàng, không giúp thu nhỏ các tệp vật lý của bạn.
Có rất nhiều vấn đề này và trong rất nhiều trường hợp ma quỷ nằm trong chi tiết.
Kích thước cơ sở dữ liệu không thành vấn đề . Nếu bạn có nhiều hơn một bảng với hơn một triệu bản ghi, thì hiệu suất thực sự bắt đầu giảm. Số lượng bản ghi tất nhiên ảnh hưởng đến hiệu suất: MySQL có thể chậm với các bảng lớn . Nếu bạn đạt một triệu bản ghi, bạn sẽ gặp vấn đề về hiệu suất nếu các chỉ số không được đặt đúng (ví dụ: không có chỉ mục nào cho các trường trong "Câu lệnh WHERE" hoặc "Điều kiện BẬT" trong các phép nối). Nếu bạn đạt 10 triệu bản ghi, bạn sẽ bắt đầu gặp vấn đề về hiệu suất ngay cả khi bạn có tất cả các chỉ số của mình. Nâng cấp phần cứng - thêm bộ nhớ và nhiều bộ xử lý hơn, đặc biệt là bộ nhớ - thường giúp giảm các vấn đề nghiêm trọng nhất bằng cách tăng hiệu suất một lần nữa, ít nhất là ở một mức độ nhất định. Ví dụ37 tín hiệu đã chuyển từ RAM 32 GB sang RAM 128 GB cho máy chủ cơ sở dữ liệu Basecamp.
Tôi sẽ tập trung đầu tiên vào các chỉ mục của bạn, hơn là quản trị viên máy chủ nhìn vào HĐH của bạn và nếu tất cả những điều đó không giúp ích gì thì có lẽ đã đến lúc cấu hình chính / phụ.
Đúng. Một điều khác thường hoạt động là chỉ cần giảm số lượng dữ liệu liên tục làm việc với. Nếu bạn có "dữ liệu cũ" và "dữ liệu mới" và 99% truy vấn của bạn hoạt động với dữ liệu mới, chỉ cần di chuyển tất cả dữ liệu cũ sang bảng khác - và đừng nhìn vào đó;)
-> Có một cái nhìn vào phân vùng .
Thật là vô nghĩa khi nói về "hiệu suất cơ sở dữ liệu", "hiệu suất truy vấn" là một thuật ngữ tốt hơn ở đây. Và câu trả lời là: nó phụ thuộc vào truy vấn, dữ liệu mà nó hoạt động, chỉ mục, phần cứng, v.v. Bạn có thể biết được có bao nhiêu hàng sẽ được quét và những chỉ mục nào sẽ được sử dụng với cú pháp EXPLAIN.
2GB không thực sự được tính là cơ sở dữ liệu "lớn" - nó có kích thước trung bình hơn.
Tôi hiện đang quản lý cơ sở dữ liệu MySQL trên cơ sở hạ tầng đám mây của Amazon đã tăng lên 160 GB. Hiệu suất truy vấn là tốt. Những gì đã trở thành một cơn ác mộng là sao lưu, khôi phục, thêm nô lệ hoặc bất cứ điều gì khác liên quan đến toàn bộ dữ liệu hoặc thậm chí DDL trên các bảng lớn. Bắt một bản nhập sạch của một tệp kết xuất đã trở thành vấn đề. Để làm cho quá trình đủ ổn định để tự động hóa, cần có nhiều lựa chọn khác nhau để ưu tiên sự ổn định hơn hiệu suất. Nếu chúng ta phải phục hồi sau thảm họa bằng cách sử dụng bản sao lưu SQL, chúng ta sẽ thất vọng trong nhiều ngày.
SQL mở rộng theo chiều ngang cũng khá đau đớn và trong hầu hết các trường hợp dẫn đến việc sử dụng nó theo cách mà bạn có thể không có ý định khi bạn chọn đưa dữ liệu của mình vào SQL ngay từ đầu. Shard, đọc nô lệ, multi-master, et al, chúng đều là những giải pháp thực sự tồi tệ làm tăng thêm sự phức tạp cho mọi thứ bạn từng làm với DB, và không một trong số chúng giải quyết vấn đề; chỉ giảm nhẹ nó theo một số cách. Tôi thực sự khuyên bạn nên xem xét việc chuyển một số dữ liệu của bạn ra khỏi MySQL (hoặc thực sự là bất kỳ SQL nào) khi bạn bắt đầu tiếp cận một tập dữ liệu có kích thước trong đó các loại điều này trở thành một vấn đề.
Cũng xem ra cho tham gia phức tạp. Độ phức tạp giao dịch có thể là một yếu tố lớn ngoài khối lượng giao dịch.
Tái cấu trúc các truy vấn nặng đôi khi cung cấp một hiệu suất lớn.
Tôi đã từng được kêu gọi để xem xét một mysql đã "ngừng hoạt động". Tôi phát hiện ra rằng các tệp DB đang nằm trên một bộ lọc Công cụ Mạng được gắn với NFS2 và với kích thước tệp tối đa là 2 GB. Và chắc chắn, bảng đã ngừng chấp nhận giao dịch chính xác là 2GB trên đĩa. Nhưng liên quan đến đường cong hiệu suất, tôi đã nói rằng nó hoạt động như một nhà vô địch cho đến khi nó không hoạt động! Trải nghiệm này luôn phục vụ cho tôi như một lời nhắc nhở tốt đẹp rằng luôn có kích thước bên trên và bên dưới thứ bạn nghi ngờ một cách tự nhiên.
Một điểm cần xem xét cũng là mục đích của hệ thống và dữ liệu hàng ngày.
Ví dụ: đối với hệ thống có giám sát GPS của ô tô không phải là dữ liệu truy vấn có liên quan từ các vị trí của xe trong những tháng trước.
Do đó, dữ liệu có thể được chuyển đến các bảng lịch sử khác để tham khảo ý kiến và giảm thời gian thực hiện của các truy vấn hàng ngày.
Hiệu suất có thể giảm trong vài nghìn hàng nếu cơ sở dữ liệu không được thiết kế đúng.
Nếu bạn có các chỉ mục thích hợp, hãy sử dụng các công cụ thích hợp (không sử dụng MyISAM nơi dự kiến sẽ có nhiều DML), sử dụng phân vùng, phân bổ bộ nhớ chính xác tùy theo việc sử dụng và tất nhiên có cấu hình máy chủ tốt, MySQL có thể xử lý dữ liệu ngay cả trong terabyte!
Luôn có cách để cải thiện hiệu suất cơ sở dữ liệu.
Nó phụ thuộc vào truy vấn và xác nhận của bạn.
Ví dụ: tôi đã làm việc với một bảng gồm 100 000 loại thuốc có tên chung là cột có hơn 15 ký tự cho mỗi loại thuốc trong bảng đó. Tôi đặt một truy vấn để so sánh tên chung của các loại thuốc giữa hai bảng. Nhiều phút hơn để chạy. Tương tự, nếu bạn so sánh các loại thuốc sử dụng chỉ số thuốc, sử dụng cột id (như đã nói ở trên), chỉ mất vài giây.
Kích thước cơ sở dữ liệu KHÔNG quan trọng về số byte và số hàng của bảng. Bạn sẽ nhận thấy một sự khác biệt lớn về hiệu suất giữa cơ sở dữ liệu ánh sáng và cơ sở dữ liệu đầy ắp. Khi ứng dụng của tôi bị kẹt vì tôi đặt hình ảnh nhị phân bên trong các trường thay vì giữ hình ảnh trong tệp trên đĩa và chỉ đặt tên tệp trong cơ sở dữ liệu. Mặt khác, việc lặp lại một số lượng lớn các hàng không phải là miễn phí.
Không, nó không thực sự quan trọng. Tốc độ MySQL là khoảng 7 triệu hàng mỗi giây. Vì vậy, bạn có thể mở rộng nó một chút
Hiệu suất truy vấn chủ yếu phụ thuộc vào số lượng bản ghi cần quét, các chỉ mục đóng vai trò cao trong đó và kích thước dữ liệu chỉ mục tỷ lệ thuận với số lượng hàng và số lượng chỉ mục.
Các truy vấn có điều kiện trường được lập chỉ mục cùng với giá trị đầy đủ thường được trả về sau 1ms, nhưng started_with, IN, Between, rõ ràng có chứa các điều kiện có thể mất nhiều thời gian hơn với nhiều bản ghi hơn để quét.
Ngoài ra, bạn sẽ phải đối mặt với nhiều vấn đề bảo trì với DDL, như ALTER, DROP sẽ chậm và khó khăn với lưu lượng truy cập trực tiếp nhiều hơn ngay cả khi thêm chỉ mục hoặc cột mới.
Nói chung, nên phân cụm Cơ sở dữ liệu thành nhiều cụm theo yêu cầu (500 GB sẽ là điểm chuẩn chung, như những người khác nói, nó phụ thuộc vào nhiều yếu tố và có thể thay đổi tùy theo trường hợp sử dụng) theo cách đó giúp cách ly tốt hơn và độc lập với quy mô cụ thể cụm (phù hợp hơn trong trường hợp B2B)