Khóa chính lớn: 1+ tỷ hàng MySQL + InnoDB?

Question

Tôi đã tự hỏi nếu InnoDB sẽ là cách tốt nhất để định dạng bảng? Bảng này chứa một trường, khóa chính và bảng sẽ nhận được 816k hàng mỗi ngày (ước tính). Điều này sẽ rất lớn rất nhanh! Tôi đang làm việc trên một cách lưu trữ tập tin (điều này sẽ nhanh hơn)? Bảng sẽ lưu trữ số ID ID của Twitter đã được xử lý?

Ngoài ra, mọi mức sử dụng bộ nhớ ước tính trên tuyên bố SELECT min('id') là gì? Bất kỳ ý tưởng khác được đánh giá rất nhiều!

Answer 1

Câu trả lời dứt khoát duy nhất là thử cả hai và kiểm tra và xem điều gì xảy ra.

Nói chung, MyISAM nhanh hơn để viết và đọc, nhưng không phải cả hai cùng một lúc. Khi bạn viết vào một bảng MyISAM toàn bộ bảng bị khóa cho chèn để hoàn thành. InnoDB có chi phí cao hơn nhưng sử dụng khóa cấp hàng để đọc và ghi có thể xảy ra đồng thời mà không có các vấn đề mà bảng MyISAM bị khóa.

Tuy nhiên, vấn đề của bạn, nếu tôi hiểu chính xác, có một chút khác biệt. Chỉ có một cột, cột đó là khóa chính có cân nhắc quan trọng theo các cách khác nhau mà MyISAM và InnoDB xử lý các chỉ mục khóa chính.

Trong MyISAM, chỉ mục khóa chính giống như bất kỳ chỉ mục phụ nào khác. Bên trong mỗi hàng có một id hàng và các nút chỉ mục chỉ trỏ đến các id hàng của các trang dữ liệu. Một chỉ số khóa chính không được xử lý khác với bất kỳ chỉ mục nào khác. Trong InnoDB, tuy nhiên, khóa chính được nhóm lại, có nghĩa là chúng được gắn với các trang dữ liệu và đảm bảo rằng nội dung hàng vẫn được sắp xếp theo thứ tự vật lý trên đĩa theo khóa chính (nhưng chỉ trong các trang dữ liệu đơn lẻ) có thể được phân tán theo bất kỳ thứ tự nào.Đây là trường hợp, tôi hy vọng rằng InnoDB có thể có lợi thế trong đó MyISAM về cơ bản sẽ phải làm việc gấp đôi - viết số nguyên một lần vào các trang dữ liệu, sau đó viết lại vào các trang chỉ mục. InnoDB sẽ không làm điều này, chỉ số khóa chính sẽ giống hệt với các trang dữ liệu và sẽ chỉ phải viết một lần. Nó sẽ chỉ phải quản lý dữ liệu ở một nơi, nơi mà MyISAM sẽ không cần thiết phải quản lý hai bản sao.

Đối với một trong hai công cụ lưu trữ, hãy thực hiện điều gì đó như min() hoặc max() không đáng kể trên cột được lập chỉ mục hoặc chỉ kiểm tra sự tồn tại của một số trong chỉ mục. Vì bảng chỉ là một cột nên không cần tra cứu dấu trang vì dữ liệu sẽ được đại diện hoàn toàn trong chính chỉ mục đó. Đây sẽ là một chỉ số rất hiệu quả.

Tôi cũng sẽ không lo lắng về kích thước của bảng. Trường hợp chiều rộng của một hàng chỉ là một số nguyên, bạn có thể phù hợp với một số lượng lớn các hàng trên mỗi trang chỉ mục/dữ liệu.

Answer 2

Nếu các số ID này tăng lên một cách đơn điệu và dữ liệu phụ của bạn chỉ ghi (không bao giờ sửa đổi), có thể sẽ nhanh hơn rất nhiều khi sử dụng một tệp. Một SELECT min('id') sau đó chỉ trở thành đọc dòng đầu tiên của tập tin, và bất cứ điều gì khác là một tìm kiếm nhị phân.

