Chúng tôi đã sử dụng solr cho các trường hợp sử dụng tìm kiếm/nguồn cấp dữ liệu/tự động đề xuất/cá nhân hóa thương mại điện tử của mình.

Những thách thức với cụm solr

• Quản lý cơ sở hạ tầng solr (zookeeper, JVM, phân tích GC, v.v.) là một thách thức. Nói chung, chúng tôi cần một nhà phát triển chuyên dụng (SRE/SDE-3) cho nó.
• Nâng cấp lên phiên bản ổn định mới hơn. Hỗ trợ cộng đồng ít hơn cho bất kỳ vấn đề quan trọng.

ELK hiện đi kèm với giấy phép cao cấp linh hoạt. Vì vậy, chúng tôi đã chọn opensearch vì nó là mã nguồn mở. Nó dựa trên phiên bản elaticsearch 7.10. Nó có giấy phép apache.

Thách thức lớn

• Mã hiện tại có vấn đề về thiết kế. Kết hợp chặt chẽ với solr. Kiến trúc microservice và sự phụ thuộc vào nhiều dịch vụ.
• Kích thước cụm lớn ở một số khu vực và ra mắt theo quốc gia.

1. Chúng tôi đã sử dụng địa hình để hình thành cụm tìm kiếm mở ở tất cả các vùng.
2. Đối với mã, chúng tôi đã sử dụng mẫu thiết kế nhà máy và mẫu thiết kế Bộ điều hợp.
3. Nhập dữ liệu song song trong cả opensearch & solr.
4. Di chuyển dữ liệu delta opensearch & solr bằng dịch vụ lập chỉ mục lại của chúng tôi.
5. Khởi chạy từng dịch vụ một với sự hỗ trợ cho cả opensearch & solr
6. Khi các bước từ 1 đến 5 đã sẵn sàng. Chúng tôi đã lên kế hoạch ra mắt và theo dõi thông minh trên toàn quốc về newRelic.

Nút cổ chai lớn : Đó là xung quanh việc lựa chọn máy AWS loại nút c5. Chúng tôi đã sửa nó bằng cách đo điểm chuẩn và chọn sử dụng c6g.

Kết quả

Chúng tôi đã di chuyển thành công hơn 100 triệu tài liệu từ solr sang opensearch mà không có thời gian chết. Quá trình di chuyển liên quan đến hơn 100 nút trên solr và opensearch. Chúng tôi cũng đã tiết kiệm được khoảng 0,8 triệu USD.

Thẩm quyền giải quyết

1. Mẫu thiết kế nhà xưởng
2. địa hình
3. tìm kiếm mở
4. solr
5. Mẫu thiết kế bộ điều hợp