NicMC rašė:
> On 2011.12.07 17:41, Laimis wrote:
>> Pirma realiai išbandyk. Nes tolko aklai upgrade'inti hw, tai panašiai
>> tiek pat, kaip išgerti apelsinų sulčių, vietoje citrinų, tikintis, kad
>> tos bus švelnesnės (jos bus švelnesnės), kai šalia gal padėta stiklinė
>> stiklinė pieno...
>
> Tai pabandysi, tikraiu pabandysiu - kitą trečiadienį žinosiu.

Keletas minčių dėl konkurentiškumo. Galima būtų pabandyti realizuoti taip:
Pasirašyti trigerį, kuris kas tam tikrą laiką išrinktų iš tos sąlyginai 
didelės lentelės į atskirą lentelę (kuri, beje, gali būti in memory) 
eilinę ID porciją (kokį šimtuką-tūkstantuką, priklausomai nuo to, kaip 
sparčiai valgoma ta eilė).
Tada kiekvienas klientas nerakindamas lentelės skaito jau kur kas 
mažesnę lentelę:
1) SELECT id FROM que WHERE reserved = 0 ORDER BY id LIMIT 1

ir transakcijoje bando rezervuotis id:
2) UPDATE que SET s_id = CONNECTION_ID(), reserved = 1 WHERE id = {ID}

iš karto po to pasitikrina ar tokio id rezervacijos nenukniaukė kita 
transakcija (t.y. ar pavyko rezervacija):
3) SELECT id, s_id, reserved FROM que WHERE id = {ID}

ir jei nenukniaukė (s_id = CONNECTION_ID(), tai toliau jau vienoje 
transakcijoje:
{...}
DELETE FROM que ...
DELETE FROM original_que ...

Jei nepavyko, tai kartojamas ciklas nuo 1).

Tokio sprendimo *teorinis* privalumas, kad neblokuojamas skaitymas ir 
rašymas/trynimas ir tai vyksta iš esmės lygiagrečiai, o ne nuosekliai. 
Kolizijos (blokavimas) įvyksta tik tuomet, jei keletas (bent du) 
konkuruojantys ir sinchroniški SELECT'ai perskaitė tą patį nerezervuotą 
id ir bando jį rezervuotis.
Tai reiškia, kad SELECT'ai įvyksta beveik sinchroniškai, gal tik 
milisekundės (dalių) postūmiu (nes jei kiek labiau pasistūmę, tai 
anksčiausioji transakcija suspėtų rezervuoti).
Tačiau ir kolizijos atveju, viena laimėjusi (sėkmingai rezervavusi) 
transakcija tęsia darbą. Ribinė situacija, jei kaskart vis įvyktų 
kolizija, artėtų prie nuoseklaus apdorojimo spartos, tačiau 
paviršutiniškai žiūrint vis tiek būtų spartesnė.

Jei nesvarbus valgymo eiliškumas (t.y. iš esmės nėra FIFO, tik pagal 
sąlygą „reikalinga garantija, kad nei vienas valgantis klientas negaus 
įrašo, kurį ką tik gavo kitas klientas“), tai juk galima klientams 
paskirstyti id porcijomis (po kokį šimtuką-tūkstantuką), ir jie 
nesipešdami dėl rakinimo/skaitymo iš vienos lentelės kiekvieną sykį, 
lygiagrečiai apdorotų paskirto paketo eilutes...