MemSQL

Hvali se vse kar obstaja, kar ne pomeni, da je tudi dobro zate. Predvsem moraš najprej razumeti, kaj tvoj problem je, kako ga rešuješ, kje imaš potencialna ozka grla, šele potem greš gruntat, če ti neka tehnologija lahko pomaga in kako.

Fact: query != query ... torej 80k/s *kakšnih* queryjev? Enakih kot jih imaš v tvoji aplikaciji?

Večina ljudi prisega na postgres. MySQL ima svoje štose, a je tudi še kar popularen. Če ne rabiš relacij, imaš na izbiro še nekaj drugih tehnologij in izdelkov.

Splošnonamenskih alternativ ni prav veliko, a za specifične probleme obstajajo specifične rešitve, ki so ponavadi boljše od generične ponudbe.

Zato začniva še enkrat od začetka: kakšen problem rešuješ, kako ga rešuješ, kje imaš potencialna ozka grla? Verjamem, da ti bo generična relacijska baza v 99% primerih dovolj dobra. Kar ta forum poglej, spodaj teče postgres, se ti zdi prepočasen?

Da dam kar konkreten primer, kar se baze tiče, bom na kratko kolikor je mogoče, ker lahko o tem pišem roman. Gre za uporabnike (ID, username, password, datum registracije, datum zadnjega logina, IP zadnjega logina in registracije,...) v strukturi so torej ekipe, igralci, trenerji, stadioni, finance, sporočila, tekme, lige, statstika, play by play teks, transferji, sponzorji... še morje drugega, seveda ne bom pri vsaki stvari pisal vsega, kot primer ima samo igralec v entiteti 16 tipov podatkov (igralcev pa sem zgeneriral 300.000), ki se nenehno procesirajo na več tisoč tekmah naenkrat in obenem se generira stran s statistiko. Torej ogromno poizvedb in veliko "udrihanja" po bazi in ogromno relacij. Sistem je seveda že povsem razdelan in je na bazi hobija, oz. je časa za razvoj veliko, tako da gre z roko v roki za učenje, hobi in dolgoročno za projekt, ki je že dogovorjen (oz. pogodba za prejšne nosilce poteče čez dobro leto in pol). Ne iščem odrešitelja, samo mnenja katere platforme izbrati. Še vedno je bilo najboljše slišati mnenje ljudi iz prakse, po možnosti čim bolj objektivnih ljudi, kar preberem na netu v veliki večini verjamem, ko pa gre za malce bolj resno stvar pa raje stvar v popolnost razdelam, južnjaki pravjo bolje sprečit, nego lečit.

Ni nobene težave, zgolj želja, da bi delovalo čim hitreje pa četudi komu na oko neopazno. Gre za to, da v času tekme je že tako največ ljudi online in je aktivnost že tako povečana, med samimi tekmami, to je recimo 3x tedensko po 2h pa je ta aplikacija obremenjena verjetno bolj kot katerikoli bančni sistem v Sloveniji. Seveda je kvaliteten hosting tu ključnega pomena, ampak jaz vedno pravim, na faktor na katerega lahko vplivam, je treba zbrusit do konca.

@blackbfm, s matero bazo pa delaš?

Kurzweil je 6. dec 2014 ob 00:32 izjavil:

med samimi tekmami, to je recimo 3x tedensko po 2h pa je ta aplikacija obremenjena verjetno bolj kot katerikoli bančni sistem v Sloveniji.

Dude, start talking numbers. Koliko DB requestov je to?

Stvar je povsem preprosta. DB model naredis tako, da imas ustrezne podatke pravilno de-normalizirane, da se izognes morebitnim joinom. Ce gre vecinoma za iskanje in branje iz baze, potem poskrbis za ustrezen cache in to je to. RAM je poceni, privosci si ga. :) PostgreSQL je dovolj dober prakticno za vse. V bistvu ljudje ugotavljajo, da se jim razni switchi na NoSQL baze niso splacali in bi bilo bolje, da ce bi samo konfiguracijo SQL serverja mal posraufal. :)

Lej, v najboljsih casih Slashdota je to zadevo furalo en kup Perl skript in MySQL. :)

prozac je 6. dec 2014 ob 15:31 izjavil:

prej kot menjavo baze bi pogledu keri kveriji se izvajajo najpogosteje in kateri so najbolj potratni potem bi pa tam začel z optimizacijo qverijev, relacij, dodajanjem indeksov, hintov,... če se da bi v naprej pripravil kake vmesne rezultate (staging, sinhronizacijo...). Šele na koncu bi se lotil menjave baze. Za to bi moral biti res dober razlog.

+1

Ce ne znas zoptimizirat queryja ti bo povsod delal pocasi