В SOLR db уникальные строковые поля хранятся более одного раза в оперативной памяти? - PullRequest
0 голосов
/ 20 октября 2011

У меня есть база данных SOLR, для которой нужно новое поле, содержащее список строк, похожих на теги, за исключением того, что они предопределены и используются для внутренних целей. Результаты поиска из этого ядра SOLR будут передаваться через общедоступный Интернет сторонним разработчикам веб-сайтов. Поэтому я хочу запутать теги и лишить кого-либо возможности угадать тег, который раскрыл бы информацию о другом клиенте.

Я мог бы легко сделать это, используя GUID, но мне интересно, какое влияние окажут сотни тысяч записей в ОЗУ с полем, содержащим массив из нескольких GUID.

Если GUID были записаны как атомы, то есть одна копия GUID и много ссылок на него, то это не проблема. Но я не могу выяснить, используют ли SOLR или Lucene атомы в своих структурах данных в оперативной памяти. Дисковое хранилище не является проблемой.

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

1 Ответ

0 голосов
/ 20 октября 2011

Существует два индекса:

  1. Инвертированный индекс.Каждый гид будет сохранен один раз (фактически меньше одного раза) независимо от того, сколько раз он используется.
  2. Нормальный индекс.Каждый гид будет храниться один раз при каждом его использовании.Вы можете использовать сжатие здесь, если хотите.(«Сжатие» может означать, что у вас есть специальная таблица, которая переводит цифры <-> теги, поэтому каждый тег хранится в виде числа -> каждый тег занимает 1 байт [при условии, что тегов меньше 2 ^ 8].)
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...