Проектирование системы хранения и корпоративного поиска: от файлового сервера до S3 и Elasticsearch

Введение: зачем нужна единая система хранения и поиска

Корпоративный поиск по файлам нужен, когда документы разбросаны по SMB-шарам, облачным дискам, локальным машинам сотрудников и бэкапным томам. Поиск нужного документа занимает 15-20 минут, а иногда заканчивается неудачей. По отраслевым оценкам, сотрудники могут тратить до 20% рабочего времени на поиск информации. Для инженера это означает простой в решении задачи, для бизнеса - прямые финансовые потери.

Проблема не в отсутствии данных, а в отсутствии единого поискового слоя. Файловый сервер сам по себе не предоставляет единого полнотекстового индекса. Облачное хранилище хранит объекты, но не связано с корпоративной базой знаний. Elasticsearch или OpenSearch индексирует текст, но не получает данные автоматически без настроенного пайплайна.

Эта статья дает практический план построения системы, которая объединяет хранение и полнотекстовый поиск. Мы разберем архитектурные паттерны, модель метаданных, стратегии индексации документов, автоматизацию каталогизации, выбор поискового движка, безопасность и мониторинг. Материал ориентирован на DevOps-инженеров и ИТ-архитекторов, которые проектируют корпоративный поиск по файлам и систему навигации по данным.

Базовые принципы выбора типа хранилища - файловое, блочное или объектное - подробно разобраны в отдельном руководстве. Здесь мы сфокусируемся на связке хранилища с поисковым движком.

Когда эта архитектура нужна

Связка файлового или объектного хранилища с отдельным поисковым слоем оправдана, если стандартного поиска в приложении или файловом сервере уже недостаточно. Окончательные пороги зависят от оборудования, форматов документов и требований безопасности, но для первичной оценки используйте следующие критерии:

• данные поступают из нескольких источников или объем растет до сотен тысяч объектов и выше;
• поиск нужен десяткам или сотням пользователей и должен работать по содержимому, имени файла и метаданным;
• для интерактивного сценария требуется измеримый p95 задержки, а не просто возможность выполнить поиск;
• результаты должны учитывать ACL, группы пользователей, наследование прав и отзыв доступа;
• документы регулярно создаются, изменяются и удаляются, поэтому ручная переиндексация неприемлема;
• нужно обрабатывать PDF, DOCX, XLSX и изображения со сканами, включая OCR.

Если документов мало, источником является один файловый сервер, а требования к полнотекстовому поиску и ACL-фильтрации невысоки, отдельный кластер может быть избыточным. В остальных случаях сначала спроектируйте поток данных и SLO, затем выбирайте конкретные компоненты.

Содержание

1. Архитектурные паттерны хранения и поиска.
2. Сравнение SMB/NFS, S3 и гибридной схемы.
3. Поток данных и модель метаданных.
4. Стратегии индексации и анализаторы для русского языка.
5. Production-ready пайплайн, Logstash и обработка изменений.
6. Выбор между Elasticsearch и OpenSearch.
7. Безопасность, ACL и контроль доступа на уровне документов.
8. SLO, мониторинг и оптимизация.
9. Пилот и дорожная карта внедрения.
10. FAQ по корпоративному поиску.

Итоговая таблица выбора хранилища

Архитектурные паттерны систем хранения: файловый сервер, S3 и гибрид

Выбор базовой архитектуры хранения определяет, как вы будете строить поиск. Каждый паттерн имеет свои компромиссы по масштабируемости, сложности и стоимости.

Файловый сервер: простота и ограничения

Классическая схема: общий сетевой диск по SMB или NFS, права доступа через Active Directory или локальные учетные записи. Пользователи работают с файлами напрямую, через проводник или терминал. Для отдела из 10-20 человек с небольшим объемом документов это рабочее решение.

Ограничения проявляются при росте данных. Полнотекстовый поиск по SMB-шаре через Windows Search может работать медленно и непредсказуемо при объеме в несколько сотен тысяч файлов. Результат зависит от версии Windows, конфигурации индекса, форматов документов, нагрузки на сервер и клиентские машины. Версионирование также не является свойством обычной файловой шары: перезаписанный файл может потерять историю. Горизонтальное масштабирование упирается в производительность одного файлового сервера.

