Solr điều chỉnh hiệu suất

Question

Tôi đã đọc phần sau đây:

http://wiki.apache.org/solr/SolrPerformanceFactors

http://wiki.apache.org/solr/SolrCaching

http://www.lucidimagination.com/content/scaling-lucene-and-solr

Và tôi có thắc mắc về một vài điều:

1. Nếu tôi sử dụng tùy chọn JVM -XX:+UseCompressedStrings loại tiết kiệm bộ nhớ tôi có thể đạt được? Để giữ một ví dụ đơn giản, nếu tôi có 1 trường được lập chỉ mục (chuỗi) và 1 trường được lưu trữ (chuỗi) với omitNorms = true và omitTf = true, tôi có thể mong đợi loại tiết kiệm nào trong bộ nhớ cache của chỉ mục và tài liệu? Tôi đoán khoảng 50%, nhưng có lẽ đó là quá lạc quan.
2. Khi nào bộ nhớ cache của bộ lọc Solr hoạt động? Nếu tôi chỉ làm một truy vấn đơn giản với AND và một vài OR, và sắp xếp theo điểm số, tôi có cần nó không?
3. Nếu tôi muốn lưu vào bộ nhớ cache tất cả tài liệu trong bộ nhớ cache của tài liệu, tôi sẽ tính toán khoảng trống cần thiết như thế nào? Sử dụng ví dụ từ trên, nếu tôi có tài liệu 20M, sử dụng chuỗi đã nén và độ dài trung bình của trường được lưu trữ là 25 ký tự, là khoảng trống cần thiết về cơ bản (25 byte + small_admin_overhead) * 20M?
4. nếu tất cả tài liệu nằm trong bộ nhớ cache của tài liệu, bộ đệm truy vấn quan trọng như thế nào?
5. Nếu tôi muốn tự động hóa mọi tài liệu vào bộ nhớ cache của tài liệu, truy vấn autowarm sẽ là *:* làm điều đó?
6. Bài viết mở rộng-và-solr nói rằng FuzzyQuery chậm. Nếu tôi đang sử dụng tính năng kiểm tra chính tả của solr thì về cơ bản tôi đang sử dụng quyền truy vấn mờ (vì tính năng kiểm tra chính tả có cùng tính toán khoảng cách chỉnh sửa) không? Vì vậy, có lẽ truy vấn chính tả và truy vấn mờ là cả hai đều "chậm"?
7. Phần mô tả bộ nhớ cache trường lucene cho chuỗi là một chút khó hiểu. Tôi đọc nó một cách chính xác rằng không gian cần thiết về cơ bản là kích thước của trường chuỗi được lập chỉ mục + một số nguyên arry bằng số lượng các thuật ngữ duy nhất trong lĩnh vực đó?
8. Cuối cùng, dưới tối đa hóa thông lượng, có một tuyên bố về việc để lại đủ không gian cho bộ đệm đĩa của hệ điều hành. Nó nói, "Tất cả trong tất cả, cho một chỉ số quy mô lớn, nó là tốt nhất để chắc chắn rằng bạn có ít nhất một vài gigabyte RAM vượt quá những gì bạn đang đưa cho JVM." Vì vậy, nếu tôi có một máy bộ nhớ 12GB (như một ví dụ), tôi nên cung cấp cho ít nhất 2-3GB cho hệ điều hành? Tôi có thể ước tính không gian bộ nhớ cache đĩa cần thiết bởi hệ điều hành bằng cách nhìn vào kích thước chỉ mục trên đĩa?

Answer 1

1. Cách duy nhất để chắc chắn là dùng thử. Tuy nhiên, tôi dự kiến ​​sẽ tiết kiệm rất ít trong chỉ mục, vì chỉ mục sẽ chỉ chứa chuỗi thực tế một lần mỗi lần, phần còn lại là dữ liệu cho các vị trí của chuỗi đó trong tài liệu. Chúng không phải là một phần lớn của chỉ mục.
2. Bộ nhớ cache bộ lọc chỉ lưu trữ các truy vấn bộ lọc. Nó có thể không hữu ích cho trường hợp sử dụng chính xác của bạn, nhưng nhiều người thấy chúng hữu ích. Ví dụ: thu hẹp kết quả theo quốc gia, ngôn ngữ, loại sản phẩm, v.v. Solr có thể tránh tính lại kết quả truy vấn cho những thứ như thế này nếu bạn sử dụng chúng thường xuyên.
3. Thực tế, bạn chỉ cần thử và đo lường nó bằng một hồ sơ. Nếu không có kiến ​​thức sâu về chính xác cấu trúc dữ liệu được sử dụng, bất cứ điều gì khác là SWAG tinh khiết. Tính toán của bạn chỉ là tốt như bất cứ ai khác mà không có hồ sơ.
4. Bộ nhớ cache của tài liệu chỉ tiết kiệm thời gian trong việc cấu thành kết quả SAU KHI truy vấn đã được tính toán. Nếu bạn dành phần lớn thời gian của mình để tính toán các truy vấn, bộ nhớ cache của tài liệu sẽ làm bạn ít tốt. Bộ nhớ truy vấn chỉ hữu ích cho các truy vấn được sử dụng lại.Nếu không có truy vấn nào của bạn được lặp lại, thì Bộ nhớ truy vấn là vô ích
5. có, giả sử bộ nhớ cache Tài liệu đủ lớn để giữ tất cả.

