DevProTalk

DevProTalk (http://www.devprotalk.com/index.php)
-   SQL baze podataka - Sponzor: Baze-Podataka.net (http://www.devprotalk.com/forumdisplay.php?f=10)
-   -   uzasno spor obican select upit , tabela 1GB sa 700000 redova (http://www.devprotalk.com/showthread.php?t=10508)

apash86 07. 11. 2011. 20:58
uzasno spor obican select upit , tabela 1GB sa 700000 redova
 
vise ne znam sta da optimizujem kad obican select traje i vise od minut, server je sa 8gb ram, mysql 5.1.58

tabela ima 700000rows

npr ovaj upit
SELECT record_num,title FROM content ORDER BY record_num DESC LIMIT 668936,36

first time execution: 175sec!!!
Showing rows 0 - 29 ( 36 total, Query took 175.9067 sec)

second time is ok
Showing rows 0 - 29 ( 36 total, Query took 0.0003 sec)

svi ovi upiti se PRVI put uzasno sporo izvrsavaju, dok kad se refreshuju ili opet izvrsi ISTI upit onda sve bude normalno oko 1sec

SELECT record_num,title FROM content ORDER BY record_num DESC LIMIT 587456,36
SELECT record_num,title FROM content ORDER BY record_num DESC LIMIT 452369,36
SELECT record_num,title FROM content ORDER BY record_num DESC LIMIT 698745,36


isto se desava sa fulltext pretragom, prvi put katastrofa, dok sledeci put bolje

koristi se memcache na serveru, ali dzabe to kad se prvi put ceka ogromno vreme
.
svaka pomoc dobrodosla!


znam za resenje WHERE record_num >698745 AND record_num <698835

ali to ne mogu da odradim jer ima "rupa" medju record_num, a i da to odradim za select ne bih mogao za fulltext search

salebab 07. 11. 2011. 21:09
A WHERE record_num > 698745 LIMIT 36 ?

Uvek za taj broj uzmeš poslednji row iz prethodnog upita...

Ili, da koristiš dodatnu tabelu, evo ti primer:
http://stackoverflow.com/questions/1...e-limit-clause

apash86 07. 11. 2011. 21:22
moze i tako ali opet to samo malo skracuje vreme u zavisnosti gde je taj ID jel na pocetku ili pri kraju tabele

resio sam da cu ici ipak sa
WHERE record_num >698745 AND record_num <698835 , pa neka bude poneka rupa, nema ih vise od 400-500, a to je zanemarljivo

ali sad ostaje veci problem, sta sa fulltext pretragom?

Citat:
SELECT record_num,title, (MATCH (title,keywords) AGAINST ('interracial' IN BOOLEAN MODE)) as score FROM content WHERE MATCH (title, keywords) AGAINST ('interracial' IN BOOLEAN MODE) HAVING score > 0 ORDER BY content.record_num DESC LIMIT 456859,36
ovde moram koristiti LIMIT , ne znam kako drugacije?

dinke 07. 11. 2011. 21:24
Index na record_num polju postoji?

Dalje, koliko se secam kad radis nesto ovako, MySQL "svlaci" prvih X slogova do setovanog offseta (prvi parametar u limitu) pa tek onda vrati slogove sa tog mesta.

Pogledaj ovaj link, mozda iskopas nesto korisno:

http://www.mysqlperformanceblog.com/...-optimization/

ivanhoe 07. 11. 2011. 21:25
to ti je zbog ORDER BY, on mora uvek da prvo sortira svih 700K redova...

imas dva resenja, ili da smanjis broj redova kao sto kaze salebab, ili da optimizujes indexe na tabeli tako da se sortiranje radi na indexima direktno. Tu je takodje bitno i da mysql ima dovoljno memorije da mu ceo index stane u memoriju.

dodaj EXPLAIN ispred upita pa vidi sta ce da ti kaze... i procitaj ovo

EDIT: pretece me dinke

EDIT2: Da ne pravim novu poruku, za FULLTEXT ti je isti problem, jer sam full text search je jako brz, ali verovatno interracial (hmm, cime se ti to bavis? :)) vrati previse rezultata...

apash86 07. 11. 2011. 22:09
orderby ne verujem da je problem, i bez njega je ista situacija

problem je kao sto kazete kada se koristi limit onda prodje kroz celu tabelu i uzme samo x zadnjih

explain SELECT record_num,title FROM content ORDER BY record_num DESC LIMIT 718745,36

Kôd:
id        select_type        table        type        possible_keys        key        key_len        ref        rows        Extra
1        SIMPLE        content        ALL        NULL        NULL        NULL        NULL        702900        Using filesort
explain SELECT record_num,title FROM content WHERE record_num>718745 AND record_num<718845 ORDER BY record_num DESC

Kôd:
id        select_type        table        type        possible_keys        key        key_len        ref        rows        Extra
1        SIMPLE        content        range        PRIMARY        PRIMARY        8        NULL        1        Using where

recimo da je ovaj problem sa select resen na ovaj nacin, ostaje veci problem sa fulltext pretragom gde moram koristiti LIMIT ?


Citat:
EDIT2: Da ne pravim novu poruku, za FULLTEXT ti je isti problem, jer sam full text search je jako brz, ali verovatno interracial (hmm, cime se ti to bavis? ) vrati previse rezultata...
a da li postoji nekako nacin da ogranicim fulltext pretragu da pretrazuje samo dok ne skupi npr 10000 pogodaka, ili nesto slicno?

radim sa nekim adult spajderima, sve je bilo dobro dok poseta i baza nije bila velika, sad je problem to optimizovati, a klijent je spreman uzeti i poseban server za mysql ali opet mislim da ovo i nije nesto velika baza pa da ne moze izdrzati..


pogledacu ove linkove, ali mislim da sam ih vec sigurno prosao jer vec 2-3 dana samo to gledam

apash86 07. 11. 2011. 22:16
pogledao sam one linkove, ali to recimo da je reseno, dajte neku literaturu za
fulltext + big table + LIMIT + orderby , google mi nista korisno nije dao:)

agvozden 07. 11. 2011. 22:53
Mozes li da postavis Create Table da bi videli kako je kreirana tabela i indeksi?

apash86 07. 11. 2011. 22:57
testiram samo sa ovim jednim osnovnim poljem, tako da druga ne bi trebala ni da uticu ni na sta

Citat:
CREATE TABLE IF NOT EXISTS `content` (
`title` varchar(255) NOT NULL DEFAULT '',
`filename` varchar(255) NOT NULL DEFAULT '',
`orig_filename` varchar(255) NOT NULL,
`thumbnail` varchar(255) NOT NULL DEFAULT '',
`embed` text NOT NULL,
`description` text NOT NULL,
`paysite` int(11) NOT NULL DEFAULT '0',
`keywords` varchar(255) NOT NULL,
`pornstars` varchar(255) NOT NULL DEFAULT '',
`scheduled_date` date NOT NULL DEFAULT '0000-00-00',
`date_added` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
`encoded_date` datetime NOT NULL,
`rating` varchar(5) NOT NULL DEFAULT '0',
`length` int(11) NOT NULL DEFAULT '0',
`submitter` int(11) NOT NULL DEFAULT '0',
`ip` varchar(15) NOT NULL,
`approved` int(11) NOT NULL DEFAULT '0',
`hotlinked` varchar(255) NOT NULL DEFAULT '0',
`enabled` int(11) NOT NULL DEFAULT '0',
`main_thumb` int(11) NOT NULL DEFAULT '3',
`xml` varchar(32) NOT NULL,
`photos` int(11) NOT NULL DEFAULT '0',
`record_num` bigint(11) NOT NULL AUTO_INCREMENT,
`source` varchar(200) NOT NULL,
`source_url` varchar(250) NOT NULL,
`video_hash` varchar(250) NOT NULL,
`duration` varchar(100) NOT NULL,
`cdate` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
`seo_url` varchar(250) NOT NULL,
`source_thumb` varchar(250) NOT NULL,
`pornstar` varchar(250) NOT NULL,
`img_exist` int(1) NOT NULL,
`temp` varchar(50) NOT NULL,
`views` bigint(20) NOT NULL,
`niche` int(11) NOT NULL,
PRIMARY KEY (`record_num`),
KEY `rating` (`rating`),
KEY `length` (`length`),
KEY `approved` (`approved`),
KEY `enabled` (`enabled`),
KEY `source` (`source`),
KEY `video_hash` (`video_hash`),
KEY `duration` (`duration`),
KEY `views` (`views`),
KEY `niche` (`niche`),
FULLTEXT KEY `title` (`title`,`keywords`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=715228 ;

ivanhoe 07. 11. 2011. 23:06
Koliko ja znam, boolean fulltext ne bi trebalo da automatski sortira rezultate po relevance, sto znaci da bi trebalo da radi jako brzo. Ja imam u jednoj firmi foto-arhivu sa 2M rekorda i to radi pristojno brzo...

znaci mora da bude problem ili sa necim drugim u upitu ili sa samom bazom (da je index prevelik, pa ne staje u memoriju)

Najbolji izvor informacija ti je mysql dokumentacija i stackoverflow.com

EDIT: Nama treba chat ovde, prebrzo idu odgovori :)

EDIT 2: probaj da koristis ORDER BY score, pa vidi jel onda brze...

dinke 07. 11. 2011. 23:09
Mozes da smanjis record_num polje sa big int na neki manji int, a ostala int polja ako da takodje korigujes u skladu sa vrednostima koje se trebaju unositi.

Takodje za order je neophodan index, tako da ga moras kreirati (record_num polje), trenutno ga nemas.

apash86 07. 11. 2011. 23:57
tu je index nego 10puta sam brisao sve indexe i optimizovao bazu. skratio sam bigint i ostale int/varchar/text polja na minimum ali opet sve isto, pvi put za upit treba i vise od 100sec, dok svaki sledeci radi ispod 1s

evo i config od mysql, mislim da je i on ok

Citat:
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
tmpdir=/tmp_sql
max_connections=300
max_allowed_packet = 8000M
max_connections = 100
key_buffer_size = 1000M
myisam_sort_buffer_size = 72M
myisam_max_sort_file_size = 2048M
join_buffer_size = 3M
read_buffer_size = 2M
sort_buffer_size = 3M
table_cache = 10000
thread_cache_size = 384
wait_timeout = 30
interactive_timeout = 60
connect_timeout = 10
tmp_table_size = 128M
max_heap_table_size = 128M
max_allowed_packet = 128M
max_seeks_for_key = 1000
group_concat_max_len = 1024
net_buffer_length = 16384
max_connect_errors = 100000
concurrent_insert = 2
read_rnd_buffer_size = 786432
bulk_insert_buffer_size = 8M
query_cache_limit = 2M
query_cache_size = 64M
query_cache_type = 1
query_prealloc_size = 262144
query_alloc_block_size = 65536
range_alloc_block_size = 4096
transaction_alloc_block_size = 8192
transaction_prealloc_size = 4096
default-storage-engine = MyISAM
max_write_lock_count = 8
slow_query_log=1
long_query_time=30

# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

instalirao sam sad sphinx pa cu videti da kroz njega ide pretraga, posto stvarno vise nemam ideju sta da radim

nixa 08. 11. 2011. 00:09
bolje probaj Apache Lucene ...

apash86 08. 11. 2011. 00:22
cini mi se da je lighttpd server

jedno brzinsko pitanje, ako je "record_num" primary key, onda on nema potrebe da se opet definise kao index?!

dinke 08. 11. 2011. 00:26
nema potrebe, sorry nisam video gore da ti je record_num zapravo primary key.

cvele 08. 11. 2011. 07:56
@dinke

Da li si siguran da definisana velicina polja u mysql-u (i vecini drugih db) ima bilo kakav uticaj na brzinu ?

Koliko sam ja upucen signed pretpostavlja vrednosti od -2147483648 do 2147483647, a unsigned 0 do 4294967295. Mozda gresim ali zar nije velicina polja tu samo radi validacije pri unosu i slicnih stvari ?

miks 08. 11. 2011. 08:10
Citat:
Originalno napisao apash86 (Napišite 102755)
...
resio sam da cu ici ipak sa
WHERE record_num >698745 AND record_num <698835 , pa neka bude poneka rupa, nema ih vise od 400-500, a to je zanemarljivo

ali sad ostaje veci problem, sta sa fulltext pretragom?



ovde moram koristiti LIMIT , ne znam kako drugacije?
Probaj sa

Kôd:
  ... WHERE record_num >698745 LIMIT 36
sa ovim nebi trebalo da ima rupa.

dinke 08. 11. 2011. 11:26
@cvele
Siguran sam, naravno :)

Za pocetak manual oko numerickih tipova:

http://dev.mysql.com/doc/refman/5.5/...ric-types.html

Kao sto vidis int koristi 4 bajta za smestanje, bigint koristi celih 8. Ukratko za istu kolicinu podataka zauzeces duplo veci broj podataka na hdd-u. Veca tabela = sporija tabela, sporiji indeksi itd. Za vise detalja mysql manual :) http://dev.mysql.com/doc/refman/5.5/en/data-size.html

