Apache Solr

Chương 2: Documents, Fields, and Schema Design
2.1 Overview of Documents, Fields, and Schema Design
Tiền đề cơ bản của Solr khá là đơn giản. Bạn cung cấp cho nó rất nhiều thông
tin, sau đó bạn có thể hỏi nó câu hỏi và tìm thấy những thông tin bạn muốn.
Phần mà bạn cung cấp thông tin trong tất cả các thông tin được gọi là indexing
hoặc updating. Khi bạn đặt câu hỏi, nó được gọi là query.
Một cách để hiểu Solr làm việc như thế nào là nghĩ đến một quyển sách nấu ăn
lỏng lẻo. Mỗi lần bạn thêm công thức vào sách, bạn cập nhật chỉ mục ở mặt
sau. Bạn liệt kê từng thành phần và số trang của công thức mà bạn vừa thêm.
Giả sử bạn thêm một trăm công thức nấu ăn. Sử dụng chỉ mục, bạn có thể
nhanh chóng tìm thấy tất cả các công thức nấu ăn sử dụng đậu garbanzo, hoặc
atisô, hoặc cà phê, như một thành phần. Sử dụng chỉ mục nhanh hơn nhiều so
với việc tìm kiếm từng công thức một. Hãy tưởng tượng một cuốn sách của
1000 công thức nấu ăn, hoặc một triệu.
Solr cho phép bạn xây dựng một chỉ mục với nhiều lĩnh vực khác nhau, hoặc
các loại mục. Ví dụ trên cho thấy làm thế nào để xây dựng một chỉ mục chỉ với
một trường, các thành phần. Bạn có thể có các lĩnh vực khác trong chỉ mục cho
cách nấu ăn của công thức nấu ăn, Asia, Cajun, hoặc vegan, và bạn có thể có
một trường chỉ mục cho thời gian chuẩn bị. Solr có thể trả lời những câu hỏi
như "Những công thức nấu ăn kiểu Cajun nào có dùng cam đỏ như một thành
phần có thể được chuẩn bị trong vòng chưa tới 30 phút?"
Lược đồ là nơi bạn cho Solr cách xây dựng chỉ mục từ các tài liệu đầu vào.
2.1.1 How Solr Sees the World

Đơn vị cơ bản của thông tin Solr là một document, là một bộ dữ liệu mô tả một
cái gì đó. Một tài liệu về công thức sẽ chứa các thành phần, hướng dẫn, thời
gian chuẩn bị, thời gian nấu, các công cụ cần thiết, v.v ... Ví dụ: một tài liệu về
một người có thể chứa tên, tiểu sử, màu sắc yêu thích và kích thước giày của
người đó. Tài liệu về sách có thể chứa tiêu đề, tác giả, năm xuất bản, số trang,
v.v ...
Trong vũ trụ Solr, các tài liệu bao gồm các filed, đó là những thông tin cụ thể
hơn. Kích thước giày có thể là một cánh đồng. Tên và họ là field.
Các trường có thể chứa các loại dữ liệu khác nhau. Một trường tên, ví dụ, là
văn bản (dữ liệu đối tượng). Trường kích thước giày có thể là một số điểm nổi
để nó có thể chứa các giá trị như 6 và 9.5. Rõ ràng, định nghĩa các trường là
linh hoạt (bạn có thể định nghĩa một trường kích thước giày như một trường
văn bản chứ không phải là một số điểm nổi), nhưng nếu bạn xác định chính xác
các trường của mình, Solr sẽ có thể giải thích chúng một cách chính xác và
người dùng của bạn sẽ nhận được kết quả tốt hơn khi họ thực hiện truy vấn.
Bạn có thể cho Solr biết loại dữ liệu mà một trường chứa bằng cách xác định
loại trường của nó. Loại trường cho Solr cách giải thích trường và cách nó có
thể được truy vấn.
Khi bạn thêm một tài liệu, Solr lấy thông tin trong các trường của tài liệu và
thêm thông tin vào một chỉ mục. Khi bạn thực hiện một truy vấn, Solr có thể
nhanh chóng tham khảo chỉ mục và trả lại các tài liệu phù hợp.
2.1.2 Field Analysis

Field Analysis cho Solr biết phải làm gì với dữ liệu đến khi xây dựng một chỉ
mục. Một tên chính xác hơn cho quá trình này sẽ được processing hoặc thậm
chí digestion, nhưng tên chính thức là analysis.
Ví dụ, hãy xem xét một trường tiểu sử trong một tài liệu người. Mỗi từ của tiểu
sử phải được lập chỉ mục để bạn có thể nhanh chóng tìm thấy những người có
cuộc sống có liên quan đến cà chua, chuồn chuồn hoặc mật mã.
Tuy nhiên, tiểu sử có thể chứa nhiều từ bạn không quan tâm và không muốn
làm tắc nghẽn các từ chỉ mục của bạn như "the", "a", "to", v.v ... Hơn nữa, giả
sử tiểu sử chứa từ "Ketchup", viết hoa ở đầu câu. Nếu người dùng thực hiện
truy vấn cho "ketchup", bạn muốn Solr cho bạn biết về người đó mặc dù tiểu
sử có chứa chữ viết hoa.
Giải pháp cho cả hai vấn đề này là phân tích thực địa. Đối với lĩnh vực tiểu sử,
bạn có thể nói cho Solr làm thế nào để phá vỡ các tiểu sử thành từ. Bạn có thể
nói cho Solr rằng bạn muốn làm cho tất cả các từ chữ thường, và bạn có thể
cho Solr để loại bỏ dấu.
Phân tích hiện trường là một phần quan trọng của một loại trường.
Understanding Analyzers, Tokenizers, and Filters là một mô tả chi tiết về phân
tích hiện trường.
2.1.3 Solr’s Schema File
Solr lưu trữ chi tiết về các loại trường và các trường mà nó dự kiến sẽ hiểu
trong một tệp giản đồ. Tên và vị trí của tệp này có thể khác nhau tùy thuộc vào
cách bạn cấu hình Solr ban đầu hoặc nếu bạn đã sửa đổi nó sau này.
 Managed-schema là tên của tệp lược đồ Solr sử dụng mặc định để hỗ
trợ thực hiện các thay đổi Schema khi chạy thông qua schema API, hoặc
các tính năng của Schemaless Mode. Bạn có thể cấu hình rõ ràng các tính
năng lược đồ được quản lý để sử dụng tên tệp khác nếu bạn chọn,
nhưng nội dung của tệp vẫn được Solr cập nhật tự động.
 Schema.xml là tên truyền thống của tệp giản đồ có thể được chỉnh sửa
thủ công bởi người dùng sử dụng ClassicIndexSchemaFactory.
 Nếu bạn đang sử dụng SolrCloud, bạn sẽ không thể tìm thấy bất kỳ tập
tin nào bằng các tên này trên hệ thống tập tin cục bộ. Bạn chỉ có thể xem
sơ đồ thông qua schema API(nếu được bật) hoặc thông qua Solr Admin
UI’s Cloud Screens.
Cho dù tên của tệp được sử dụng trong cài đặt của bạn, cấu trúc của tệp không
bị thay đổi. Tuy nhiên, cách bạn tương tác với tệp sẽ thay đổi. Nếu bạn đang sử
dụng giản đồ được quản lý, dự kiến rằng bạn chỉ tương tác với tệp bằng
Schema API và không bao giờ thực hiện các chỉnh sửa thủ công. Nếu bạn không
sử dụng giản đồ được quản lý, bạn sẽ chỉ có thể thực hiện chỉnh sửa thủ công
đối với tệp, Schema API sẽ không hỗ trợ bất kỳ sửa đổi nào.
Lưu ý rằng nếu bạn không sử dụng API của Schema nhưng bạn sử dụng
SolrCloud, bạn sẽ cần phải tương tác với schema.xml thông qua ZooKeeper
bằng lệnh upconfig và downconfig để tạo bản sao cục bộ và tải các thay đổi của
bạn. Các tùy chọn để thực hiện việc này được mô tả trong Tài liệu tham khảo
Solr Control Script Reference and Using ZooKeeper to Manage Configuration
Files.
2.2 Solr Field Types

Kiểu trường xác định cách Solr giải thích dữ liệu trong một trường và cách lĩnh
vực này có thể được truy vấn. Có nhiều loại trường bao gồm trong Solr theo
mặc định, và chúng cũng có thể được định nghĩa cục bộ.
2.2.1 Field Type Definitions and Properties
Một loại trường xác định phân tích sẽ xảy ra trên một trường khi tài liệu được
lập chỉ mục hoặc các truy vấn được gửi tới chỉ mục.
Định nghĩa kiểu trường có thể bao gồm bốn loại thông tin:
 Tên của loại trường (bắt buộc).
 Tên lớp triển khai (bắt buộc).
 Nếu kiểu trường là TextField, mô tả của việc phân tích trường cho kiểu
trường.
 Thuộc tính loại trường - phụ thuộc vào lớp thực hiện, một số thuộc tính
có thể là bắt buộc.
2.2.1.1 Field Type Definitions in schema.xml
Các loại trường được xác định trong schema.xml. Mỗi loại trường được xác
định giữa các phần tử fieldType. Họ có thể tùy ý được nhóm lại trong một phần
tử kiểu. Dưới đây là một ví dụ về một định nghĩa kiểu trường cho một loại
được gọi là text_general:
 Dòng đầu tiên trong ví dụ trên chứa tên trường, text_general, và tên của
lớp triển khai, solr.TextField.
 Phần còn lại của là về phân tích hiện trường, được mô tả trong
Understanding Analyzers, Tokenizers, and Filters.
Lớp triển khai có trách nhiệm đảm bảo trường được xử lý chính xác. Trong tên
lớp trong schema.xml, chuỗi ký tự là viết tắt cho org.apache.solr.schema hoặc
org.apache.solr.analysis. Vì vậy, solr.TextField thực sự là
org.apache.solr.schema.TextField.
2.2.1.2 Field Type Properties

Lớp trường lĩnh vực xác định hầu hết các hành vi của một loại trường, nhưng
các thuộc tính tùy chọn cũng có thể được định nghĩa. Ví dụ, định nghĩa sau đây
của một loại trường ngày định nghĩa hai thuộc tính, sortMissingLast và
omitNorms.
Các thuộc tính có thể được xác định cho một loại trường nhất định được chia
thành ba loại chính:
 Thuộc tính cụ thể cho lớp của trường loại.
 Các thuộc tính chung Solr hỗ trợ cho bất kỳ loại trường nào.
 Các thuộc tính mặc định của trường có thể được chỉ định trên trường
trường sẽ được thừa hưởng bởi các trường sử dụng loại này thay vì
hành vi mặc định.
2.2.1.3 General Properties
Property Description Values
name Tên của fieldType. Giá trị này
được sử dụng trong các định
nghĩa trường, trong thuộc tính
"type". Chúng tôi đề nghị rằng các
tên bao gồm các ký tự chữ hoặc
số gạch dưới và không bắt đầu
bằng chữ số. Đây không phải là
thực thi nghiêm ngặt.
class Tên lớp được sử dụng để lưu trữ
và lập chỉ mục dữ liệu cho loại
này. Lưu ý rằng bạn có thể thêm
tiền tố bao gồm các tên lớp với
"solr." và Solr sẽ tự động tìm ra
gói để tìm kiếm lớp - vì vậy
solr.TextField sẽ làm việc. Nếu
bạn đang sử dụng một lớp của
bên thứ ba, có lẽ bạn sẽ cần phải
có một tên lớp đủ điều kiện. Các
tương đương đủ điều kiện cho
solr.TextField là
org.apache.solr.schema.TextField.
positionIncrementGap Đối với trường nhiều cạnh, chỉ integer
định khoảng cách giữa nhiều giá
trị, ngăn ngừa các kết hợp cụm
giả mạo.
autoGeneratePhraseQueries Đối với trường văn bản. Nếu true or
đúng, Solr tự động tạo ra các truy false
vấn cụm từ cho các điều khoản
lân cận. Nếu sai, thuật ngữ phải
được bao gồm trong ngoặc kép
để được coi là cụm từ.
enableGraphQueries Đối với trường văn bản, áp dụng true or
khi truy vấn với sow = false. Sử false
dụng đúng (mặc định) cho các
loại trường với các trình phân tích
truy vấn bao gồm các bộ lọc nhận
biết đồ thị, ví dụ: Synonym Graph
Filter and Word Delimiter Graph
Filter. Sử dụng false cho loại
trường với các trình phân tích
truy vấn bao gồm các bộ lọc có
thể khớp tài liệu khi thiếu một số
mã, ví dụ: Shingle Filter.
docValuesFormat Định nghĩa một DocValuesFormat n/a
tùy chỉnh để sử dụng cho các
trường kiểu này. Điều này đòi hỏi
một codec nhận dạng giản đồ,
chẳng hạn như
SchemaCodecFactory đã được
cấu hình trong solrconfig.xml.
docValuesFormat Định nghĩa một PostingsFormat n/a
tùy chỉnh để sử dụng cho các
trường kiểu này. Điều này đòi hỏi
một codec nhận dạng giản đồ,
chẳng hạn như
SchemaCodecFactory đã được
cấu hình trong solrconfig.xml.
2.2.2 Field Types Included with Solr
Bảng dưới đây liệt kê các loại trường hiện có trong Solr. Gói
org.apache.solr.schema bao gồm tất cả các lớp được liệt kê trong bảng này.
Class Description
BinaryField Binary data.
Có chứa true hoặc false. Các giá trị
của "1", "t", hoặc "T" trong ký tự đầu
BoolField tiên được hiểu là true. Bất kỳ giá trị
nào khác trong ký tự đầu tiên được
hiểu là false.
Hỗ trợ so khớp Unicode cho các truy
vấn sắp xếp và phạm vi.
CollationField ICUCollationField là sự lựa chọn tốt
hơn nếu bạn có thể sử dụng ICU4J.
Xem phần Unicode Collation.
Hỗ trợ tiền tệ và tỷ giá. Xem phần
CurrencyField Working with Currencies and
Exchange Rates.
Hỗ trợ các phạm vi ngày lập chỉ mục,
bao gồm các trường hợp điểm thời
gian (thời lượng một milli giây). Xem
phần Working with Dates để biết
thêm chi tiết về việc sử dụng loại
DateRangeField
trường này. Xem xét sử dụng trường
trường này ngay cả khi nó chỉ dành
cho các trường hợp ngày, đặc biệt khi
các truy vấn thường rơi vào UTC năm
/ tháng / ngày / giờ, vv, ranh giới.
Kéo giá trị từ một tệp trên đĩa. Xem
ExternalFileField phần Working with External Files and
Processes.
Cho phép xác định một tập hợp các
giá trị liệt kê có thể không được sắp
EnumField
xếp dễ dàng theo thứ tự chữ cái hoặc
số (chẳng hạn như danh sách các
mức độ nghiêm trọng, ví dụ). Loại
trường này lấy tệp cấu hình, liệt kê
thứ tự đúng của giá trị trường. Xem
phần Working with Enum Fields để
biết thêm thông tin.
Hỗ trợ so khớp Unicode cho các truy
ICUCollationField vấn sắp xếp và phạm vi. Xem phần
Unicode Collation.
Spatial Search: một cặp vĩ độ / kinh
độ; có thể nhiều giá trị cho nhiều
LatLonPointSpatialField
điểm. Thông thường, nó được chỉ
định là "lat, lon" với một dấu phẩy.
(deprecated) Spatial Search: cặp phối
hợp vĩ độ vĩ độ / đơn vị kinh độ.
LatLonType
Thông thường, nó được chỉ định là
"lat, lon" với một dấu phẩy.
Spatial Search: Một điểm n chiều có
giá trị duy nhất. Nó vừa để phân loại
các dữ liệu không gian không phải là
PointType lat-lon, và cho một số trường hợp sử
dụng hiếm hoi hơn. (CHÚ Ý: đây
không liên quan đến các trường số
"dựa trên điểm")
Cung cấp một cách để gửi đến các
luồng mã thông báo được nối tiếp
Solr, tùy chọn với các giá trị được lưu
trữ độc lập của một trường, và có
thông tin này được lưu trữ và lập chỉ
PreAnalyzedField
mục mà không cần bất kỳ xử lý văn
bản bổ sung. Cấu hình và sử dụng
PreanalyzedField được ghi lại trên
trang Working with External Files and
Processes.
Không chứa giá trị. Truy vấn sắp xếp
theo kiểu trường này sẽ trả về kết
RandomSortField quả theo thứ tự ngẫu nhiên. Sử dụng
trường năng động để sử dụng tính
năng này.
(RPT for short) Spatial Search: Chấp
SpatialRecursivePrefixTreeFieldType
nhận chuỗi kinh độ vĩ tuyến vĩ độ
hoặc các hình dạng khác ở định dạng
WKT.
Chuỗi (chuỗi được mã hoá UTF-8
hoặc Unicode). Chuỗi được dùng cho
các lĩnh vực nhỏ và không được đánh
StrField
dấu hoặc phân tích dưới bất kỳ hình
thức nào. Họ có giới hạn cứng hơi ít
hơn 32K.
Văn bản, thường là nhiều từ hoặc các
TextField
thẻ.
Trường Date. Biểu thị một điểm
trong thời gian với độ chính xác
millisecond. Xem phần Working with
Dates. precisionStep = "0" giảm thiểu
kích thước chỉ mục; precisionStep =
TrieDateField
"8" (mặc định) cho phép truy vấn
phạm vi hiệu quả hơn. Đối với trường
có giá trị duy nhất, hãy sử dụng
docValues = "true" để phân loại hiệu
quả.
Trường đôi (điểm nổi IEEE 64-bit).
precisionStep = "0" giảm thiểu kích
thước chỉ mục; precisionStep = "8"
TrieDoubleField (mặc định) cho phép truy vấn phạm
vi hiệu quả hơn. Đối với trường có giá
trị duy nhất, hãy sử dụng docValues =
"true" để phân loại hiệu quả.
Trường điểm nổi (điểm nổi IEEE 32-
bit). precisionStep = "0" cho phép
phân loại số hiệu quả và giảm thiểu
TrieFloatField
phạm vi hiệu quả. Sử dụng docValues
= "true" để phân loại hiệu quả. Đối
với trường có giá trị duy nhất, hãy sử
dụng docValues = "true" để phân loại
hiệu quả.
Trường số nguyên (số nguyên ký số
TrieIntField 32 bit). precisionStep = "0" cho phép
phân loại số hiệu quả và giảm thiểu
phạm vi hiệu quả. Đối với trường có
giá trị duy nhất, hãy sử dụng
docValues = "true" để phân loại hiệu
quả.
Trường dài (ký số số nguyên 64 bit).
precisionStep = "0" giảm thiểu kích
thước chỉ mục; precisionStep = "8"
TrieLongField (mặc định) cho phép truy vấn phạm
vi hiệu quả hơn. Đối với trường có giá
trị duy nhất, hãy sử dụng docValues =
"true" để phân loại hiệu quả.
Nếu loại trường này được sử dụng,
một thuộc tính "type" cũng phải
được chỉ định, các giá trị hợp lệ là: số
TrieField nguyên, long, float, double, date. Sử
dụng trường này cũng giống như sử
dụng bất kỳ trường Trie nào đã đề
cập ở trên.
Trường Date. Biểu thị một điểm
trong thời gian với độ chính xác
millisecond. Xem phần Working with
Dates. Lớp này hoạt động tương tự
như TrieDateField, nhưng sử dụng
DatePointField cấu trúc dữ liệu "Điểm thứ bậc" thay
vì các thuật ngữ được lập chỉ mục, và
không yêu cầu cấu hình của một
bước chính xác. Đối với trường có giá
trị duy nhất, docValues = "true" phải
được sử dụng để cho phép phân loại.
Trường đôi (điểm nổi IEEE 64-bit).
Lớp này hoạt động tương tự như
TrieDoubleField, nhưng sử dụng cấu
trúc dữ liệu "Điểm thứ bậc" thay vì
DoublePointField các thuật ngữ được lập chỉ mục, và
Trường điểm nổi (điểm nổi IEEE 32-
bit). Lớp này hoạt động tương tự như
TrieFloatField, nhưng sử dụng cấu
trúc dữ liệu "Điểm thứ bậc" thay vì
FloatPointField các thuật ngữ được lập chỉ mục, và
Trường số nguyên (số nguyên ký số
32 bit). Lớp này hoạt động tương tự
như TrieIntField, nhưng sử dụng cấu
trúc dữ liệu "Dimensional Points"
thay vì các thuật ngữ được lập chỉ
IntPointField
mục, và không yêu cầu cấu hình của
một bước chính xác. Đối với trường
có giá trị duy nhất, docValues =
"true" phải được sử dụng để cho
phép phân loại.
Trường dài (ký số số nguyên 64 bit).
Lớp này hoạt động tương tự như
TrieLongField, nhưng sử dụng cấu
trúc dữ liệu "Điểm thứ hai" thay vì
LongPointField các thuật ngữ được lập chỉ mục, và
Mã nhận dạng duy nhất chung
(UUID). Đi qua giá trị "NEW" và Solr
sẽ tạo một UUID mới. Lưu ý: việc cấu
hình một thể hiện UUIDField với giá
trị mặc định là "NEW" không được
khuyến khích cho hầu hết người dùng
UUIDField
khi sử dụng SolrCloud (và không thể
nếu giá trị UUID được định cấu hình
làm trường khoá duy nhất) vì kết quả
sẽ là mỗi bản sao của mỗi tài liệu sẽ
nhận được giá trị UUID duy nhất. Sử
dụng UUIDUpdateProcessorFactory
để tạo ra các giá trị UUID khi thêm tài
liệu được đề nghị thay thế.
2.2.3 Working with Currencies and Exchange Rates
Loại tiền tệ FieldType cung cấp hỗ trợ cho các giá trị tiền tệ cho Solr / Lucene
với việc chuyển đổi tiền tệ theo thời gian truy vấn và tỷ giá hối đoái. Các tính
năng sau đây được hỗ trợ:
 Truy vấn điểm
 Truy vấn phạm vi
 Truy vấn phạm vi chức năng
 Phân loại
 Phân tích tiền tệ theo mã tiền tệ hoặc biểu tượng