Типичный сценарий: SMB-шар с 500 ГБ проектной документации. Поиск по содержимому PDF занимает минуты, индексация выполняется на клиентских машинах, результаты различаются у разных пользователей. Это узкое место можно устранить внешним поисковым индексом, а переход на объектное хранилище остается одним из вариантов архитектуры.

Объектное хранилище S3: масштабируемость и гибкость

Объектная модель хранения использует плоское пространство имен: объекты лежат в бакетах, каждый объект имеет уникальный ключ и набор метаданных. Нет иерархии каталогов в классическом смысле - есть префиксы ключей, которые имитируют структуру. Доступ выполняется через HTTP API: PUT, GET, DELETE, LIST.

Ключевые преимущества для корпоративного поиска:

• Горизонтальная масштабируемость: добавление узлов может увеличивать емкость и пропускную способность без остановки сервиса, если это поддерживается конкретной реализацией.
• API-доступ: любой компонент пайплайна может читать и записывать объекты программно.
• Метаданные: произвольные пары ключ-значение на уровне объекта, которые можно передавать в поисковый индекс.
• События: уведомления о создании, изменении и удалении объектов для автоматической индексации, если конкретное S3-совместимое хранилище и конфигурация поддерживают нужные события.

Популярные S3-совместимые решения: MinIO для on-premise установки, Ceph RGW для распределенных кластеров, AWS S3 для облачной инфраструктуры. Совместимость API упрощает миграцию, но не гарантирует идентичное поведение по событиям, ACL, версиям и пограничным ошибкам. Эти свойства нужно проверить в целевой версии.

Гибридный подход: когда нужно и то, и другое

Пользователи привыкли работать с файлами через сетевые диски, а не через API. Резкий переход на объектное хранилище ломает привычные процессы. Гибридная схема решает это противоречие: файловый доступ остается для повседневной работы, а данные автоматически реплицируются в объектное хранилище для поиска, аналитики и резервного копирования.

Реализация: S3-шлюзы для файловых протоколов. Инструменты s3fs и rclone mount монтируют бакет как локальную файловую систему. Пользователи работают с файлами через привычный интерфейс, а данные физически хранятся в объектном хранилище. Обратная схема: файловый сервер как источник, отдельный процесс синхронизации копирует новые и измененные файлы в бакет.

Монтирование S3 не является полной заменой файловому протоколу: семантика блокировок, rename, согласованность каталогов и производительность зависят от инструмента и нагрузки. Перед production-использованием проверьте конкурентную запись, восстановление после разрыва соединения и поведение приложений, которым нужен POSIX-подобный доступ.

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

Схема потока данных

До проектирования маппинга зафиксируйте полный путь документа: источник → очередь или события → извлечение текста и OCR → обогащение ACL → индекс → поисковый интерфейс.

1. Источник сообщает о новом, измененном или удаленном объекте. Для SMB/NFS это может быть сканер, журнал изменений или агент.
2. Очередь отделяет прием события от обработки и позволяет повторить неудачную операцию.
3. Обработчик получает объект, извлекает текст и формирует нормализованные метаданные.
4. ACL-обработчик рассчитывает эффективные права, включая группы и наследование.
5. Индексатор выполняет идемпотентный upsert или удаление по стабильному document ID.
6. Поисковый интерфейс передает запрос в серверный слой, который добавляет ограничения доступа и возвращает только разрешенные результаты.

Такое разделение помогает отдельно масштабировать чтение объектов, OCR и поисковые запросы. Оно также позволяет измерять задержку каждого этапа и находить пропущенные события.

Модель метаданных: ключ к эффективному поиску

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

Какие метаданные собирать: обязательный минимум

Разделите метаданные на системные и пользовательские. Системные собираются автоматически из файловой системы или объектного хранилища. Пользовательские задаются вручную или извлекаются из контента.

Обязательный минимум для корпоративного поиска:

• Название - отображается в результатах, участвует в поиске по заголовкам.
• Автор - фильтрация по владельцу документа, поиск всех материалов конкретного сотрудника.
• Дата создания и изменения - сортировка по свежести, фильтрация по периоду.
• Тип документа - PDF, DOCX, изображение, таблица; позволяет фильтровать результаты.
• Теги и категории - пользовательская классификация: проект, отдел, тема.
• Права доступа - список пользователей и групп, которым разрешен просмотр; критично для document-level security.
• Текстовое содержимое - извлеченный текст для полнотекстового поиска.
• Идентификатор источника и версия - стабильный ключ объекта, checksum или version ID для идемпотентности и контроля изменений.
• Статус обработки - результат извлечения текста, OCR и индексации, включая ошибку и причину отказа.

