Hiệu năng của chỉ mụcDB

Question

Có thể ai đó chỉ cho tôi một bài viết, hoặc tốt nhất là cung cấp một số kinh nghiệm về hiệu suất của IndexedDB (lý tưởng trong Chrome) - tìm nạp, chèn và cập nhật hiệu suất như thế nào? Có vẻ như có một số lượng ý kiến ​​hợp lý rằng khá nhiều không thể sử dụng cho các tập dữ liệu của hơn một nghìn bản ghi nhưng tôi không chắc nếu điều này không chỉ do thiếu lập chỉ mục - chắc chắn khái niệm không thể chậm hơn so với lưu trữ web vì cả hai có lẽ sử dụng lưu trữ khóa-giá trị trong nội bộ?

Cảm ơn

Answer 1

Gần đây tôi đã thực hiện một số so sánh hiệu suất giữa WebSQL và IndexedDB. Đáng ngạc nhiên, IndexedDB thắng (mà tôi không mong đợi).

http://blog.oharagroup.net/post/16394604653/a-performance-comparison-websql-vs-indexeddb

---

Edit: URL ở trên là xuống, nhưng có sẵn trên archive.org: http://web.archive.org/web/20160418233232/http://blog.oharagroup.net/post/16394604653/a-performance-comparison-websql-vs-indexeddb

Nói tóm lại:

WebSQL mất trung bình giữa ~ 750-850ms để hoàn thành truy vấn và hiển thị kết quả; và IndexedDB mất trung bình ~ 300-350ms để hiển thị kết quả chính xác.

Answer 2

Chỉ ghi lại hiệu suất tôi đã thấy là the one produced by @Scott (tác giả của the other answer to this question). Thật không may, bài viết của ông không làm công lý Cơ sở dữ liệu Web SQL, vì nó sử dụng một mệnh đề HAVING không hiệu quả để hạn chế kích thước của tập kết quả. Tôi chỉnh SQL của Scott, thay thế HAVING, GROUP BY và LEFT JOIN với (hầu như) tương đương WHERE và phụ Selects:

SELECT p.Name AS ProgramName, 
     s.rowid, 
     s.Name, 
     s.NowShowing, 
     s.ProgramID, 
     (SELECT COUNT(*) FROM Episode WHERE SeriesID = s.rowid AND STATUS IN ('Watched', 'Recorded', 'Expected') OR STATUS IS NULL) AS EpisodeCount, 
     (SELECT COUNT(*) FROM Episode WHERE SeriesID = s.rowid AND STATUS = 'Watched') AS WatchedCount, 
     (SELECT COUNT(*) FROM Episode WHERE SeriesID = s.rowid AND STATUS = 'Recorded') AS RecordedCount, 
     (SELECT COUNT(*) FROM Episode WHERE SeriesID = s.rowid AND STATUS = 'Expected') AS ExpectedCount 
    FROM Program p 
    JOIN Series s ON p.rowid = s.ProgramID 
WHERE s.NowShowing IS NOT NULL OR 
     EXISTS (SELECT * FROM Episode WHERE SeriesID = s.rowid AND STATUS IN ('Recorded', 'Expected')) 
ORDER BY CASE 
      WHEN s.NowShowing IS NULL THEN 1 
      ELSE 0 
     END, 
     s.NowShowing, 
     p.Name 

Đây là nhanh hơn so với bản gốc khoảng 28 lần - 20 ms vs 560 ms trên máy tính của tôi - trong đó, bằng cách ngoại suy từ các số của Scott, làm cho nó nhanh hơn khoảng 10 lần so với IndexedDB tương đương. Tôi đã không thể xác nhận điều này vì mã IndexedDB không hoạt động trong trình duyệt của tôi, dường như do thay đổi API.

Tôi nên giải thích "(gần như)" tôi đã viết ở trên. SQL ban đầu của tôi và của tôi có ý nghĩa khác nhau một cách tinh tế: một mệnh đề WHERE vô cớ trong tập EpisodeCount của tôi - có tác dụng thay thế quét bảng bằng tìm kiếm chỉ mục - có thể không tính một số tập nếu nó không bao gồm tất cả các giá trị Trạng thái có thể. Việc loại bỏ mệnh đề này sẽ xóa bỏ sự khác biệt với chi phí nhân đôi thời gian thực hiện lên 40 ms.

Lưu ý rằng, trước đó, tôi discussed with Scott một thay đổi nhỏ hơn đối với SQL của mình cũng đạt được thời gian 40 ms.

CẬP NHẬT: Rất cám ơn Scott đã cập nhật số article của bạn để xác nhận cuộc thảo luận mà chúng tôi có.

Answer 3

Thực hiện một số so sánh hiệu suất giữa IndexeDB và các cơ sở dữ liệu phía máy khách và phía máy khách khác. Hiệu năng phụ thuộc vào trình duyệt khi Firefox thực hiện API IndexeDB nhiều hơn nhiều so với Chrome hoặc IE. Firefox đang sử dụng SQLlite làm cơ sở dữ liệu phụ trợ, do đó, IndexedDB được triển khai trên đầu trang của nó. Bạn có thể tìm thấy nhiều bài viết về hiệu suất của IndexedDB, nhưng chủ yếu là các reserches và các nhà phát triển đang nói rằng IDB thực hiện nhanh hơn với SQL như là một backend. So sánh với triển khai Chrome nơi IDB được triển khai ở trên cùng của LevelDB (là NOSQL) chậm hơn nhiều so với Firefox.Vào một WEBSQL kết thúc khác (khấu hao) đang hoạt động nhanh trong Chrome, trong Firefox không được hỗ trợ nữa.

Tôi đã xuất bản một bài báo có một số kết quả về hiệu suất của chỉ mục IndexedDB. https://www.researchgate.net/profile/Stefan_Kimak/publication/281065948_Performance_Testing_and_Comparison_of_Client_Side_Databases_Versus_Server_Side/links/55d3465c08ae0a3417226302/Performance-Testing-and-Comparison-of-Client-Side-Databases-Versus-Server-Side.pdf

Answer 4

Tôi gặp sự cố với quá trình chèn hàng loạt lớn (100.000 - 200.000 bản ghi). Tôi đã giải quyết tất cả các vấn đề về hiệu năng của IndexedDB bằng thư viện Dexie. Nó có tính năng quan trọng này:

Dexie có hiệu suất kick-ass. Đó là phương pháp hàng loạt tận dụng lợi thế của một tính năng không nổi tiếng trong indexedDB mà làm cho nó có thể lưu trữ công cụ mà không cần nghe mọi sự kiện onsuccess. Điều này tăng tốc độ hiệu suất đến mức tối đa.

Dexie: https://github.com/dfahlander/Dexie.js

BulkPut() ->http://dexie.org/docs/Table/Table.bulkPut()