페이지뷰는 무쟈게 빠르네요
DB 로 저장되지않는다면 서버이전 같은경우엔 그냥파일통째로올리면 DB도 딸려오는건가?

음 잘 몰라서 질문 하지만 My sql를 사용하지 않는 보드는 이전에도 있었던거 같은데 ..

문제는 보안상에 문제가 있었던걸로 기억 합니다만 ..

보안상에 문제는 .. 어떻게 처리 하셨는지 디비 없이 사용하는 보드가 이전에도 있었던거 같은데

문제는 보안상 문제때문에 사용자들이 사용을 하지 않았던걸로 기억하는데 ^^;;

디비가 없으면 파일로 처리하나요?

단순히 읽는 페이지뷰는 빠를지몰라도, 여러개의 게시판에서 삭제/수정시 어떻게 처리되는지가 궁금하네요..

mysql이 맘에 안드시면, 다른 대안으로 cubrid나 PostgreSQL 을 선택하시는것도 고려해보세요

index도 타질려나 -_- 100만건에서 검색하면 빠르게 될까요? 궁굼해요 +_+

개인홈페이지에선 유용할듯 하네요.
mysql을 사용하지 않아서 많은 데이터양에선 맥없이 무너질겁니다.
힙까지 웬만큼 구연하셔야 어느정도 커버가 될까요

흠... flat-file system... 이게 빠르긴 엄청 빠른데, 두가지 큰 단점이 있죠.

첫째, 심하게 서버의 사양에 속도가 의존된다는 것, 즉 동시 사용자가 많을수록 속도가 현저하게 느려진다는 것. 게시글의 크기가 클수록, 게시물이 많아질수록 기하급수적으로 속도가 느려진다는것. ->fopen, fread, fwrite, file, 등등. 동접인원 여러명이 동시에 fwrite 을 하면 서버가 일시적으로 크래시 되는 엉뚱한 일들도 발생할 수 있음. 이 취약점을 악용해 홈 전체를 날려버릴수도 있음.

둘째, 검색속도가 아주 안습이라는 점. 왜냐, 인덱스를 걸수가 없고, 파일을 하나하나 다 열어봐야 하기 때문에.


한 게시글이 300개 이하인 소규모 홈페이지에는 적당한 솔루션인것 같습니다.


근데 이런걸 혼자 만드시다니, 대단하시네요.

수고하십니다.

그런데, 그게 말이죠. item._pl 이 인덱스인 셈 아닙니까.
flat-file system 의 큰 문제점이 한사람이 읽고 있는 파일을 다른사람이 수정할수가 없다는 이야기입니다.
예를 들어서 A라는 사람이 게시물을 작성함으로써 item._pl 을 업데이트 중에 있다고 합시다. 그 짧은 시간이지만 item._pl 이 작성되는 시간에는 B라는 사용자가 그 파일에 접근을 할 수가 없어야 한다는 겁니다. 만약 파일이 수정되는 동안 B 라는 사용자가  접근을 한게 된다면 A가 게시물을 작성한 후, B가 게시물을 작성하게 되면 A의 게시물은 B의 게시물이 써 진후 사라진다는 말이죠. 즉 지금 test.txt 라는 파일을 두번 여신 후, 한 창에는 abcd 라는 내용을 쓰시고, 다른 창에는 efgh 라는 내용을 쓰신 후, 먼저 연 창을 저장 한 뒤, 다른 창을 저장한 후 test.txt 파일을 열어보면 abcd 와 efgh가 모두 있는게 아니라, efgh 만 남아 있다는거죠! 즉, 스스로가 스스로를 덮어씌우기 하지 못하니, 인덱싱은 순차적으로 하나하나 이뤄질수밖에 없을테죠. 근본적으로 이를 막을 방법은 없거니와, 또 그런 방법이 있다 할지라도 그순간 부터는 '동시접속' 이라는 개념이 없어지는거죠.

속도 또한 file() 은 텍스트 파일이 10MB 정도 되면 file() 하는데 20초 이상이 걸립니다... 인덱스도 분열해서 잘 사용하시면 말씀하신데로 속도문제는 별로 없을것 같네요.

그치만 검색의 경우는 여전히 의심이 가네요. 1000만개의 게시물을 테스트 해 보셨다고 하셨는데, 그러면 그 1000만개의 게시물 내용이 다 item._pl 파일 하나에 인덱스 되는건가요? 그렇다면 그 파일 하나만 여는데도 시간이 굉장히 길지 않을까요? 제가 들은 바로는 10MB 정도의 DB에서 file_get_content, file, fread 등이 mysql의 처리속도보다 3500배 정도 느리다고 들었습니다. 게다가 읽은 파일을 또 php의 strstr 함수로 찾아줘야 할텐데, 이 함수도 원래 좀 느린거라...

저도 이 시스템을 좋아하지만 이런 중요한 단점 때문에... 정말 기대해 보겠습니다. 수고하세요!

저 분 인아워넷에서 고등학생이라고 소개하신분인데 대단하신 것 같습니다
결과야 어떠튼 배움에 단계일테니까요

"게시판명 : 스콜보드(Scurboard) 라이선스 : GPL 개발시작일 : 2009.03.29 http://scur.tk/ 혼자만든겁니다. 나이를 밝히기엔 뭐 그렇지만.. 15 세 입니다. ㅋㅋ 믿거나 말거나 ㅋㅋ..;; TDB 구조라서.. MYSQL을... "

정말 믿거나 말거나...ㅡ,.ㅡ; 난 저때 게임하지 않았나...?

http://search.naver.com/search.naver?where=nexearch&query=%BD%BA%C4%DD%BA%B8%B5%E5&sm=top_hty&fbm=1

많은량의 데이터들이 있을경우 비추 하는 방식이므로 커뮤니티 이용 절때 안될듯 싶습니다.
데이터 몇건까지 테스트 해보셨나요? 페이징이나 인덱싱 속도 이런 부분 확인해보고 벤치 마킹 올려주시면 도움 될듯 하네요 속도라는게 상대적이기에...
끊어 검색... 뭐 이런게 있네요... 하지만 데이터 통합 검색 같은경우.... 엄청난 부화가

데이타건수는 크게 중요할 것 갖진 않네요.
킴스큐도 인덱스부분은 DB가 아닌 파일로 처리하던데 나름 속도괜찮고요...

수훈님, 테스트하실 때 데이타 1개의 용량은 post_max_size와 일치시켜서 해보시는 것이 좋겠네요.
10k짜리 천만건... 이렇다면 아무 의미없구요, 사용자가 입력할 수 있는 최대치로 해야겠죠...
왠만한 호스팅사에서 보통 2메가 정도니까 그누의 우편번호파일로 대체하시면 딱 맞을 겁니다.

그리고 소스보니까 fread(파일, filesize(파일)) 처럼 버퍼사이즈를 파일크기로 잡으셨던데
그러면서도 위에서 말한 100명 정도의 동접자를 유지한다는게 신기하네요;;;
2메가의 버퍼로 동접 100명이면 200메가, 이 정도 bps를 받쳐주는 호스팅사양이 과연?
배포버전이라면 일반유저의 서버환경도 고려해야 할 것 같네요.

저 수훈님 나이때...

애들이랑 길거리에서 떡볶이 먹고 돌아 댕기며 오락실 출근했었습니다. ^^;;

대성 하실거 같아요~~