Поисковый индекс в оперативной памяти для приложения поднимает слишком много памяти - какие-либо предложения?
Дочерние маршруты не будут работать, потому что главный индекс должен быть загружен раньше, чтобы получить все маршруты. Обходной путь - перенаправлять на основной индекс каждый раз, когда серверная часть не находит путь:
@Controller
@RequestMapping("/error")
public class ErrorHandlerController extends AbstractErrorController {
private static final String ROOT_PATH = "/";
public ErrorHandlerController(ErrorAttributes errorAttributes) {
super(errorAttributes);
}
@RequestMapping
public void errorHtml(HttpServletRequest request,
HttpServletResponse response) throws IOException {
if(HttpStatus.NOT_FOUND.equals(getStatus(request))) {
response.sendRedirect(ROOT_PATH);
}
}
@Override
public String getErrorPath() {
return "error";
}
}
7 ответов
Если это будет 1 ГБ... помещает его на диск. Используйте что-то как Беркли DB. Это все еще будет очень быстро.
Вот проект, который предоставляет интерфейс .NET ему:
Я вижу несколько решений:
- Если Вы имеете ApplicationObjects в массиве, храните просто индекс - могло бы быть меньшим.
- Вы могли использовать немного C++ / CLI для хранения словаря, с помощью UTF-8.
- Не потрудитесь хранить все различные строки, используйте Trie
Вы могли проявить подход, который сделал Lucene. Во-первых, Вы создаете произвольный доступ поток в оперативной памяти (Система. IO.MemoryStream), этот поток зеркально отражает дисковый, но только часть ее (если у Вас есть неправильная часть, загрузите другой от диска). Это действительно вызывает одну головную боль, Вам нужен отображаемый файлом формат для Вашего словаря. Википедия имеет описание разбиения памяти на страницы.
На отображаемом файлом сценарии. Если Вы откроете Отражатель и отразите класс Словаря, то Вы будете видеть, что это, включает блоки. Можно, вероятно, использовать каждый из этих блоков как страница и физический файл (этот способ, которым вставки быстрее). Можно затем также свободно удалить значения путем простой вставки "объекта x удаленное" значение в файл и время от времени очистить файл.
Между прочим, блоки содержат значения с идентичными хешами. Очень важно, чтобы Ваши значения, которые Вы храните, переопределили GetHashCode () метод (и компилятор предупредит Вас о, Равняется () так переопределение это также). Вы получите значительное увеличение скорости поисков, если Вы сделаете это.
Как насчет того, чтобы использовать Файл Win32 С отображенной памятью API для прозрачной поддержки структуры памяти?
http://www.eggheadcafe.com/articles/20050116.asp имеет необходимое PInvokes для включения его.
Я подозреваю, что можно найти, что у Вас есть много очень маленьких списков.
Я предлагаю, чтобы Вы узнали примерно, на что частота похожа - сколько из Ваших словарных статей имеет единственные списки элемента, сколько имеет два списка элемента и т.д. Вы могли потенциально сохранить несколько отдельных словарей - один для "я только получил один элемент" (прямое отображение) затем, "у меня есть два элемента" (отобразитесь на Парную структуру с этими двумя ссылками в), и т.д., пока это не становится глупым - вполне возможно при приблизительно 3 записях - в которой точке Вы возвращаетесь к нормальным спискам. Инкапсулируйте всех позади простого интерфейса (добавьте, что запись / получает записи). Тем путем Вы намного меньше потратите впустую пространство (главным образом пустые буферы, количества и т.д.).
Если ни одно из этого не имеет много смысла, сообщите мне, и я попытаюсь придумать некоторый код.
Я соглашаюсь с bobwienholt, но Если Вы индексируете наборы данных, я предполагаю, что они прибыли из базы данных куда-нибудь. Имело бы смысл просто искать это с поисковой системой как DTSearch или Lucene.net?
Индекс только добавляется к, или Вы удаляете ключи из него также?