Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Chinese / Japanese / Korean tokenizer support for search / tantivy #882

Open
joepio opened this issue May 6, 2024 · 2 comments
Open

Chinese / Japanese / Korean tokenizer support for search / tantivy #882

joepio opened this issue May 6, 2024 · 2 comments

Comments

@joepio
Copy link
Member

joepio commented May 6, 2024

Out of the box, Tantivy only support latin languages. We could add some extra tokenizers:

Chinese (tantivy-jieba and cang-jie), Japanese (lindera, Vaporetto, and tantivy-tokenizer-tiny-segmenter) and Korean (lindera + lindera-ko-dic-builder)

I'm not sure if tokenizers can be combined. It doesn't look like it...

Tokenizer-specific fields

use tantivy::schema::{Schema, SchemaBuilder, TEXT};

fn create_schema() -> Schema {
    let mut schema_builder = SchemaBuilder::default();
    
    // Create a field for English with a specific tokenizer
    schema_builder.add_text_field("english_text", TEXT);
    
    // Create a field for Chinese with a different tokenizer
    schema_builder.add_text_field("chinese_text", TEXT);
    
    schema_builder.build()
}

Problem with this approach is that it is very inefficient, it makes the search DB way bigger for every extra tokenizer we have

One Tokenizer To Rule Them All

Not sure if this is possible. We now use the SimpleTokenizer, but that is apparently not good for Chinese chars.

Select tokenizer as config option

We can make the user decide when booting up AtomicServer.
This would add some code complexity.
It would not work for mixed language instances.

@shidianxia
Copy link

Another possible approach:
Generate JSON file at runtime and use off-the-shelf search engine server to read the data.

  1. add a config field to determine whether to generate JSON(already done by 'atomic-server export' but not at runtime), and probably a generating schedule
  2. user could choose their own each engine like Algolia, Meilisearch...

@joepio
Copy link
Member Author

joepio commented May 7, 2024

  1. user could choose their own each engine like Algolia, Meilisearch...

That would work as a fallback, but it would not integrate with the front-end. I think AtomicServer should provide a good out-of-the-box experience.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants