Lucene в качестве резервного хранилища для memcached

Question

Кто-нибудь пробовал использовать lucene в качестве резервного хранилища для memcached?

Вот сделка: я работаю над архитектурой для масштабируемого статического хранения данных.Фирма решила сделать локализацию определенной статической информации, поэтому вскоре у нас будет 20 переводов наших объектов БД, что даст примерно + 4G общего статического текста.Природа данных полностью доступна только для чтения (это в основном геолокация и переводы пользовательских сводок).

Поэтому я решил использовать lucene из-за его NIOFSDirectory и MMapDirectory.Проблема в том, что у нас 32-битная версия jvm =>, поэтому скоро классные времена с MMapDirectory закончатся (до сих пор я делал архитектуру для 2 языков).Я протестировал NIOFSDirectory, и его производительность выглядит привлекательно, но мне не очень нравится высокая загрузка диска, поэтому я думаю о memcached и использую NIOFSDirectory в качестве хранилища резервных копий, когда что-то случится с процессом memcached.

Физически это будетбыть как каждый узел в приложении.кластер будет содержать текст 4G в процессе memcached и поддержан lucene 'NIOFSDirectory.

Так что вы думаете, ребята?Это арка.Неплохо?

Answer 1

Lucene известен своими поисковыми возможностями: он способен выполнять сложные запросы к быстро меняющимся массивам неструктурированных документов благодаря инвертированному индексу и использованию аккуратных алгоритмов.

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