100만개 디비 튜닝

잡동사니 백화점 | 내멋대로
http://blog.naver.com/webssin/110005055952


mysql 튜닝도 필요하고, 여러가지가 필요 합니다. HTML로 만들어 버리는 경우도 있고..등등

그 부분은 여러분들 노력여하에 따라서 가능 할검당.



게시판만 1개 잘 만드는데만 4-5 개월 이상 걸립니다.

게시판 1개만 잘만들면, 다른 솔루션은 2주-1달 안팎으로 만들 수 있습니다. 웹의 모든것을요..



게시판 무시하거나, 베끼거나 하면 이쪽 계통의 일을 하시지 않는 것이 좋습니다.

가장 기본이고, 가장 중요한 것 입니다.



★ 데이터베이스 검색 결과 표시..  

www.google.com 은 ASP에 관한 단어를 3천만개 이상 찾았슴에도.. 840 개만 보여줌.. www.phpbuilder.com 은 최근것 중에 100 개 까지만 보여줌.. ^^

explain 사용

a984.1 a984 a914 a214.5.2 a214.4 a101 a00984.1.6 a00984.1 로 인덱스가 탄당... a0300000312 a0000200001.9.7 a0000200001.9.2 a0000200001.1.7 a0000000312 a0000000012 a0000000002 a0000000001.1.7 a0000000001.1 a0000000001 로 인덱스가 탄다.

페이지 분활

phpBuilder.com 페이지 네비게이션은 10만개에서 1초나 걸린다... 페이지 계산도 엄청나게 속도 탄당 !! 냠...좋은 사이트 가 좋은 소스가 있는 것이 아니다 !!

30만개 게시물 검색시 이유...2  

$numresults=mysql_query("select count(tcode) from $board where $find like '%투덜%' "); 는  20초 걸린다. $numresults=mysql_query("select count(tcode) from $board where $find like '투덜%' "); 는 0.02 초 훔. % % 는 어떤 디비도 인덱스가 타지 않는다 !!

myisamchk 에서 정렬 빠르게    

-S, --sort-index Sort index blocks. This speeds up "read-next" in applications. 인덱스 블락 정열. 애플리케이션에서 "read-next" 속도를 향상.(??) c:\mysql\bin>myisamchk -S c:\mysql\data\toopyboard\toopy_1 하루에 1번 해줘라. 속도 업 !! 인덱스 정렬 !!

정렬과 관련해서 !

숫자가 가장 빠릅니다. mysql 이나 ms sql 이나 오라클이나 마찬가지 입니다. 숫자는 젤 큰것이 4바이트나 8바이트 입니다. 실수는 8바이트 구요. 문자형은 문자 1개당 1바이트 입니다. int 형은 4바이트 이며, 1억 까지 인가..10억 까지 인가가 표현 됩니다. float 나 double 은 택도 없죠. int 4바이트, 실수 8바이트 , 문자형 문자열바이트 입니다. 그러니까 실수형이 2배느리고, 문자형은 몇십배는 아니더라도 굉장히 느려 집니다. 저두 문자형으로 해봤죠..그렇게 느리지는 않아도 느립니다. 1000 만개..5천만개 이런 게시판 로직은 이렇게 생각 할 수 있습니다. 1. 삭제가 불가 하다면 쉽다. select * from 테이블명 where code<30 and code>20 order by code order by code 경우 10만개 경우 10만개를 불러와서 정렬을 시키기 때문에 where 절에 먼가를 써줘야 합니다. 삭제가 불가 하다면 30 번째 부터 40번째 까지를 알 수 있으니 잘 됩니다. 페이지 네비게이션이 쉽구요.. 2. 테이블 나누는 수 밖에 없다. 위 처럼 해도 테이블을 분리 하지 않을 수 없습니다. 최소 2만개에서 최대 20 만개 정도 씩은 테이블을 분리 해야 합니다. 메모리가 2G 정도 되면 20만개 정도로 분 리 하면 되죵.. 3. 가장 문제는 검색이당.. 검색은 최근 3개월 내..제목 검색만.. 내용 검색 불가..하게 하는 것이 좋습니다. 테이블을 나눈 담에 정렬 하는 것은 무자게 불편하죠... 테이블마다 검색 하게 만드는 것 보다..최근 3개월 내 검색을 고정화 시켜 버리는 것입니다. 상세 검색 부분도 추가를 고려 해야죠... 이외에도 몇가지가 더 필요 하겟죵...^^ 모든 작동을 정수 로 하세요.. 예를 들어 남자는 1, 여자는 2 , 관리자는 1, 일반회원은 2, 준회원은 3, 정회원은 4 등등...^^ ------------------------------------------------------------------ :: 미티겠음 님 write :: 이 아래보니, 게시판 로직인거 같은데, 투널님께서 실수가 정수 보다 2배가 느리다고 하셨는데, 정렬할때 말씀 맞는가요 ?? 만약에.. 0.99 <= 이런것을 실수형도 아니고 정수형도 아닌, 문자형 varchar으로 했을경우, 정수,실수형보다 몇배가 늦어질까요 ? 문자형일경우 최대30배까지 늦어진다는말을 들어서리.. 문자형일경우, 실수나, 정수보다.. depth에 제한이 좀 적어 질꺼 같아서여... 근데, 또 문자형으로 할경우, 차라리 haetlove님의 아스키방식을 이용해 depth의 폭을 넓혀볼까도 생각중인데, 아스키방식과, 0.99 등의 수형문자열방식과 <=정렬속도를 비교한다면 똑같을까요요 ?? 아니면 숫자쪽이 정렬에서 좀더 빠를까요 ??? 투덜님 도움바랍니다.

게시판 마지막 중요한 원칙! ★◆

"게시판은 쓰기보다 읽기가 30-500 배 정도 많습니다." 쓰기 보다 select 가 중요하다는 것이죠.. 여기 질문 게시판도 보면..쓰는 것은 하루에 많게는 50개 정도..읽는 것은 500 정도 됩니다. 그러면 10배 네용...ㅋㅋㅋ 글구 여기 여기 질문 게시판은 답변이 10개를 넘기가 힘듭니다. 그런데 굳이 100개 까지 답변 되게 할 필요가 있나요? 20개면 충분 합니다. 대빵큰 사이트 도 답변이 100개가 넘는 것은 거의 볼 수 없습니다. 잘해야 70-80 개 거나.. 요즘에는 특히 코멘트 가 많죠... 위의 문구의 의미를 잘 세겨 보세요... 게시판에서 가장 중요한 것은 읽기와 검색 입니다. select 죠.. 페이지 분활이 중요한게 아니라는 것입니다.