Advanced ChemBlocks: Magento'da Elasticsearch Araması

Kimya kataloğunda kimse gezinmez. Müşteri arama kutusuna bir tanımlayıcı yapıştırır — CAS numarası, MDL numarası, SMILES string'i ya da 4-Amino-5-chloro-2-methoxybenzaldehyde gibi bir isim — ve doğru building block'u ilk sayfada bekler. Advanced ChemBlocks (achemblock.com) bu kataloğu Magento 2 üzerinde satıyor; Magento 2 de aramanın tamamını Elasticsearch'e devrediyor.

Sonra hosting değiştirdiler. Yeni shared-hosting ortamı Elasticsearch'ü hiç desteklemiyordu, kendi kurulum denemeleri anlaşılmaz bir fatal error ile ölüyordu ve sonunda Docker'da ayağa kalkan cluster'ın yeni bir derdi vardı: yedi aranabilir attribute'tan yalnızca üçü vitrinde sonuç dönüyordu. Aşağıda yalnızca evidence pack'in gösterdiği var — uydurma sayı yok.

Kısa cevap: "Elasticsearch bu sunucuda çalışmıyor" cümlesinin gerçek karşılığı boot sırasında bir JNA fatal error'dı — JVM, JNA'in native kütüphanesini temp dizininden çıkarıp çalıştıramıyordu. -Djna.io.tmpdir'i elasticsearch kullanıcısının sahip olduğu bir dizine çevirmek crash'i çözdü ve Magento sürümlerinin desteklediği 7.17 hattına giden yolu yeniden açtı. "Name alanı hiçbir şey dönmüyor" belirtisi ise: yakalanan Magento query'si tüm aranabilir attribute'ların boost'larıyla birlikte istendiğini kanıtlıyor — yani bug query'de değil, index tarafında.

Sorun

Advanced ChemBlocks, Magento 2 mağazasını Elasticsearch 7.17.11'in sorunsuz çalıştığı ve tüm aranabilir alanların doğru sonuç verdiği managed bir host'tan, Elasticsearch desteği olmayan bir shared-hosting sağlayıcısına taşıdı. Kurulumu kendileri denedi. Kendi anlatımlarındaki sıra:

• Elasticsearch 8.x — eski Magento sürümüyle uyumsuz. Çalışmadı.
• Elasticsearch 7.17.11 (RPM) — "bu sunucuda düzgün çalışmadı." Sonuç yok.
• Elasticsearch 7.8.1 (Docker) — nihayet ayakta.

Ama ayakta olmak doğru çalışmak değil. Magento'da yedi aranabilir attribute tanımlıydı: name, sku, cas, mdl, formula, iupac ve smiles. Vitrinde yalnızca sku, cas ve mdl sonuç dönüyordu. name alanı terminalden Elasticsearch sorgulandığında görünüyordu — ama ürün adıyla yapılan storefront aramaları boş dönüyordu. Ekibin çalışma teorisi versiyon uyumsuzluğuydu; çünkü taşınmadan önce her şey 7.17.11'de çalışıyordu.

Kimya tedarikçisi için bu kozmetik bir sorun değil. hydrochloride ya da tam IUPAC adı arayıp sonuç alamayan müşteri, o bileşiği stoklamadığınızı varsayar.

Teşhis

Versiyon sorunu olmayan versiyon sorunu

İlk somut kanıt, kendi sunucularındaki Elasticsearch log'unda duran fatal error'dı:

[2023-07-14T09:40:47,382][ERROR][o.e.b.ElasticsearchUncaughtExceptionHandler]
fatal error in thread [main], exiting
java.lang.NoClassDefFoundError: Could not initialize class com.sun.jna.Native

Elasticsearch native çağrılar için JNA kullanır (memory locking, temp dosya işlemleri). JNA, native kütüphanesini bir temp dizinine çıkarır ve oradan yükleyip çalıştırır. Sertleştirilmiş ya da shared host'larda temp dizini çoğu zaman noexec mount edilir — JNA çıkardığı dosyayı çalıştıramaz, class initialize olamaz ve Elasticsearch daha port'a bind olmadan main içinde çıkar.

Bu hata modeli tüm gizemi açıklıyor: native RPM kurulumları "bu sunucuda çalışmazken" aynı yazılımın Docker'da (kendi dosya sistemiyle gelir) ve önceki host'ta sorunsuz çalışması. Şüpheli hiçbir zaman Elasticsearch versiyonu değildi. Çalıştığı ortamdı.

Yakalanan tek query'nin kanıtladığı

İkinci kanıt, Magento'nun Elasticsearch'e gönderdiği gerçek arama isteğiydi. Önemli kısmıyla:

{
  "query": {
    "bool": {
      "must": [{ "terms": { "visibility": ["3", "4"] } }],
      "should": [
        { "match": { "_search": { "query": "...", "boost": 2.0 } } },
        { "match": { "name":    { "query": "...", "boost": 9.0 } } },
        { "match": { "sku":     { "query": "...", "boost": 11.0 } } },
        { "match": { "formula": { "query": "...", "boost": 8.0 } } },
        { "match": { "mdl":     { "query": "...", "boost": 8.0 } } },
        { "match": { "iupac":   { "query": "...", "boost": 7.0 } } },
        { "match": { "smiles":  { "query": "...", "boost": 8.0 } } },
        { "match": { "cas":     { "query": "...", "boost": 10.0 } } },
        { "match_phrase_prefix": { "name": { "analyzer": "prefix_search" } } },
        { "match_phrase_prefix": { "sku":  { "analyzer": "sku_prefix_search" } } }
      ],
      "minimum_should_match": "1"
    }
  },
  "track_total_hits": 2147483647
}

