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