Tỷ giá hối đoái đối xứng và không đối xứng (tỷ giá bất đối xứng rất hữu ích
nếu có phí liên quan đến việc trao đổi đồng tiền)
2.2.3.1 Configuring Currencies
Loại trường tiền tệ được định nghĩa trong schema.xml. Đây là cấu hình mặc
định của loại này:
<fieldType name="currency" class="solr.CurrencyField" precisionStep="8"
defaultCurrency="USD" currencyConfig="currency.xml" />
Trong ví dụ này, chúng tôi đã xác định tên và lớp của loại trường và định nghĩa
defaultcurrency là "USD", cho Đô la Mỹ. Chúng tôi cũng đã xác định một
CurrencyConfig để sử dụng tệp có tên "currency.xml". Đây là tệp tỷ giá giữa
ngoại tệ mặc định của chúng tôi với các đơn vị tiền tệ khác. Có một sự thực
hiện thay thế cho phép tải dữ liệu tiền tệ thường xuyên. Xem Tỷ giá ở bên dưới
để biết thêm.
Nhiều lược đồ ví dụ có tàu với Solr bao gồm một trường năng động sử dụng
loại này, chẳng hạn như ví dụ này:
<dynamicField name="*_c" type="currency" indexed="true" stored="true"/>
Trường năng động này sẽ khớp với bất kỳ trường nào kết thúc bằng _c và làm
cho trường đó đánh dấu một loại tiền tệ.
Tại thời điểm lập chỉ mục, các trường tiền tệ có thể được lập chỉ mục bằng một
loại tiền tệ bản địa. Ví dụ: nếu một sản phẩm trên trang web thương mại điện
tử được liệt kê bằng Euro, lập chỉ mục trường giá là "1000, EUR" sẽ lập chỉ mục
một cách thích hợp. Giá phải được tách ra khỏi đồng tiền bằng dấu phẩy, và giá
phải được mã hoá với một giá trị điểm nổi (một dấu thập phân thập phân).
Trong quá trình xử lý truy vấn, phạm vi và các truy vấn điểm đều được hỗ trợ.
2.2.3.2 Exchange Rates

Bạn định cấu hình tỷ giá bằng cách chỉ định một nhà cung cấp. Tự nhiên, hai
loại nhà cung cấp được hỗ trợ: FileExchangeRateProvider hoặc
OpenExchangeRatesOrgProvider.
2.2.3.3 FileExchangeRateProvider
Nhà cung cấp này yêu cầu bạn cung cấp một tập tin của tỷ giá hối đoái. Đó là
mặc định, có nghĩa là để sử dụng nhà cung cấp này, bạn chỉ cần xác định
đường dẫn tệp và tên như là một giá trị cho currencyConfig trong định nghĩa
cho loại này.
Có một tệp mẫu currency.xml có trong Solr, được tìm thấy trong cùng một thư
mục với tệp schema.xml. Dưới đây là một đoạn nhỏ từ tệp này:
<currencyConfig version="1.0">
<rates>

<rate from="USD" to="ARS" rate="4.333871" comment="ARGENTINA Peso" />
<rate from="USD" to="AUD" rate="1.025768" comment="AUSTRALIA Dollar" />
<rate from="USD" to="EUR" rate="0.743676" comment="European Euro" />
<rate from="USD" to="CAD" rate="1.030815" comment="CANADA Dollar" />


<rate from="EUR" to="GBP" rate="0.869914" />
<rate from="EUR" to="NOK" rate="7.800095" />
<rate from="GBP" to="NOK" rate="8.966508" />


<rate from="EUR" to="USD" rate="0.5" />
</rates>
</currencyConfig>
2.2.3.4 OpenExchangeRatesOrgProvider
Bạn có thể cấu hình Solr để tải về tỷ giá hối đoái từ OpenExchangeRates.Org,
với mức giá cập nhật giữa USD và 170 tiền tệ hàng giờ. Các mức giá này chỉ
mang tính đối xứng.
Trong trường hợp này, bạn cần chỉ định providerClass trong các định nghĩa cho
kiểu trường và đăng ký một khóa API. Đây là một ví dụ:
<fieldType name="currency" class="solr.CurrencyField" precisionStep="8"
providerClass="solr.OpenExchangeRatesOrgProvider"
refreshInterval="60"
ratesFileLocation="http://www.openexchangerates.org/api/latest.json?app_id=
yourPersonalAppIdKey"/>
Thời gian refreshInterval là phút, vì vậy ví dụ trên sẽ tải xuống mức giá mới
nhất mỗi 60 phút. Khoảng làm mới có thể được tăng lên, nhưng không giảm.
2.2.4 Working with Dates
2.2.4.1 Date Formatting
Các trường ngày của Solr (TrieDateField, DatePointField và DateRangeField) đại

diện cho "ngày tháng" như là một điểm trong thời gian với độ chính xác mili
giây. Định dạng được sử dụng là một hình thức hạn chế của đại diện kinh điển
của dateTime trong đặc tả của Lược đồ XML - một tập con bị giới hạn của ISO-
8601. Đối với những người quen thuộc với Java 8, Solr sử dụng
DateTimeFormatter.ISO_INSTANT để định dạng và phân tích cú pháp quá với
"khoan hồng".
YYYY-MM-DDTHh: mm: ssZ
 YYYY là năm.
 MM là tháng.
 DD là ngày trong tháng.
 hh là giờ trong ngày như trên đồng hồ 24 giờ.
 mm là phút.
 ss là giây.
 Z là một chữ 'Z' ký tự chỉ ra rằng đại diện này của chuỗi ngày là UTC
Lưu ý rằng không thể chỉ định múi giờ; các biểu diễn chuỗi các ngày tháng luôn
được diễn tả trong Giờ Hợp nhất (UTC). Đây là một giá trị ví dụ:
1972-05-20T17: 33: 18Z
Bạn có thể tùy ý bao gồm các giây phân số nếu bạn muốn, mặc dù độ chính xác
vượt quá mili giây sẽ bị bỏ qua. Dưới đây là các giá trị ví dụ với các giây phụ:
 1972-05-20T17: 33: 18.772Z
 1972-05-20T17: 33: 18.77Z
 1972-05-20T17: 33: 18.7Z
Phải có một '-' hàng đầu cho các ngày trước năm 0000, và Solr sẽ định dạng
ngày với '+' hàng đầu cho năm sau năm 9999. Năm 0000 được coi là năm 1 BC;
không có những điều như năm 0 AD hoặc BC.
2.2.4.2 Date Range Formatting
Ngày thángRegionField của Solr hỗ trợ cùng một điểm trong cú pháp ngày
tháng được mô tả ở trên (với toán ngày được mô tả dưới đây) và nhiều hơn
nữa để thể hiện phạm vi ngày. Một lớp các ví dụ là ngày cắt ngắn, thể hiện
toàn bộ khoảng ngày đến độ chính xác đã chỉ ra. Các lớp khác sử dụng cú pháp
phạm vi ([TO]). Dưới đây là một số ví dụ:
 2000-11 - Cả tháng của tháng 11 năm 2000.
 2000-11T13 - Tương tự như vậy nhưng trong một giờ trong ngày (1300
đến trước 1400, tức là 13:00 đến 14:00).
 -0009 - Năm 10 TCN. A 0 tại vị trí năm là 0 AD, và cũng được coi là 1 BC.
 [2000-11-01 TO 2014-12-01] - Phạm vi ngày được chỉ định ở độ phân giải
ngày
 [2014 TO 2014-12-01] - Từ đầu năm 2014 cho đến cuối ngày đầu tiên của
tháng 12.
 [* TO 2014-12-01] - Từ thời gian có thể đại diện sớm nhất cho đến cuối
ngày vào ngày 2014-12-01.
Hạn chế: Cú pháp phạm vi không hỗ trợ toán học ngày được nhúng. Nếu bạn
chỉ định một trường hợp ngày được TrieDateField hỗ trợ với ngày toán cắt bớt
nó, giống như NOW / DAY, bạn vẫn nhận được mili giây đầu tiên của ngày đó
chứ không phải là phạm vi toàn bộ ngày. Phạm vi độc quyền (sử dụng {&}) hoạt
động trong các truy vấn chứ không phải cho các phạm vi lập chỉ mục.
2.2.4.3 Date Math
Các loại trường ngày của Solr cũng hỗ trợ các biểu thức toán học ngày, giúp dễ
dàng tạo ra các khoảng thời gian tương ứng với các khoảnh khắc cố định, bao
gồm thời gian hiện tại có thể được biểu diễn sử dụng giá trị đặc biệt của
"NOW".
2.2.4.4 Date Math Syntax
Các biểu thức toán học Date bao gồm hoặc thêm một số lượng thời gian vào
một đơn vị nhất định, hoặc làm tròn thời gian hiện tại của một đơn vị xác định.
biểu thức có thể được chuỗi và được đánh giá từ trái sang phải.
Ví dụ: điều này đại diện cho một điểm trong thời gian hai tháng kể từ bây giờ:
NOW + 2MONTHS
Đây là một ngày trước đây:
NOW-1DAY
Dấu gạch chéo được sử dụng để biểu thị làm tròn. Điều này đại diện cho sự bắt
đầu của giờ hiện tại:
NOW / HOUR
Ví dụ sau tính (với độ chính xác mili giây) thời điểm sáu tháng và ba ngày trong
tương lai và sau đó vòng tròn thời gian đó để bắt đầu ngày đó:
NGAY + 6 THÁNG + 3 NGÀY / NGÀY
Lưu ý rằng trong khi toán ngày được sử dụng phổ biến nhất so với NOW, nó
cũng có thể được áp dụng cho bất kỳ thời điểm cố định nào:
1972-05-20T17: 33: 18.772Z + 6 THÁNG + 3 NGÀY / NGÀY
2.2.4.5 Request Parameters That Affect Date Math

2.2.4.6 More DateRangeField Details
2.2.5 Working with Enum Fields
2.2.5.1 Defining an EnumField in schema.xml
Định nghĩa kiểu EnumField khá đơn giản, như trong ví dụ này xác định kiểu
trường cho các bảng liệt kê "priorityLevel" và "riskLevel":
<fieldType name="priorityLevel" class="solr.EnumField"
enumsConfig="enumsConfig.xml" enumName="priority"/>
<fieldType name="riskLevel" class="solr.EnumField"
enumsConfig="enumsConfig.xml" enumName="risk" />
Bên cạnh tên và lớp học, được phổ biến cho tất cả các loại trường, loại này
cũng mất hai thông số bổ sung:
 enumsConfig: tên của một tệp tin cấu hình có chứa danh sách các giá trị
của trường và thứ tự của chúng mà bạn muốn sử dụng với loại trường
này. Nếu một đường dẫn đến tập tin không được xác định quy định, tập
tin nên được trong thư mục conf cho bộ sưu tập.
 enumName: tên của liệt kê cụ thể trong tệp enumsConfig để sử dụng
cho loại này.
2.2.5.2 Defining the EnumField configuration file