Для имени файла и пути полезно хранить отдельные поля: одно поле text для поиска по словам и поле keyword для точного фильтра или отображения. Каждое поле должно отвечать на конкретный вопрос поиска: кто создал, когда изменил, к какому проекту относится, кому доступен, что внутри.

Схема метаданных для Elasticsearch/OpenSearch

Отображение метаданных в маппинг поискового движка определяет, как поля индексируются и запрашиваются. Ключевое различие - между типами text и keyword. Поле text анализируется: разбивается на токены, проходит стемминг, используется для полнотекстового поиска. Поле keyword хранится как есть: используется для точного совпадения, фильтрации, сортировки и агрегаций.

Пример маппинга для документа:

{
  "mappings": {
    "properties": {
      "title": {
        "type": "text",
        "fields": {
          "keyword": { "type": "keyword" }
        }
      },
      "author": { "type": "keyword" },
      "created_at": { "type": "date" },
      "modified_at": { "type": "date" },
      "doc_type": { "type": "keyword" },
      "tags": { "type": "keyword" },
      "access_groups": { "type": "keyword" },
      "content": {
        "type": "text",
        "analyzer": "russian"
      }
    }
  }
}

Multi-fields решают задачу двойного использования: поле title индексируется как text для поиска по словам и как keyword для точной сортировки. Поле content использует русский анализатор для корректной обработки морфологии.

Стратегии индексации: как обеспечить быстрый и точный поиск

Индексация - это процесс преобразования исходных файлов в структурированные документы поискового индекса. Качество индексации определяет точность и полноту поиска.

Обработка текста: извлечение и очистка

Файлы в хранилище имеют разные форматы: PDF, DOCX, XLSX, изображения со сканами. Поисковый движок работает с текстом, поэтому первый этап - извлечение. Apache Tika - распространенный инструмент, который поддерживает множество форматов и может использоваться в связке с Elasticsearch через ingest pipeline с attachment processor. Доступность и параметры attachment processor для конкретной версии Elasticsearch или OpenSearch нужно проверять отдельно.

Пример ingest pipeline для извлечения текста из PDF:

{
  "description": "Extract text from attachments",
  "processors": [
    {
      "attachment": {
        "field": "data",
        "target_field": "attachment",
        "indexed_chars": -1
      }
    },
    {
      "remove": { "field": "data" }
    }
  ]
}

Параметр indexed_chars без ограничения может увеличить нагрузку на память при больших вложениях. В production задайте лимит, контролируйте размер исходного объекта и сохраняйте статус ошибки обработки.

Для изображений со сканами требуется OCR. Tesseract - основной open-source движок, который интегрируется в пайплайн как отдельный этап перед индексацией. Точность OCR нельзя гарантировать одной цифрой: она зависит от разрешения и качества скана, языка, макета, таблиц, печатей и рукописного текста. Для production измеряйте долю ошибок и полноту распознавания на собственном наборе документов.

Настройка анализаторов и токенизация

Анализатор определяет, как текст разбивается на токены и нормализуется перед записью в индекс. Для русского языка стандартный анализатор может работать хуже специализированной конфигурации: он не учитывает морфологию, поэтому поиск по слову «настройка» может не найти документ со словом «настройки».

Настройка русского анализатора в Elasticsearch:

{
  "settings": {
    "analysis": {
      "filter": {
        "russian_stop": { "type": "stop", "stopwords": "_russian_" },
        "russian_stemmer": { "type": "stemmer", "language": "russian" }
      },
      "analyzer": {
        "russian": {
          "type": "custom",
          "tokenizer": "standard",
          "filter": ["lowercase", "russian_stop", "russian_stemmer"]
        }
      }
    }
  }
}

Стемминг приводит слова к основе: «настройка», «настройки», «настройке» - к близкому токену. Стоп-слова отфильтровывают частотные слова без смысловой нагрузки. Выбор анализатора влияет на recall и precision: агрессивный стемминг увеличивает полноту, но снижает точность.

Для русскоязычного поиска отдельно протестируйте смешанные русско-английские термины, имена файлов, номера версий и аббревиатуры. Синонимы лучше хранить в управляемом наборе и применять через отдельную настройку анализатора, чтобы изменение словаря не требовало несанкционированной перестройки индекса. Для точной фразы используйте match_phrase, а fuzzy-поиск ограничивайте полями title или имени файла и небольшим fuzziness: широкое применение fuzzy увеличивает нагрузку и число нерелевантных результатов.

Проверяйте не только отдельные слова, но и реальные запросы: «квартальный отчет», название проекта, сочетание русского и английского термина, точное имя файла и запрос с опечаткой. Результаты оценивайте по precision и recall на заранее подготовленном наборе.

Автоматизация каталогизации через пайплайны

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

Минимальный production-ready пайплайн

Для первого production-контура достаточно следующих компонентов:

1. Мониторинг новых файлов в бакете S3: через события или периодическое сканирование.
2. Извлечение текста: Apache Tika для офисных форматов, OCR для сканов.
3. Обогащение метаданными: добавление системных полей, тегов, прав доступа и статуса обработки.
4. Формирование стабильного document ID из источника и ключа объекта.
5. Запись в индекс: bulk-запрос в Elasticsearch или OpenSearch с повтором временных ошибок.
6. Периодическая сверка источника и индекса для обнаружения пропущенных событий.

Минимальный вариант должен быть идемпотентным: повторная доставка одного события не создает дубликат и не меняет права доступа непредсказуемо. Секреты не храните в конфигурации и логах, а соединения с production-кластером защищайте TLS.

Фрагмент конфигурации Logstash для чтения из S3 и записи в Elasticsearch:

input {
  s3 {
    bucket => "corporate-documents"
    region => "us-east-1"
    prefix => "documents/"
    interval => 60
    additional_settings => {
      force_path_style => true
      endpoint => "http://minio:9000"
    }
  }
}
filter {
  mutate {
    add_field => {
      "source" => "s3"
      "indexed_at" => "%{@timestamp}"
    }
  }
}
output {
  elasticsearch {
    hosts => ["http://elasticsearch:9200"]
    index => "documents-%{+YYYY.MM.dd}"
    user => "logstash_internal"
    password => "${ELASTIC_PASSWORD}"
  }
}

Важная деталь: запись вида ${@timestamp} в mutate не является корректной ссылкой на поле события. Для текущей временной метки используется формат %{@timestamp}. Поле indexed_at показывает время обработки, а не modified_at источника, поэтому его нельзя использовать как единственный признак изменения документа.

Конфигурация выше является упрощенным примером. S3 input обычно опрашивает бакет, а не обеспечивает полноценную доставку событий об удалении. Для MinIO endpoint http://minio:9000 допустим только в изолированном тестовом контуре; в production используйте HTTPS, проверку сертификата и секреты через переменные окружения или менеджер секретов.

Расширенный вариант: очередь, retry и dead-letter queue

При большом объеме документов вынесите события в очередь или брокер. Обработчик должен иметь retry с backoff для временных ошибок S3, Tika, OCR и поискового кластера, а окончательно неуспешные сообщения направлять в dead-letter queue с причиной, счетчиком попыток и исходным идентификатором.

Контроль идемпотентности строится на стабильном document ID, checksum или version ID. Обработчик должен безопасно повторять upsert, не затирать более новую версию старым событием и фиксировать состояние обработки. Отдельный reconciliation job сравнивает источник с индексом по watermark, ключам и версиям, возвращая в очередь пропущенные и зависшие объекты.

Для более сложных сценариев с ветвлением и обработкой ошибок используйте Apache NiFi: визуальный интерфейс, встроенные процессоры для S3, Tika, Elasticsearch, управление backpressure и повторными попытками. Состав процессоров и параметры соединений проверяйте в версии, которая будет использоваться в production.

Обработка обновлений и удалений

Индекс должен отражать актуальное состояние хранилища. Обновление файла требует переиндексации: старый документ заменяется новым. Удаление файла требует удаления документа из индекса и, при необходимости, очистки связанных OCR-результатов или вложенных объектов.

Стратегии синхронизации:

• События S3: бакет отправляет уведомления о создании, изменении и удалении объектов. Пайплайн реагирует быстро, но требует настройки событий и обработки повторной доставки.
• Периодическое сканирование: пайплайн каждые N минут сравнивает список объектов в бакете с индексом. Проще в настройке, но имеет задержку и дополнительную нагрузку.
• Версионирование: хранилище сохраняет все версии объекта, индекс содержит ссылку на актуальную. Позволяет искать по истории изменений, если это предусмотрено моделью данных и политикой доступа.
• Reconciliation: отдельная проверка периодически ищет пропущенные события, устаревшие версии и документы без объекта-источника.

