Я работаю Backend-разработчиком в индустрии CRM, где все дело в поиске :). Да, вы правы, это система с большим количеством столбцов таблицы данных. Таким образом, для поддержки этого гибко настраиваемого поиска была выбрана серверная среда Java с интеграцией Spring. Да, вы правы, мы выбрали Elasticsearch(ES) в качестве хранилища данных. Как всегда, были голоса за и против, но в конце концов это было правильное решение. Это было четыре года назад, и последняя стабильная версия была 1.7. Ой, совсем забыл, позвольте мне немного рассказать об ES.

ES — это поисковая система с открытым исходным кодом, основанная на Lucene. Конечно, это не первичное хранилище данных, однако эффективное для систем с поиском везде. ES легко масштабируется. Elasticsearch хранит метаданные об индексе (рассматриваем его как таблицу в SQL) и другую информацию о данных в файлах Как это хранится в ES. Узлы — это не что иное, как ваши серверы, которые вместе можно назвать кластером. Узлы помогают хранить реплики ваших данных. ES хранит данные в форме JSON и, в частности, следует так называемым законам JSON. Если вы хотите узнать больше об основах терминов ES, посетите здесь.

Давайте вернемся к тому, о чем я на самом деле должен говорить. Поддерживать ES действительно сложно и дорого. Я имел в виду, что, поскольку большинство стартапов не имеют так называемого DevOps-механизма автоматического масштабирования и других интересных вещей, по мере увеличения данных нам нужно загружать машины или узлы, чтобы поддерживать стабильность ES. Или же увидит «Ошибка пространства кучи», так как это полностью построено с использованием Java, да, разработчикам JAVA понравится эта ошибка :).

Реальные трудности разработчиков

  1. Добро пожаловать в реальный мир индексации. В elasticsearch вы всегда будете слышать об индексации. Индексация — это не что иное, как запись всех ваших данных в ES. Индексация также является операцией создания/обновления в системе. Существуют стратегии индексации, которые следует тщательно настроить в ES. Это означает, что системы с тяжелыми операциями чтения/записи должны выполнять соответствующие настройки в ES. Индексация съедает оперативную память вашей системы, как индеец ест острую пищу (я просто обожаю ее). Полную индексацию следует проводить с осторожностью в часы пик, так как это тяжелая операция.
  2. В версии 1.7 нет отношений родитель-потомок. Да, вы можете поддерживать отношения в ES между индексами в более поздних версиях. Как мы это решили? Нам также пришлось хранить дочерние данные JSON внутри родителя. Это было своего рода дублирование, потому что у нас был отдельный индекс для дочерних данных, но все же нужно было сохранить родительский индекс. Тогда может возникнуть вопрос, почему снова в родительском индексе? Потому что, поскольку системный поиск происходит на вашей родительской странице путем фильтрации дочерних данных. Альтернатива разделяет запросы в каждом индексе, а затем связывает их вместе. Но тогда нужно настроить пагинацию, и ваша модельная стратегия MVP не сработает (не может быть выпущена в ближайшее время из-за проблем во всем).
  3. Затем Awwww переходит к анализаторам полей и анализаторам индексов. Кто говорит, что да, ES — это просто, идите к черту. Нет, я просто пошутил. Но у нас были трудности с конфигурациями метаданных. Так что в ES данные хранятся либо анализируя их, либо нет. Например, если вы хотите, чтобы подстановочный знак поддерживал поле поиска, вам нужно хранить их в строках нижнего регистра. Если вы хотите, чтобы поиск работал с пробелами, то вам нужны какие-то другие анализаторы, и этот список можно продолжить. Хуже всего то, что вы не можете изменить его напрямую в существующем индексе, вы можете только добавить его в новый индекс. Итак, нам нужно переиндексировать данные.
  4. Скажем, ваш клиент придумал что-то новое. Они хотят, чтобы поиск происходил по спецсимволам, теперь нужно создавать специальные анализаторы и добавлять в свои метаданные. Да, вы можете просто закрыть индекс и добавить его. Но если вы хотите указать только что созданный анализатор в каком-либо из полей, то вы не можете этого сделать. Итак, снова вернемся к первому, создадим новый индекс и переиндексируем данные.
  5. Теперь, почему я не могу сначала сохранить каждое поле с помощью анализатора. Не стоит этого делать, так как в полях с анализаторами поиск и индексация займут больше времени. Поэтому всегда будьте осторожны при назначении анализаторов полям.
  6. Агрегации — лучшая часть ES. Группа по - лучший синоним, который я могу найти. Люди любят выполнять агрегации в ES. Да, но это может даже сломать систему. Так как очень тяжелая операция на ES съедает много оперативной памяти. Должен быть тщательно построен и использован. Большинство рекомендательных систем предпочитают использовать это в настоящее время.
  7. Elasticdump — лучшая библиотека для плавного выпуска и переиндексации. Я помню, что использовал это по крайней мере 3 раза в месяц.
  8. Отдавайте предпочтение построителям запросов, а не фильтрам. Фильтры применяются только после извлечения данных из узлов. Да, вы правы, это занимает много времени.

Вывод

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