Tệp có tên với tham số enumsConfig có thể chứa nhiều danh sách giá trị kê
khai với các tên khác nhau nếu có nhiều lần sử dụng cho liệt kê trong lược đồ
Solr của bạn.
Trong ví dụ này, có hai danh sách giá trị được xác định. Mỗi danh sách là giữa
enum mở và đóng thẻ:
<?xml version="1.0" ?>
<enumsConfig>
<enum name="priority">
<value>Not Available</value>
<value>Low</value>
<value>Medium</value>
<value>High</value>
<value>Urgent</value>
</enum>
<enum name="risk">
<value>Unknown</value>
<value>Very Low</value>
<value>Low</value>
<value>Medium</value>
<value>High</value>
<value>Critical</value>
</enum>
</enumsConfig>
2.2.6 Working with External Files and Processes

2.2.6.1 The ExternalFileField Type
Kiểu ExternalFileField cho phép xác định các giá trị cho một trường trong một
tệp nằm ngoài chỉ mục Solr. Đối với trường như vậy, tệp chứa các ánh xạ từ
trường khóa đến giá trị trường. Một cách khác để nghĩ đến điều này là, thay vì
xác định trường trong tài liệu khi chúng được lập chỉ mục, Solr tìm giá trị cho
trường này trong tệp ngoài.
Loại ExternalFileField rất tiện dụng cho những trường hợp bạn muốn cập nhật
một trường đặc biệt trong nhiều tài liệu thường xuyên hơn bạn muốn cập nhật
phần còn lại của tài liệu. Ví dụ: giả sử bạn đã triển khai xếp hạng tài liệu dựa
trên số lượt xem. Bạn có thể muốn cập nhật xếp hạng của tất cả các tài liệu
hàng ngày hoặc hàng giờ, trong khi phần nội dung còn lại của tài liệu có thể
được cập nhật ít thường xuyên hơn. Nếu không có ExternalFileField, bạn sẽ cần
phải cập nhật từng tài liệu chỉ để thay đổi thứ hạng. Sử dụng ExternalFileField
hiệu quả hơn nhiều bởi vì tất cả các giá trị tài liệu cho một lĩnh vực cụ thể được
lưu trữ trong một tệp tin bên ngoài có thể được cập nhật thường xuyên như
bạn muốn.
Trong schema.xml, định nghĩa kiểu trường này có thể giống như sau:
<fieldType name="entryRankFile" keyField="pkId" defVal="0" stored="false"
indexed="false" class="solr.ExternalFileField" valType="pfloat"/>
Thuộc tính keyField xác định khoá sẽ được định nghĩa trong tệp ngoài. Nó
thường là khóa duy nhất cho chỉ mục, nhưng nó không cần phải lâu như các
keyField có thể được sử dụng để xác định các tài liệu trong chỉ mục. Một
defVal định nghĩa một giá trị mặc định sẽ được sử dụng nếu không có mục
trong tệp ngoài cho một tài liệu cụ thể.
Thuộc tính valType xác định kiểu thực tế của các giá trị sẽ được tìm thấy trong
tệp. Loại được chỉ định phải là loại trường float, vì vậy các giá trị hợp lệ cho
thuộc tính này là pfloat, float hoặc tfloat. Thuộc tính này có thể được bỏ qua.
2.2.6.2 Format of the External File

Tập tin chính nó nằm trong thư mục chỉ mục của Solr, mặc định là $
SOLR_HOME / data. Tên của tệp phải là external_fieldname hoặc
external_fieldname. *. Đối với ví dụ trên, khi đó, tệp có thể được đặt tên
external_entryRankFile hoặc external_entryRankFile.txt.
2.2.6.3 Reloading an External File
Có thể xác định người nghe sự kiện để tải lại tệp tin bên ngoài khi người tìm
kiếm được tải lại hoặc khi một người tìm kiếm mới được bắt đầu. Xem phần
Query-Related Listeners để biết thêm thông tin, nhưng một định nghĩa mẫu
trong solrconfig.xml có thể như sau:
<listener event="newSearcher"
class="org.apache.solr.schema.ExternalFileFieldReloader"/>
<listener event="firstSearcher"
class="org.apache.solr.schema.ExternalFileFieldReloader"/>
2.2.6.4 The PreAnalyzedField Type

Loại PreanalyzedField cung cấp một cách để gửi đến các luồng mã thông báo
tuần tự của Solr, tùy chọn với các giá trị được lưu trữ độc lập của một trường
và lưu trữ và lập chỉ mục các thông tin này mà không cần bất kỳ xử lý văn bản
bổ sung nào được áp dụng trong Solr. Điều này rất hữu ích nếu người dùng
muốn gửi nội dung trường đã được xử lý bởi một số đường ống xử lý văn bản
bên ngoài hiện có (ví dụ, đã được tokenized, chú thích, stemmed, chèn từ đồng
nghĩa, vv), trong khi sử dụng tất cả các thuộc tính phong phú mà Lucene's
TokenStream cung cấp (mỗi thuộc tính mã thông báo).
Định dạng serialization được pluggable bằng cách sử dụng các giao diện
PreanalyzedParser. Có hai hiện thực ngoài hiện trường:
 JsonPreAnalyzedParser: như tên cho thấy, nó phân tích nội dung sử dụng
JSON để đại diện cho nội dung của trường. Đây là bộ phân tích cú pháp
mặc định để sử dụng nếu loại trường không được định cấu hình khác.
 SimplePreAnalyzedParser: sử dụng một định dạng văn bản thuần túy
đơn giản, trong một số trường hợp có thể dễ dàng tạo ra hơn JSON.
Chỉ có một tham số cấu hình, parserImpl. Giá trị của tham số này phải là một
tên lớp đủ điều kiện của một lớp thực hiện giao diện PreAnalyzedParser. Giá trị
mặc định của tham số này là org.apache.solr.schema.JsonPreAnalyzedParser.
Theo mặc định, bộ phân tích thời gian và truy vấn cho các trường thuộc loại
này sẽ giống với trình phân tích thời gian-chỉ mục, dự kiến sẽ được phân tích
trước. Bạn phải thêm một trình phân tích loại truy vấn vào trường của bạnType
để thực hiện phân tích các truy vấn không được phân tích trước. Trong ví dụ
dưới đây, trình phân tích thời gian chỉ định định dạng serialization mặc định
của JSON và trình phân tích truy vấn thời gian sẽ sử dụng StandardTokenizer /
LowerCaseFilter:
<fieldType name="pre_with_query_analyzer" class="solr.PreAnalyzedField">

<analyzer type="query">
<tokenizer class="solr.StandardTokenizerFactory"/>
<filter class="solr.LowerCaseFilterFactory"/>
</analyzer>
</fieldType>
2.2.7 Field Properties by Use Case
Dưới đây là tóm tắt các trường hợp sử dụng phổ biến và thuộc tính các trường
hoặc trường nên có để hỗ trợ trường hợp. Một mục nhập đúng hoặc sai trong
bảng chỉ ra rằng tùy chọn phải được đặt thành giá trị nhất định cho trường hợp
sử dụng hoạt động chính xác. Nếu không có mục nhập được cung cấp, cài đặt
của thuộc tính đó sẽ không ảnh hưởng đến trường hợp.
index stor multiVal omitNo termVec termPosit docVal

Use Case
ed ed ued rms tors ions ues
search
within true
field
retrieve true
8 true8
contents
use as
unique true false
key
sort on
true7 false true 1 true7
field
highlighti
true4 true true2 true 3
ng
faceting 5 true7 true7
add
multiple
values, true
maintaini
ng order
field
length
false
affects
doc score
MoreLike
true 6
This 5
Ghi chú:
 Khuyến cáo nhưng không cần thiết
 Sẽ được sử dụng nếu có, nhưng không cần thiết.
 (nếu termVectors = đúng)
 Một tokenizer phải được định nghĩa cho trường, nhưng nó không cần
phải được lập chỉ mục.
 Mô tả trong Các Phân tích Hiểu, Tokenizers, và Bộ lọc.
 Các vectơ vectơ không bắt buộc ở đây. Nếu không đúng, thì một trường
lưu trữ được phân tích. Vì vậy các vector vectơ được khuyến cáo, nhưng
chỉ yêu cầu nếu lưu trữ = false.
 Đối với hầu hết các loại trường, lập chỉ mục hoặc docValues phải là sự
thật, nhưng cả hai không bắt buộc. DocValues có thể hiệu quả hơn trong
nhiều trường hợp. Đối với [PointFields [Int / Long / Float / Double /
Date], docValues = true là bắt buộc.
 Nội dung lưu trữ sẽ được sử dụng theo mặc định, nhưng docValues cũng
có thể được sử dụng. Xem DocValues.
2.2 Defining Fields
2.2.1 Example
Ví dụ sau định nghĩa một trường có tên giá với một loại có tên float và một giá
trị mặc định là 0.0; các thuộc tính được lập chỉ mục và lưu trữ được xác định rõ
ràng là true, trong khi các thuộc tính khác được chỉ định trên kiểu trường float
được kế thừa.
<field name="price" type="float" default="0.0" indexed="true"

stored="true"/>
2.2.2 Field Properties
Property Description
Tên của cánh đồng. Tên trường chỉ nên bao gồm các ký tự chữ
hoặc số gạch dưới và không bắt đầu bằng chữ số. Đây không
phải là thực thi nghiêm ngặt, nhưng các tên trường khác sẽ
name không được hỗ trợ lớp học đầu tiên từ tất cả các thành phần và
khả năng tương thích ngược lại không được đảm bảo. Tên có cả
dấu gạch dưới và dấu đầu dòng (ví dụ: _version_) được giữ
nguyên. Mỗi lĩnh vực phải có một name.
Tên của trường fieldType cho trường này. Điều này sẽ được tìm
type thấy trong thuộc tính name trên định nghĩa fieldType. Mỗi lĩnh
vực phải có một type.
Giá trị mặc định sẽ được tự động thêm vào bất kỳ tài liệu nào
default không có giá trị trong trường này khi nó được lập chỉ mục. Nếu
thuộc tính này không được chỉ định, không có mặc định.
2.2.3 Optional Field Type Override Properties

Các trường có thể có nhiều thuộc tính giống như trường. Thuộc tính từ bảng
dưới đây được chỉ định trên từng trường sẽ ghi đè bất kỳ giá trị rõ ràng nào
cho thuộc tính đó được chỉ định trên fieldType của trường hoặc bất kỳ giá trị
mặc định ngầm định nào được cung cấp bởi việc triển khai fieldType bên dưới.
Bảng dưới đây được sao chép từ Field Type Definitions and Properties, có
thêm chi tiết:
Implicit
Property Description Values
Default
Nếu true, giá trị của trường có thể
true or
indexed được sử dụng trong truy vấn để lấy true
false
các tài liệu phù hợp.
Nếu true, giá trị thực của trường có
true or
stored thể được truy xuất bằng các truy true
false
vấn.
Nếu true, giá trị của trường sẽ được
true or
docValues đưa vào cấu trúc DocValues định false
false
hướng theo cột.
sortMissingFirst Kiểm soát vị trí của các tài liệu khi true or
false
sortMissingLast không có trường sắp xếp. false
Nếu true, chỉ ra rằng một tài liệu
true or
multiValued duy nhất có thể chứa nhiều giá trị false
false
cho loại trường này.
Nếu true, bỏ qua các chỉ tiêu liên
quan đến trường này (điều này làm
vô hiệu hoá độ dài chuẩn cho
trường và tiết kiệm bộ nhớ). Các giá
true or
omitNorms trị mặc định cho tất cả các loại *
false
trường sơ khai (không được phân
tích), chẳng hạn như int, float, data,
bool và string. Chỉ trường hoặc
trường toàn văn cần các định mức.
Nếu true, bỏ qua tần suất, vị trí, và
trọng tải từ các bài đăng cho lĩnh
vực này. Đây có thể là tăng hiệu
suất cho các trường không yêu cầu
thông tin đó. Nó cũng làm giảm
không gian lưu trữ cần thiết cho chỉ
omitTermFreqAnd true or
mục. Các truy vấn dựa vào vị trí *
Positions false
được phát hành trên một trường
với tùy chọn này sẽ tự động không
tìm được tài liệu. Thuộc tính này
mặc định là true cho tất cả các loại
trường mà không phải trường văn
bản.
Tương tự như
true or
omitPositions omitTermFreqAndPositions nhưng *
false
giữ lại thông tin về tần số hạn.
Các tùy chọn này hướng dẫn Solr
duy trì vectơ đầy đủ cho mỗi tài
liệu, tùy chọn bao gồm thông tin vị
trí, bù đắp và tải trọng cho mỗi lần
termVectors
xảy ra trong các vectơ đó. Chúng có
termPositions true or
thể được sử dụng để tăng tốc độ false
termOffsets false
làm nổi bật và các chức năng phụ
termPayloads
trợ khác, nhưng áp đặt một chi phí
đáng kể về kích thước chỉ mục.
Chúng không cần thiết cho việc sử
dụng điển hình của Solr.
Chỉ thị cho Solr từ chối bất kỳ nỗ lực
nào để thêm một tài liệu không có true or
required false
giá trị cho trường này. Thuộc tính false
này mặc định là false.
Nếu lĩnh vực này đã bật docValues,
việc thiết lập giá trị này là đúng sẽ
cho phép trường được trả về như
useDocValuesAsSt true or
thể nó là một trường được lưu trữ true
ored false
(ngay cả khi nó đã lưu trữ = false)
khi khớp với "*" trong một tham số
fl.
Lớn các lĩnh vực luôn lười biếng tải
và sẽ chỉ mất không gian trong bộ
nhớ cache tài liệu nếu giá trị thực tế
là <512KB. Tùy chọn này yêu cầu true or
large false
lưu trữ = "true" và multiValued = false
"false". Nó dành cho các lĩnh vực có
thể có giá trị rất lớn để chúng không
bị lưu trữ trong bộ nhớ.
2.3 Copying Fields
Bạn có thể muốn giải thích một số trường tài liệu theo nhiều cách. Solr có một
cơ chế để làm bản sao các trường để bạn có thể áp dụng một số trường trường
riêng biệt cho một mẩu thông tin đến.
Tên của trường mà bạn muốn sao chép là nguồn, và tên của bản sao là đích
đến. Trong schema.xml, rất đơn giản để sao chép các trường:
<copyField source="cat" dest="text" maxChars="30000" />
Trong ví dụ này, chúng tôi muốn Solr sao chép trường mèo vào một trường có
tên văn bản. Các trường được sao chép trước khi phân tích được thực hiện, có
nghĩa là bạn có thể có hai trường có nội dung gốc giống hệt nhau, nhưng sử
dụng các chuỗi phân tích khác nhau và được lưu trữ trong chỉ mục khác nhau.
Trong ví dụ ở trên, nếu lĩnh vực đích văn bản có dữ liệu của riêng nó trong các
tài liệu đầu vào, nội dung của trường mèo sẽ được thêm vào như các giá trị bổ
sung - giống như tất cả các giá trị ban đầu được chỉ định bởi máy khách. Hãy
nhớ định cấu hình các trường của bạn dưới dạng multivalued = "true" nếu cuối
cùng họ sẽ nhận được nhiều giá trị (hoặc từ nguồn có nhiều giá trị hoặc từ các
chỉ thị nhiều bản copyField).
Cách sử dụng chung cho chức năng này là tạo một trường "tìm kiếm" duy nhất
sẽ phục vụ như là trường truy vấn mặc định khi người dùng hoặc khách hàng
không chỉ định một trường để truy vấn. Ví dụ: tiêu đề, tác giả, từ khóa và phần
thân tất cả có thể là các trường cần được tìm kiếm theo mặc định, với các quy
tắc trường sao chép cho mỗi trường để sao chép vào một trường catchall (ví
dụ có thể được đặt tên bất kỳ). Sau đó bạn có thể đặt một quy tắc trong
solrconfig.xml để tìm kiếm trường catchall theo mặc định. Một caveat này là
chỉ mục của bạn sẽ phát triển khi sử dụng các lĩnh vực sao chép. Tuy nhiên, cho
dù điều này trở nên có vấn đề với bạn và kích thước cuối cùng sẽ phụ thuộc
vào số lượng các lĩnh vực đang được sao chép, số lượng các lĩnh vực đích được
sao chép, phân tích sử dụng, và không gian đĩa có sẵn.
Tham số maxChars, một tham số int, thiết lập một giới hạn trên cho số ký tự
được sao chép từ giá trị nguồn khi xây dựng giá trị được thêm vào trường đích.
Giới hạn này hữu ích cho các tình huống mà bạn muốn sao chép một số dữ liệu
từ trường nguồn, nhưng cũng kiểm soát kích thước của các tệp chỉ mục.
Cả nguồn và đích của copyField có thể chứa dấu hoa thị hoặc dấu hoa thị đầu,
điều này sẽ khớp với bất cứ thứ gì. Ví dụ: dòng sau sẽ sao chép nội dung của
tất cả các trường đến phù hợp với mẫu ký tự đại diện * _t vào trường văn bản:
<copyField source="*_t" dest="text" maxChars="25000" />
Sao chép được thực hiện ở cấp nguồn luồng và không có bản sao chép dữ liệu
vào một bản sao khác. Điều này có nghĩa là các trường sao chép không thể bị
ràng buộc, tức là bạn không thể sao chép từ đây đến đó và từ đó đến nơi khác.
Tuy nhiên, trường nguồn tương tự có thể được sao chép sang nhiều trường
đích:
<copyField source="here" dest="there"/>
<copyField source="here" dest="elsewhere"/>
2.4 Dynamic Fields

Các trường động cho phép các trường Solr chỉ mục mà bạn đã không xác định
rõ ràng trong lược đồ của mình.
Điều này hữu ích nếu bạn phát hiện ra bạn đã quên xác định một hoặc nhiều
trường. Các trường động có thể làm cho ứng dụng của bạn không bị giòn hơn
bằng cách cung cấp một số tính linh hoạt trong các tài liệu bạn có thể thêm vào
Solr.
Một lĩnh vực động cũng giống như một trường thông thường, ngoại trừ nó có
một tên với một ký tự đại diện trong đó. Khi bạn lập chỉ mục các tài liệu, một
trường không khớp với bất kỳ trường nào được xác định rõ ràng có thể được
kết hợp với trường năng động.
Ví dụ: giả sử lược đồ của bạn bao gồm trường năng động với tên * _i. Nếu bạn
cố gắng lập chỉ mục một tài liệu với trường cost_i, nhưng không có trường
cost_i rõ ràng nào được định nghĩa trong lược đồ, thì trường cost_i sẽ có kiểu
trường và phân tích được xác định cho * _i.
Giống các trường thông thường, trường năng động có tên, loại trường và các
tùy chọn.
<dynamicField name="*_i" type="int" indexed="true" stored="true"/>
Chúng tôi đề nghị bạn bao gồm các ánh xạ trường động động cơ bản (như
được hiển thị ở trên) trong schema.xml của bạn. Các ánh xạ có thể rất hữu ích.
2.5 Other Schema Elements
2.5.1 Unique Key
Phần tử uniqueKey xác định trường nào là một số nhận dạng duy nhất cho tài
liệu. Mặc dù không yêu cầu duy nhấtKey, nó gần như luôn luôn được bảo đảm
bởi thiết kế ứng dụng của bạn. Ví dụ: uniqueKey nên được sử dụng nếu bạn sẽ
cập nhật một tài liệu trong chỉ mục.
Bạn có thể xác định trường khoá duy nhất bằng cách đặt tên nó:
<uniqueKey>id</uniqueKey>
2.5.2 Default Search Fields & Query Operator
Mặc dù chúng đã bị phản đối khá lâu, nhưng Solr vẫn hỗ trợ cho việc cấu hình
dựa trên Schema của <defaultSearchField /> (được thay thế bởi tham số df) và
<solrQueryParser defaultOperator = "OR" /> (được thay thế bởi q Tham số .op.
Nếu bạn có các tùy chọn này được chỉ định trong Lược đồ của mình, bạn nên
thay thế chúng bằng các tham số yêu cầu (hoặc mặc định tham số yêu cầu) vì
sự hỗ trợ cho các tham số này có thể được loại bỏ khỏi bản phát hành Solr
trong tương lai.
2.5.3 Similarity
Tính tương đồng là một lớp Lucene được sử dụng để ghi một tài liệu trong tìm
kiếm.
Mỗi bộ sưu tập có một tính tương đồng "toàn cầu", và mặc định Solr sử dụng
một SchemaSimilarityFactory ngầm định cho phép các kiểu trường cá nhân
được cấu hình với tính tương đồng cụ thể theo từng loại và ngầm sử dụng
BM25 Tương tự cho bất kỳ loại trường nào không có Tính tương đồng rõ ràng.
Hành vi mặc định này có thể được ghi đè bằng cách khai báo một phần tử
<similarity /> ở mức cao nhất trong schema.xml của bạn, bên ngoài bất kỳ loại
trường nào. Tuyên bố tương tự này có thể trực tiếp tham chiếu đến tên của
một lớp với một hàm tạo không có đối số, chẳng hạn như trong ví dụ này cho
thấy BM25Similarity:
<similarity class="solr.BM25SimilarityFactory"/>
hoặc bằng cách tham khảo một sự thực hiện Tương tự, có thể có các tham số
khởi tạo tùy chọn:
<similarity class="solr.DFRSimilarityFactory">
<str name="basicModel">P</str>
<str name="afterEffect">L</str>
<str name="normalization">H2</str>
<float name="c">7</float>
</similarity>
Trong hầu hết các trường hợp, chỉ định mức độ tương tự cấp độ toàn cầu như
thế này sẽ gây ra lỗi nếu lược đồ schema.xml của bạn cũng bao gồm các khai
báo <tương đồng / trường> kiểu trường. Một ngoại lệ quan trọng đối với việc
này là bạn có thể khai báo một cách rõ ràng một SchemaSimilarityFactory và
chỉ định hành vi mặc định đó là gì cho tất cả các loại trường mà không tuyên bố
tính tương đồng rõ ràng bằng cách sử dụng tên của loại trường (được xác định
bởi defaultSimFromFieldType) được cấu hình với một sự tương đồng cụ thể :
<similarity class="solr.SchemaSimilarityFactory">
<str name="defaultSimFromFieldType">text_dfr</str>
</similarity>
<fieldType name="text_dfr" class="solr.TextField">
<analyzer ... />
<similarity class="solr.DFRSimilarityFactory">
<str name="basicModel">I(F)</str>
<str name="afterEffect">B</str>
<float name="mu">900</float>
</similarity>
</fieldType>
<fieldType name="text_ib" class="solr.TextField">
<analyzer ... />
<similarity class="solr.IBSimilarityFactory">
<str name="distribution">SPL</str>
<str name="lambda">DF</str>
</similarity>
</fieldType>
<fieldType name="text_other" class="solr.TextField">
<analyzer ... />
</fieldType>
Trong ví dụ trên, IBSimilarityFactory (sử dụng mô hình Thông tin dựa trên) sẽ
được sử dụng cho bất kỳ trường nào thuộc kiểu text_ib, trong khi
DFRSimilarityFactory (phân kỳ ngẫu nhiên) sẽ được sử dụng cho bất kỳ trường
nào thuộc kiểu text_dfr, cũng như bất kỳ trường nào sử dụng kiểu mà không
không rõ ràng xác định một <tương đồng />.
Nếu SchemaSimilarityFactory được tuyên bố một cách rõ ràng với việc định
cấu hình defaultSimFromFieldType, thì BM25Similarity được ngầm sử dụng làm
mặc định.
Ngoài các nhà máy khác nhau được đề cập trong trang này, có một số triển
khai tương tự khác có thể được sử dụng như SweetSpotSimilarityFactory,
ClassicSimilarityFactory, vv .... Để biết chi tiết, xem Solr Javadocs cho các nhà
máy tương tự.
2.6 Schema API
API giản đồ cho phép bạn sử dụng một API HTTP để quản lý nhiều thành phần
của lược đồ của bạn.
API giản đồ sử dụng lớp ManagedIndexSchemaFactory, đây là nhà máy lược đồ

mặc định trong các phiên bản Solr hiện đại. Xem phần Định nghĩa Nhà máy
Giản đồ trong SolrConfig để biết thêm thông tin về việc chọn một nhà máy
lược đồ cho chỉ mục của bạn.
API này cung cấp khả năng đọc và ghi vào lược đồ Solr cho mỗi bộ sưu tập
(hoặc cốt lõi, khi sử dụng Solr độc lập). Đọc quyền truy cập vào tất cả các yếu
tố lược đồ được hỗ trợ. Các lĩnh vực, lĩnh vực năng động, các loại trường và các
quy tắc copyField có thể được thêm, xoá hoặc thay thế. Bản phát hành trong
tương lai Solr sẽ mở rộng quyền truy cập ghi để cho phép sửa đổi các yếu tố
lược đồ hơn.
API cho phép hai chế độ đầu ra cho tất cả các cuộc gọi: JSON hoặc XML. Khi yêu
cầu lược đồ đầy đủ, có một chế độ đầu ra khác là XML được mô hình hoá sau
tệp tin được quản lý-schema, ở định dạng XML.
Khi sửa đổi lược đồ với API, tải lại cốt lõi sẽ tự động xảy ra để các thay đổi có
sẵn ngay lập tức cho các tài liệu được lập chỉ mục sau đó. Các tài liệu được lập
chỉ mục trước đây sẽ không được cập nhật tự động - chúng phải được lập chỉ
mục lại nếu dữ liệu chỉ mục hiện có sử dụng các phần tử lược đồ mà bạn đã
thay đổi.
2.7 Putting the Pieces Together
2.7.1 Choosing Appropriate Numeric Types

Đối với các nhu cầu số chung, hãy xem xét sử dụng một trong các lớp
`IntPointField`, LongPointField, FloatPointField hoặc DoublePointField, tùy
thuộc vào các giá trị cụ thể mà bạn mong đợi. Các lớp số dựa trên số "Điểm
chiều" này sử dụng các cấu trúc dữ liệu được mã hóa đặc biệt để hỗ trợ các
truy vấn phạm vi hiệu quả bất kể kích thước của các phạm vi được sử dụng. Bật
DocValues trên các trường này khi cần thiết để phân loại và / hoặc faceting.
Một số tính năng của Solr có thể chưa làm việc với "Những điểm chiều", trong
trường hợp đó bạn có thể muốn xem các lớp TrieIntField, TrieLongField,
TrieFloatField và TrieDoubleField tương đương. Cấu hình độ chính xácStep =
"0" nếu bạn muốn giảm thiểu kích thước chỉ mục, nhưng nếu bạn mong đợi
người dùng thực hiện các truy vấn thường xuyên trên các loại số, hãy sử dụng
độ chính xác mặc định (không xác định) hoặc chỉ định nó là precisionStep = "8"
( là mặc định). Điều này cung cấp tốc độ nhanh hơn cho các truy vấn phạm vi
tại các chi phí tăng kích thước chỉ mục.
2.7.2 Working With Text
Xử lý văn bản đúng cách sẽ làm cho người dùng của bạn hạnh phúc bằng cách
cung cấp cho họ những kết quả tốt nhất có thể cho tìm kiếm văn bản.
Một kỹ thuật đang sử dụng một lĩnh vực văn bản như là một catch-all để tìm
kiếm từ khoá. Hầu hết người dùng không tinh vi về tìm kiếm của họ và tìm
kiếm phổ biến nhất có thể là một tìm kiếm từ khóa đơn giản. Bạn có thể sử
dụng copyField để thực hiện nhiều lĩnh vực khác nhau và đưa chúng vào một
trường văn bản duy nhất để tìm kiếm từ khoá.
Trong tệp schema.xml cho ví dụ "techproducts" bao gồm trong Solr, các khai
báo của tệp copyField được sử dụng để hủy nội dung của cat, name, manu,
features và include vào một trường, văn bản. Ngoài ra, bạn nên sao chép ID
thành văn bản trong trường hợp người dùng muốn tìm kiếm một sản phẩm cụ
thể bằng cách chuyển số sản phẩm của nó sang tìm kiếm từ khóa.
Một kỹ thuật khác là sử dụng copyField để sử dụng cùng một trường theo
những cách khác nhau. Giả sử bạn có một lĩnh vực mà là một danh sách các tác
giả, như thế này:
Schildt, Herbert; Wolpert, Lewis; Davies, P.
Để tìm kiếm theo tác giả, bạn có thể làm tokenize trường, chuyển đổi sang chữ
thường, và gỡ bỏ dấu chấm câu:
schildt / herbert / wolpert / lewis / davies / p
Để phân loại, chỉ cần sử dụng một trường chưa được giải phóng, được chuyển
đổi sang chữ thường, với dấu chấm câu được loại bỏ:
schildt herbert wolpert lewis davies p
Cuối cùng, đối với faceting, sử dụng tác giả chính chỉ thông qua một StrField:
Schildt, Herbert
2.8 DocValues
2.8.1 Why DocValues?
Cách tiêu chuẩn mà Solr xây dựng chỉ mục là với một chỉ số đảo ngược. Kiểu
này xây dựng một danh sách các thuật ngữ tìm thấy trong tất cả các tài liệu
trong chỉ mục và bên cạnh mỗi thuật ngữ là một danh sách các tài liệu mà
thuật ngữ xuất hiện (cũng như bao nhiêu lần thuật ngữ xuất hiện trong tài liệu
đó). Điều này làm cho việc tìm kiếm rất nhanh - vì người dùng tìm kiếm theo
các thuật ngữ, việc có sẵn một danh sách các giá trị từ ngày đến tài liệu làm
cho tiến trình truy vấn nhanh hơn.
Đối với các tính năng khác mà chúng tôi thường kết hợp với tìm kiếm, chẳng
hạn như phân loại, faceting và làm nổi bật, cách tiếp cận này không phải là rất
hiệu quả. Ví dụ: công cụ khắc phục hậu quả phải tìm kiếm mỗi thuật ngữ xuất
hiện trong mỗi tài liệu sẽ tạo thành bộ kết quả và kéo ID tài liệu để xây dựng
danh sách khía cạnh. Trong Solr, điều này được duy trì trong bộ nhớ và có thể
tải chậm (tùy thuộc vào số tài liệu, điều khoản, v.v.).
Trong Lucene 4.0, một phương pháp tiếp cận mới đã được giới thiệu. Các
trường thuộc dạng DocValue bây giờ là các trường định hướng theo cột với
một bản đồ giá trị tài liệu được xây dựng ở thời gian chỉ mục. Cách tiếp cận này
hứa hẹn làm giảm một số yêu cầu về bộ nhớ của fieldCache và thực hiện tìm
kiếm cho faceting, phân loại và nhóm nhanh hơn nhiều.
2.8.2 Enabling DocValues
Để sử dụng docValues, bạn chỉ cần kích hoạt nó cho một trường mà bạn sẽ sử
dụng nó với. Giống như tất cả các thiết kế lược đồ, bạn cần định nghĩa một loại
trường và sau đó xác định các trường của loại đó với docValues được bật. Tất
cả các hành động này được thực hiện trong schema.xml.
Cho phép một trường cho docValues chỉ yêu cầu thêm docValues = "true" vào
trường (hoặc trường kiểu) định nghĩa, như trong ví dụ này từ schema.xml của
Solr của sample_techproducts_configs config set:
<field name="manu_exact" type="string" indexed="false" stored="false"
docValues="true" />
DocValues chỉ có sẵn cho các loại trường cụ thể. Các loại được chọn xác định
loại Lucene docValue cơ bản sẽ được sử dụng. Các loại trường Solr sẵn có là:
 StrField và UUIDField.
o Nếu trường này có giá trị đơn (nghĩa là đa giá trị là sai), Lucene sẽ
sử dụng loại SORTED.
o Nếu lĩnh vực này là đa giá trị, Lucene sẽ sử dụng loại SORTED_SET.
 Bất kỳ trường Trie * số, ngày lĩnh vực và EnumField.
sử dụng loại NUMERIC.
o Nếu lĩnh vực này là đa giá trị, Lucene sẽ sử dụng loại SORTED_SET.
 Trường Boolean
 Int | Long | Float | Đôi | Ngày PointField
sử dụng loại NUMERIC.
o Nếu trường có nhiều giá trị, Lucene sẽ sử dụng loại
SORTED_NUMERIC.
 Các kiểu Lucene này có liên quan đến cách các giá trị được sắp xếp và
lưu trữ.
Có một tùy chọn cấu hình bổ sung có sẵn, đó là để sửa đổi các
docValuesFormat được sử dụng bởi các loại trường. Việc triển khai mặc định
sử dụng một hỗn hợp của tải một số thứ vào bộ nhớ và giữ một số trên đĩa.
Trong một số trường hợp, tuy nhiên, bạn có thể chọn để chỉ định một sự thực
hiện DocValuesFormat thay thế. Ví dụ, bạn có thể chọn để giữ tất cả mọi thứ
trong bộ nhớ bằng cách chỉ định docValuesFormat = "Bộ nhớ" trên một loại
trường:
<fieldType name="string_in_mem_dv" class="solr.StrField" docValues="true"
docValuesFormat="Memory" />
Xin lưu ý rằng tùy chọn docValuesFormat có thể thay đổi trong bản phát hành
trong tương lai.
2.8.3 Using DocValues

Giá trị trường thu được trong các truy vấn tìm kiếm thường được trả lại từ các
giá trị được lưu trữ. Tuy nhiên, các trường docValues không lưu trữ sẽ được
trả lại cùng với các trường lưu trữ khác khi tất cả các trường (hoặc mẫu kết
hợp) được chỉ định trả về (ví dụ: "fl = *") cho truy vấn tìm kiếm tùy thuộc vào
giá trị hiệu dụng của tham số useDocValuesAsStored cho mỗi lĩnh vực. Đối với
các phiên bản lược đồ> = 1,6, mặc định ngầm định là useDocValuesAsStored =
"true". Xem Định nghĩa Loại trường và Thuộc tính & Xác định Trường để biết
thêm chi tiết.
Khi useDocValuesAsStored = "false", các trường DocValues không được lưu trữ
vẫn có thể được yêu cầu rõ ràng theo tên trong param fl, nhưng sẽ không khớp
với mẫu glob ("*"). Lưu ý rằng DocValues trở lại cùng với các trường được lưu
trữ "thường xuyên" tại thời điểm truy vấn có ý nghĩa về hiệu suất mà các
trường được lưu trữ có thể không phải do DocValues được định hướng theo
cột và do đó có thể phải chịu thêm chi phí để truy xuất cho mỗi tài liệu được
trả lại. Cũng lưu ý rằng trong khi trả lại các trường không lưu trữ từ DocValues,
các giá trị của một trường có nhiều giá trị được trả về theo thứ tự được sắp
xếp (chứ không phải lệnh chèn). Nếu bạn yêu cầu các trường có nhiều giá trị
được trả về theo thứ tự chèn ban đầu, hãy làm cho trường đa giá trị của bạn
được lưu trữ (như vậy cần phải lập lại chỉ mục).
Trong trường hợp truy vấn đang trả về chỉ các lĩnh vực docValues có thể cải
thiện kể từ khi gửi lại các trường lưu trữ đòi hỏi phải đọc và giải nén đĩa trong
khi các trường docValues trở lại trong danh sách fl yêu cầu truy cập bộ nhớ.
Khi lấy các trường từ mẫu docValues của chúng (sử dụng trình xử lý / xuất
khẩu, biểu thức phát trực tuyến hoặc nếu trường được yêu cầu trong tham số
fl), hai sự khác biệt quan trọng giữa các trường lưu trữ thường xuyên và các
trường docValues phải được hiểu:
 Thứ tự không được giữ nguyên. Để đơn giản thu hồi các trường lưu trữ,
thứ tự chèn là thứ tự trả về. Đối với docValues, nó là thứ tự sắp xếp.
 Nhiều mục giống hệt nhau được thu gọn thành một giá trị. Vì vậy, nếu
tôi chèn giá trị 4, 5, 2, 4, 1, trở lại của tôi sẽ là 1, 2, 4, 5.
2.9 Schemaless Mode
Chế độ Schemaless là một tập hợp các tính năng Solr, khi được sử dụng với
nhau, cho phép người dùng nhanh chóng xây dựng một giản đồ hiệu quả bằng
cách đơn giản lập chỉ mục các dữ liệu mẫu, mà không phải tự chỉnh sửa lược
đồ.
Các tính năng Solr, tất cả được điều khiển qua solrconfig.xml, là
 Lược đồ được quản lý: Các sửa đổi giản đồ được thực hiện trong thời
gian chạy thông qua các API Solr, đòi hỏi sử dụng schemaFactory hỗ trợ
những thay đổi này - xem Định nghĩa Nhà máy Schema trong SolrConfig
để biết thêm chi tiết.
 Giá trị trường lớp đoán: Các trường chưa nhìn thấy trước đây được chạy
qua bộ phân tích cú pháp dựa trên giá trị, đoán các giá trị trường của lớp
Java - các bộ phân tích cho Boolean, Integer, Long, Float, Double và Date
hiện đang có sẵn.
 Bổ sung lĩnh vực lược đồ tự động, dựa vào các lớp giá trị trường: Các
trường chưa nhìn thấy trước đây được thêm vào giản đồ, dựa trên các
lớp Java giá trị trường, được ánh xạ tới các loại trường lược đồ - xem Các
loại trường Solr.
2.9.1 Using Schemaless Example
Ba tính năng của chế độ lược đồ được cấu hình sẵn trong tập dữ liệu
data_driven_schema_configs trong phân phối Solr. Để bắt đầu một thể hiện ví
dụ của Solr bằng cách sử dụng các cấu hình này, hãy chạy lệnh sau:
bin / solr start -e-schema
Thao tác này sẽ khởi chạy máy chủ Solr và tự động tạo một bộ sưu tập (có tên
"startedstart") chỉ chứa ba trường trong lược đồ ban đầu: id, _version_ và
_text_.
Bạn có thể sử dụng / schema / fields Schema API để xác nhận điều này: curl
http: // localhost: 8983 / solr / gettingstarted / schema / fields sẽ xuất ra:
{
"responseHeader":{
"status":0,
"QTime":1},
"fields":[{
"name":"_text_",
"type":"text_general",
"multiValued":true,
"indexed":true,
"stored":false},
{
"name":"_version_",
"type":"long",
"indexed":true,
"stored":true},
{
"name":"id",
"type":"string",
"multiValued":false,
"indexed":true,
"required":true,
"stored":true,
"uniqueKey":true}]}
2.9.2 Configuring Schemaless Mode

Enable Managed Schema
Như được mô tả trong phần Schema Factory Definition trong SolrConfig, hỗ trợ
Managed Schema được kích hoạt mặc định, trừ khi cấu hình của bạn chỉ định
ClassicIndexSchemaFactory nên được sử dụng.
Bạn có thể cấu hình ManagedIndexSchemaFactory (và kiểm soát tập tin tài
nguyên được sử dụng, hoặc vô hiệu hóa các sửa đổi trong tương lai) bằng cách
thêm một <schemaFactory /> rõ ràng như dưới đây, vui lòng xem Định nghĩa
Nhà máy Schema trong SolrConfig để biết thêm chi tiết về các tùy chọn có sẵn
<schemaFactory class="ManagedIndexSchemaFactory">
<bool name="mutable">true</bool>
<str name="managedSchemaResourceName">managed-schema</str>
</schemaFactory>
Define an UpdateRequestProcessorChain
UpdateRequestProcessorChain cho phép Solr đoán các loại trường, và bạn có
thể định nghĩa các lớp loại trường mặc định để sử dụng. Để bắt đầu, bạn nên
định nghĩa nó như sau (xem liên kết javadoc bên dưới để cập nhật các tài liệu
của nhà sản xuất bộ vi xử lý):
<updateRequestProcessorChain name="add-unknown-fields-to-the-schema">

<processor class="solr.UUIDUpdateProcessorFactory" />
<processor class="solr.RemoveBlankFieldUpdateProcessorFactory"/>
<processor class="solr.FieldNameMutatingUpdateProcessorFactory">
<str name="pattern">[^\w-\.]</str>
<str name="replacement">_</str>
</processor>
<processor class="solr.ParseBooleanFieldUpdateProcessorFactory"/>
<processor class="solr.ParseLongFieldUpdateProcessorFactory"/>
<processor class="solr.ParseDoubleFieldUpdateProcessorFactory"/>
<processor class="solr.ParseDateFieldUpdateProcessorFactory">
<arr name="format">
<str>yyyy-MM-dd'T'HH:mm:ss.SSSZ</str>
<str>yyyy-MM-dd'T'HH:mm:ss,SSSZ</str>
<str>yyyy-MM-dd'T'HH:mm:ss.SSS</str>
<str>yyyy-MM-dd'T'HH:mm:ss,SSS</str>
<str>yyyy-MM-dd'T'HH:mm:ssZ</str>
<str>yyyy-MM-dd'T'HH:mm:ss</str>
<str>yyyy-MM-dd'T'HH:mmZ</str>
<str>yyyy-MM-dd'T'HH:mm</str>
<str>yyyy-MM-dd HH:mm:ss.SSSZ</str>
<str>yyyy-MM-dd HH:mm:ss,SSSZ</str>
<str>yyyy-MM-dd HH:mm:ss.SSS</str>
<str>yyyy-MM-dd HH:mm:ss,SSS</str>
<str>yyyy-MM-dd HH:mm:ssZ</str>
<str>yyyy-MM-dd HH:mm:ss</str>
<str>yyyy-MM-dd HH:mmZ</str>
<str>yyyy-MM-dd HH:mm</str>
<str>yyyy-MM-dd</str>
</arr>
</processor>
<processor class="solr.AddSchemaFieldsUpdateProcessorFactory">
<str name="defaultFieldType">strings</str>
<lst name="typeMapping">
<str name="valueClass">java.lang.Boolean</str>
<str name="fieldType">booleans</str>
</lst>
<str name="valueClass">java.util.Date</str>
<str name="fieldType">tdates</str>
</lst>
<str name="valueClass">java.lang.Long</str>
<str name="valueClass">java.lang.Integer</str>
<str name="fieldType">tlongs</str>
</lst>
<str name="valueClass">java.lang.Number</str>
<str name="fieldType">tdoubles</str>
</lst>
</processor>
<processor class="solr.LogUpdateProcessorFactory"/>
<processor class="solr.DistributedUpdateProcessorFactory"/>
<processor class="solr.RunUpdateProcessorFactory"/>
</updateRequestProcessorChain>
Make the UpdateRequestProcessorChain the Default for the
UpdateRequestHandler
Khi UpdateRequestProcessorChain đã được xác định, bạn phải hướng dẫn
UpdateRequestHandlers sử dụng nó khi làm việc với các cập nhật chỉ mục (tức
là, thêm, xoá, thay thế tài liệu). Dưới đây là một ví dụ sử dụng InitParams để
thiết lập mặc định trên tất cả / xử lý yêu cầu cập nhật:
<initParams path="/update/**">
<lst name="defaults">
<str name="update.chain">add-unknown-fields-to-the-schema</str>
</lst>
</initParams>
Examples of Indexed Documents
Khi đã bật chế độ lược đồ (cho dù bạn đã định cấu hình bằng tay hoặc đang sử
dụng data_driven_schema_configs), các tài liệu bao gồm các trường không
được định nghĩa trong lược đồ của bạn phải được thêm vào chỉ mục và các
trường mới được thêm vào giản đồ.
Ví dụ: thêm một tài liệu CSV sẽ làm cho các trường của nó không có trong lược
đồ được thêm, với các trườngTypes dựa trên các giá trị:
curl "http://localhost:8983/solr/gettingstarted/update?commit=true" -H
"Content-type:application/csv" -d '
id,Artist,Album,Released,Rating,FromDistributor,Sold
44C,Old Shews,Mead for Walking,1988-08-13,0.01,14,0'
Output indicating success:

<response>
<lst name="responseHeader"><int name="status">0</int><int
name="QTime">106</int></lst>
</response>
The fields now in the schema (output from curl

http://localhost:8983/solr/gettingstarted/schema/fields ):
{
"responseHeader":{
"status":0,
"QTime":1},
"fields":[{
"name":"Album",
"type":"strings"}, // Field value guessed as String -> strings
fieldType
{
"name":"Artist",
"type":"strings"}, // Field value guessed as String -> strings
fieldType
{
"name":"FromDistributor",
"type":"tlongs"}, // Field value guessed as Long -> tlongs
fieldType
{
"name":"Rating",
"type":"tdoubles"}, // Field value guessed as Double ->
tdoubles fieldType
{
"name":"Released",
"type":"tdates"}, // Field value guessed as Date -> tdates
fieldType
{
"name":"Sold",
"type":"tlongs"}, // Field value guessed as Long -> tlongs
fieldType
{
"name":"_text_",
...
},
{
"name":"_version_",
...
},
{
"name":"id",
...}]}
Khi trường đã được thêm vào lược đồ, loại trường của nó đã được sửa. Do đó,
thêm tài liệu có giá trị trường (s) xung đột với kiểu trường đã đoán trước đó sẽ
không thành công. Ví dụ: sau khi thêm tài liệu trên, trường "Đã bán" có
fieldType kéo dài, nhưng tài liệu dưới đây có một giá trị thập phân không tách
rời trong trường này:
curl "http://localhost:8983/solr/gettingstarted/update?commit=true" -H
"Content-type:application/csv" -d '
id,Description,Sold
19F,Cassettes by the pound,4.93'
This document will fail, as shown in this output:

<response>
<lst name="responseHeader">
<int name="status">400</int>
<int name="QTime">7</int>
</lst>
<lst name="error">
<str name="msg">ERROR: [doc=19F] Error adding field 'Sold'='4.93'
msg=For input string: "4.93"</str>
<int name="code">400</int>
</lst>
</response>
Chương 3 : Understanding Analyzers, Tokenizers, and Filters

Các phần sau mô tả cách Solr bị hỏng và làm việc với dữ liệu văn bản. Có ba
khái niệm chính để hiểu: analyzers, tokenizers, and filters.
Field analyzers: được sử dụng cả trong quá trình nuốt phải, khi một tài liệu
được lập chỉ mục và tại thời điểm truy vấn. An phân tích kiểm tra văn bản của
các lĩnh vực và tạo ra một dòng token. Bộ phân tích có thể là một lớp duy nhất
hoặc chúng có thể bao gồm một loạt các lớp tokenizer và bộ lọc.
Tokenizers: phá vỡ dữ liệu trường vào các đơn vị từ vựng, hoặc các mã thông
báo.
Filters: kiểm tra một chuỗi các mã thông báo và giữ chúng, biến đổi hoặc loại
bỏ chúng, hoặc tạo ra những cái mới. Tokenizers và bộ lọc có thể được kết hợp
để tạo thành đường ống, hoặc chuỗi, trong đó đầu ra của một là đầu vào tiếp
theo. Một chuỗi tokenizers và bộ lọc như vậy được gọi là một máy phân tích và
đầu ra kết quả của một máy phân tích được sử dụng để kết hợp các kết quả
truy vấn hoặc xây dựng các chỉ số.
Using Analyzers, Tokenizers, and Filters

Mặc dù quá trình phân tích được sử dụng cho cả lập chỉ mục và truy vấn,
nhưng không cần phải sử dụng quy trình phân tích tương tự cho cả hai hoạt
động. Để lập chỉ mục, bạn thường muốn đơn giản hóa, hoặc bình thường, từ.
Ví dụ: đặt tất cả các chữ cái thành chữ thường, loại bỏ dấu chấm câu và dấu
trọng âm, lập bản đồ từ cho thân, vân vân. Làm như vậy có thể làm tăng thu
hồi bởi vì, ví dụ: "ram", "Ram" và "RAM" sẽ khớp với truy vấn cho "ram". Để
tăng độ chính xác thời gian truy vấn, bạn có thể sử dụng bộ lọc để thu hẹp các
đối sánh, ví dụ bỏ qua từ viết tắt tất cả chữ cái nếu bạn quan tâm đến con cừu
đực nhưng không phải là Bộ nhớ truy cập ngẫu nhiên.
Thẻ tín dụng được xuất ra theo quy trình phân tích xác định các giá trị hoặc các
thuật ngữ của trường đó và được sử dụng để xây dựng một chỉ mục các thuật
ngữ đó khi thêm tài liệu mới hoặc để xác định tài liệu nào chứa các thuật ngữ
bạn đang truy vấn.
For More Information

Các phần này sẽ cho bạn thấy làm thế nào để cấu hình các trình phân tích
trường và cũng có thể đóng vai trò là một tham chiếu cho các chi tiết của việc
định cấu hình từng lớp mã tokenizer và các lớp lọc. Nó cũng là một hướng dẫn
để bạn có thể cấu hình các lớp phân tích riêng của mình nếu bạn có những nhu
cầu đặc biệt mà không thể gặp được với các bộ lọc hoặc các tokenizers.
Đối với Analyzers, có:
Analyzers: Thông tin khái niệm chi tiết về các máy phân tích Solr.
Running Your Analyzers: Thông tin chi tiết về thử nghiệm và chạy bộ phân tích
Solr của bạn.
Đối với Tokenizers,có:
Tokenizers: Thông tin về cách cấu hình tokenizers, và về các lớp nhà máy
tokenizer bao gồm trong phân phối của Solr.
About Tokenizres: Thông tin khái niệm chi tiết về các thẻ tokenizers Solr.
Đối với Filters, có:
About Filters: Thông tin khái niệm chi tiết về các bộ lọc Solr.
Filter Description: Thông tin về cấu hình bộ lọc, và về các lớp nhà máy lọc bao
gồm trong phân phối của Solr.
CharFilterFactories: Thông tin về bộ lọc cho các ký tự nhập vào chế biến trước.
3.1 Analyzers
Analyzers kiểm tra văn bản của các lĩnh vực và tạo ra một dòng token.
Analyzers được chỉ định là con của phần tử <fieldType> trong tệp cấu hình
schema.xml (trong cùng thư mục conf / với tệp tin solrconfig.xml).
Trong cách sử dụng thông thường, chỉ những trường thuộc loại solr.TextField
sẽ chỉ định một máy phân tích. Cách đơn giản nhất để cấu hình một máy phân
tích là với một phần tử <analyzer> có thuộc tính class là một tên lớp Java đầy
đủ. Lớp được đặt tên phải lấy được từ org.apache.lucene.analysis.Analyzer. Ví
dụ:
<fieldType name="nametext" class="solr.TextField">
<analyzer class="org.apache.lucene.analysis.core.WhitespaceAnalyzer"/>
</fieldType>
Trong trường hợp này, một lớp duy nhất, WhitespaceAnalyzer, chịu trách
nhiệm phân tích nội dung của trường văn bản được đặt tên và phát ra các thẻ
tương ứng. Đối với các trường hợp đơn giản, chẳng hạn như văn xuôi tiếng
Anh đơn giản, một phân tích đơn lớp như thế này có thể là đủ. Nhưng thường
thì cần phải phân tích phức tạp hơn về nội dung hiện trường
Ngay cả những yêu cầu phân tích phức tạp nhất thường có thể bị phân hủy
thành một loạt các bước xử lý rời rạc, tương đối đơn giản. Như bạn sẽ sớm
khám phá, phân phối Solr đi kèm với một sự lựa chọn lớn của tokenizers và bộ
lọc bao gồm hầu hết các kịch bản mà bạn có thể gặp phải. Thiết lập một chuỗi
phân tích rất đơn giản; bạn chỉ định một phần tử <analyzer> đơn giản (không
có thuộc tính lớp) với các phần tử con tên các lớp factory cho tokenizer và các
bộ lọc để sử dụng, theo thứ tự bạn muốn chúng chạy.
Ví dụ:
<analyzer>
<filter class="solr.StandardFilterFactory"/>
<filter class="solr.StopFilterFactory"/>
<filter class="solr.EnglishPorterFilterFactory"/>
</analyzer>
</fieldType>
Lưu ý rằng các lớp trong gói org.apache.solr.analysis có thể được đề cập đến ở
đây với Solver rút ngắn. tiếp đầu ngữ.
Trong trường hợp này, không có lớp Analyzer nào được chỉ định trên phần tử
<analyzer>. Thay vào đó, một chuỗi các lớp đặc biệt hơn được nối với nhau và
cùng hành động như là Bộ phân tích cho trường. Văn bản của trường được
chuyển đến mục đầu tiên trong danh sách (solr.StandardTokenizerFactory), và
các mã thông báo xuất hiện từ danh mục cuối cùng
(solr.EnglishPorterFilterFactory) là những thuật ngữ được sử dụng để lập chỉ
mục hoặc truy vấn bất kỳ trường nào sử dụng " nametext "fieldType.
Analysis Phases
Phân tích diễn ra trong hai ngữ cảnh. Tại thời điểm chỉ mục, khi một trường
đang được tạo ra, luồng mã thông báo từ kết quả phân tích sẽ được thêm vào
một chỉ mục và xác định tập hợp các thuật ngữ (bao gồm vị trí, kích thước, vv)
cho trường. Tại thời điểm truy vấn, các giá trị đang được tìm kiếm sẽ được
phân tích và các kết quả phù hợp với các kết quả được lưu trữ trong chỉ mục
của trường.
Trong nhiều trường hợp, phân tích tương tự nên được áp dụng cho cả hai giai
đoạn. Điều này là mong muốn khi bạn muốn truy vấn cho chuỗi trận đấu chính
xác, có thể với trường hợp-insensitivity, ví dụ. Trong các trường hợp khác, bạn
có thể áp dụng các bước phân tích hơi khác trong quá trình lập chỉ mục so với
các thao tác được sử dụng tại thời điểm truy vấn.
Nếu bạn cung cấp một định dạng <analyzer> đơn giản cho một loại trường,
như trong các ví dụ trên, thì nó sẽ được sử dụng cho cả lập chỉ mục và các truy
vấn. Nếu bạn muốn phân tích riêng biệt cho mỗi giai đoạn, bạn có thể bao gồm
hai định nghĩa <phân tích> phân biệt với thuộc tính loại. Ví dụ:
<analyzer type="index">
<filter class="solr.KeepWordFilterFactory" words="keepwords.txt"/>
<filter class="solr.SynonymFilterFactory" synonyms="syns.txt"/>
</analyzer>
</analyzer>
</fieldType>
Trong ví dụ lý thuyết này, tại thời điểm chỉ mục văn bản được token hoá, các
thẻ được đặt thành chữ thường, bất kỳ dấu nào không được liệt kê trong tệp
keepwords.txt đều bị loại bỏ và những tệp còn lại được ánh xạ tới các giá trị
thay thế được xác định bởi các quy tắc từ đồng nghĩa trong tập tin syns .txt.
Điều này về cơ bản xây dựng một chỉ mục từ một tập các giá trị có thể bị giới
hạn và sau đó bình thường hoá các giá trị đó thậm chí không xuất hiện trong
văn bản ban đầu.
Tại thời điểm truy vấn, sự bình thường duy nhất xảy ra là chuyển đổi các thuật
ngữ truy vấn sang chữ thường. Các bước lọc và lập bản đồ xảy ra tại thời điểm
chỉ mục không được áp dụng cho các thuật ngữ truy vấn. Các truy vấn phải sau
đó, trong ví dụ này, rất chính xác, chỉ sử dụng các thuật ngữ đã được chuẩn
hóa được lưu trữ tại thời điểm chỉ mục.
Analysis for Multi-Term Expansion
Trong một số loại truy vấn (ví dụ: Tiền tố, Wildcard, Regex, v.v ...) thì đầu vào
được cung cấp bởi người dùng không phải là ngôn ngữ tự nhiên dành cho Phân
tích. Những thứ như Từ đồng nghĩa hoặc Ngừng lọc từ không hoạt động theo
cách hợp lý trong các loại Truy vấn này.
Các nhà phân tích có thể làm việc trong các loại truy vấn này (chẳng hạn như
Hạ xuống, hoặc Các nhà máy Bình thường hoá) được biết đến như
MultiTermAwareComponents. Khi Solr cần thực hiện phân tích cho một truy
vấn dẫn đến sự mở rộng nhiều điểm, chỉ các MultiTermAwareComponents
được sử dụng trong bộ phân tích truy vấn được sử dụng, Nhà máy mà không
phải là nhận thức đa chiều sẽ bị bỏ qua.
For most use cases, this provides the best possible behavior, but if you wish for
absolute control over the analysis performed on these types of queries, you may
explicitly define a multiterm analyzer to use, such as in the following example:
<filter class="solr.KeepWordFilterFactory" words="keepwords.txt"/>
<filter class="solr.SynonymFilterFactory" synonyms="syns.txt"/>
</analyzer>
</analyzer>

<analyzer type="multiterm">
<tokenizer class="solr.KeywordTokenizerFactory" />
</analyzer>
</fieldType>
3.2 Running Your Analyzers
Khi bạn đã xác định trường trường trong Schema của mình và chỉ định các
bước phân tích mà bạn muốn áp dụng cho nó, bạn nên kiểm tra nó để chắc
chắn rằng nó hoạt động theo cách bạn mong đợi.
May mắn thay, có một trang rất tiện dụng trong giao diện quản trị của Solr cho
phép bạn làm điều đó. Bạn có thể gọi cho máy phân tích cho bất kỳ trường văn
bản nào, cung cấp đầu vào mẫu, và hiển thị dòng thông báo kết quả.
Ví dụ: hãy xem một số loại trường "Văn bản" có sẵn trong cấu hình ví dụ về bin
/ solr -e-techproducts và sử dụng Màn hình Phân tích (http: // localhost: 8983 /
solr / # / techproducts / analysis) để so sánh cách các thẻ được tạo ra tại thời
điểm chỉ mục cho câu "Chạy Analyzer" khớp với một văn bản truy vấn hơi khác
"chạy trình phân tích của tôi"
Chúng ta có thể bắt đầu với "text_ws" - một trong những loại trường văn bản
đơn giản nhất có sẵn:
Bằng cách nhìn vào các vị trí bắt đầu và kết thúc cho mỗi thuật ngữ, chúng ta
có thể thấy rằng điều duy nhất mà loại trường này thực hiện là tokenize text
trên khoảng trống. Lưu ý trong hình này là thuật ngữ "Chạy" có vị trí bắt đầu
bằng 0 và vị trí cuối là 7, trong khi "an" có vị trí bắt đầu là 8 và vị trí cuối là 10,
và "Analyzer" bắt đầu từ 11 và kết thúc tại 19. Nếu khoảng trắng giữa các thuật
ngữ cũng được bao gồm, số sẽ là 21; vì nó là 19, chúng ta biết rằng khoảng
trống đã được gỡ bỏ khỏi truy vấn này.
Lưu ý rằng các điều khoản được lập chỉ mục và các thuật ngữ truy vấn vẫn còn
rất khác nhau. "Running" không khớp với "run", "Analyzer" không khớp với
"analyzer" (với máy tính), và rõ ràng là "an" và "my" là những từ hoàn toàn
khác nhau. Nếu mục tiêu của chúng tôi là cho phép các truy vấn như "chạy bộ
phân tích" của tôi để phù hợp với văn bản được lập chỉ mục như "Chạy
Analyser" thì rõ ràng chúng ta cần chọn một loại trường khác với phân tích văn
bản chỉ mục và truy vấn thời gian mà không xử lý nhiều đầu vào.
Khi kích hoạt kết xuất verbose, chúng ta có thể thấy mỗi giai đoạn của các máy
phân tích mới của chúng tôi sửa đổi các mã thông báo mà họ nhận được trước
khi chuyển chúng sang giai đoạn tiếp theo. Khi chúng tôi cuộn xuống kết quả
cuối cùng, chúng ta có thể thấy rằng chúng ta bắt đầu có được một kết hợp
trên "analyzer" từ mỗi chuỗi nhập vào, nhờ vào giai đoạn "LCF" - nếu bạn di
chuột qua, bạn sẽ thấy là "LowerCaseFilter":
Loại trường "text_general" được thiết kế để hữu ích cho bất kỳ ngôn ngữ nào
và chắc chắn chúng ta đã gần gũi hơn với mục tiêu của chúng ta hơn là
"text_ws" từ ví dụ đầu tiên của chúng tôi bằng cách giải quyết vấn đề nhạy cảm
trường hợp. Nó vẫn không hoàn toàn là những gì chúng tôi đang tìm kiếm bởi
vì chúng tôi không thấy các nguyên tắc bắt nguồn hoặc ngăn chặn được áp
dụng. Vì vậy, bây giờ chúng ta hãy thử các "text_en" lĩnh vực loại:
Bây giờ chúng ta có thể nhìn thấy giai đoạn "SF" (StopFilter) của các máy phân
tích giải quyết vấn đề loại bỏ Stop Words ("an"), và khi chúng ta cuộn xuống,
chúng ta cũng thấy giai đoạn "PSF" (PorterStemFilter) áp dụng các quy tắc bắt
nguồn thích hợp cho đầu vào tiếng Anh của chúng tôi, sao cho các từ ngữ được
tạo ra bởi "trình phân tích chỉ mục" của chúng tôi và các cụm từ được tạo ra
bởi "bộ phân tích truy vấn" phù hợp với cách chúng tôi mong đợi.
Tại thời điểm này, chúng tôi có thể tiếp tục thử nghiệm với các đầu vào bổ
sung, xác minh rằng các máy phân tích của chúng tôi tạo ra các mã số phù hợp
khi chúng tôi mong đợi chúng khớp và các thẻ khác nhau khi chúng tôi không
mong đợi chúng khớp, khi chúng tôi lặp lại và điều chỉnh cấu hình loại trường
của chúng tôi.
3.3 About Tokenizers
Công việc của một tokenizer là chia nhỏ một dòng văn bản thành các mã thông
báo, trong đó mỗi mã thông báo là (thường là một chuỗi phụ của các ký tự
trong văn bản). Một máy phân tích nhận thức được trường được cấu hình,
nhưng một tokenizer thì không. Tokenizers đọc từ một dòng nhân vật (một
Reader) và tạo ra một chuỗi các đối tượng Token (TokenStream).
Các ký tự trong luồng đầu vào có thể bị loại bỏ, chẳng hạn như khoảng trắng
hoặc các dấu phân cách khác. Chúng cũng có thể được thêm vào hoặc được
thay thế, chẳng hạn như lập bản đồ các bí danh hoặc chữ viết tắt cho các mẫu
chuẩn. Một token chứa các siêu dữ liệu khác nhau ngoài giá trị văn bản của nó,
chẳng hạn như vị trí mà mã thông báo xuất hiện trong trường. Bởi vì một
tokenizer có thể tạo các token phân tách từ văn bản đầu vào, bạn không nên
cho rằng văn bản của token là cùng một văn bản xảy ra trong trường, hoặc
chiều dài của nó giống như văn bản ban đầu. Cũng có thể có nhiều hơn một
token để có cùng vị trí hoặc tham khảo cùng một sự bù đắp trong văn bản ban
đầu. Lưu ý điều này nếu bạn sử dụng siêu dữ liệu mã thông báo cho những thứ
như làm nổi bật kết quả tìm kiếm trong văn bản trường.
<fieldType name="text" class="solr.TextField">
<analyzer>
</analyzer>
</fieldType>
Lớp có tên trong phần tử tokenizer không phải là tokenizer thực tế, mà là lớp
thực hiện TokenizerFactory API. Lớp nhà máy này sẽ được gọi để tạo các
trường hợp tokenizer mới nếu cần. Các vật thể được tạo ra bởi nhà máy phải
lấy được từ Tokenizer, điều này chỉ ra rằng chúng tạo ra các trình tự của các
mã thông báo. Nếu tokenizer tạo các token có thể sử dụng được như là nó, nó
có thể là thành phần duy nhất của máy phân tích. Nếu không, các thẻ ra của
tokenizer sẽ đóng vai trò là đầu vào cho giai đoạn lọc đầu tiên trong đường
ống.
Một TypeTokenFilterFactory sẵn sàng tạo ra một TypeTokenFilter lọc các thẻ
thông tin dựa trên TypeAttribute, được đặt trong factory.getStopTypes.
Để có danh sách đầy đủ các TokenFilters hiện có, hãy xem phần Tokenizers.
When To use a CharFilter vs. a TokenFilter

Có một vài cặp CharFilters và TokenFilters có liên quan (ví dụ:
MappingCharFilter và ASCIifoldingFilter) hoặc gần như giống hệt nhau (tức là:
PatternReplaceCharFilterFactory và PatternReplaceFilterFactory) chức năng và
nó có thể không phải lúc nào cũng rõ ràng đó là sự lựa chọn tốt nhất.
Quyết định về việc sử dụng phụ thuộc phần lớn vào Tokenizer mà bạn đang sử
dụng, và liệu bạn cần phải preprocess dòng của các ký tự.
Ví dụ, giả sử bạn có một tokenizer như StandardTokenizer và mặc dù bạn khá
hài lòng với cách nó hoạt động tổng thể, bạn muốn tùy chỉnh một số nhân vật
cụ thể hành xử. Bạn có thể sửa đổi các quy tắc và xây dựng lại tokenizer của
riêng bạn với JFlex, nhưng nó có thể được dễ dàng hơn để chỉ đơn giản là bản
đồ một số nhân vật trước khi tokenization với một CharFilter
3.4 Tokenizers
Tokenizers có trách nhiệm phá vỡ dữ liệu hiện trường thành các đơn vị từ
vựng, hoặc các token.
Bạn định cấu hình tokenizer cho một loại trường văn bản trong schema.xml với
phần tử <tokenizer>, như là một đứa trẻ của <analyzer>:

</analyzer>
</fieldType>
Thuộc tính class đặt tên cho một lớp factory mà sẽ nhanh chóng tạo ra một đối
tượng tokenizer khi cần thiết. Các lớp máy phát Tokenizer thực hiện các
org.apache.solr.analysis.TokenizerFactory. Phương thức create () của
TokenizerFactory chấp nhận Reader và trả về TokenStream. Khi Solr tạo ra
tokenizer nó đi qua một đối tượng Reader cung cấp nội dung của trường văn
bản.
Đối số có thể được truyền cho các nhà máy tokenizer bằng cách đặt các thuộc
tính trên phần tử <tokenizer>.
<fieldType name="semicolonDelimited" class="solr.TextField">
<tokenizer class="solr.PatternTokenizerFactory" pattern="; "/>
</analyzer>
</fieldType>
Các phần sau mô tả các lớp của nhà sản xuất tokenizer trong bản phát hành
Solr này.
Để biết các mẹo sử dụng về mã thông báo của Solr, xem

http://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters.
Standard Tokenizer
This tokenizer splits the text field into tokens, treating whitespace and
punctuation as delimiters. Delimiter characters are discarded, with the following
exceptions:
Các khoảng thời gian (dấu chấm) không được theo sau bởi khoảng trống được
giữ như một phần của token, bao gồm tên miền Internet.
Ký tự "@" là một trong số các dấu chấm câu chia nhỏ dấu cách, do đó, địa chỉ
email không được bảo vệ như là các mã đơn.
Lưu ý rằng các từ được chia theo dấu nối.

Standard Tokenizer hỗ trợ các ranh giới từ UEX # 29 với tiêu chuẩn Unicode với
các loại mã thông báo sau: <ALPHANUM>, <NUM>, <SOUTHEAST_ASIAN>,
<IDEOGRAPHIC> và <HIRAGANA>.
Factory class: solr.StandardTokenizerFactory
Arguments:
maxTokenLength: (integer, default 255) Solr ignores tokens that exceed the
number of characters specified by maxTokenLength.
Example:
<analyzer>
</analyzer>
In: "Please, email john.doe@foo.com by 03-09, re: m37-xq."
Out: "Please", "email", "john.doe", "foo.com", "by", "03", "09", "re", "m37",
"xq"
Classic Tokenizer
Bộ Tokenizer Cổ điển lưu giữ cùng một hành vi như Standard Tokenizer của
Solr phiên bản 3.1 và trước đó. Nó không sử dụng các quy tắc đường biên từ
UAX # 29 của chuẩn Unicode mà Standard Tokenizer sử dụng. Tokkenizer chia
tách trường văn bản thành các mã thông báo, xử lý khoảng trắng và dấu chấm
câu như các dấu phân cách. Các ký tự phân cách bị hủy bỏ, với các ngoại lệ sau:
Các khoảng thời gian (dấu chấm) không được theo sau bởi khoảng trống được
giữ như một phần của token.
Các từ được chia thành các dấu nối, trừ khi có một số trong từ đó, trong
trường hợp đó, mã thông báo không được tách ra và số và dấu nối được bảo
toàn.
Nhận dạng tên miền Internet và địa chỉ email và bảo vệ chúng dưới dạng một
mã thông báo duy nhất.
Factory class: solr.ClassicTokenizerFactory
Arguments:
maxTokenLength: (integer, default 255) Solr ignores tokens that exceed the
number of characters specified by maxTokenLength.
Example:
<analyzer>
<tokenizer class="solr.ClassicTokenizerFactory"/>
</analyzer>
Out: "Please", "email", "john.doe@foo.com", "by", "03-09", "re", "m37-xq"
Keyword Tokenizer
Tokenizer xử lý toàn bộ trường văn bản như một mã thông báo duy nhất.
Factory class: solr.KeywordTokenizerFactory
Arguments: None
Example:
<analyzer>
<tokenizer class="solr.KeywordTokenizerFactory"/>
</analyzer>
Out: "Please, email john.doe@foo.com by 03-09, re: m37-xq."
Letter Tokenizer
Trình tạo token này tạo ra các thẻ từ các chuỗi ký tự liền kề, loại bỏ tất cả các
ký tự không phải là chữ cái.
Factory Class: solr.LetterTokenizerFactory
Đối số: Không
Thí dụ:
<analyzer>
<tokenizer class="solr.LetterTokenizerFactory"/>
</analyzer>
In: "I can’t."

Out: "I", "can", "t"
3.5 About Filters
Giống như tokenizers, các bộ lọc tiêu thụ đầu vào và sản xuất một dòng tokens.
Bộ lọc cũng lấy được từ org.apache.lucene.analysis.TokenStream. Không giống
như tokenizers, đầu vào của bộ lọc là một TokenStream khác. Công việc của
một bộ lọc thường dễ dàng hơn của một tokenizer vì trong hầu hết các trường
hợp, một bộ lọc nhìn vào từng token trong luồng tuần tự và quyết định có nên
vượt qua nó hay thay thế nó hay loại bỏ nó.
Bộ lọc cũng có thể phân tích phức tạp hơn bằng cách nhìn vào phía trước để
xem xét nhiều token cùng một lúc, mặc dù điều này ít phổ biến hơn. Một giả
thiết cho một bộ lọc như vậy có thể được sử dụng để bình thường hóa tên nhà
nước có thể được tokenized như hai từ. Ví dụ: mã thông báo duy nhất
"california" sẽ được thay thế bằng "CA", trong khi cặp dấu hiệu "rhode" theo
sau là "đảo" sẽ trở thành mã thông báo đơn "RI".
Bởi vì các bộ lọc tiêu thụ một TokenStream và tạo ra một TokenStream mới,
chúng có thể được nối tiếp nhau một cách vô hạn. Mỗi bộ lọc trong chuỗi lần
lượt xử lý các thẻ bài được sản xuất bởi người tiền nhiệm của nó. Thứ tự mà
bạn chỉ định các bộ lọc là đáng kể. Thông thường, việc lọc chung nhất được
thực hiện đầu tiên, và các giai đoạn lọc sau đó chuyên biệt hơn.
<analyzer>
<filter class="solr.EnglishPorterFilterFactory"/>
</analyzer>
</fieldType>
Ví dụ này bắt đầu bằng mã tokenizer chuẩn của Solr, nó phá vỡ văn bản của
trường thành các mã thông báo. Những thẻ này sau đó đi qua bộ lọc tiêu
chuẩn của Solr, loại bỏ các chấm từ các từ viết tắt và thực hiện một vài thao
tác thông thường khác. Tất cả các mã thông báo sau đó được đặt thành chữ
thường, điều này sẽ tạo ra sự kết hợp không phân biệt chữ hoa chữ thường với
thời gian truy vấn.
Bộ lọc cuối cùng trong ví dụ trên là một bộ lọc stemmer sử dụng thuật toán bắt
nguồn của Porter. Một người khởi tạo về cơ bản là một tập hợp các quy tắc lập
bản đồ để lập bản đồ các hình thức của một từ trở lại từ cơ sở, hoặc từ gốc, từ
mà từ đó chúng bắt nguồn. Ví dụ, trong tiếng Anh những từ "ôm", "ôm" và
"ôm" là tất cả các hình thức từ gốc "ôm". Các stemmer sẽ thay thế tất cả các
điều khoản với "ôm", đó là những gì sẽ được lập chỉ mục. Điều này có nghĩa là
một truy vấn cho "ôm" sẽ khớp với thuật ngữ "ôm", nhưng không phải là "rất
lớn".
Ngược lại, việc áp dụng một stemmer vào các thuật ngữ truy vấn của bạn sẽ
cho phép các truy vấn có chứa cụm từ không bắt nguồn, như "ôm", để khớp
các tài liệu với các biến thể khác nhau của cùng một từ gốc, chẳng hạn như
"ôm". Điều này hoạt động bởi vì cả hai chỉ số và truy vấn sẽ bản đồ đến cùng
một gốc ("ôm").
Ngữ cảnh rõ ràng là rất cụ thể về ngôn ngữ. Solr bao gồm một số stemmers
ngôn ngữ cụ thể được tạo ra bởi máy phát Snowball được dựa trên các thuật
toán bắt đầu của Porter. Bộ lọc cầu vồng Snowball Porter có thể được sử dụng
để cấu hình bất kỳ máy ghép ngôn ngữ nào. Solr cũng bao gồm một wrapper
tiện lợi cho cây thông Snowball tiếng Anh. Ngoài ra còn có một số stemmers
mục đích xây dựng cho các ngôn ngữ không phải tiếng Anh. Các bộ đệm này
được mô tả trong Phân tích Ngôn ngữ.
3.6 Filter Description
 ASCII Folding Filter

 Beider-Morse Filter
 Classic Filter
 Common Grams Filter
 Collation Key Filter
 Daitch-Mokotoff Soundex Filter
 Double Metaphone Filter
 Edge N-Gram Filter
 English Minimal Stem Filter
 English Possessive Filter
 Fingerprint Filter
 Flatten Graph Filter
 Hunspell Stem Filter
 Hyphenated Words Filter
 ICU Folding Filter
 ICU Normalizer 2 Filter
 ICU Transform Filter
 Keep Word Filter
 KStem Filter
 Length Filter
 Limit Token Count Filter
 Limit Token Offset Filter
 Limit Token Position Filter
 Lower Case Filter
 Managed Stop Filter
 Managed Synonym Filter
 N-Gram Filter
 Numeric Payload Token Filter
 Pattern Replace Filter
 Phonetic Filter
 Porter Stem Filter
 Remove Duplicates Token Filter
 Reversed Wildcard Filter
 Shingle Filter
 Snowball Porter Stemmer Filter
 Standard Filter
 Stop Filter
 Suggest Stop Filter
 Synonym Filter
 Synonym Graph Filter
 Token Offset Payload Filter
 Trim Filter
 Type As Payload Filter
 Type Token Filter
 Word Delimiter Filter
 Word Delimiter Graph Filter
3.7 CharFilterFactories
CharFilter là một thành phần mà trước khi xử lý ký tự đầu vào.
CharFilters có thể được chuỗi như Token Filters và đặt ở phía trước của một
Tokenizer. CharFilters có thể thêm, thay đổi, hoặc loại bỏ các ký tự trong khi
vẫn giữ các giá trị nhân bản ban đầu để hỗ trợ các tính năng như làm nổi bật.
solr.MappingCharFilterFactory
Bộ lọc này tạo org.apache.lucene.analysis.MappingCharFilter, có thể được sử

dụng để thay đổi một chuỗi khác (ví dụ, để normalizing é đến e.)
Bộ lọc này yêu cầu chỉ định một đối số lập bản đồ, đó là đường dẫn và tên của
một tệp có chứa ánh xạ để thực hiện.
Thí dụ:
<analyzer>
<charFilter class="solr.MappingCharFilterFactory" mapping="mapping-
FoldToASCII.txt"/>
<tokenizer ...>
[...]
</analyzer>
Lập bản đồ cú pháp tập tin:

 Nhận xét các dòng bắt đầu bằng dấu băm (#), cũng như dòng trống, sẽ bị
bỏ qua.
 Mỗi dòng không phải chú thích, không trống bao gồm một bản đồ của
mẫu: "nguồn" ⇒ "mục tiêu"
o Chuỗi nguồn được trích dẫn đôi, khoảng trắng tùy chọn, mũi tên
(⇒), khoảng trắng tùy chọn, chuỗi mục tiêu được trích dẫn kép.
 Không cho phép nhận xét chung về các đường vẽ bản đồ.
 Chuỗi nguồn phải chứa ít nhất một ký tự, nhưng chuỗi mục tiêu có thể
trống.
 Các chuỗi ký tự thoát sau đây được nhận diện trong chuỗi nguồn và các
chuỗi đích:
Resulting
Unicode Example
Escape Sequence Character
Character Mapping Line
(ECMA-48 alias)
\\ \ U+005C "\\" ⇒ "/"
"\"and\"" ⇒
\" " U+0022
"'and'"
\b backspace (BS) U+0008 "\b" ⇒ " "
\t tab (HT) U+0009 "\t" ⇒ ","
\n newline (LF) U+000A "\n" ⇒ "<br>"
\f form feed (FF) U+000C "\f" ⇒ "\n"
carriage return "\r" ⇒ "/carriage-
\r U+000D
(CR) return/"
Unicode char
\uXXXX referenced by the U+XXXX "\uFEFF" ⇒ ""
4 hex digits
 Một dấu gạch chéo ngược theo sau bởi bất kỳ ký tự nào khác được diễn
giải như thể nhân vật có mặt mà không có dấu xăm.
solr.HTMLStripCharFilterFactory
Bộ lọc này tạo org.apache.solr.analysis.HTMLStripCharFilter. CharFilter này dải

HTML từ luồng đầu vào và chuyển kết quả sang một CharFilter hoặc một
Tokenizer khác.
Bộ lọc này:
 Gỡ bỏ các thẻ HTML / XML trong khi bảo vệ các nội dung khác.
 Loại bỏ các thuộc tính trong thẻ và hỗ trợ trích dẫn thuộc tính tùy chọn.
 Loại bỏ hướng dẫn xử lý XML, chẳng hạn như: <? Foo bar?>
 Xóa nhận xét XML.
 Xóa các phần tử XML bắt đầu bằng <!>.
 Xóa nội dung của các phần tử <script> và <style>.
 Xử lý các nhận xét XML bên trong các phần tử này (xử lý nhận xét bình
thường sẽ không luôn luôn hoạt động).
 Thay thế các đối tượng thuộc tính ký tự số như & # 65; hoặc & # x7f; với
nhân vật tương ứng.
 Chấm dứt ';' là tùy chọn nếu các thực thể tham chiếu ở cuối đầu vào;
nếu không chấm dứt ';' là bắt buộc, để tránh các trận đấu giả mạo giống
như "Alpha & Omega Corp".
 Thay thế tất cả các tham chiếu thuộc tính nhân vật có tên với ký tự
tương ứng.
 & nbsp; được thay thế bằng không gian thay vì ký tự 0xa0.
 Newlines được thay thế cho các phần tử cấp khối.
 <CDATA> phần được công nhận.
 Thẻ nội tuyến, chẳng hạn như <b>, <i>, hoặc <span> sẽ bị xóa.
 Các ký tự chữ hoa như các ký tự, gt, lt và amp được ghi nhận và xử lý
dưới dạng chữ thường.
Bảng dưới đây trình bày các ví dụ về việc tước bỏ HTML.

Input Output
my <a href="www.foo.bar">link</a> my link
<br>hello<!--comment-→ hello
hello<script><!-- f('<!--internal-
hello
→</script>'); -→</script>
if a<b then print a; if a<b then print a;
hello <td height=22 nowrap
hello
align="left">
a<b &#65 Alpha&Omega Ω a<b A Alpha&Omega Ω
Example:
<analyzer>
<charFilter class="solr.HTMLStripCharFilterFactory"/>
<tokenizer ...>
[...]
</analyzer>
solr.ICUNormalizer2CharFilterFactory
Example:
<analyzer>
<charFilter class="solr.ICUNormalizer2CharFilterFactory"/>
<tokenizer ...>
[...]
</analyzer>
solr.PatternReplaceCharFilterFactory
Example:
<analyzer>
<charFilter class="solr.PatternReplaceCharFilterFactory"
pattern="([nN][oO]\.)\s*(\d+)" replacement="$1$2"/>
<tokenizer ...>
[...]
</analyzer>
Bảng dưới đây trình bày các ví dụ về thay thế mô hình regex-based:
Replaceme Descriptio
Input Pattern Output
nt n
Removes
see-ing "ing" from
(\w+)(ing) $1 see-ing look
looking the end of
word.
Same as
above. 2nd
see-ing
(\w+)ing $1 see-ing look parenthes
looking
es can be
omitted.
No.1 NO. no. [nN][oO]\.\s*(\d Replace
#$1 #1 NO. #543
543 +) some
string
literals
Change
abc=1234=56 (\w+)=(\d+)=(\d 5678=abc=12 the order
$3=$1=$2
78 +) 34 of the
groups.
3.8 Language Analysis
Phần này chứa thông tin về tokenizers và bộ lọc có liên quan đến chuyển đổi
bộ ký tự hoặc để sử dụng với các ngôn ngữ cụ thể.
Đối với các ngôn ngữ châu Âu, tokenization khá đơn giản. Token được phân
cách bằng khoảng trắng và / hoặc một tập hợp các ký tự chấm câu tương đối
nhỏ.
Trong các ngôn ngữ khác các quy tắc tokenization thường không đơn giản như
vậy. Một số ngôn ngữ Châu Âu cũng có thể yêu cầu các quy tắc tokenization
đặc biệt, chẳng hạn như các quy tắc để giải mã các từ tiếng Đức.
Để biết thông tin về phát hiện ngôn ngữ ở thời gian chỉ mục, hãy xem Phát hiện
các ngôn ngữ trong quá trình lập chỉ mục.
KeywordMarkerFilterFactory
Bảo vệ các từ khỏi bị sửa đổi bởi các bộ đệm. Danh sách từ được bảo vệ tùy
chỉnh có thể được chỉ định với thuộc tính "được bảo vệ" trong lược đồ. Bất kỳ
từ trong danh sách từ được bảo vệ sẽ không được sửa đổi bởi bất kỳ stemmer
trong Solr.
Một ví dụ mẫu Solr protwords.txt có thể được tìm thấy trong tập tin thiết đặt
cấu hình sample_techproducts_configs:
<fieldtype name="myfieldtype" class="solr.TextField">
<analyzer>
<tokenizer class="solr.WhitespaceTokenizerFactory"/>
<filter class="solr.KeywordMarkerFilterFactory"
protected="protwords.txt" />
<filter class="solr.PorterStemFilterFactory" />
</analyzer>
</fieldtype>
KeywordRepeatFilterFactory
Phát ra mỗi mã thông báo hai lần, một với thuộc tính KEYWORD và một lần
không có.
Nếu được đặt trước thân cây, kết quả sẽ là bạn sẽ nhận được thẻ bài báo
không lưu giữ được ở cùng vị trí với cây có gốc. Truy vấn khớp với cụm từ
chính xác gốc sẽ có được điểm số tốt hơn trong khi vẫn duy trì lợi ích thu hồi
được. Một ưu điểm khác của việc giữ lại mã thông báo ban đầu là sự cắt ngắn
ký tự đại diện sẽ hoạt động như mong đợi.
Để định cấu hình, thêm KeywordRepeatFilterFactory trong chuỗi phân tích.

Chúng tôi cũng khuyên bạn nên bao gồm RemoveDuplicatesTokenFilterFactory
để tránh trùng lặp khi các thẻ không phải là stemmed.
Cấu hình fieldType mẫu có thể như sau:
<fieldtype name="english_stem_preserve_original" class="solr.TextField">

<analyzer>
<filter class="solr.KeywordRepeatFilterFactory" />
<filter class="solr.RemoveDuplicatesTokenFilterFactory" />
</analyzer>
</fieldtype>
StemmerOverrideFilterFactory
Ghi đè các thuật toán bắt nguồn bằng cách áp dụng lập bản đồ tùy chỉnh, sau
đó bảo vệ các điều khoản này khỏi bị sửa đổi bởi các bộ đệm.
Một bản đồ tùy chỉnh các từ cho thân cây, trong một tệp được tách bằng tab,
có thể được chỉ định cho thuộc tính "dictionary" trong lược đồ. Các từ trong
bản đồ này sẽ được bắt nguồn từ các tập tin, và sẽ không được thay đổi bởi
bất kỳ stemmer.
Một mẫu stemdict.txt với ý kiến có thể được tìm thấy trong Nguồn Repository.
<fieldtype name="myfieldtype" class="solr.TextField">
<analyzer>
<tokenizer class="solr.WhitespaceTokenizerFactory"/>
<filter class="solr.StemmerOverrideFilterFactory"
dictionary="stemdict.txt" />
</analyzer>
</fieldtype>
Dictionary Compound Word Token Filter
Bộ lọc này chia tách, hoặc giải mã, ghép từ thành từng từ bằng cách sử dụng
một từ điển của các từ thành phần. Mỗi mã thông báo đầu vào được truyền
qua không thay đổi. Nếu nó cũng có thể được decompounded thành các
subwords, mỗi subword cũng được thêm vào dòng tại cùng một vị trí hợp lý.
Các từ phức thường được tìm thấy nhiều nhất trong các ngôn ngữ Germanic.
Thí dụ:
<analyzer>
<filter class="solr.DictionaryCompoundWordTokenFilterFactory"
dictionary="germanwords.txt"/>
</analyzer>
Unicode Collation
Unicode Collation là một phương pháp phân loại văn bản nhạy cảm với ngôn
ngữ cũng có thể được sử dụng cho mục đích tìm kiếm nâng cao.
Việc so sánh Unicode trong Solr rất nhanh, bởi vì tất cả công việc được thực
hiện ở thời gian chỉ mục.
Thay vì chỉ định một bộ phân tích trong <fieldtype ... class = "solr.TextField">,
các lớp loại trường lĩnh vực solr.CollationField và solr.ICUCollationField cung
cấp tính năng này. solr.ICUCollationField, được hỗ trợ bởi thư viện ICU4J, cung
cấp cấu hình linh hoạt hơn, có nhiều miền địa phương, nhanh hơn đáng kể, và
đòi hỏi ít bộ nhớ hơn và không gian chỉ mục ít hơn, vì các phím của nó nhỏ hơn
so với các sản phẩm do việc triển khai JDK hỗ trợ. CollationField.
solr.ICUCollationField được bao gồm trong phân tích Solr-extras contrib - xem
hướng dẫn để biết các bình chứa nào bạn cần thêm vào SOLR_HOME / lib để
sử dụng nó.
solr.ICUCollationField và các lĩnh vực solr.CollationField có thể được tạo ra

theo hai cách:
 Dựa trên trình kết hợp hệ thống với một Locale.
 Dựa trên bộ quy tắc RuleBasedCollator phù hợp.
ASCII & Decimal Folding Filters
ASCII Folding
Bộ lọc này chuyển đổi ký tự Unicode, số và ký tự Unicode không phải là ký tự
127 ký tự ASCII đầu tiên (khối Unicode Cơ bản Latin) thành các ASCII tương
đương của chúng, nếu tồn tại. Chỉ những ký tự với các lựa chọn ASCII hợp lý
mới được chuyển đổi.
Điều này có thể làm tăng thu hồi bằng cách gây ra nhiều trận đấu hơn. Mặt
khác, nó có thể làm giảm độ chính xác vì sự khác biệt về ngôn ngữ cụ thể có
thể bị mất.
Ví dụ:
<analyzer>
<filter class="solr.ASCIIFoldingFilterFactory"/>
</analyzer>
Decimal Digit Folding

Bộ lọc này chuyển đổi bất kỳ ký tự nào trong danh mục chung chung "Số thập
phân" Unicode (Nd) thành các chữ số Latinh cơ bản tương đương (0-9).
Điều này có thể làm tăng thu hồi bằng cách gây ra nhiều trận đấu hơn. Mặt
khác, nó có thể làm giảm độ chính xác vì sự khác biệt về ngôn ngữ cụ thể có
thể bị mất.
Ví dụ:
<analyzer>
<filter class="solr.DecimalDigitFilterFactory"/>
</analyzer>
Language-Specific Factories
Các factories này được thiết kế để làm việc với các ngôn ngữ cụ thể. Các ngôn
ngữ được đề cập ở đây là:
 Arabic
 Brazilian Portuguese
 Bulgarian
 Catalan
 Traditional Chinese
 Simplified Chinese
 Czech
 Danish
 Dutch
 Finnish
 French
 Galician
 German
 Greek
 Hebrew, Lao, Myanmar, Khmer
 Hindi
 Indonesian
 Italian
 Irish
 Japanese
 Latvian
 Norwegian
 Persian
 Polish
 Portuguese
 Romanian
 Russian
 Scandinavian
 Serbian
 Spanish
 Swedish
 Thai
 Turkish
 Ukrainian
3.9 Phonetic Matching
Beider-Morse Phonetic Matching (BMPM)
Ví dụ về cách sử dụng mã hoá này trong máy phân tích của bạn, hãy xem Bộ lọc
Beider Morse trong phần Mô tả Bộ lọc.
Beider-Morse Phonetic Matching (BMPM) là một công cụ "âm thanh" cho phép
bạn tìm kiếm bằng cách sử dụng một hệ thống phù hợp ngữ âm mới. BMPM
giúp bạn tìm kiếm các tên cá nhân (hoặc chỉ là họ) trong một chỉ mục Solr /
Lucene, và cao hơn nhiều so với các bộ mã hoá âm vị hiện có, như soundex
thường, metaphone, caverphone, v.v ...
Nhìn chung, phù hợp ngữ âm cho phép bạn tìm kiếm một danh sách tên cho
các tên có ngữ âm tương đương với tên mong muốn. BMPM tương tự như
một tìm kiếm soundex trong đó không chính xác chính tả là không cần thiết.
Không giống như soundex, nó không tạo ra một số lượng lớn hits giả mạo.
Từ chính tả của tên, BMPM cố gắng xác định ngôn ngữ. Sau đó áp dụng các quy
tắc ngữ âm cho ngôn ngữ cụ thể đó để chuyển ngữ thành một bảng chữ cái
ngữ âm. Nếu không thể xác định được ngôn ngữ với mức độ chắc chắn, nó sẽ
sử dụng ngữ âm học chung. Cuối cùng, nó áp dụng các quy tắc độc lập về ngôn
ngữ liên quan đến những thứ như những phụ âm và nguyên âm lồng tiếng và
không nói ra để đảm bảo độ tin cậy của các trận đấu.
Ví dụ: giả sử rằng các kết quả tìm thấy khi tìm kiếm Stephen trong cơ sở dữ liệu
là "Stefan", "Steph", "Stephen", "Steve", "Steven", "Stove" và "Stuffin".
"Stefan", "Stephen" và "Steven" có thể có liên quan và là tên mà bạn muốn
xem. "Stuffin", tuy nhiên, có lẽ không liên quan. Cũng bị từ chối là "Steph",
"Steve", và "Stove". Trong số đó, "Bếp" có lẽ không phải là cái mà chúng tôi
muốn. Nhưng "Steph" và "Steve" có thể là những cái mà bạn có thể quan tâm.
Đối với Solr, tìm kiếm BMPM có sẵn cho các ngôn ngữ sau:
 English
 French
 German
 Greek
 Hebrew written in Hebrew letters
 Hungarian
 Italian
 Polish
 Romanian
 Russian written in Cyrillic letters
 Russian transliterated into English letters
 Spanish
 Turkish
Việc so khớp tên cũng được áp dụng cho các họ không phải Do Thái từ các
quốc gia mà ngôn ngữ đó được nói.
Daitch-Mokotoff Soundex
Để sử dụng mã hoá này trong máy phân tích của bạn, hãy xem Bộ lọc Soundex
Daitch-Mokotoff trong phần Mô tả Bộ lọc.
Thuật toán Soundex của Daitch-Mokotoff là sự tinh tế của các thuật toán
Russel và American Soundex, mang lại độ chính xác cao hơn trong việc kết hợp
các họ Slavic và Yiddish với cách phát âm tương tự nhưng sự khác biệt trong
chính tả.
Sự khác biệt chính so với các biến thể soundex khác là:
 tên được mã hoá dài 6 chữ số
 ký tự ban đầu của tên được mã hoá
 quy tắc để mã hoá nhiều ký tự n-gram
 nhiều mã hoá có thể cho cùng tên (phân nhánh)
Lưu ý: việc triển khai được sử dụng bởi Solr (DaitchMokotoffSoundex của
commons-codec) có các quy tắc phân nhánh bổ sung so với mô tả ban đầu của
thuật toán.
Double Metaphone
Để sử dụng mã hóa này trong máy phân tích của bạn, xem Bộ lọc Metaphone
Đôi trong phần Mô tả Bộ lọc. Ngoài ra, bạn có thể chỉ định mã hóa =
"DoubleMetaphone" bằng Bộ lọc Âm vị, nhưng lưu ý rằng phiên bản Bộ Phóng
sinh sẽ không cung cấp mã hóa thứ hai ("luân phiên") được tạo ra bởi Bộ lọc
Kênh Đôi cho một số mã thông báo.
Metaphone
Để sử dụng mã hóa này trong máy phân tích của bạn, hãy chỉ định mã hóa =
"Metaphone" bằng Bộ lọc âm vị.
Mã hóa các mã thông báo sử dụng thuật toán Metaphone của Lawrence
Philips, mô tả trong "Hanging on the Metaphone" trong Ngôn ngữ Máy tính,
tháng 12 năm 1990.
Soundex
"Soundex" bằng Bộ lọc âm vị.
Mã hóa các mã thông báo sử dụng thuật toán Soundex, được sử dụng để liên
hệ các tên tương tự, nhưng cũng có thể được sử dụng như là một chương trình
mục đích chung để tìm các từ với các âm vị tương tự.
Refined Soundex
"RefinedSoundex" bằng Bộ lọc âm vị.
Mã hóa các mã thông báo sử dụng phiên bản cải tiến của thuật toán Soundex.
Caverphone
Để sử dụng mã hoá này trong máy phân tích của bạn, hãy chỉ định mã hóa =
"Caverphone" bằng Bộ lọc âm vị.
Caverphone là một thuật toán được tạo ra bởi Dự án Caversham tại Đại học
Otago. Thuật toán được tối ưu hóa cho các dấu trọng âm hiện diện ở phía nam
thành phố Dunedin, New Zealand.
Kölner Phonetik a.k.a. Cologne Phonetic
Để sử dụng mã hóa này trong máy phân tích của bạn, chỉ định mã hóa =
"ColognePhonetic" với Bộ lọc âm vị.
Kölner Phonetik, một thuật toán được xuất bản bởi Hans Joachim Postel vào
năm 1969, được tối ưu hóa cho tiếng Đức.
NYSIIS
Để sử dụng mã hoá này trong máy phân tích của bạn, chỉ định mã hóa =
"Nysiis" với Bộ lọc Âm vị.
NYSIIS là một bộ mã hóa được sử dụng để liên hệ các tên tương tự, nhưng
cũng có thể được sử dụng như là một chương trình mục đích chung để tìm các
từ có các âm vị tương tự.

Apache Solr

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Apache Solr

Uploaded by

Copyright:

Available Formats

Chương 2: Documents, Fields, and Schema Design

2.1 Overview of Documents, Fields, and Schema Design

2.1.1 How Solr Sees the World

2.1.2 Field Analysis

2.2 Solr Field Types

2.2.1 Field Type Definitions and Properties

2.2.1.2 Field Type Properties

2.2.2 Field Types Included with Solr

2.2.3 Working with Currencies and Exchange Rates

 Truy vấn điểm

 Truy vấn phạm vi

 Truy vấn phạm vi chức năng

 Phân tích tiền tệ theo mã tiền tệ hoặc biểu tượng

2.2.3.2 Exchange Rates

2.2.4 Working with Dates

2.2.4.1 Date Formatting

Các trường ngày của Solr (TrieDateField, DatePointField và DateRangeField) đại

2.2.4.3 Date Math

Đây là một ngày trước đây:

NGAY + 6 THÁNG + 3 NGÀY / NGÀY

1972-05-20T17: 33: 18.772Z + 6 THÁNG + 3 NGÀY / NGÀY

2.2.4.5 Request Parameters That Affect Date Math

2.2.5.2 Defining the EnumField configuration file

2.2.6 Working with External Files and Processes

2.2.6.2 Format of the External File

2.2.6.4 The PreAnalyzedField Type

<fieldType name="pre_with_query_analyzer" class="solr.PreAnalyzedField">

2.2.7 Field Properties by Use Case

index stor multiVal omitNo termVec termPosit docVal

2.2 Defining Fields

<field name="price" type="float" default="0.0" indexed="true"

2.2.3 Optional Field Type Override Properties

2.3 Copying Fields

<copyField source="cat" dest="text" maxChars="30000" />

2.4 Dynamic Fields

2.5 Other Schema Elements

2.5.1 Unique Key

2.5.2 Default Search Fields & Query Operator

2.6 Schema API

API giản đồ sử dụng lớp ManagedIndexSchemaFactory, đây là nhà máy lược đồ

2.7 Putting the Pieces Together

2.7.1 Choosing Appropriate Numeric Types

Schildt, Herbert; Wolpert, Lewis; Davies, P.

schildt / herbert / wolpert / lewis / davies / p

schildt herbert wolpert lewis davies p

2.8.3 Using DocValues

bin / solr start -e-schema

2.9.2 Configuring Schemaless Mode

Output indicating success:

The fields now in the schema (output from curl

This document will fail, as shown in this output:

Chương 3 : Understanding Analyzers, Tokenizers, and Filters

Using Analyzers, Tokenizers, and Filters

For More Information

Đối với Analyzers, có:

3.2 Running Your Analyzers

3.3 About Tokenizers

When To use a CharFilter vs. a TokenFilter

<fieldType name="text" class="solr.TextField">

Để biết các mẹo sử dụng về mã thông báo của Solr, xem

Lưu ý rằng các từ được chia theo dấu nối.