Cara pengindeksan bekerja di magento


30
  1. Cara pengindeksan bekerja di Magento
  2. Apa tepatnya itu?
  3. Mengapa itu diperlukan?

Tautan ini: stackoverflow.com/questions/4945307/… akan membantu Anda
TBI Infotech

Berikut adalah proses dan tindakannya di Magento 2 magento.stackexchange.com/questions/90510/…
Yogesh Trivedi

Versi Magento apa yang Anda gunakan? Cukup banyak perubahan telah dibuat di v1.13 - jadi harapkan perbedaan dalam versi sebelum versi itu. Berikut ini adalah posting blog yang bagus menjelaskan modul mView dan pengindeksan dalam versi 1.13 dari Magento: eschrade.com/page/…
Pitt

Jawaban:


63

Ada berbagai jenis indeks di Magento.
Semua pengindeks ada untuk membuat segalanya berjalan lebih cepat.
Saya akan membahas di sini hanya beberapa dari mereka.

Indeks Rata
Ada 2 indeks seperti itu. Satu untuk kategori dan satu untuk produk.
Secara default kategori dan entitas produk (dan pelanggan dan alamat pelanggan tetapi mereka tidak penting dalam situasi ini) adalah entitas EAV . Ini sangat bagus untuk diperpanjang. Tapi ini adalah pembunuh kinerja karena untuk mendapatkan semua nilai untuk semua atribut yang Anda butuhkan banyak bergabung atau beberapa permintaan.
Di sinilah pengindeks datar ikut bermain.
Ini mengubah struktur EAV menjadi struktur datar. Maksud saya membuat tabel (satu untuk setiap tampilan toko di Magento) yang memiliki satu kolom yang sesuai dengan atribut. Ini membuat pemilihan lebih cepat. Untuk kategori semua atribut dikonversi ke kolom tabel. Hanya untuk produk yang Anda tandai sebagai 'Digunakan dalam daftar produk' karena Anda dapat menjual semua jenis produk dengan atribut berbeda dan membuat satu tabel dengan kolom trilyun mungkin tidak dimungkinkan.
Juga, beberapa produk mungkin dinonaktifkan atau mungkin bukan milik situs web tertentu dan tidak perlu memasukkannya ke dalam entri untuk mencari. Mereka dikecualikan oleh pengindeks.
Tabel datar yang dihasilkan digunakan untuk membaca data di fronend. Backend masih menggunakan struktur EAV.

Indeks Pencarian Katalog
Anda dapat mencari produk dengan banyak nilai atribut. Beberapa dari mereka mungkin tidak termasuk dalam tabel datar yang dihasilkan oleh pengindeksan datar. Indeks ini mengisi tabel dengan nilai atribut yang dapat dicari untuk produk sehingga lebih mudah untuk mencari mereka berdasarkan kata kunci. Memiliki semua info dalam satu tabel (atau satu bidang) memungkinkan untuk menggunakan pencarian teks lengkap dan mendapatkan hasil yang relevan.

Harga produk .
Harga suatu produk dapat dipengaruhi oleh banyak variabel. Misalnya, grup pelanggan, situs web, aturan diskon katalog.
Sama seperti di atas, mendapatkan produk dengan harga mereka akan berarti banyak bergabung atau banyak pilihan. Selain itu produk bundel memiliki sistem penetapan harga yang aneh. Pengindeks ini mengagregasi data dalam beberapa tabel ( catalog_product_index_price_*) dan membuat pemilihan (menyortir dan memfilter) lebih mudah.

Url katalog Menulis ulang
Ini membersihkan aturan penulisan ulang url dengan mengatur url mana yang sesuai dengan produk atau kategori mana. Dengan cara ini lebih mudah bagi sistem internal manajemen url untuk memutuskan halaman mana yang harus Anda lihat ketika memanggil url non-standar. Alih-alih mencari melalui semua kunci URL produk dan kategori itu hanya mencari dalam satu tabel.

Kategori Produk
Di Magento Anda dapat mengatur atribut kategori bernama 'Is Anchor' menjadi benar atau salah. Jika itu benar itu berarti bahwa kategori yang dimaksud akan mendaftar semua produk dari kategori anak itu. Sekali lagi, menentukan waktu nyata ini akan membutuhkan lebih banyak sumber daya daripada hanya membaca satu tabel. Pengindeks ini membuat hubungan antara produk dan kategori berdasarkan asosiasi yang Anda atur di backend dan bendera 'Is Anchor' pada kategori.

Status Stok
Untuk produk sederhana mudah. Mereka bisa dalam stok atau kehabisan stok, tetapi untuk dapat dikonfigurasi, dikelompokkan dan bundel tidak mudah. Mereka dapat stok atau habis tergantung pada produk anak yang terkait dengan produk utama. Lagi (saya hanya mengulangi diri saya di sini) mendapatkan status mereka secara real time akan berarti banyak pertanyaan.

Atribut Produk .
Yang ini mengumpulkan semua atribut yang dapat digunakan dalam navigasi berlapis untuk alasan yang sama. Memiliki semuanya di satu tempat untuk membaca lebih cepat.

Agregasi Tag
Saya tidak tahu apa fungsinya. Saya tidak pernah menggunakan tag dalam proyek langsung nyata.


Terima kasih marius, ini adalah jawaban terbaik ... Saya sudah punya
sonam

Apa maksud Anda ketika Anda mengatakan bahwa tabel datar hanya digunakan di frontend (dan backend masih menggunakan struktur EAV)? Saya seorang pemula, dan dari apa yang saya mengerti, ketika kita membuat / memperbarui entitas seperti produk, masih menggunakan tabel EAV untuk melakukan operasi ini dan kami telah menetapkan opsi untuk memperbarui tabel datar setelah menyimpan atau memperbaruinya secara manual untuk perubahan ini tercermin dalam tabel datar. Apakah Anda mengacu pada proses ini ketika Anda mengatakan itu? Bisakah Anda menguraikan ini? Terima kasih!
Bharadwaj Srigiriraju

1
@Marius: Selama pengindeksan ulang, saya mendapatkan tabel kesalahan penuh. Tolong bantu. Kesalahan yang saya peroleh adalah Tabel 'catalog_product_index_price_bundle_sel_tmp' sudah penuh
Blackbeard

1
@Marius setelah 3 tahun jawaban ini sekarang, apakah Anda tahu tentang Tag Aggregation, apakah ini terkait dengan tag produk ??
Murtuza Zabuawala

1
@Hitam. Anda memiliki 2 pengaturan untuk indeks. "Perbarui saat disimpan" dan "Manual". Untuk pembaruan tentang penyimpanan, segala sesuatu harus terjadi secara otomatis saat Anda menyimpan produk. Tetapi ini dapat menyebabkan masalah kinerja. Misalnya jika Anda mengubah banyak produk sekaligus. Untuk mode manual, tidak ada pengindeksan ulang dipicu segera setelah menyimpan, tetapi Anda harus membangun kembali secara manual ketika Anda selesai.
Marius

11

Tidak dapat mengambil kredit untuk ini karena diambil dari pos asli di: https://stackoverflow.com/questions/4945307/can-someone-explain-magentos-indexing-feature-in-detail

Pengindeksan Magento hanya mirip dengan pengindeksan tingkat basis data dalam semangat. Seperti yang dinyatakan Anton, ini adalah proses denormalisasi untuk memungkinkan operasi situs yang lebih cepat. Biarkan saya mencoba menjelaskan beberapa pemikiran di balik struktur database Magento dan mengapa pengindeksan diperlukan untuk beroperasi dengan cepat.

Dalam database MySQL yang lebih "khas", tabel untuk menyimpan produk katalog akan disusun seperti ini:

PRODUCT:
    product_id INT
    sku        VARCHAR
    name       VARCHAR
    size       VARCHAR
    longdesc   VARCHAR
    shortdesc  VARCHAR
    ... etc ...