Answer 3

Tôi khuyên bạn nên bắt đầu partioning bảng của mình theo ID hoặc ngày. Phân chia chia tách một bảng lớn thành một vài bảng nhỏ hơn theo một số logic xác định (như tách nó theo phạm vi ngày), điều này làm cho chúng hiệu suất và trí nhớ dễ quản lý hơn nhiều. MySQL 5.1 có tính năng này được tích hợp sẵn hoặc bạn có thể triển khai tính năng này bằng các giải pháp tùy chỉnh.

Khi triển khai lưu trữ trong tệp phẳng, bạn mất tất cả các ưu điểm của cơ sở dữ liệu - bạn không còn có thể thực hiện các truy vấn liên quan đến dữ liệu.

Answer 4

Nếu bạn có chỉ mục trên cột id của mình, hãy chọn min (id) phải là O (1), sẽ không có nhiều yêu cầu về bộ nhớ cho điều này.

Nếu khóa chính của bạn ở trên id twitter thì bạn có chỉ mục trên đó.

Answer 5

Có một so sánh tốt của công cụ lưu trữ trên khu MySQL Dev:

• MySQL Storage Engine Architecture, Part 1: An Overview
• MySQL Storage Engine Architecture, Part 2: An In-Depth Look
• MySQL Storage Engine Architecture, Part 3: Details and Comparison

Từ mô tả của bạn tôi sẽ nói MyISAM sẽ tốt hơn, nhưng nó phụ thuộc khá nhiều vào các mẫu đọc và viết so sánh của ứng dụng của bạn.

Answer 6

Với một trường duy nhất, là khóa chính, chỉ bao giờ thêm bản ghi, điều này không thực sự phù hợp với cơ sở dữ liệu thông thường.

Để bắt đầu, bạn sẽ lưu trữ gấp đôi số lượng thông tin mà bạn cần, với mỗi trường đi vào bảng dữ liệu và chỉ mục.

Như một cơ sở dữ liệu quan hệ sang một bên được gọi như vậy, vì một, chúng lưu trữ dữ liệu liên quan vào một hàng đơn lẻ; thật khó để xem dữ liệu của bạn đủ điều kiện như thế nào :-) Nếu bạn đang lưu trữ các nội dung khác, cơ sở dữ liệu sẽ đáng giá.

Bạn không đề cập đến liệu dữ liệu có được truy cập bởi nhiều quy trình cùng một lúc hay không - nếu không, thì bạn không cần tất cả các ưu điểm được trao bởi nguyên tắc ACID cơ sở dữ liệu. Ngay cả khi bạn muốn ACID, điều đó vẫn có thể đạt được mà không có cơ sở dữ liệu đầy đủ.

Mặc định đầu tiên của tôi là xây dựng tệp dữ liệu B-tree hoặc B + -tree của riêng bạn để lưu trữ ID twitter để tránh trùng lặp dữ liệu. Các truy vấn duy nhất tôi có thể thấy bạn đang thực hiện (dựa trên câu hỏi) là:

• chọn min (id) từ tbl; và
• chọn id từ tbl trong đó id =?

Việc đầu tiên có thể được thực hiện O (1) bằng cách lưu trữ thấp nhất trong tệp khác bên ngoài cấu trúc B-tree (và thay thế nó khi bạn nhận được thấp hơn). Tôi không chắc chắn về trường hợp kinh doanh cho điều này trừ khi nó để nhanh chóng tìm ra một ID twitter nhất định không có trong bảng (vì vậy bạn có thể muốn tối đa cũng như trong trường hợp đó).

Thứ hai là các kỹ thuật tìm kiếm cây tiêu chuẩn mà cơ sở dữ liệu thường sử dụng dưới dạng bìa.

Answer 7

Tôi cũng đã thấy một số công ty kinh doanh sử dụng cơ sở dữ liệu đánh dấu tức là. kdb + http://kx.com/