Post meta vs tabele separate în baza de date

Dacă plugin-ul tău va gestiona O CANTITATE MARE de date, atunci utilizarea tabelei wp_postmeta NU este o idee bună, așa cum este demonstrat mai jos:

Luând WooCommerce ca exemplu, într-un magazin cu ~30.000 de produse, va exista în medie ~40 de metadate (atribute și altele) per produs, 5 imagini per produs, ceea ce înseamnă că vor exista ~4 metadate pentru fiecare imagine:

30.000 produse x 40 metadate fiecare = 1.200.000 de rânduri în wp_postmeta

+

30.000 produse x 5 imagini fiecare x 4 metadate per imagine = 600.000 de rânduri în wp_postmeta

Așadar, cu doar 30.000 de produse, ajungi să ai 1.800.000 de rânduri în wp_postmeta.

Dacă adaugi mai multe proprietăți la produse sau la imaginile produselor, acest număr se va multiplica.

Problema este dublă:

• Self joins sunt foarte costisitoare în MySQL
• Tabela wp_postmeta nu este indexată decât dacă folosești versiuni mai noi de MySQL (adică nu există index FULLTEXT pentru meta_value)

Ca exemplu dintr-un caz real:

SELECT meta_value FROM wp_postmeta WHERE meta_key LIKE '_shipping_city'

Această interogare care selectează orașul de livrare din toate detaliile comenzilor durează aproximativ ~3 secunde pe un server dedicat de nivel entry, chiar dacă există doar 5-10 comenzi. Acest lucru se întâmplă pentru că interogarea este rulată pe un tabel wp_postmeta care are ~3 milioane de rânduri într-o instalație live.

Chiar și pagina principală încarcă destul de încet, deoarece tema preia diverse elemente din wp_postmeta - slide-uri, câteva recenzii, alte metadate. În general, listarea produselor este foarte lentă, iar căutările sunt la fel de lente când afișează produsele.

Nu poți rezolva acest lucru prin metode normale. Poți instala Elastic Search pe server și să folosești un plugin Elastic Search în WordPress, poți utiliza redis/memcached, poți folosi un plugin bun de cache pentru pagini, dar în final problema fundamentală va rămâne - extragerea oricăror date dintr-un tabel wp_postmeta umflat va fi lentă, oricând s-ar face. Pe serverul unde am testat soluția implementată mai jos, toate acestea erau instalate și configurate corect și optimizate, iar site-ul funcționa acceptabil pentru utilizatorii nelogați sau pentru interogările comune, deoarece plugin-urile de cache intrau în acțiune.

Dar în momentul în care un utilizator logat încerca să facă ceva neobișnuit sau cron-urile, plugin-urile de cache sau orice alt utilitar dorea să extragă date reale din baza de date pentru a le stoca în cache sau pentru a face altceva, lucrurile deveneau extrem de lente.

Așa că am încercat altceva:

Am creat un mic plugin care să mute toate metadatele produselor (postmeta pentru tipul de post product) într-un tabel personalizat generat prin cod. Acest plugin a luat toate metadatele pentru fiecare post și a creat un tabel adăugând fiecare meta ca coloană și inserând valorile în fiecare rând. Am transformat formatul EAV într-un format relațional plat, orizontal. De asemenea, am configurat plugin-ul să șteargă postmeta din toate produsele mutate din tabela wp_postmeta.

Pe lângă asta, am mutat metadatele pentru tipul de post attachment și pentru toate celelalte tipuri de posturi în tabele proprii.

Apoi, am folosit filtrul get_(post_type)_meta pentru a suprascrie extragerea metadatelor și a le servi din noile tabele personalizate.

Acum, aceeași interogare de mai sus, care dura ~3 secunde pe wp_postmeta, durează ~0.006 secunde. Site-ul acum funcționează ca și cum ar fi o instalație fresh de WordPress.

....................

Desigur, abordarea "în stil WordPress" este mai bună. De fapt, este norma.

Totuși, este de asemenea un lucru cunoscut că tabelele EAV sunt foarte ineficiente la scalare. Sunt infinit flexibile și îți permit să stochezi orice date, dar prețul pe care îl plătești pentru asta este performanța. Este un compromis fundamental.

În acest context, este dificil să îi recomanzi cuiva care intenționează să aibă o cantitate imensă de date și - Doamne ferește - să interogheze/caute în acele date să folosească tabela wp_postmeta cu siguranță. Impactul asupra performanței va fi mare.

Folosirea tabelelor personalizate îți va permite ca datele tale să crească și totuși să rămână suficient de rapide.

Exact cum Pippin Williams, creatorul plugin-ului Easy Digital Downloads, a menționat că ar folosi tabele personalizate dacă ar începe acum să codeze plugin-ul său, dacă intenționezi să creezi ceva care va fi folosit pe termen lung sau va acumula multe date, este mai eficient să folosești tabele personalizate, dacă le proiectezi bine.

Trebuie să te asiguri că orice alt dezvoltator de plugin-uri/addon-uri are mijloace să se conecteze la plugin-ul tău pentru a manipula datele înainte și după extragerea lor. Dacă faci asta, atunci ești pe drumul cel bun.

Depinde de ceea ce faci. Modul WordPress este să folosești tabelele existente, deoarece au fost proiectate să fie suficient de flexibile, dar ocazional poți întâlni o nouă clasă de date care nu poate fi plasată într-un tabel existent, de exemplu, dacă ai vrea metadate pentru categorii, ai putea alege să creezi un tabel wp_termsmeta.

Totuși, de obicei poți stoca datele destul de confortabil în diferitele tabele existente, iar locul în care le stochezi depinde de ceea ce face pluginul tău.

• Pentru setări generale ale pluginului, folosește apelul API get_option() - acesta va fi și cache-uit.
• Pentru setări ale pluginului care sunt specifice unui anumit post, folosește metadatele personalizate per post cu get_post_meta(). De obicei, acest lucru este suficient pentru ceea ce ai nevoie.

Cache-ul este implementat în WordPress pentru a accelera timpul de răspuns.

de acord cu Denis 100%. Dar există o soluție pentru această problemă.

Problema cu utilizarea meta datelor postării pentru valori care trebuie interogate apare atunci când valorile sunt tablouri etc. De exemplu:

array(
'key1' => 'val 1',
'key2' => 'val 2'
);

Acest lucru este stocat în baza de date ca un șir serializat, care va arăta cam așa:

{array["key1"]...{}...}

Deci, atunci când doriți să interogați toate postările cu array['key2'] = 'val 2', WordPress trebuie să extragă fiecare intrare meta numită array, să o despacheteze, să o testeze și apoi să treacă la următoarea. Acest lucru va afecta negativ performanța serverului dacă site-ul dvs. este popular și are multe postări, pagini, postări personalizate etc.

Soluția depinde de proiect și veți înțelege de ce. Dacă ați stoca datele ca var = val, atunci WordPress ar putea căuta fără ca PHP să despacheteze fiecare test. Pentru a face acest lucru în scenariul de mai sus, ați folosi un spațiu de nume și ați stoca cheile meta:

_array_key1 = 'val 1';
_array_key2 = 'val 2';

atunci WordPress, căutând key2 cu val2, ar putea extrage direct valoarea. Totuși, această soluție depinde de proiect. Proiectul meu curent necesită stocarea a aproximativ 20 de tipuri de date diferite cu fiecare postare personalizată, așa că metoda de mai sus ar crea doar un tabel masiv de căutat, având în vedere că ne așteptăm la sute de mii de postări. În acest scenariu, un tabel personalizat este singura soluție.

Sper că acest lucru va ajuta pe cineva

Pentru site-ul meu FarmVille :) Am făcut ambele dar nu l-am terminat pentru că l-am vândut:

1. Am citit XML-ul de la FarmVille și am încărcat datele într-o tabelă personalizată
2. În WordPress am creat câmpuri personalizate automat pentru fiecare câmp din acea tabelă (și câteva extra)
3. Apoi a apărut problema ce se întâmplă dacă o valoare se schimbă fie în tabelă, fie pe cealaltă parte: câmpurile personalizate, deoarece ele trebuie să fie continuu sincronizate

Am făcut asta pentru că am vrut pe de o parte ca utilizatorii să poată edita site-ul WordPress introducând noi date FarmVille, de exemplu "o vacă costă 10 monede" DAR din partea de integrare: DACĂ o schimbare în XML înseamnă că vaca acum costă "20 de monede" (prin plugin-ul de editare front-end) aceasta ar fi oferită ca opțiune după: astfel încât fie XML-ul, fie utilizatorul să aibă dreptate (un fel de sistem wiki).

Deci iată un exemplu când folosești ambele.