Mạng
Trước hết, kể từ khi sử dụng rowid và rownum dù sao cũng là nhà cung cấp khóa, bạn nên cân nhắc sử dụng các quy trình được lưu trữ trong cơ sở dữ liệu. Nó có thể giảm đáng kể chi phí truyền dữ liệu từ cơ sở dữ liệu đến máy chủ ứng dụng (đặc biệt nếu chúng nằm trên các máy khác nhau và được kết nối qua mạng).
Xem xét rằng bạn có 80 triệu bản ghi để truyền, đó có thể là cách tăng hiệu suất tốt nhất cho bạn, mặc dù nó phụ thuộc vào loại công việc mà chuỗi của bạn thực hiện.
Rõ ràng là tăng băng thông cũng sẽ giúp giải quyết các vấn đề về mạng.
Hiệu suất đĩa
Trước khi thực hiện các thay đổi trong mã, hãy kiểm tra tải của ổ cứng trong khi các tác vụ đang chạy, có lẽ nó không thể xử lý nhiều I / O như vậy (10 luồng đọc đồng thời).
Di chuyển sang SSD / RAID hoặc cơ sở dữ liệu phân cụm có thể giải quyết vấn đề. Mặc dù thay đổi cách bạn truy cập cơ sở dữ liệu sẽ không xảy ra trong trường hợp đó.
Đa luồng có thể giải quyết các vấn đề về CPU, nhưng cơ sở dữ liệu chủ yếu phụ thuộc vào hệ thống đĩa.
Rownum
Có một số vấn đề bạn có thể gặp phải nếu bạn triển khai nó bằng rowid và rownum.
1) rownum được tạo nhanh chóng cho mỗi kết quả của truy vấn. Vì vậy, nếu truy vấn không có explicitsorting và có thể một số bản ghi có các rownum khác nhau mỗi khi bạn chạy truy vấn.
Ví dụ:bạn chạy nó lần đầu tiên và nhận được kết quả như thế này:
some_column | rownum
____________|________
A | 1
B | 2
C | 3
sau đó bạn chạy nó lần thứ hai, vì bạn không có sắp xếp rõ ràng, dbms (vì một lý do nào đó mà chính nó đã biết) quyết định trả về kết quả như thế này:
some_column | rownum
____________|________
C | 1
A | 2
B | 3
2) điểm 1 cũng ngụ ý rằng nếu bạn sẽ lọc kết quả trên rownum nó sẽ tạo bảng tạm thời với TẤT CẢ kết quả và sau đó lọc nó
So rownum không phải là một lựa chọn tốt cho kết quả phân tách. Trong khi rowid có vẻ tốt hơn, nó cũng có một số vấn đề.
Rowid
Nếu bạn xem mô tả ROWID bạn có thể nhận thấy rằng "giá trị rowid xác định duy nhất một hàng trong cơ sở dữ liệu ".
Vì điều đó và thực tế là khi bạn xóa một hàng, bạn có một "lỗ hổng" trong chuỗi rowid, các rowid có thể được phân phối không đồng đều giữa các bản ghi bảng.
Vì vậy, ví dụ:nếu bạn có ba luồng và mỗi luồng tìm nạp 1'000'000 rowid, thì có thể một luồng sẽ nhận được 1'000'000 bản ghi và hai luồng khác 1 bản ghi. Vì vậy, một người sẽ bị choáng ngợp, trong khi hai người khác chết đói .
Nó có thể không phải là vấn đề lớn trong trường hợp của bạn, mặc dù nó rất có thể là vấn đề bạn đang gặp phải hiện tại với mẫu khóa chính.
Hoặc nếu trước tiên bạn tìm nạp tất cả các rowid trong dispatcher và sau đó chia đều chúng (như peter.petrov đã đề xuất) có thể làm được điều đó, mặc dù việc tìm nạp 80 triệu id vẫn có vẻ nhiều, tôi nghĩ sẽ tốt hơn nếu thực hiện chia nhỏ với một sql-query trả về đường viền của các khối.
Hoặc bạn có thể giải quyết vấn đề đó bằng cách đưa ra số lượng rowid thấp cho mỗi tác vụ và sử dụng khung Fork-Join được giới thiệu trong Java 7, tuy nhiên nó nên là đã sử dụng cẩn thận .
Cũng có một điểm rõ ràng:cả rownum và rowid đều không di động trên các cơ sở dữ liệu.
Vì vậy, sẽ tốt hơn nhiều nếu có cột "sharding" của riêng bạn nhưng sau đó bạn sẽ phải tự đảm bảo rằng nó chia các bản ghi thành nhiều phần bằng nhau hoặc ít hơn.
Cũng nên nhớ rằng nếu bạn định làm điều đó trong nhiều chuỗi, điều quan trọng là phải kiểm tra xem cơ sở dữ liệu chế độ khóa sử dụng gì , có lẽ nó chỉ khóa bảng cho mọi truy cập, khi đó đa luồng là vô nghĩa.
Như những người khác đã đề xuất, trước tiên bạn nên tìm lý do chính của hiệu suất thấp là gì (mạng, đĩa, khóa cơ sở dữ liệu, ngừng hoạt động chuỗi hoặc có thể bạn chỉ có các truy vấn dưới mức tối ưu - hãy kiểm tra các kế hoạch truy vấn).