6-8 Không dương.

Từ kinh nghiệm của riêng tôi với điều chỉnh hiệu suất Solr, bạn nên để Solr xử lý các truy vấn, chứ không phải lưu trữ tài liệu. Phần lớn các câu hỏi của bạn tập trung vào cách các tài liệu chiếm không gian. Solr là một công cụ tìm kiếm, không phải là kho lưu trữ tài liệu. Nếu bạn muốn Solr là FAST và chiếm bộ nhớ tối thiểu, thì điều duy nhất cần lưu giữ là thông tin chỉ mục cho các mục đích tìm kiếm. Bản thân tài liệu phải được lưu trữ, truy xuất và hiển thị ở nơi khác. Tốt nhất là trong hệ thống được tối ưu hóa đặc biệt cho công việc đó. Trường duy nhất bạn nên lưu trữ trong tài liệu Solr là một ID để truy xuất từ ​​hệ thống lưu trữ tài liệu.

Answer 2

Caches

Nói chung, bộ nhớ đệm trông giống như một ý tưởng tốt để cải thiện hiệu suất, nhưng điều này cũng có rất nhiều vấn đề:

• đối tượng lưu trữ có thể sẽ đi vào thế hệ cũ của người thu gom rác, tốn kém hơn để thu thập,
• việc quản lý việc chèn thêm và gợi ý bổ sung thêm một số chi phí.

Hơn nữa, bộ nhớ đệm không thể cải thiện độ trễ tìm kiếm của bạn nhiều trừ khi có các mẫu trong truy vấn của bạn. Ngược lại, nếu 20% lưu lượng truy cập của bạn là do một vài truy vấn, thì bộ nhớ cache kết quả truy vấn có thể thú vị. Cấu hình bộ nhớ cache yêu cầu bạn phải biết các truy vấn và tài liệu của mình rất tốt. Nếu không, bạn có lẽ nên vô hiệu hóa bộ nhớ đệm.

Thậm chí nếu bạn vô hiệu hóa tất cả bộ đệm, hiệu suất vẫn có thể khá tốt nhờ vào bộ nhớ đệm I/O OS. Thực tế, điều này có nghĩa rằng nếu bạn đọc cùng một phần của một tập tin một lần nữa và một lần nữa, nó có khả năng là nó sẽ được đọc từ đĩa chỉ lần đầu tiên, và sau đó từ bộ nhớ đệm I/O. Và vô hiệu hóa tất cả các cache cho phép bạn cung cấp ít bộ nhớ hơn cho JVM, do đó sẽ có nhiều bộ nhớ hơn cho bộ nhớ đệm I/O. Nếu hệ thống của bạn có 12GB bộ nhớ và nếu bạn cung cấp 2GB cho JVM, điều này có nghĩa là bộ nhớ đệm I/O có thể lưu trữ tới 10G chỉ mục của bạn (tùy thuộc vào các ứng dụng khác yêu cầu bộ nhớ).

Tôi recommand bạn đọc để có thêm thông tin về bộ nhớ cache ứng dụng cấp so với I/O cache:

https://www.varnish-cache.org/trac/wiki/ArchitectNotes

http://antirez.com/post/what-is-wrong-with-2006-programming.html

Dòng bộ nhớ cache

Kích thước của bộ đệm trường cho một chuỗi là (một mảng các số nguyên của chiều dài maxDoc) + (một mảng cho tất cả các cá thể chuỗi duy nhất). Vì vậy, nếu bạn có chỉ mục với một trường chuỗi có N trường hợp kích thước S trung bình và nếu chỉ mục của bạn có tài liệu M thì kích thước của bộ nhớ cache trường cho trường này sẽ là khoảng M * 4 + N * S.

Bộ nhớ cache trường chủ yếu được sử dụng cho các khía cạnh và sắp xếp. Ngay cả các chuỗi rất ngắn (ít hơn 10 ký tự) are more than 40 bytes, điều này có nghĩa là bạn nên mong đợi Solr yêu cầu nhiều bộ nhớ nếu bạn sắp xếp hoặc khía cạnh trên trường Chuỗi có số lượng giá trị duy nhất cao.

Fuzzy Query

FuzzyQuery is slow in Lucene 3.x, but much faster in Lucene 4.x.

Nó phụ thuộc vào việc thực hiện kiểm tra chính tả bạn chọn nhưng tôi nghĩ rằng Solr kiểm tra 3.x chính tả sử dụng N-Grams để tìm ứng cử viên (đây là lý do tại sao nó cần một chỉ số chuyên dụng) và sau đó chỉ tính toán khoảng cách trên tập hợp này trên ứng cử viên, do đó hiệu suất vẫn hợp lý tốt.