- MySQL
- SQL
Ar fi de dorit să întrebați cine rezolvă o problemă cu căutarea în etichete. Ce software.
Două condiții de bază:
1) Sarcina - sistemul ar trebui să fie rapid (
1-50 ms) pentru a răspunde la întrebarea în spiritul "găsi toate documentele în care există (1-tag sau-tag-30 sau 100500 sau.) Și (tag-ul tag-ul 50 sau 1000, sau.) Și.". În OR poate fi de până la două duzini de etichete, iar condițiile pot fi sub o duzină.
2) Deoarece datele pot fi adesea actualizate, este necesar să se atingă un timp minim pentru actualizarea modificărilor.
Am încercat să o fac pe Redis utilizând tipurile SET și BITMAP (cum ar fi aici "Filtrul de catalog rapid pentru magazine online pe."). SET nu se potrivea (set-a stocat ID-ul documentelor), deoarece În cazul traversării chiar două seturi de 100k cred că mai mult decât este necesar. BITMAP nu a fost abordat din cauza unui deficit puternic al documentelor de identitate, ca urmare a consumului suplimentar de memorie pentru "gauri". În general, dacă seturile sunt mari, atunci Redis din cutie se potrivește prost.
Acum lucrează la Sfinx. ID-urile sunt scrise în sql_attr_multi. Aceasta oferă o cerință specificată pentru viteza de recuperare a documentelor. Cerința pentru actualizări este rezolvată prin construirea indexului principal și al deltei. Indicele principal (pe care îl căutăm) este declarat distribuit. Practic funcționează bine, dar uneori există multe schimbări noi și indicele delta începe să încetinească. Reconstrucția indexului principal durează câteva minute (acum se află în documentul de 3,5 milioane de documente). Nu pare mult, dar se intenționează creșterea numărului de documente de zeci de ori. De asemenea, timpul de actualizare a datelor va începe să crească.
Aș vrea să știu dacă există alte soluții (cu? Tarantool? Elasticsearch?) Și cine o folosește.
sim3x. Cu toate gunoiul, baza ia ceva de aproximativ 4GB. Ie Da, totul vine în memorie. Dar acest lucru nu este fundamental așa cum mi se pare, pentru că pentru sarcina curentă există un set stupid de ID-uri care reprezintă un unsigned 32nd int. Dacă le conduce în larg Redis (în cadrul sistemului: Key „tagId.ID_tega“ (de exemplu, „tagId.100“), valoarea setată în care documentele de identitate asociate cu această etichetă, și anume, ID-ul de document este duplicat de multe ori), se pare ceva apoi aproximativ 2,5 GB.
Alexey Sundukov.
Apoi merită să răsuciți setările submeniului
Uită-te la tabelele index-interogări lente, cum funcționează interogările tale
Nu ne vom gândi încă la rechin - există o mulțime de cheltuieli generale și detalii
În timp ce întregul sub-obiect este stocat în memorie, trebuie să îl optimizați
sim3x. Nu, nu este. IN este în esență OR. În plus, sarcina inițială este complet diferită. Este necesar "pentru a găsi ID-ul tuturor documentelor care au (tag-tag 1 sau 500 sau tag-ul de N.) și (tag-tag-ul 20 sau 30), I.". Alte opțiuni, cu excepția aderării, nu văd. În general, în cadrul RDBMS nu funcționează bine.
sim3x. Nu știu. Despre expansiune sishnoe sub postgri cu siguranță m-am gândit, dar dacă codul sishny pur nu poate face intersecția N seturi (reprezentând int) mai repede decât Sfinxul, înseamnă fumul spre expansiune sub sishnogo Build devreme. Am înțeles cu siguranță că probabil codul nu este foarte optim și există multe de gândit, dar eu nu am de gând să termina sishnik mine. Și deoarece sarcina nu este unică în principiu, sper că într-un fel cineva a creat deja ceva de genul asta, sub forma unei biblioteci finalizate. Aici și ischyu.
Alexey Sundukov. în postgrass există o intersecție nativă
Va fi necesar să extindeți extensia deja când capacitățile de cache pentru clienți sunt epuizate
Prin parametrii specificați, orice document este selectat în mai puțin de o secundă
un grup de documente în decurs de două săptămâni (indiferent cât de multe documente) este selectat nu mai mult de 10 secunde
timpul maxim de eșantionare pentru toate documentele pentru toate etichetele de 20 de minute
server aproape de partea de jos - 1 la sută 8 nuclee, 58 GB de memorie RAM, în timp ce pe acest server se utilizează în mod activ 32 de baze de date (numai discuri bune)
Învățați o parte matematică
- secționare
- indicii
- Grupuri de fișiere
- Inmemori
Base 4 giga :))))) Am această bază de date 700 GB și tabele mai mult de 100 GB nimic atât de normalnnenko, foarte rapid ales :)
Sunt sigur pe alte platforme, puteți, de asemenea, să optimizați
La naiba!
Baza 4 Giga - Carl. auzi 4 Gig Carl.
(pentru sarcina dvs., unii indici ar fi trebuit să aibă xs la fel de mult, indicii mei cântăresc mai mult decât datele de 1,5 ori)
igruschkafox pentru mine în al doilea rând este foarte lung. (Și am și MySQL). Filtrul ar trebui să funcționeze maxim 50 ms. Într-o masă primitivă în 2 câmpuri (care sunt ints) tagId, docId este destul de dificil de făcut. Și înregistrează numai pe 4M. Se pare că totul este simplu. Funcționează de asemenea. Numai în contextul în care am nevoie este prea lent. Cât timp aveți în baza de date se duce la răspunsul la întrebarea „pentru a găsi id documente în care există (tag-ul 1 sau 2 de etichetă sau tag 10) și (tag-ul 100 sau tag-ul 200 sau tag-ul 300.) Și.“ și anume de fapt banal IN () și IN () și IN (). În acest eșantion, cel puțin două etichete sunt asociate cu mai mult de 100k documente. Fie ca IN să aibă până la 10 etichete și există maximum 10 astfel de condiții. Cum arată interogarea și cât de mult funcționează?
Despre partiționarea pe care o cunosc. Aici vreau să fac pe Postgresql prin moștenirea meselor.
Maestru al ceremoniilor
O voi lăsa ca o remarcă pentru istorie. În acest moment, schema din sfinx este cea mai rapidă. Problema cu indicele delta a fost decisă pur și simplu prin renumele mai frecventă. Acum, aplicația monitorizează dimensiunea sa și, de îndată ce are mai mult de 20k documente, începe să se rotească. Rata de eșantionare necesară este obținută chiar și în cazul unor întrebări complexe.
Și este obligatoriu să primești TOATE? Totuși, la fel, utilizatorul nu citește imediat. Puteți primi fiecare etichetă separat, iar după AJAX-oh trageți în sus și. dacă este necesar, sortați pe client.