Xử lý dữ liệu rất lớn với mysql

MySQL có thể thực hiện hợp lý các truy vấn trên hàng tỷ hàng không? - MySQL có thể 'xử lý' hàng tỷ hàng. "Hợp lý" phụ thuộc vào các truy vấn; hãy xem chúng.

InnoDB (MySQL 5.5.8) có phải là lựa chọn phù hợp cho nhiều tỷ hàng không? - 5.7 có một số cải tiến, nhưng 5.5 là khá tốt, mặc dù gần bằng 6 8 tuổi, và sắp không còn được hỗ trợ.

Lưu trữ dữ liệu tốt nhất cho hàng tỷ hàng - Nếu bạn có nghĩa là 'Động cơ', thì đó là InnoDB.

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 - Một lần nữa, điều đó phụ thuộc vào các truy vấn. Tôi có thể cho bạn xem một bảng hàng 1K sẽ giảm dần; Tôi đã làm việc với các bảng hàng tỷ hàng trùng lặp.

Tại sao MySQL có thể chậm với các bảng lớn? - quét phạm vi dẫn đến I / O, đây là phần chậm.

Mysql có thể xử lý các bảng sẽ chứa khoảng 300 triệu bản ghi không? - một lần nữa, vâng. Giới hạn là khoảng một nghìn tỷ hàng.

(đối với bảng InnoDB, đó là trường hợp của tôi) tăng innodb_buffer_pool_size (ví dụ:lên đến 80% RAM). Ngoài ra, tôi đã tìm thấy một số cài đặt kiểm tra hiệu suất MySQL khác ở đây trong blog Percona - vâng

có các chỉ mục thích hợp trên bảng (sử dụng GIẢI THÍCH trên các truy vấn) - tốt, chúng ta hãy xem chúng. Có rất nhiều sai lầm có thể mắc phải trong quan trọng này khu vực.

phân vùng bảng - "Phân vùng không phải là thuốc chữa bách bệnh!" Tôi thích điều đó trong blog của tôi

MySQL Sharding - Hiện đây là sản phẩm DIY

Phân cụm MySQL - Hiện tại câu trả lời tốt nhất là một số tùy chọn dựa trên Galera (PXC, MariaDB 10, DIY w / Oracle). Oracle's "Group Replication" là một đối thủ khả thi.

Phân vùng không hỗ trợ FOREIGN KEY hoặc "toàn cầu" UNIQUE .

UUID, ở quy mô mà bạn đang đề cập, sẽ không chỉ làm chậm hệ thống mà còn thực sự giết chết nó. UUID loại 1 có thể là một giải pháp thay thế.

Tốc độ chèn và tạo chỉ mục - Có quá nhiều biến thể để đưa ra một câu trả lời duy nhất. Hãy xem CREATE TABLE dự kiến ​​của bạn và cách bạn định cung cấp dữ liệu.

Rất nhiều phép nối - "Bình thường hóa, nhưng đừng bình thường hóa quá mức." Đặc biệt, không chuẩn hóa lịch ngày tháng trôi nổi hoặc các giá trị "liên tục" khác.

Tạo bảng tóm tắt

2,3 triệu giao dịch mỗi ngày - Nếu đó là 2,3 triệu lượt chèn (30 / giây), thì không có nhiều vấn đề về hiệu suất. Nếu phức tạp hơn, thì RAID, SSD, lô, v.v., có thể cần thiết.

đối phó với khối lượng dữ liệu như vậy - Nếu hầu hết hoạt động là với các hàng "gần đây", thì buffer_pool sẽ 'lưu vào bộ nhớ cache' hoạt động một cách độc đáo, do đó tránh được I / O. Nếu hoạt động là "ngẫu nhiên", thì MySQL (hoặc bất kỳ ai khác) sẽ có vấn đề về I / O.

Việc thu nhỏ các kiểu dữ liệu sẽ giúp ích trong một bảng giống như bảng của bạn. Tôi nghi ngờ liệu bạn có cần 4 byte để chỉ định fuel_type không . Có nhiều cách tiếp cận 1 byte.