2012-03-12 74 views
6

Trước khi bạn đánh dấu câu hỏi này là trùng lặp, XIN VUI LÒNG NGHE TÔI RA !!
Tôi đã đọc các câu hỏi được hỏi ở đây về cách cải thiện hiệu suất, ví dụ: chỉ cần đề cập đến một vài số Improve INSERT-per-second performance of SQLite?What are the performance characteristics of sqlite with very large database files?SQLite: giới hạn thực tế là gì?

Tôi đang cố gắng làm cho sqlite hoạt động với kích thước tệp cơ sở dữ liệu là 5 gigabyte. Ngược lại, có những người ở đó, những người tuyên bố rằng sqlite hoạt động 'tuyệt vời' cho họ ngay cả khi kích thước cơ sở dữ liệu lớn tới 160 GB. Tôi đã không thử nó bản thân mình nhưng từ những câu hỏi hỏi, tôi đoán rằng tất cả các băng ghế dự bị-đánh dấu có lẽ được thực hiện chỉ với bảng trong cơ sở dữ liệu.

Tôi đang sử dụng một cơ sở dữ liệu với
- 20 hoặc lâu hơn bảng
- Một nửa trong số các bảng có hơn 15 cột
- Mỗi 15-or-cái cột bảng có 6/7 chính nước ngoài cột - Một vài trong số các bảng này đã phát triển để có 27 triệu bản ghi trong một tháng

Máy phát triển mà tôi đang sử dụng là 3 GHz Máy lõi tứ có 4 gờ RAM và phải mất hơn 3 phút chỉ để truy vấn row_count trong các bảng lớn này.

Tôi không thể tìm thấy bất kỳ cách nào để phân chia dữ liệu theo chiều ngang. Ảnh chụp tốt nhất mà tôi có là chia nhỏ dữ liệu trên nhiều tệp cơ sở dữ liệu cho mỗi bảng. Nhưng trong trường hợp đó, theo như tôi biết, các ràng buộc cột khóa ngoài không thể được sử dụng, vì vậy tôi sẽ phải tạo một bảng tự đủ (không có bất kỳ khóa ngoại).

Vì vậy, câu hỏi của tôi là
a) Tôi có sử dụng cơ sở dữ liệu sai cho công việc không?
b) Bạn nghĩ tôi đang đi sai ở đâu?
c) Tôi chưa thêm các chỉ mục trên các khóa ngoại trừ nếu chỉ truy vấn đếm hàng mất bốn phút thì các chỉ mục của các khóa ngoài sẽ giúp tôi như thế nào?

EDIT Để cung cấp thêm thông tin mặc dù không có ai đã yêu cầu cho nó :) Tôi đang sử dụng SQLite phiên bản 3.7.9 với phiên bản system.data.sqlite.dll 1.0.77.0

EDIT2: TÔI NGHĨ nơi tôi sẽ khác với những người biểu diễn 160 gigabyte là họ có thể chọn một bản ghi cá nhân hoặc một phạm vi nhỏ các bản ghi. Nhưng tôi phải tải tất cả 27 triệu hàng trong bảng của tôi, nối chúng với một bảng khác, nhóm các bản ghi theo yêu cầu của Người dùng và trả về kết quả. Bất kỳ đầu vào nào là cách tốt nhất để tối ưu hóa cơ sở dữ liệu cho kết quả như vậy.

Tôi không thể lưu trữ kết quả của truy vấn trước đó vì nó không có ý nghĩa trong trường hợp của tôi. Cơ hội nhấn cache sẽ khá thấp.

+2

Nếu người khác nói rằng cơ sở dữ liệu 160GB chạy tốt, rõ ràng nó phải là thứ bạn đang làm, nhưng bạn không nói với chúng tôi cách bạn làm mọi thứ, ngoại trừ việc bạn không có chỉ mục ở nước ngoài phím. Bạn đã thử * lập chỉ mục các khóa ngoại? –

+0

Theo các câu hỏi được hỏi, tôi đoán rằng 160 cơ sở dữ liệu Gb chỉ sử dụng một bảng. Không, tôi chưa thêm các chỉ mục trên các khóa ngoại, bởi vì ngay cả khi tôi chạy truy vấn mà các khóa ngoại không liên quan tức là 'Chọn số (*) từ some_table', sqlite mất vài phút để trả về kết quả của truy vấn này. Tôi sẽ thêm chỉ mục vào khóa ngoài và quay lại. Vui lòng cho tôi biết bạn muốn biết thêm thông tin nào. – WPFAbsoluteNewBie

+0

Bạn có chỉ mục trên bảng không? –

Trả lời

4

Có rất nhiều điều cần xem xét ở đây, nhưng lời khuyên đầu tiên của tôi sẽ không lấy thống kê hiệu suất của người khác theo mệnh giá. Hiệu suất cơ sở dữ liệu phụ thuộc vào rất nhiều thứ, bao gồm cơ sở dữ liệu của bạn được cấu trúc như thế nào, sự phức tạp của các truy vấn của bạn, chỉ mục nào bạn đã xác định (hoặc không), và thường là số lượng dữ liệu tuyệt đối trong chúng. Rất nhiều số hiệu suất được báo cáo đến từ rất nhiều thử nghiệm và lỗi, và/hoặc kết hợp cơ sở dữ liệu với công việc trong tầm tay. Nói theo cách khác, hiệu suất bạn sẽ nhận được từ bất kỳ DBMS nào không thể so sánh với hiệu năng của ứng dụng khác trừ khi bộ dữ liệu và cấu trúc của bạn gần giống hệt nhau - chúng chắc chắn là hướng dẫn và có lẽ là một lý tưởng để phấn đấu , nhưng bạn không nhất thiết phải nhận được hiệu suất điên rồ "ra khỏi hộp."