Her match clause ayrıca operator: OR, minimum_should_match: "3", max_expansions: 50 ve fuzzy_transpositions: true taşıyor; isteğin sonunda layered navigation için fiyat histogram aggregation'ı var.

Bu tek yakalama en kritik soruyu kapatıyor. Magento name alanını istiyor — hem de sku (11.0) ve cas (10.0)'dan sonra üçüncü en yüksek boost olan 9.0 ile. Query üretimi sağlam. Alan istekte varken hiç eşleşmiyorsa sorun index tarafındadır: mapping, analyzer ya da dokümanların kendisi.

Kimyasal tanımlayıcılar vs analiz edilen metin

Clause başına minimum_should_match: "3" tam da kimya verisinde ilginçleşiyor. 4-Amino-5-chloro-2-methoxybenzaldehyde gibi bir sorgu birden fazla terime analiz edilir ve bir alanda en az üçünün eşleşmesi gerekir. cas ve mdl gibi kısa, düzenli kod alanları eşleşiyordu. name ve iupac gibi uzun analiz edilen metinlerse ancak index tarafındaki analyzer, saklanan değeri arama tarafıyla uyumlu tokenize ederse eşleşir — tire ve rakam yoğun kimyasal adlandırma, analyzer uyumsuzluğunun bir alanı terminaldeki _search'te dolu gösterip vitrinde sıfır sonuç döndürdüğü metin türünün ta kendisi. Yakalanan query avı tam bu katmana daraltıyor.

Çözüm

Boot crash'in dokümante, sıkıcı bir çözümü var — Elastic'in JNA temporary directory dokümanına göre JNA'i elasticsearch kullanıcısının sahip olduğu ve execute edebildiği bir temp dizinine yönlendirmek:

# /etc/sysconfig/elasticsearch
ES_JAVA_OPTS="-Djna.io.tmpdir=/var/lib/elasticsearch/tmp"

mkdir -p /var/lib/elasticsearch/tmp
chown -R elasticsearch:elasticsearch /var/lib/elasticsearch/tmp

Eşdeğer alternatif: /etc/elasticsearch/jvm.options içine -Djava.io.tmpdir=${ES_TMPDIR} yazmak.

Crash ortadan kalkınca native kurulum yolu çıkmaz olmaktan çıkıyor — bu önemli, çünkü hedef hiçbir zaman "herhangi bir Elasticsearch" değildi; Magento sürümlerinin gerçekten desteklediği ve önceki host'ta yedi alanı da doğru servis ettiği kanıtlı 7.17.11'di. Alan belirtisinin peşine düşmek ise standart index-tarafı yöntemi izler: mapping ve analyzer'ları çalışan bir referansla karşılaştır, gerçek bir ürün adı için _analyze ile token çıktısını doğrula, Magento'dan reindex et. Evidence pack teşhisi ve crash fix'ini kaydediyor; final reindex çıktıları pack'te yok — gösteremeyeceğim bir finali anlatmayacağım.

Sonuçlar

Yalnızca kaynak pack'in desteklediği:

Sonuç	Kanıt
Fatal JNA boot crash teşhis edildi ve çözüldü	Error log + jna.io.tmpdir fix'i, birebir komutlarla
"Yanlış versiyon" teorisi emekli edildi	Aynı hata Docker'da ve önceki host'ta yok; crash ortamsal
Elasticsearch çalışması sürdü	Docker'da 7.8.1; Magento'nun desteklediği hedef 7.17.11
Arama isteğinin anatomisi belgelendi	Production query tam haliyle yakalandı, 7 attribute + boost'lar
Alan belirtisi index tarafına izole edildi	name query'de 9.0 boost ile var, vitrinde sonuç yok

İddia etmeyeceklerim: arama latency'si, conversion artışı ya da önce/sonra eşleşme yüzdesi. Bu sayılar kaynak pack'te yok; text alanları için final reindex sonucu da pack'e kaydedilmemiş.

Öğrendiklerimiz

1. Versiyon değiştirmeden önce fatal error'ı okuyun. main içindeki boot crash'in nedeni bir log satırı ötede; versiyon ruleti onu gizler.
2. noexec temp dizinleri JNA'i öldürür. Shared/sertleştirilmiş host'larda -Djna.io.tmpdir'i elasticsearch kullanıcısının sahibi olduğu dizine verin.
3. "Docker çalışıyor, RPM çalışmıyor" host hakkında ipucudur, paket hakkında değil. Container kendi dosya sistemi varsayımlarıyla gelir.
4. Önce gerçek query'yi yakalayın. Alan istekte varsa uygulamayı debug etmeyi bırakın, mapping ve analyzer'lara geçin.
5. Tanımlayıcılar ve adlandırma ayrı arama problemleridir. SKU/CAS/MDL kodları ile tire yoğun kimyasal adlar alan bazında bilinçli analysis ister — minimum_should_match: "3" her tokenization uyumsuzluğunu büyütür.
6. Magento'nun ne istediğini bilin. track_total_hits: 2147483647 her aramada kesin toplam ister — büyük kataloglarda bilinmesi gereken bir maliyet.

E-ticaret aramanız tuhaf davranıyor ve log'lar Java duvarıysa, yaptığım iş tam olarak bu zemin seviyesi debugging — arama sağlığa kavuştuktan sonra onu öyle tutmak ise bir monitoring işi: searchali.com/tr/monitoring.

Mağazanızda Elasticsearch derdi mi var? → searchali.com