Inace isto vazi i sa ostale fiksne tipove (npr char), premda opet stvari nisu crno bele, char je brzi za pretrazivanje od varchara ali da ne sirim pricu :)

webarto 08. 11. 2011. 11:45
Citat:
SELECT * FROM forum_posts ORDER BY pid DESC LIMIT 668936,36
Showing rows 0 - 29 ( 36 total, Query took 0.7483 sec) [pid: 201054 - 201011]
Citat:
SELECT pid,post FROM forum_posts ORDER BY pid DESC LIMIT 668936,36
Showing rows 0 - 29 ( 36 total, Query took 0.1019 sec) [pid: 201054 - 201011]
Tabela slična, odnosno oko 1 000 000 redova i malo jače od 1GB...

apash86 08. 11. 2011. 13:21
Citat:
Originalno napisao webarto (Napišite 102778)
Tabela slična, odnosno oko 1 000 000 redova i malo jače od 1GB...
to su rezultati za prvi put kad se izvrsava upit?

tek sad mi nije jasno sto se onako sporo izvrsava, moracu da jurim sys admina da pogleda mysql

webarto 08. 11. 2011. 13:57
da, da, sve prvi put, za FULLTEXT, identično tvom query, oko 2s... Server nije ništa posebno, neki semi-dedicated.
Citat:
SELECT * FROM forum_posts ORDER BY pid DESC LIMIT 765432,36
Showing rows 0 - 29 ( 36 total, Query took 0.8544 sec) [pid: 68647 - 68604]


Vreme je GMT +2. Trenutno vreme je 14:11.

Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.

Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.