Интересно, а раззиповка индексных файлов из памяти работает быстрее, чем чтение с диска?
Я так же делаю. ;)
Миллионы файлов это многовато. Но если использовать стемку, то их количество сильно уменьшается. Тысяч до ста, а с этим линуксы уже справляются. Можно ещё посмотреть в сторону BerkeleyDb - я пока не тестировал на необходимость беркли, но должно быть лучш. Если Вы храните индекс в одном файле, то там есть маленькая проблема. Добавление/удаление/изменение документа приводит к значительным операциям с этим файлом. Даже если он весь хранится в памяти, то сдвиги сотен мегабайт данных в памяти не сказка. Если кусочек оказывается на диске, то вообще получаются ужасы. С кучей маленьких файлов таких проблем нет.
Самый простой способ в Вашем случае хранить файл на диске, а смещения и часть индекса держать в памяти (кешь).
В Mirhosting хороший сервис. Как бывший клиент говорю.
Какое Ку? Откуда возьмётся второй нотариус? Он появится только после предъявления обвинения. Даже если к тому времени ФСБ не изымет сервер, они проведут все предварительные мероприятия по фиксированию нарушения прежде чем владелец форума узнает о предъявленно обвинении и сможет пойти к нотариусу.
Изучите свой рынок, пожалуйста.
Разбиваете обратный индекс по словам. Для каждого слова свой файл с обратным индексом. Файлы хранятся на диске. Если требуется большая производительность и время чтения с диска критично, то кидаете часто используемые файлы в memcached.
Соответственно, при построении обратного индекса Вы берёте базу документов и создаёте прямой индекс, сбрасывая его постепенно на диск (незачем ему хранится в памяти целиком). Затем для каждого уникального слова по очереди проходитесь по прямому индексу, составляете обратный индекс для этого слова, файл сбрасываете на диск. Таким образом, Вы можете индексировать базы любого размера. Правда количество проходов по прямому индексу получается равно количеству уникальных слов. Но это можно оптимизировать 🙄 Самое узкое место - дисковая подсистема. Это уже лечится только добавлением памяти.
Канал в Россию у них как? Не падает? Нормальный по ширине?
Да не нужно ничего. Я предлагаю Ваше любимое решение: вынести Mysql на отдельный комп. Только с некоторой вариацией - вместе с полной копией web-части. Простаивать ничего не будет, балансер не нужен, массив тоже. А запас производительности на каждом из серверов всегда есть. В крайнем случае можно будет рубить половину трафика (например, весь зарубежный) или снизить доступность части сервисов. При этом сайт будет продолжать работать и нести прибыль.
После этого один из нотариусов разорится. Им, нотариусам, это надо? Нотариус отвечает за свою подпись всей своей личной собственностью, а не уставным капиталом 10 тыс. рублей.
Можно. Но можно сделать, например, связку из двух серверов. На каждом будет храниться полная работоспособная версия сайта, но работать будут как web-сервер и mysql-сервер. В случае падения одной из железок вторая включается в автономный режим, а сломанная неспешно ремонтируется. Вторая железка, ясное дело, будет при нагрузках тормозить. Но сайт работать будет. Чем больше железок, тем лучше будет система работать при умирании сервера. Гемор в том, что российские датацентры требуют от серверов 1U. Иначе две-три домашние PC-шки по надёжности и нагрузкам рвали бы обычные сервера как тузик грелку.
