Vārdnīca uz Drupal

airbijs Mon, 11/19/2012 - 15:36

Sveicināti,

varbūt variet ieteikt optimālo risinājumu, izrakos cauri drupal.org forumam, bet galējo slēdzienu vēl nevaru uztaisīt.

Uzdevums: uztaisīt vārdnīcu uz Drupal, ideja ļoti vienkārša - vārdam pretī ir lietotāja piedāvātais tulkojums, vienam vārdam var būt vairāki.

Visvienkāršākais ir taisīt katru vārdu kā lapu (node) ar attiecīgajiem laukiem, bet bažas vai tad, kad tiks sasniegts apjoms, piemēram, 10000 vārdi, vai meklēšanas sistēma nesāks bremzēt.

Varbūt ir kādi labāki ieteikumi, idejas, piemēram, balstīt to visu uz taxonomy un terms, gaidu jebkādus ierosinājumus, kas palīdzētu tikt uz pareizā ceļa!

Izpētīju risinājumus un optimālākais šķiet šāds:

katrs tulkojums ir atsevišķa lapa (node), kuras virsraksts (title) tiek pievienots vārdnīcā, piem., english-latvian, kā ieraksts (term). Līdz ar to atrodot konkrētu ierakstu (term) tiek parādītas visas lapas, kas tam piesaistītas.

Vēl joprojām paliek aktuāls jautājums, kā būs ar meklēšanas ātrumu, ja ir kādi 10000 ieraksti vai vairāk?

Varbūt ir vēl kādi ieteikumi?

Ceru, ka doma uzķerama.

Domāju, ka meklēšanas lietas ar Apache Solr integrāciju varētu pavilkt tīri labi. Tur (biju pētījis tikai D6 versiju, bet var būt D7 ir tas pats kurss ieturēts) bija gan facetu integrācija, gan arī indeksāciju var izcelt pilnībā ārā no D instalācijas, tādā veidā diezgan nozīmīgi palielinot DB darbību. Tajā skaitā atslēdzot Log into database, un novirzot tos uz Syslog (D7 core sastāvā). Indeksācijai var uztaisīt atsevišķu serveri, kur, ja arī tam pietrūkst jaudas, var skeilot tos horizontāli.

Tavs risinājums izklausās vienkāršs, līdz ar ko pad domāju, ka Apache Solr pamata konfigurācija būs derīga vajadzībām.

Pašlaik nenoprecizēšu konkrētu saiti, bet biju lasījis (ka tik ne MySQL Performance un Percona lapās), ka 10k ieraksti neitrāli skatoties uz MySQL veiktspēju nevienu neizbrīna un papildus jautājumus neuzdod. Taču jautājumi visnotaļ būs pie servera jaudām un attiecīgās konfigurēšanas.

Attiecībā uz ātrdarbību - te atkal ir pavisam cits jautājums, un īsti uz MySQL kā vienu vienīgu pudeles kaklu noteikti nebūtu jāskatās. Ja Anonīmiem  lietotājiem, tad failu bāzēts, vai ja RAM atļauj, tad RAM glabāts kešs. Viss grozās ap to, cik liels apmeklējums būs. Tas arī noteiks, ko un kā vajadzētu darīt. Pieļauju domu, ka MySQL pie šī apjoma mazliet iebremzēs, ja mēģināsi veidot jaunus ierakstus, bet šā kā tā default MySQL konfigurācija ir pietiekama neilgam laikam :)

 

Ieteikums - meklēšanu atstāj Apache Solr ziņā, nomet nost no MySQL visu lieko - tracking, stats, logging, un uzliec to visu uz alternatīviem risinājumiem. Pieliec klāt boost/apc/memcache Var izvirst arī ar Nginx kā Reverse proxy. Ieteiktu grafiku noteikti taisīt vieglu un ar sprite, lai tajā ziņā vismaz serverim nebūtu lieks darbs jādara.

 

Protams, filosofiski, bet man šīs lietas darbojas ar pozitīviem rezultātiem. Tik lielu MySQL ierakstu skaitu gan vēl neesmu sasniedzis, bet optimizācijai šādas tādas iemaņas ir konstatētas :)

Nu skaidrs, sākumā jālaiž vaļā un laika gaitā jāseko līdzi un jāoptimizē.

Izskatās ka Entity reference nestrādās manā gadījumā, jo šis modulis prasa, lai jau termini būtu pievienoti vārdnīcai, un tad varētu izvēlēties. Man ir nepieciešams, lai ir iespēja automātiski izvēlēties no esošajiem vai pievienot jaunus.

Mēģinot ar entity references met ārā šādu paziņojumu: There are no entities matching "kuku"

Kuku šajā gadījumā būtu pievienojamais vārds.

Savukārt, ja kuku būtu jau terminu sarakstā, tad viss ok.

Varbūt ir iespēja ļaut šim modulim ģenerēt arī jaunus ierakstus, ne tikai viekt izvēli no esošajiem?

Kā ar hostingiem Latvijā, kuri atbalsta Apache Solr?

Nano nepiedāvā.

Lai viss būtu tīrs un labs, labāk ir skatīties VPS virzienā, jo pašlaik zināmais Apache Solr kā serviss laikam ir tikai Acquia. Tas ir reti pieprasīts risinājums, tādēļ nedomāju, ka būs pieejams tā pat, kā hostinga piedāvājumi. Ja ir interese, varam uzbūvēt instanci, apskatīsies, un ja patiks, tālāk varam atrast risinājumu. Uzraksti PM, ja interesē.

 

Te ir alternatīvi risinājumi, bet gan ne LV: