Dacă nu știți, atunci un nou driver mysql este furnizat cu PHP / 5.3 - mysqlnd. Are câteva caracteristici și capabilități care o diferențiază de libmysql.
Primul nu este foarte interesant. Acum, când rezultatul este preluat, nu există nici o copiere din memoria libmysql în memoria sub controlul motorului zend. De fapt, întregul set de rezultate este în memoria motorului Zend. Aceasta înseamnă că eșantioanele care depășesc limita de limită de memorie vor genera acum memorie. Poate că acest lucru este de valoare pentru proprietarii de hosting partajat, dar pentru cei care au un server dedicat acest lucru este de puțin folos.
Al doilea este deja interesant. A existat o oportunitate de a executa interogări în baza de date într-o manieră non-blocantă (în documentație această posibilitate se numește "cereri asincrone", care este literalmente incorectă). Acest lucru vă permite să:
- paraleliza citirea / scrierea;
- Implementați un SLA în ceea ce privește interogările bazei de date.
Paralelizarea unei înregistrări poate fi utilă atunci când o operație logică de scriere fizică are ca rezultat actualizarea informațiilor stocate pe mai multe servere. Acest lucru poate fi deosebit de benefic atunci când procesul dvs. este ocupat în cea mai mare parte a timpului de așteptare pentru confirmarea din baza de date despre această înregistrare (i / o legat). Necesitatea de a "scrie dintr-o dată în mai multe locuri" poate apărea, de exemplu, dacă faceți o oglindă software a bazei dvs. de date. La prima vedere acest lucru poate părea prostie, de ce nu doar să înființeze replicarea? Cu toate acestea, există situații în care replicarea stratului de aplicație are avantaje față de replicarea mysql. De asemenea, paralelizarea unei înregistrări poate fi utilă în cazul mecanismelor complexe de rupere. Uneori, un obiect nu trebuie să fie scris într-o singură bucată, ci în câteva (aceasta nu este o oglindă). Astfel de operațiuni de scriere sunt candidați buni pentru paralelizare (cel puțin, atâta timp cât cioburile sunt pe servere fizice diferite).
Și, desigur, SLA. Personal, acest lucru lipsește foarte mult. Dacă cererea nu ne blochează, atunci din punct de vedere tehnic nu putem aștepta rezultatele execuției sale. Nu are nici un sens să aștepte, desigur, nu, dar nu așteptați mai mult decât este strict anumită perioadă de timp, este foarte util. Am scris deja despre repede. Ori de câte ori faceți o interogare mai puțin complexă într-o bază de date, nu puteți fi siguri cât timp va dura această interogare. Și utilizatorii nu le place să aștepte. Probabil că toți au fost martori ca un DB la o încărcare crescândă mai încet și mai încet procesează cererile existente. Într-o astfel de situație, noile solicitări dau efectul de zăpadă. Pe de altă parte, este foarte posibil să nu avem nevoie de rezultat. Ei bine, eu cred că nu arată utilizatorului de pe pagina de căutare ca noile sale mesaje către „PM“, - nu este pentru această căutare inițiată. cererile de non-blocking poate realiza un comportament atunci când ne întrebăm baza de date: „cât de mult un Mesaj Privat“ și nedozhdavshis răspuns în timeout specificat ca în cazul în care să spună, „nu foarte mult și a vrut să“ și pur și simplu ascunde unitatea cu mesaje personale. Mai mult decât atât, este posibil să se pună în aplicare un sistem în care clientul fără să aștepte un răspuns, printr-o conexiune de control separat, va bate propria cerere, deci nu generează o sarcină suplimentară asupra bazei de date - se pare a fi, și deci nu este dulce, dacă ea nu a avut timp să răspundă în timp (desigur , toate acestea nu funcționează cu interogări DML).
Trimiteți-le prietenilor: