Наилучшие подходы к сокращению числа поисков между хранилищами объектов filenet для поиска документа на основе времени создания документа?
Например, есть 5 хранилищ объектов. Я думаю о вставке документов в них, но не в последовательном порядке. Первоначально это могло бы быть последовательным, но если бы я мог вставить, используя некоторый метод ранжирования, было бы легче узнать, какое хранилище объектов искать, чтобы найти документ. Цель состоит в том, чтобы уменьшить количество поисков в хранилище объектов. Это может быть достигнуто, только если вставка использует какой-то интеллектуальный алгоритм.
Один метод, который я нашел полезным, использует MOD N текущего года (количество хранилищ объектов), чтобы определить, куда идет документ. Могли бы у нас быть лучшие подходы к этому?
3 ответа
Если вы хотите быстрый доступ, есть пара критериев:
Хеш-функция должна воспроизводиться на основе запрашиваемых данных. Это означает, что многое зависит от ожидаемых вами запросов.
Вы обычно хотите распределить ваш объект как можно более равномерно по магазинам. Если вы хотите идти параллельно, вы хотите получить доступ к каждому документу для данного запроса из разных хранилищ, чтобы они не блокировали друг друга. Следовательно, ваша функция хеширования должна распространяться как можно больше в разные хранилища для похожих документов. Если вы ожидаете, что документы, относящиеся к одному и тому же запросу, относятся к одному и тому же году, не используйте этот год напрямую.
Это предполагает, что вы хотите иметь возможность быстрого запроса, который может быть парализован. Если вместо этого у вас есть система, в которой вы сначала должны открыть потенциально дорогое соединение с магазином, то большинство документов, относящихся к одному и тому же запросу, должны отправляться в один и тот же магазин, и вы не должны принимать мой совет выше.
Ваш критерий "что происходит в хранилище объектов FileNet?" в основном "какие документы логически принадлежат друг другу?"
Это старая тема, но мышление серьезно ошибочно. Object_id — это уникальный ключ базы данных в данной базе данных/схеме. Вы предлагаете создать внешний интерфейс для COTS-приложения, а затем выполнять поиск по нескольким базам данных? Во-первых, вам не следует хранить более 4 КБ в больших двоичных объектах БД, поэтому даже если у вас есть отдельные физические базы данных, самая большая задержка будет связана с вводом-выводом хранилища. Чтобы распределить операции ввода-вывода между несколькими подсистемами хранения, добавьте в политику хранения несколько областей хранения, чтобы они выполняли циклический перебор. Вы можете использовать фильтр, чтобы указать, что и куда идет, как спрашивал/подразумевал paulsm. Если производительность извлечения действительно вызывает беспокойство, то следует решить эту проблему при выборе размера и конструкции системы. Используя Consistency Checker в качестве эталона, виртуальная машина, на хосте которой были многопутевые оптоволоконные сети SAN, обрабатывала около 80000 документов в минуту. Для сравнения, виртуальная машина, использующая NFS для хранения, едва могла достичь скорости 80 документов в минуту. Это 1/1000 производительности. Если вы тратите семизначную сумму на лицензии на программное обеспечение и нанимаете самый дешевый ресурс для проектирования/сборки/администрирования вашей системы, вы тратите свои деньги впустую.