Как стать автором
Обновить

Комментарии 6

За бонус спасибо!

Это единственный очевидный путь, как из Elastic можно получить доступ к данным в MSSQL.

Костыль это а не единственный очевидный путь. Насколько я понимаю вы работаете на платформе .NET, которая богата имплементациями EventSourcing. БД как API это тоже костыль или пуля в ногу.


Logstash в вашем случае тоже костыль, корни слова просто кричат за себя log stash. Вы же ведь не дрова в БД храните а ваши ненаглядные бизнес данные.


Что мешает сделать через модель событий с двумя типами слушателей Data и FullTextIndexer, которые могут быть параллельными или один идти после другого.

Спасибо за конструктивный комментарий. Это отличный метод и мы обязательно его используем, когда будем писать новый проект, и у нас встанет схожая задача. Проблема использовать его сейчас заключается в том, что система уже готова и давно работает. Чтобы на данном этапе сделать это так, как вы описали, нужно перепроектировать архитектуру. К тому же, на данный момент всё решение уже функционирует несколько лет, и там накопилось большое количество информации. Писать своё решение для индексирования её в Elastic при наличии готового тоже как-то не комильфо.

а перенести их оттуда нельзя по соображениям информационной безопасности.

Т.е. содержание копии в индексах elasticsearch с точки зрения информационной безопасности — это не перенос данных?

Спасибо. В тексте была неточность. Внесли исправления в статью: перенести данные дорого — вся система завязана на MSSQL. Использовать сторонние сервисы не получится по соображениям информационной безопасности.

Также отказались от SharePoint, поскольку он умеет искать только по спискам.

Поиск в SharePoint умеет индексировать внешние источники данных и искать по ним.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий