Solr'u e-ticaret arama/besleme/otomatik önerme/kişiselleştirme kullanım durumlarımız için kullandık.

Solr kümesiyle ilgili zorluklar

• Solr altyapısını yönetmek (zookeeper , JVM, GC analizi vb.) zorlu bir iştir. Genel olarak, bunun için özel bir geliştiriciye (SRE/SDE-3) ihtiyacımız var.
• Daha yeni bir kararlı sürüme yükseltme. Herhangi bir kritik sorun için daha az topluluk desteği.

ELK artık esnek premium lisansla geliyor. Bu yüzden açık kaynak olduğu için opensearch'ü seçtik. Elasticsearch 7.10 sürümüne dayanmaktadır. apache lisansı vardır.

Başlıca Zorluklar

• Mevcut kodun tasarım sorunları vardı. Solr ile sıkı bir şekilde birleştirilmiştir. Mikro hizmet mimarisi ve çoklu hizmet bağımlılığı.
• Bazı bölgelerde ve ülke bazında lansmanlarda büyük küme boyutu.

1. Tüm bölgelerde açık arama küme oluşumu için terraform kullandık.
2. Kod için fabrika tasarım modelini ve Adaptör tasarım modelini kullandık.
3. Hem opensearch hem de solr'da paralel veri alımı.
4. Yeniden indeksleme hizmetimiz tarafından delta verisi opensearch & solr'un taşınması.
5. Hem opensearch hem de solr desteğiyle tek tek hizmet lansmanı
6. 1'den 5'e kadar olan adımlar hazır olduğunda. newRelic'te ülke bazında lansman ve izleme planladık.

Büyük darboğaz : Düğüm tipi c5 AWS makinesinin seçimi civarındaydı. Kıyaslama yaparak düzelttik ve c6g ile gitmeyi seçtik.

Sonuç

100 milyondan fazla belgeyi hiçbir kesinti olmadan solr'dan opensearch'e başarıyla taşıdık. Geçiş, solr ve opensearch üzerinde 100'den fazla düğüm içeriyordu. Ayrıca yaklaşık 0,8 milyon USD tasarruf etmeyi başardık.

Referans

1. Fabrika tasarım deseni
2. Dünya biçimi
3. açık arama
4. Güneş
5. Adaptör tasarım deseni