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

feat: Re-support for Elasticsearch #13166

Closed
wants to merge 23 commits into from

Conversation

MomentQYC
Copy link
Contributor

What

Re-support for ElasticSearch Search
Earlier versions of ElasticSearch and OpenSearch are not currently supported due to some official ElasticSearch behavior.

Why

MeiliSearch currently has issues with certain aspects (such as cumbersome upgrade steps). A solution could be provided by re-supporting ElasticSearch.

Additional info (optional)

Checklist

  • Read the contribution guide
  • Test working in a local environment
  • (If needed) Add story of storybook
  • (If needed) Update CHANGELOG.md
  • (If possible) Add tests

@github-actions github-actions bot added the packages/backend Server side specific issue/PR label Feb 5, 2024
@MomentQYC MomentQYC marked this pull request as ready for review February 5, 2024 06:12
Copy link
Contributor

github-actions bot commented Feb 5, 2024

このPRによるapi.jsonの差分

差分はこちら

Get diff files from Workflow Page

Copy link

codecov bot commented Feb 5, 2024

Codecov Report

Attention: Patch coverage is 26.94611% with 122 lines in your changes are missing coverage. Please review.

Project coverage is 64.89%. Comparing base (61eec93) to head (6d226e3).
Report is 5 commits behind head on develop.

Current head 6d226e3 differs from pull request most recent head d45f35f

Please upload reports for the commit d45f35f to get more accurate results.

Files Patch % Lines
packages/backend/src/core/SearchService.ts 10.23% 114 Missing ⚠️
packages/backend/src/GlobalModule.ts 63.63% 8 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff             @@
##           develop   #13166      +/-   ##
===========================================
- Coverage    66.21%   64.89%   -1.33%     
===========================================
  Files          990      986       -4     
  Lines       117137   111806    -5331     
  Branches      4489     5750    +1261     
===========================================
- Hits         77568    72551    -5017     
+ Misses       39538    37821    -1717     
- Partials        31     1434    +1403     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@u1-liquid
Copy link
Sponsor Contributor

I believe that for indexing purposes, it's more flexible to route indexing through Logstash or a similar intermediary rather than calling Elasticsearch directly from Misskey.

Due to Elasticsearch's architecture, concentrating all data into a single index is not advisable for both performance and management reasons.
It's preferable to split indices by month or day and use a wildcard (*) to query them collectively.
Additionally, setting up an indices policy could automatically remove outdated data from remote servers.

Attempting to finely tune this setup within Misskey could become inefficient, akin to developing a template engine.
Instead, implementing a feature to transfer json_lines over TCP/UDP for use with Logstash / vector.dev would be more beneficial.

@MomentQYC
Copy link
Contributor Author

I believe that for indexing purposes, it's more flexible to route indexing through Logstash or a similar intermediary rather than calling Elasticsearch directly from Misskey.

Due to Elasticsearch's architecture, concentrating all data into a single index is not advisable for both performance and management reasons. It's preferable to split indices by month or day and use a wildcard (*) to query them collectively. Additionally, setting up an indices policy could automatically remove outdated data from remote servers.

Attempting to finely tune this setup within Misskey could become inefficient, akin to developing a template engine. Instead, implementing a feature to transfer json_lines over TCP/UDP for use with Logstash / vector.dev would be more beneficial.

I have currently implemented index splitting by month and the ability to query them simultaneously using a wildcard, allowing for more efficient data retrieval.
I'm not really good at Elasticsearch-related development, and I don't have any friends around me who are particularly proficient in this area, so there's not much I can do at the moment.

@MomentQYC

This comment was marked as resolved.

@MomentQYC
Copy link
Contributor Author

Temporarily closed

@MomentQYC MomentQYC closed this May 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
packages/backend Server side specific issue/PR packages/misskey-js
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants