|
Boolean search na innodb
Ok ovo jeste malo... khm... mozda cak i nemoguce...
Dakle zbog mogucnosti koriscenja stranih kljuceva sve tabele su innodb tipa ali sada se ukazala potreba za boolean pretragama :/ Stvari kojima sam razmisljao su sledece: 1. Deljenje tabele na dva dela (da ne objasnjavam zasto... ali nije moguce) 2. Particionisanje tabele na dva dela... moguce ali imam osecaj da cu se ubiti kasnije pokusavajuci da prebacim procedure na production server i nisam siguran kako bi to uopste radilo ako su dva dela razlicitog tipa :/ 3. Pokusaj da se boolean zameni like iskazima... overkill big overkill, tabela je ogromna tako da je preformance katastrofa Ogranicenja... nemogu koristiti extenzije za mysql poput http://www.sphinxsearch.com tabele moraju ostati innodb Ima li nesto sto sa prevideo ? google mi nerece nista, ali nista osim na par mesta gde ljudi daju linkove ka sphinx Neka pomoc ? |
mislis na boolean fulltext search ?
mozes da napravis pomocne tabele, jednu sa spiskom nadjenih reci, drugu sa referencama na recorde gde se reci pojavljuju, i onda iz njih radis klasican select sa join-om... |
Ako je u pitanju fulltext search, na flickru su to resili ovako: imaju bazu sa innodb tabelama u kojima nema fulltext indekse. Tu bazu repliciraju, ali kopije nisu innodb tipa, vec MyISAM na kojima jesu postavili fulltext indekse.
Na ovaj nacin izbegavaju problem pada performansi pri istovremenom citanju i pisanju iz baze (u innodb samo insertuju, iz MyISAM samo selectuju). Sa ovom elegantnom cakom su zaobisli problem nepostojanja fulltext indexa na innodb tabelama, a koristene su samo out-of-the-box mogucnosti MySQL-a. Znam da tebi to treba za jedan server, ali reko' da napisem, mozda bude korisno posto nije ocigledno da kod replikacije mozemo menjati tip tabela. |
covek svakim danom nauci nesto novo :)
@zigor razmisljao sam o tome ali ne dovoljno ozbiljno, recimo sada sam prvi put saznao da mysql ima triggere dakle finalno resenje ce biti kreiranje nove myisam tabele koja ce se puniti preko trigera |
Citat:
Ovaj pristup ima veliku prednost jer možeš da akumuliraš pretražive podatke iz celog sistema na jedno mesto. Samo treba na neki način da održiš referencu na izvorni podatak i da znaš kako da matchevani row iz indexa prebaciš u odgovarajući row iz originalne tabele. Dobro je znati da tako nešto može da bude rešeno na nivou baze. Doduše, MySQL5 je teška egzotika (mnogo veća od PHP5), ali ako radiš nešto custom gde možeš da kontrolišeš platformu mislim da je to prilično fino rešenje. @zigor: ako ovo za mešanje enginea kod replikacija radi ulepšao si mi dan :D Sad samo da u neko dogledno vreme dodam podršku da skripta može da koristi dve različite konekcije za dve različite operacije (čitanje i pisanje) i problem rešen. |
da radi se o potpuno custum resenju kome ce platforma biti server specijalno podignut samo za tu aplikaciju, tako da mogu da pustim masti na volju i koristim svu egzotiku koju zelim :)
@ilija nikako da se nateram da prevedem ono cudo :) nisam zaboravio ;) |
Moze MySQL svasta jos... :)
Postoji cak i partitioning, table splitting (na fixed i dynamic row size), kompresovanje radi brzeg selektovanja, triggers, views, stored procedures, events, podjela database direktorija na vise hard diskova radi boljih I/O performansi, dinamicko podesavanje buffera i session varijabli ... i td. @cvele: U praksi jos nisam imao potrebu za necim ovakvim kao sto ti imas sad, ali vjerujem da bi razdvajanje na dvije tabele (jedna InnoDB i jedna MyISAM), kao sto je vec predlozeno, rijesilo tvoj problem... Trenutno mi ne pada neko bolje rjesenje na pamet. :( |
Slucajno sam danas naleteo na sledeci text
Citat:
http://mysqldatabaseadministration.b...reference.html |
mysql se u principu ne snalazi najbolje kad tabela poraste preko ~1.4GB (moja odokativna procena), dodje do naglog pada perfomansi... mi smo krenuli da splitujemo tabele zbog toga, sto resi problem (mada naravno nije bas zgodno za search)
|
Citat:
|
| Vreme je GMT +2. Trenutno vreme je 01:10. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.