Làm thế nào để thiết kế một cơ sở dữ liệu để lưu trữ một danh sách được sắp xếp?

Tôi đang tìm cách lưu trữ một danh sách được sắp xếp bên trong cơ sở dữ liệu. Tôi muốn thực hiện các hoạt động sau đây một cách hiệu quả.

1. Chèn (x) - Chèn bản ghi x vào bảng
2. Xóa (x) - Xóa bản ghi x khỏi bảng
3. Trước (x, n) - Trả về các bản ghi 'n' trước bản ghi x trong danh sách được sắp xếp.
4. Sau (x, n) - Trả về các bản ghi 'n' thành công bản ghi x trong danh sách được sắp xếp.
5. Đầu tiên (n) - Trả về các bản ghi 'n' đầu tiên từ danh sách được sắp xếp.
6. Lần cuối (n) - Trả về các bản ghi 'n' cuối cùng từ danh sách đã sắp xếp.
7. So sánh (x, y) - Cho hai bản ghi x và y từ bảng, tìm nếu x> y.

Phương pháp đơn giản tôi có thể nghĩ đến là lưu trữ một loại thuộc tính 'thứ hạng' trong bảng và truy vấn bằng cách sắp xếp trên thuộc tính đó. Nhưng trong phương pháp này, việc chèn / sửa đổi một bản ghi với thứ hạng sẽ trở thành một hoạt động tốn kém. Có một phương pháp tốt hơn?

Cụ thể, tôi đang tìm cách triển khai bảng bằng SimpleDB của Amazon. Nhưng một câu trả lời chung cho cơ sở dữ liệu quan hệ cũng sẽ hữu ích.

Cập nhật hồ sơ tải:

Vì tôi đang lập kế hoạch này cho một ứng dụng web, nó phụ thuộc vào số lượng người dùng sử dụng ứng dụng đó.

Nếu có 100k người dùng hoạt động (siêu lạc quan: P), thì ước tính rất gần đúng của tôi mỗi ngày sẽ là

500k chọn, 100k chèn và xóa, cập nhật 500k

Tôi hy vọng bảng sẽ tăng tổng cộng lên tới 500k.

Tôi đang tìm cách tối ưu hóa các bản cập nhật, chèn và các hoạt động So sánh. Thứ hạng của các vật phẩm sẽ liên tục thay đổi và tôi cần cập nhật bảng.

Nếu thứ hạng không hoàn toàn tùy ý mà thay vào đó có thể lấy được từ một số tài sản khác (ví dụ như tên, điểm người chơi, v.v.) thì hãy xem câu trả lời của Joel .

Nếu đó là một thuộc tính tùy ý của dữ liệu của bạn, thì đó nên được lưu trữ dưới dạng một cột trong bảng hồ sơ của bạn. Giả sử SimpleDB của Amazon tương tự như RDBMS điển hình, sau đó bạn có thể lập chỉ mục cột này và nhanh chóng đáp ứng tất cả các truy vấn trên của bạn bằng chiến lược lập chỉ mục phù hợp. Điều này là bình thường đối với RDBMS.

Cho rằng bạn mong đợi hoạt động chèn và cập nhật cao, nhưng hoạt động đọc tương đối cao, tôi khuyên bạn nên làm như sau:

• Phân cụm bảng trên thứ hạng, đặc biệt nếu phần lớn các truy vấn của bạn chống lại thứ hạng. Nếu không, hoặc nếu chọn khóa phân cụm không có sẵn trong SimpleDB, thì chỉ cần tạo một chỉ mục có thứ hạng là cột hàng đầu. Điều này sẽ đáp ứng các truy vấn 3-6.
• Một chỉ mục trên bản ghi trước rồi xếp hạng (hoặc, trong thế giới Máy chủ SQL, chỉ cần ghi và INCLUDExếp hạng hoặc chỉ ghi nếu bạn phân cụm theo thứ hạng) sẽ đáp ứng truy vấn 7.
• Hoạt động 1 và 2 có thể được tối ưu hóa bằng cách sắp xếp dữ liệu của bạn một cách thích hợp (nghĩa là cài đặt FILLFACTORtrong SQL Server). Điều này đặc biệt quan trọng nếu bạn co cụm về thứ hạng.
• Khi bạn chèn hoặc cập nhật thứ hạng, hãy duy trì càng nhiều khoảng cách giữa các số thứ hạng càng tốt để giảm thiểu khả năng đó là bạn sẽ cần phải xếp hạng lại một bản ghi hiện có để phù hợp với việc chèn hoặc cập nhật xếp hạng. Ví dụ: nếu bạn xếp hạng các bản ghi của mình theo các bước 1000, bạn sẽ có đủ chỗ cho khoảng một nửa số thay đổi và chèn với cơ hội tối thiểu bạn sẽ cần xếp hạng lại một bản ghi không liên quan trực tiếp đến những thay đổi đó.
• Mỗi đêm xếp hạng lại tất cả các hồ sơ để thiết lập lại khoảng cách xếp hạng giữa chúng.
• Bạn có thể điều chỉnh tần suất của bảng xếp hạng lại hàng loạt cũng như kích thước khoảng cách xếp hạng để phù hợp với số lần chèn hoặc cập nhật dự kiến ​​của bạn so với số lượng hồ sơ hiện có. Vì vậy, nếu bạn có 100 nghìn hồ sơ và mong muốn các bản chèn và cập nhật của bạn là 10% trong số đó, hãy chừa đủ chỗ cho 10 nghìn cấp bậc mới và xếp hạng lại hàng đêm.
• Xếp hạng lại các bản ghi 500K là một hoạt động tốn kém, nhưng được thực hiện một lần một ngày hoặc một tuần ngoài giờ sẽ tốt cho cơ sở dữ liệu như vậy. Việc xếp hạng lại hàng giờ ngoài giờ này để duy trì khoảng cách xếp hạng là điều giúp bạn tiết kiệm được nhiều thứ hạng cho mỗi lần cập nhật thứ hạng hoặc chèn trong giờ bình thường và giờ cao điểm.

Nếu bạn mong đợi 100K + lần đọc trên bảng có kích thước 100K + tôi không khuyên bạn nên sử dụng phương pháp tiếp cận danh sách được liên kết. Nó sẽ không mở rộng quy mô tốt.

Tôi thường sử dụng phương pháp "xếp hạng" mà bạn mô tả. Thay vì loay hoay với việc cập nhật các hàng khi các mục cần sắp xếp lại, tôi thường có thể thoát khỏi việc xóa tất cả các bản ghi trong danh sách và chèn lại các mục mới theo đúng thứ tự. Phương pháp này được tối ưu hóa rõ ràng để lấy.

Một cách tiếp cận khác là mô hình hóa các bản ghi dưới dạng một danh sách được liên kết bằng cách sử dụng cột khóa ngoại tiếp theo phản xạ "tiền thân" trên bảng:

ID   setID   item       predecessor
---  ------  ------     ------------
1    1       Apple      null
2    1       Orange     1
3    2       Cucumber   null
4    1       Pear       2
5    1       Grape      4
6    2       Carrot     3

Bạn có thể dễ dàng truy xuất danh sách và thêm và xóa các mục với ít chi phí, nhưng việc lấy các bản ghi theo thứ tự phù hợp sẽ rất khó khăn. Có lẽ có một cách thông minh để thực hiện nó trong một truy vấn duy nhất, có thể có rất nhiều phép nối bảng bí danh.

Tôi thường sử dụng phương pháp sau này khi tôi lập mô hình mối quan hệ kiểu cây (danh mục, thư mục, bộ và tập hợp con). Tôi thường có một hàm đệ quy nào đó để tái tạo lại toàn bộ cây trong ứng dụng của mình.

Tôi sẽ nghĩ rằng điều cần làm là lưu trữ các thuộc tính hoặc các thuộc tính được sử dụng để tính thứ hạng và sau đó xây dựng một chỉ mục trên chúng. Thay vì cố gắng buộc cơ sở dữ liệu lưu trữ dữ liệu theo thứ tự vật lý hoặc sử dụng danh sách được liên kết được quản lý thủ công, tại sao không để công cụ cơ sở dữ liệu làm những gì nó được thiết kế để làm?

Đây là những hạn chế của một RDBMS không đơn giản như SimpleDB. Các tính năng bạn yêu cầu không thể được triển khai ở phía DB trong SimpleDB, chúng phải được triển khai từ phía lập trình / ứng dụng.

Đối với RDBMS như SQL server, các tính năng bạn yêu cầu thô sơ đối với chỉ mục được nhóm.

• Chèn (x) - Chèn bản ghi x vào bảng> Chèn đơn giản.
• Xóa (x) - Xóa bản ghi x khỏi bảng> Xóa đơn giản.

• Trước (x, n) - Trả về các bản ghi 'n' trước bản ghi x trong danh sách được sắp xếp. > Chọn kết quả top n trong đó x nhỏ hơn giá trị và sắp xếp theo mệnh đề.

• Sau (x, n) - Trả về các bản ghi 'n' thành công bản ghi x trong danh sách được sắp xếp. > Chọn kết quả top n trong đó x lớn hơn giá trị và thứ tự theo mệnh đề.

• Đầu tiên (n) - Trả về các bản ghi 'n' đầu tiên từ danh sách được sắp xếp. > Chọn kết quả n hàng đầu.

• Lần cuối (n) - Trả về các bản ghi 'n' cuối cùng từ danh sách đã sắp xếp. > Chọn kết quả n hàng đầu sau khi đặt hàng theo desc.

• So sánh (x, y) - Cho hai bản ghi x và y từ bảng, tìm nếu x> y. > Tuyên bố TSQL IF.

Đây là những gì tôi đã sử dụng để xếp hạng lại bảng Postgres của mình sau mỗi lần chèn:

CREATE OR REPLACE FUNCTION re_rank_list() RETURNS trigger AS $re_rank_list$
DECLARE
    temprow record;
    row_idx integer := 1;    
BEGIN
    FOR temprow IN
    SELECT * FROM your_schema.your_list WHERE list_id = NEW.list_id ORDER BY rank ASC
    LOOP
        UPDATE your_schema.your_list SET rank = row_idx * 100 WHERE id = temprow.id;
        row_idx := row_idx + 1;
    END LOOP;
    RETURN NEW;
END;
$re_rank_list$ LANGUAGE plpgsql;


CREATE TRIGGER re_rank_list AFTER UPDATE ON your_schema.your_list_value
    FOR EACH ROW 
    WHEN (pg_trigger_depth() = 0)
    EXECUTE PROCEDURE re_rank_list();

Đối với trường hợp sử dụng của tôi, hiệu suất không phải là vấn đề đáng lo ngại, nhưng sự tự tin rằng nó sẽ không bao giờ phá vỡ hoặc hành động kỳ quặc là điều quan trọng.