Для upsert используйте document ID, совпадающий с нормализованным ключом объекта в S3. Повторная индексация с тем же ID обновляет документ. Для удаления надежнее публиковать событие или tombstone и выполнять точечное удаление по стабильному ID. Delete by query оставляйте для контролируемой сверки с ограничением по индексу и времени: массовое удаление документов, чьи ключи отсутствуют в неполном списке, может привести к потере результатов.

Выбор поискового движка: Elasticsearch vs OpenSearch

Оба движка решают задачу полнотекстового поиска, но имеют разные лицензии, редакции, наборы плагинов и траектории развития. Проверка ниже актуальна для проектирования на сентябрь 2026 года на уровне общих принципов; конкретные возможности, API и условия поддержки необходимо сверять с версией дистрибутива и выбранной коммерческой редакцией перед production-внедрением.

Критерии выбора: лицензия, поддержка, экосистема

OpenSearch - форк Elasticsearch 7.10.2, созданный AWS после изменения лицензирования Elasticsearch. Ядро OpenSearch и многие компоненты проекта распространяются по Apache 2.0, однако условия конкретной сборки, плагинов, managed-сервиса и коммерческой поддержки нужно проверять отдельно.

Elasticsearch доступен под несколькими вариантами лицензирования, включая Elastic License, SSPL и AGPLv3 для соответствующих компонентов и версий. Это не означает, что любой компонент доступен на всех лицензиях или что условия одинаковы для self-managed, SaaS и встроенного использования. Лицензионную модель нужно проверять по конкретному релизу и способу эксплуатации.

Сравнение по ключевым критериям:

Если важны условия Apache 2.0 для ядра, открытый стек и конкретные функции OpenSearch - рассматривайте OpenSearch после проверки плагинов и поддержки. Если нужны функции Elastic, существующая экосистема и коммерческая поддержка Elastic - рассматривайте Elasticsearch с проверкой условий выбранной лицензии. API обоих движков схож только в определенных областях, поэтому миграция не должна считаться заменой «в один клик».

Практический пример развертывания Elasticsearch 8.x с Logstash и Kibana описан в руководстве по ELK Stack 2026. Пример нужно адаптировать под версию кластера, особенно в части security, клиентов и шаблонов индексов.

Обеспечение безопасности и контроль доступа

Корпоративный поиск индексирует документы с разными уровнями конфиденциальности. Пользователь должен видеть в результатах только те документы, к которым имеет доступ. Утечка через поиск - такой же инцидент, как утечка через файловый сервер.

Интеграция с корпоративными системами аутентификации

Подключите поисковый движок к существующему каталогу пользователей. Elasticsearch и OpenSearch поддерживают LDAP и Active Directory для аутентификации, но названия настроек и доступность функций зависят от дистрибутива. Следующий пример относится к конфигурации Elasticsearch и требует проверки по версии:

xpack.security.authc.realms.ldap.ldap1:
  order: 0
  url: "ldaps://ldap.corp.example.com:636"
  bind_dn: "cn=search,ou=service,dc=corp,dc=example,dc=com"
  bind_password: "${LDAP_BIND_PASSWORD}"
  user_search:
    base_dn: "ou=users,dc=corp,dc=example,dc=com"
    filter: "(uid={0})"
  group_search:
    base_dn: "ou=groups,dc=corp,dc=example,dc=com"

Маппинг групп на роли: группа «engineering» получает роль с доступом к индексу engineering-documents, группа «finance» - к finance-documents. SSO через SAML или OIDC подключается для бесшовного входа через корпоративный портал. Для service account используйте отдельные минимальные права и не передавайте учетные данные в клиентский JavaScript.

Модель ACL: группы, наследование и отзыв доступа

Поле access_groups должно отражать не случайный список групп, а согласованную модель эффективных прав. При индексации файлов из SMB/NFS учитывайте наследование ACL от каталогов, вложенные группы, deny-правила и пользователей с индивидуальными разрешениями. Для S3 сохраняйте сведения о bucket policy, object ACL или результате предварительного расчета прав в зависимости от принятой модели.

Изменения групп должны синхронизироваться с индексом. При добавлении пользователя в группу доступ может появиться после обновления контекста прав, а при удалении пользователя или группы доступ должен быть отозван в пределах согласованного SLO. Устаревший access_groups опаснее ошибки полнотекстового поиска: документ может быть найден и показан пользователю после отзыва доступа.