Ini cepat untuk pengambilan, tetapi menyisakan masalah mendasar untuk perangkat lunak eCommerce: apa yang Anda lakukan ketika Anda ingin menambahkan lebih banyak atribut? Bagaimana jika Anda menjual mainan, dan bukannya kolom ukuran, Anda perlu age_range? Nah, Anda bisa menambahkan kolom lain, tetapi harus jelas bahwa di toko besar (misalnya Walmart, misalnya), ini akan menghasilkan baris yang 90% kosong dan berusaha mempertahankan atribut baru hampir tidak mungkin.

Untuk mengatasi masalah ini, Magento membagi tabel menjadi unit yang lebih kecil. Saya tidak ingin membuat ulang seluruh sistem EAV dalam jawaban ini, jadi harap terima model yang disederhanakan ini:

PRODUCT:
    product_id INT
    sku        VARCHAR

PRODUCT_ATTRIBUTE_VALUES
    product_id   INT
    attribute_id INT
    value        MISC

PRODUCT_ATTRIBUTES
    attribute_id
    name

Sekarang dimungkinkan untuk menambahkan atribut sesuka hati dengan memasukkan nilai baru ke dalam product_attributes dan kemudian memasukkan catatan yang bersebelahan ke dalam product_attribute_values. Ini pada dasarnya adalah apa yang dilakukan Magento (dengan sedikit lebih menghormati jenis data daripada yang saya tampilkan di sini). Faktanya, sekarang tidak ada alasan untuk dua produk memiliki bidang yang sama sekali, jadi kami dapat membuat seluruh jenis produk dengan set atribut yang berbeda!

Namun, fleksibilitas ini harus dibayar. Jika saya ingin menemukan warna baju di sistem saya (contoh sepele), saya perlu menemukan:

  1. Product_id item (dalam tabel produk)
  2. Atribut_id untuk warna (dalam tabel atribut)
  3. Akhirnya, nilai aktual (dalam tabel attribute_values)

Dulu Magento bekerja seperti ini, tapi itu lambat sekali. Jadi, untuk memungkinkan kinerja yang lebih baik, mereka membuat kompromi: begitu pemilik toko menentukan atribut yang mereka inginkan, maju dan hasilkan tabel besar dari awal. Ketika sesuatu berubah, keluarkan dari ruang angkasa dan hasilkan kembali. Dengan begitu, data disimpan terutama dalam format fleksibel kami yang bagus, tetapi ditanya dari satu tabel.

Tabel pencarian yang dihasilkan ini adalah "indeks" Magento. Saat Anda mengindeks ulang, Anda meledakkan tabel lama dan menghasilkannya lagi.

Harapan yang sedikit memperjelas hal!


nuke it from space, bagus :)
Wietse

5

Magento adalah sistem yang cukup kuat dan kompleks. Itu memungkinkan untuk bekerja dengan sejumlah besar data, tetapi ketika database kelebihan beban dengan banyak catatan itu menjadi berat dan lambat. Magento menggunakan indeks untuk mengatasi masalah ini. Indeks adalah tabel basis data tambahan dengan beberapa data datar, yang memungkinkan untuk mengatur respons cepat dari basis data.

Secara default, sistem inti memperbarui indeks pada setiap penyimpanan item. Tetapi dalam beberapa kasus Anda harus melakukannya secara manual, misalnya beberapa jenis tindakan massal, dll. Anda dapat memperbarui indeks kapan saja dari admin backend (Admin-> Sistem-> Manajemen Indeks). Namun terkadang hal itu menyebabkan masalah.

Misalnya, jika Anda memiliki produk 10k + dan banyak kategori, membangun kembali indeks 'katalog url menulis ulang' mungkin memakan waktu berjam-jam. Maka skrip php hanya bisa rusak karena melebihi max_execution_time. Ada cara untuk memecahkan beberapa masalah dengan menjalankan proses reindex dari baris perintah.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.