메모리기반 IRS는 많이 사장된 느낌입니다. 그렇다고 없어져 간다는 것은 아니고, 겉으로 끄집어내어 얘기하지 않는다는 것이죠.
초창기 포탈에서 시도했던 것 같은데요.. 아직도 작은 컬렉션들은 메모리로 올리는 것이 대세로 알고 있습니다.

한때 사이트검색을 메모리기반으로 만들어 본적이 있습니다.
대략 20만건정도를 메모리로 올리는데 100M정도 색인파일이 생성됐던것 같네요.
요즘같으면 부가정보가 워낙 많아서 훨씬 커질것으로 예상됩니다만,
네이버의 사이트목록도 사실 그렇게 많지 않을 것으로 예상됩니다.
서비스에 나오는 것은 대략 50~60만정도가 아닐까 추측합니다.

위 예를 말씀 드리는 것은, 메모리기반으로 하게 되도 충분한 양의 데이터를 처리할 수 있다는 것이죠.

허나, 메모리만으로 처리하기에는 보통의 컬렉션 크기가 워낙 크기 때문에 깊은 고민을 하지 않는 것 같습니다.
그래서, 메모리기반으로 분산처리하는 IRS가 고민된다면 좀더 재미있는 걸 만들 수 있지 않을까 합니다.

일단, 스파님께서 위에 언급한 5가지 내용에 대해 말씀해 주시면 좋겠네요.. 다른 분들도 그에 따른 개인 의견을 낼 수 있을 것 같네요.
좋은 하루 되세요~

예...하얀눈길님 말씀대로, 초창기에 알타비스타가 그렇게 서비스를 했습니다.  Posting file을 메모리에 적재하여, 그 당시로선 엄청난 규모인 약 1기가 메모리의 서버에 몇십대에 분산하여 서비스를 했던 것으로 기억납니다.

아무튼, 데이터가 메모리로 올라가면 우리가 예상치 못했던 많은 일들이 가능해 질 것 같습니다. 우선 그 무슨 하나의 진리와도 같았던 B-tree를 사용할 필요가 없게 되고, 필요에 따라선 이진탐색보다도 훨씬 빠른 자료구조도 가능해질 수 있을 것 같습니다. (인덱스 검색시에...)

가장 큰 문제는 역시 serialization(병렬화, 디스크 백업)일 것 같습니다. 서버의 안정성이 보장된다면야 머 필요없겠지만서두, 온라인 관리를 지원하는 검색엔진이라고 한다면, 이 병렬화가 핫 이슈가 될 수 있을 것 같네요. 이전에는 실시간 문서 삽입삭제가 매우 느렸으나, 이 메모리기반 검색엔진 내에서는 이도 가능할 것 같으니까요.

아무리, 요즘 검색엔진의 속도가 최적화되었다 하더라도 (다시 말해서, 메모리버전으로 만들어봤자, 속도차이가 별로 안날 것이다라는...), 이 I/O의 병모가지 때문에, 검색순간에 처리할 수 있는 다양한 부가기능(질의확장, 실시간 클러스터링, 실시간 문서분류, 개인화기반 질의 코디네이팅 등)들이 현재 현실화되지 못하고 있는 것도 사실입니다. 이렇게 본다면, 이 메모리기반 검색엔진이라는 것도, 검색엔진 자체의 의미보다는 거기에서 실현될 수 있는 다양한 부가기능들에 더 가치가 부여되겠네요. ^^

오늘은 여기까지만 말씀드리고 또 생각나면 적겠습니다.
감사합니다.