Не смешивайте allow и deny без явно заданного порядка применения. Если модель требует deny-правил, храните их отдельно или рассчитывайте эффективное разрешение в одном контролируемом сервисе. При изменении ACL переиндексируйте документ либо обновляйте только security-метаданные, если это поддерживается выбранной схемой.

Разграничение доступа на уровне документов

Document-level security фильтрует результаты поиска на основе прав пользователя. Каждый документ содержит поле access_groups со списком групп, которым разрешен просмотр. Запрос может автоматически дополняться фильтром по этому полю.

Пример запроса с фильтром по правам доступа:

{
  "query": {
    "bool": {
      "must": [
        { "match": { "content": "квартальный отчет" } }
      ],
      "filter": [
        { "terms": { "access_groups": ["engineering", "management"] } }
      ]
    }
  }
}

Роль пользователя определяет список групп, которые подставляются в фильтр. Пользователь из группы «engineering» видит только документы с меткой «engineering» или «management». Документы с меткой «finance» скрыты.

Этот запрос показывает механику фильтрации, но фильтр в клиентском запросе сам по себе не является границей безопасности. Пользователь может изменить отправленный JSON, если сервер ему доверяет. В production ограничения должны добавляться на сервере из аутентифицированного контекста и подкрепляться DLS/RBAC или эквивалентным механизмом выбранного движка. Обязательно тестируйте прямой доступ к API, экспорт, агрегации, подсказки и кэширование результатов.

Функциональные требования и измеримые SLO

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

Мониторинг и оптимизация производительности

Система поиска работает под нагрузкой. Без мониторинга деградация производительности обнаруживается после жалоб пользователей, а не до них.

Ключевые метрики и алерты

Отслеживайте:

• CPU и heap usage: загрузка узлов, использование JVM heap. Порог алерта на уровне 85% можно использовать как начальный ориентир для sustained-значения, но его нужно подтвердить нагрузочным тестом.
• Search latency: время ответа на поисковые запросы. p95 выше 500 мс может быть сигналом для интерактивного поиска, но целевое значение зависит от сценария и сложности ACL-фильтра.
• Indexing rate: скорость индексации документов. Резкое падение указывает на проблемы в пайплайне.
• Queue size: длина очереди запросов и событий. Рост очереди - признак перегрузки или неработающего обработчика.
• Index completeness: количество объектов без документа, без текста или с устаревшим access_groups.
• OCR/Tika errors: доля ошибок извлечения, повторных попыток и сообщений в dead-letter queue.
• Delete and ACL lag: задержка удаления документа и применения изменений прав.

Инструменты: Kibana или OpenSearch Dashboards для встроенного мониторинга кластера, Prometheus с экспортером elasticsearch_exporter для интеграции с общей системой алертинга, Grafana для дашбордов. Подробные принципы построения наблюдаемости описаны в руководстве по архитектуре системы наблюдаемости.

Оптимизация запросов и индексов

Типовые проблемы и решения:

• Неправильный маппинг: поле с текстом индексировано как keyword, полнотекстовый поиск не работает. Решение: переиндексация с корректным маппингом.
• Слишком много шардов: каждый шард потребляет ресурсы, большое количество мелких шардов замедляет поиск. Решение: объединение индексов, настройка ILM для ротации.
• Частый refresh: обновление индекса каждую секунду создает нагрузку. Решение: увеличение refresh_interval до 30 секунд для индексов, где не требуется near real-time.
• Тяжелые запросы: агрегации по большим объемам данных. Решение: профилирование запросов через Profile API, оптимизация структуры запроса.
• ACL-фильтрация: большой список групп в каждом запросе увеличивает стоимость поиска. Решение: измерять запросы с реальными правами и выбирать модель индекса согласно профилю доступа.

Настройка числа шардов и реплик выполняется при создании индекса. Универсального правила, что для любого корпоративного поиска объемом до 1 ТБ достаточно 1-3 первичных шардов и 1 реплики, нет. Решение зависит от размера документов, числа полей, частоты записи и поиска, размера heap, типа дисков, требований к отказоустойчивости и фактического shard size. Выбирайте конфигурацию по измерениям, а не только по объему данных.

Пилот: что проверить до масштабирования

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

