- от Палакодети, Рави
Мы используем Endeca для создания поискового индекса и предоставления результатов поиска. Как оказалось, мы используем Endeca также для обслуживания данных, недоступных для поиска. Следовательно, наш индекс Endeca увеличился в размерах, и его создание занимает много времени. В этом посте рассказывается, как мы применяли шаблоны Domain Driven Design, CQRS и Event для перемещения данных, не доступных для поиска, из Endeca в кэш. Это обеспечивает значительный прирост производительности Endeca без негативного влияния на поиск продуктов и страницы с подробными сведениями.
Проблемы с текущим процессом
В настоящее время, когда данные клиента изменяются, изменения отображаются на сайте посредством пакетного процесса с использованием ETL и поискового индекса Endeca следующим образом:
- Другие приложения обновляют информацию о клиенте в РСУБД (системе записи).
- Запланированные задания ETL загружают все данные о клиентах в Endeca.
- Веб-сайт получает данные от Endeca через службу.
Проблемы с текущим процессом связаны с тремя аспектами:
- Поскольку Endeca содержит все сведения о клиенте (а не только данные для поиска), поисковое индексирование выполняется дольше.
- Данные могут быть устаревшими по отношению к RDBMS в зависимости от того, когда Endeca была обновлена.
- Каждый раз, когда схема сведений о клиенте пересматривается, представления базы данных, задания ETL, Endeca и служба доступа к данным требуют обновлений.
Решение
Решение для целевого состояния добавляет кеш, чтобы избежать обращения к базе данных, и службу REST для обновления сведений о клиенте. Кэш сведений о клиентах разработан с использованием DDD (Domain Driven Design) для управления шаблонами. Применяя шаблон CQRS (разделение ответственности за запросы команд), новая служба обновления клиентов обновляет (команду) РСУБД, а также делает недействительной соответствующую запись кэша для конкретного домена для клиента и новый клиент Служба сведений используется для извлечения (запроса) данных из кэша.
С помощью этого решения процесс отображения изменений данных о клиентах на веб-сайте идет двумя путями:
- Путь 1. Данные о клиентах с возможностью поиска требуют того же пакетного процесса, что и раньше, с использованием СУБД, Endeca и ETL.
- Способ 2. Все данные о клиентах сразу доступны через кэш для чтения.
Новые пути помогают смягчить проблемы с текущим процессом следующим образом:
- Поскольку Endeca не обслуживает все данные, ей нужно только содержать меньший набор доступных для поиска данных, что сокращает прогон индексации и позволяет быстрее обновлять поисковые индексы.
- Нет устаревших данных. Последние сведения о клиентах доступны на веб-сайте непосредственно из СУБД через кеш.
- Только доступные для поиска данные инициируют обновления заданий индексирования. Все остальные изменения схемы данных могут быть полностью реализованы командой разработчиков приложений, что оптимизирует весь процесс.
Кроме того, службы, основанные на принципах REST, предоставляют возможности управления версиями. Потребители услуг могут продолжать извлекать предыдущие схемы данных, что дает им время для обновления. Технология кэширования позволяет кэшировать несколько версий объекта домена, повышая эффективность.
Ниже мы рассмотрим два ключевых компонента более подробно.
Кэш сведений о клиенте
Использование Domain Driven Design для построения кэша сведений о клиентах имеет очень четко определенные стратегические значения. Ниже приведены некоторые из преимуществ (это не исчерпывающий список):
- Модель на основе домена.Кэш основан на концепциях домена, а не на каком-либо конкретном использовании кеша. Он обеспечивает общее понимание кеша для всех команд, поскольку для кеша нет специфичных для реализации нюансов. Клиентские конечные точки (например, мобильные, носимые) все еще могут быть созданы, но они находятся как можно дальше от кэша в инфраструктуре.
- Чистые границы.Эта модель устанавливает четкие границы между объектами предметной области. Это уменьшит связь между доменами и сохранит базовую архитектуру чистой и масштабируемой.
- Гибкая, итеративная, непрерывная модель.Учитывая, что решение очень модульное и несвязанное, использование принципов REST для служб позволяет команде итеративно улучшать модель, сохраняя при этом обратную совместимость и предоставляя четкий путь обновления для клиентские приложения, использующие службу.
- Создайте.. Они придут: эта модель позволяет команде разработчиков очень легко тестировать возможности запуска, поскольку изменение не очень навязчиво. Если продукты не работают, откат очень прост, и этот процесс (используя управление версиями) не влияет на существующих клиентов.
- Сущности и объекты-значения.Использование концепций "Сущностей" и "Объекты-значения" на основе предметной области, а также сервисов на основе REST, творческих и эффективных "Ресурсов". ' представления могут быть возвращены из служб, что уменьшает объем передаваемых данных. Это особенно полезно для мобильных устройств с ограничениями на объем передаваемых данных.
Службы обновления и получения подробной информации о клиентах
Внедряя службы на основе CQRS (отдельные службы чтения и обновления), мы уменьшаем связанность и отдельно масштабируем эти службы.
CQRS — это шаблон проектирования, в котором службы, которые считывают и обновляют данные, разделены. В большинстве сложных систем не существует однозначного отношения между операциями чтения и записи. Запись, как правило, больше зависит от модели объекта, тогда как чтение, как правило, зависит от рабочей нагрузки (SRP, Details и т. д.). Применение CQRS позволяет устранить связь между этими службами. Затем создаются следующие независимые службы; каждый со своими собственными модулями развертывания и конвейером.
- Служба обновления сведений о клиентах: используется для создания/обновления клиентов в системе записи.
- Служба поиска клиентов: используется для высокоскоростного поиска, когда обычно запрашивается очень большое количество записей, но для каждой требуется мало данных.
- Служба сведений о клиентах: служба, в которой осуществляется поиск одного или нескольких клиентов, но требуется много деталей.
В этой новой модели:
- Специализированные службы обновления клиентов обновляют все точки данных клиентов.
- Эти данные затем доступны в кеше с помощью комбинации чтения и прогрева кеша. Между кешем и системой записи существует непосредственная согласованность.
- Подмножество этих данных помещается в поисковый индекс через ETL. Теперь ETL просты и быстры. В современных приложениях ожидается конечная согласованность между поиском и деталями.
Общение на основе событий
По мере масштабирования этого шаблона и реализации нескольких кэшей взаимодействие между службами, которые обновляют данные, и кэшами, которые им необходимо сделать недействительными, становится сложным и ненадежным. Использование модели, основанной на событиях, в которой события аннулирования распространяются этими системами в кэш, уменьшает связь между этими системами. В этой модели также четко определено разделение проблем данных кэша.
Будущее состояние: облако
В будущем сценарии, если службы будут перемещены в облако, с помощью этой модели можно свести к минимуму прямую зависимость от базы данных. Здесь согласованность с кешем может быть реализована в конечном итоге с помощью прямого канала. В зависимости от потребностей в данных и значения точки данных возможна немедленная согласованность, но она может не требоваться для большинства точек данных. В этой модели:
- Службы и сопутствующие кэши развертываются в облаке.
- Эти кэши предупреждены до приемлемого уровня. Для набора данных клиента весь кэш может быть прогрет при запуске.
- Периодически изменения распространяются в облако с использованием подхода, основанного на событиях.
- Больше нет необходимости полагаться на базу данных или доступность подключения к помещению в любое время.