Tôi sẽ làm điểm bắt đầu, bắt đầu lập chỉ mục dữ liệu trên các bảng thực sự lớn (ngoại hình, từ nhận xét, bạn đã có) và xem điều gì xảy ra. một thời gian khá dài, nhưng đừng dừng lại ở đó.Thêm một số chỉ mục, thay đổi chúng xung quanh, hỏi bạn có đang lưu trữ dữ liệu mà bạn không cần lưu trữ hay không, và xem xét các truy vấn cơ sở dữ liệu khác, Tìm các ứng dụng và bài đăng trên blog khác sử dụng SQLite cho số hàng lớn và xem họ đã làm gì để giải quyết nó (có thể bao gồm thay đổi cơ sở dữ liệu). Đừng để nỗi sợ hãi ban đầu ngăn cản bạn, nghĩ rằng bạn đang đi xuống con đường sai lầm Có lẽ bạn đang có, có thể bạn không, nhưng không chỉ dừng lại với truy vấn COUNT. Ay bạn cắt nó, 27 triệu hồ sơ trong một bảng là một tấn crap. Cuối cùng, một lời khuyên cụ thể là: trong SQLite, không phân chia cơ sở dữ liệu thành nhiều tệp - Tôi không thấy điều đó giúp ích, bởi vì sau đó bạn sẽ phải làm nhiều việc hơn công việc truy vấn, rồi sau đó tham gia các bảng riêng biệt của bạn theo cách thủ công sau khi kết quả trả về từ nhiều truy vấn. Điều này là tái phát minh những gì RDBMS làm cho bạn, và nó là một ý tưởng điên rồ. Bạn sẽ không bằng cách nào đó tìm ra cách để tham gia nhanh hơn những người sáng tạo của hệ thống RDBMS - bạn chắc chắn sẽ lãng phí thời gian ở đó.

+0

Bạn có thể giải thích ý bạn là gì khi cắt bàn? Theo như tôi biết sqlite vốn không hỗ trợ bất kỳ phân vùng nằm ngang nào. – WPFAbsoluteNewBie

+0

Tôi đã không đề cập đến cơ sở dữ liệu, nó chỉ là một con số của bài phát biểu. Khi tôi nói "bất kỳ cách nào bạn ** slice ** [vấn đề này] ..." Tôi chỉ có nghĩa là "bất kỳ cách nào bạn ** tiếp cận ** vấn đề này, 27 triệu hồ sơ trong một bảng là rất nhiều." – jefflunt

0

số đếm (*) trong SQLite sẽ luôn chậm hơn khi so sánh với DMBS khác, vì nó quét bảng cho yêu cầu cụ thể đó. Nó không có một bảng thống kê để giúp đỡ. Điều đó không có nghĩa là các truy vấn ứng dụng của bạn sẽ chậm. Bạn cần phải kiểm tra các truy vấn của bạn để thực sự nói những gì bạn có thể mong đợi.

Một số nguyên tắc chung: Lập chỉ mục là tuyệt đối phải, bởi vì việc điều hướng một tập con dữ liệu trong cây nhị phân nhanh hơn rất nhiều so với duyệt toàn bộ bảng khi có kích thước khổng lồ. Để giúp tải thời gian, bạn nên sắp xếp dữ liệu của mình cho một chỉ mục duy nhất và nếu bạn không có chỉ mục duy nhất thì chỉ mục lớn nhất. Nếu bạn có thể thả các chỉ số trước khi tải và đưa nó trở lại sau, nó sẽ nhanh hơn. Nếu các kỹ thuật này không thể đáp ứng các thông số hoạt động và SLA của bạn, thì đã đến lúc thực hiện phân vùng theo chiều ngang và sử dụng "đính kèm" để mở rộng trên phạm vi dữ liệu bạn cần. SQLite có thể hỗ trợ tối đa 10 lần đính kèm. Tôi biết một số người nói phân vùng là công việc của công cụ, chứ không phải nhà phát triển, nhưng khi bạn phải đối mặt với giới hạn vật lý, bạn phải cuộn tay áo hoặc có thể chọn một công cụ thương mại đang thực hiện nó dưới trang bìa cho bạn.

0

Nếu bạn có 50MB db trở lên được triển khai trực tiếp trên phía máy khách, điều đó có nghĩa là bạn làm điều gì đó sai. Hãy thử di chuyển sang phía máy chủ trong khi lưu trữ khóa - giá trị quan trọng tại máy khách. (chỉ cần tham khảo) Bạn sẽ không có thời gian thực, nhưng ít nhất nó sẽ tạo ra một giải pháp thích hợp. "Phía máy chủ" là câu trả lời cho câu hỏi của bạn, đó là nếu bạn thả hoặc tối ưu hóa các yêu cầu thời gian thực, bởi vì đó là những gì bạn có (dựa trên mô tả của bạn). Trong mọi trường hợp. SQLite có thể xử lý hầu như bất cứ điều gì, nhưng từ kinh nghiệm cá nhân, chỉ cần cố gắng giữ cho mọi thứ đơn giản nhất có thể ngay cả trong chi phí của kết quả thời gian thực.

Các vấn đề liên quan