1. Соберите репрезентативный набор документов: PDF с текстом и сканами, DOCX, XLSX, изображения, большие файлы, поврежденные файлы и документы с разными ACL.
2. Подготовьте тестовые поисковые запросы: русские словоформы, смешанные русско-английские термины, точная фраза, имя файла, опечатка, фильтр по типу и периоду.
3. Проверьте ACL для обычного пользователя, нескольких групп, вложенной группы, отозванного пользователя и deny-сценария.
4. Создайте, измените и удалите объект, затем измерьте время появления, обновления и исчезновения результата.
5. Запустите нагрузочный тест с реальными профилями запросов, включая ACL и fuzzy-поиск, и зафиксируйте p95.
6. Сверьте число объектов в источнике, очереди, статусах обработки и индексе. Отдельно проверьте пропущенные события и документы, попавшие в dead-letter queue.
7. Выполните тестовое восстановление индекса или повторную обработку контрольного набора, чтобы проверить воспроизводимость пайплайна.

Заключение: дорожная карта внедрения

Построение системы хранения и корпоративного поиска - это последовательный процесс. Ключевые этапы:

1. Выберите архитектуру хранения: файловый сервер для малого объема, объектное хранилище для масштабируемости, гибрид для совместимости с текущими процессами.
2. Спроектируйте модель метаданных: системные поля, пользовательские теги, стабильный ID, статусы обработки и права доступа.
3. Настройте индексацию: извлечение текста, русский анализатор, маппинг полей, обработка имен файлов и точных фраз.
4. Автоматизируйте каталогизацию: пайплайн от хранилища до индекса с обработкой обновлений, удалений, retry и reconciliation.
5. Обеспечьте безопасность: интеграция с LDAP/AD, серверная ACL-фильтрация и document-level security.
6. Зафиксируйте SLO: время индексации, p95 поиска, полноту индекса, ошибки OCR/Tika и задержку удаления.
7. Настройте мониторинг: ключевые метрики, алерты, дашборды и контроль устаревших прав.

Начните с пилотного проекта на ограниченном наборе данных: один отдел, один тип документов, один бакет. Проверьте пайплайн, точность поиска, ACL, производительность и восстановление после ошибок. Затем расширяйте охват на другие подразделения и типы данных. Выбор между Elasticsearch и OpenSearch фиксируйте вместе с версией, лицензией, набором security-функций и результатами миграционного теста.

FAQ

Можно ли индексировать SMB без миграции в S3?

Да. SMB или NFS могут оставаться источником, если есть надежный механизм обнаружения изменений, извлечения текста и чтения ACL. Для небольшого объема подойдет периодическое сканирование, для частых изменений лучше использовать журнал изменений или агент. S3 не является обязательным условием для корпоративного поиска по файлам.

Что выбрать для on-premise?

Для on-premise выбор зависит от требований к API, лицензии, операционной команде и масштабу. Файловый сервер с внешним индексом проще внедрить в существующую среду. MinIO или Ceph RGW подходят, если нужны S3 API и масштабирование, но добавляют требования к эксплуатации. Перед выбором сравните отказоустойчивость, резервное копирование, ACL и восстановление.

Как индексировать PDF со сканами?

Сначала определите, содержит ли PDF текстовый слой. Если его нет или он неполный, передайте страницы в OCR, сохраните результат с указанием языка и статуса обработки, затем отправьте текст в ingest pipeline и индекс. Не используйте одну оценку точности для всех документов: измерьте OCR на собственных сканах и предусмотрите ручную проверку критичных документов.

Как не допустить утечку документов через поиск?

Не доверяйте access_groups, переданному клиентом. Рассчитывайте права на сервере, синхронизируйте изменения групп и наследование ACL, применяйте DLS/RBAC или эквивалентный механизм, ограничивайте доступ к API и тестируйте прямые запросы, агрегации, подсказки, экспорт и кэш. Отдельно контролируйте задержку удаления доступа.

Когда нужен OpenSearch вместо Elasticsearch?

OpenSearch стоит рассматривать, когда условия лицензирования, открытый стек или доступность конкретных функций соответствуют требованиям проекта. Elasticsearch может быть предпочтительнее при зависимости от экосистемы Elastic, существующей экспертизы и коммерческой поддержки. Сравнивайте не только базовый API, но и анализаторы, security, ingest pipeline, инструменты мониторинга, плагины, managed-сервисы и стоимость миграции.