Компромисс между чтением из базы данных и хранением в памяти строк Java с использованием сервлетов

Question

Я нахожусь в процессе настройки системы, которая должна будет повторно анализировать большие объемы текста (например, String или StringBuffer - что может быть лучше?), Полученного из источника данных. Текст будет отображаться и может состоять из нескольких тысяч слов, и каждый раз, когда текст анализируется, каждое слово может проверяться по списку из 550 стоп-слов. Это позволит отфильтровать слова с экрана.

Так что мне интересно производительность, так как это может происходить одновременно в нескольких сеансах сервлетов; лучше проверить каждое слово по таблице базы данных MySQL (MyISAM или InnoDB), используя индекс? Или просто сохранить 550 слов в массиве или массиве Java в контексте сервлета, чтобы они могли быть прочитаны быстрее?

Так что мне интересно, как компромисс между вводом-выводом базы данных и хранением 550 строк в памяти.

Какой совет?

Спасибо

Мистер Морган.

Answer 1

Предполагая, что «источником данных» не является ваша база данных, вы можете получить более высокую производительность, выполняя поиск по стоп-слову в памяти, а не запрашивая базу данных об этом. Разумеется:

• Любой алгоритм, который использует база данных, может использоваться в качестве алгоритма в памяти.
• Запуская алгоритм локально, вы избегаете затрат на отправку текста в базу данных и отправку результатов обратно.

Также возможно, что вы сможете реализовать лучший алгоритм для определения стоп-слов, чем механизм базы данных общего назначения. А память, необходимая для структуры данных, которая представляет около 500 стоп-слов, должна быть тривиальной по сравнению с пространством, используемым остальной частью вашего приложения, контейнером сервлета и всеми используемыми вами библиотеками.

Answer 2

550 String - это очень небольшой объем данных для современных серверов: вам не нужна база данных, она будет намного медленнее.

Answer 3

Я рекомендую использовать стандартный файл свойств Java, поскольку у вас не так много данных. Это позволяет использовать стандартные функции интернационализации / локали.

Это предполагает, конечно, что копия изменяется довольно медленно. Но обычно это так.