За последние десять лет мы стали свидетелями целого ряда новых решений и компаний, которые вращаются вокруг недавно получившего популярность решения для баз данных под названием NoSQL. NoSQL означает не только SQL, поскольку это решение для нереляционной базы данных, в котором используются языки запросов, отдельные от традиционного SQL, хотя он может иметь общие черты или использоваться вместе с базами данных SQL. Вы, вероятно, знакомы по крайней мере с одной из популярных баз данных NoSQL, такой как MongoDB, Cassandra, Redis, HBase и Couchbase. Однако есть одна база данных, которую часто не принимают во внимание, когда думают о решениях NoSQL…

Solr

Как проект Apache Foundation, Solr - одна из двух самых популярных поисковых систем с открытым исходным кодом в мире, а Elasticsearch - единственный проект, способный конкурировать. Естественно, многие инженеры думают о Solr как о поисковой системе, а не как о решении NoSQL, несмотря на то, что оно имеет сходство с популярными базами данных NoSQL (хранилище документов, простая репликация и высокая доступность). Хотя полнотекстовый поиск - это то, чем действительно славится Solr, он может быть очень полезен в качестве базы данных NoSQL. Он обеспечивает быструю фильтрацию, сортировку и фасетирование за счет невозможности легко представить отношения между типами документов (где реляционная база данных будет лучше).

До того, как я присоединился к команде поиска O’Reilly Media, я в основном думал о Solr как о решении NoSQL, поскольку мой предыдущий опыт работы с Solr обычно относился к среде больших данных. Как стажер в IBM, я впервые познакомился с Solr как с компонентом IBM Open Platform, который представляет собой набор сервисов больших данных, основанных на Hadoop, подобных CDH Cloudera. Я получил больше информации о Solr, когда я присоединился к IBM Watson Health в качестве инженера-программиста, работающего над их приложениями Explorys.

Я имел удовольствие создать приложение (вместе с другими сотрудниками IBM) под названием Worklist, которое помогает поставщикам медицинских услуг (врачам, медсестрам и т. Д.) Ориентироваться на пациентов из группы риска, организуя их в систему, похожую на электронную таблицу. Мы использовали Solr для поддержки быстрой фильтрации и сортировки, позволяя разделить пациентов на группы (или «рабочие списки») на основе определенных критериев состояния здоровья. Например, врач может создать рабочий список для пациентов старше 65 лет с систолическим артериальным давлением от 130 до 140, что позволит им легко идентифицировать пожилых пациентов с риском развития гипертонии. Врач мог бы даже отсортировать этот Рабочий список по снижению артериального давления, что позволило бы им выбрать наиболее уязвимых пациентов в группе.

Хотя рабочий список использовался врачами только с 20–30 пациентами, он часто использовался администраторами или директорами для управления миллионами пациентов, получающих помощь в их организации. В медицинской карте каждого пациента было 30-40 полей, которые можно было использовать для фильтрации или сортировки, и пользователи обычно создавали рабочие списки, состоящие из большого сочетания фильтров и сортировок (гораздо более сложных, чем пример, который я привел выше). Основанные на технологии больших данных, более старые приложения Explorys полагались на получение данных о состоянии здоровья непосредственно из HBase. Хотя сортировка и фильтрация были возможны с этими приложениями на базе HBase, они были слишком медленными при использовании в масштабе миллионов медицинских записей. Solr предоставил 3 замечательные функции, необходимые для приложения Worklist:

Быстрая фильтрация и сортировка. «Хлеб с маслом» Solr заключается в том, что он использует инвертированный индекс для быстрого поиска, фильтрации и сортировки по нескольким критериям. Каждый документ в Solr имеет уникальный идентификатор, а FilterQuery Solr хранит только идентификаторы документов (вместо всего поля или документа), что позволяет Solr быстро включать или исключать документы на основе любых критериев, особенно при использовании с кешированием. Конечно, ответы Solr далеко не мгновенные при фильтрации или сортировке миллионов документов, но это было намного лучше, чем унаследованные решения HBase.

Мгновенное фасетирование. Поскольку фильтрация Solr основана на идентификаторах документов и кэшировании, Solr может получить количество документов, которые соответствуют критериям фильтра, почти мгновенно. В приложении «Рабочий список» есть раскрывающийся список фильтров, в котором поставщик медицинских услуг может добавлять любое количество фильтров и логических операторов (И, ИЛИ и т. Д.). Включение этой сложной фильтрации сделало критически важным для пользователей получение обратной связи до фактического применения фильтров. Вы можете себе представить, как было бы разочарованием, если бы пользователь добавил фильтры, нажал кнопку «Применить», и теперь в электронной таблице отобразится 0 пациентов, что заставит пользователя снова открыть окно фильтра, изменить фильтры, снова нажать «Применить» и надеяться на то, что лучший.

Самая полезная часть этой функции заключалась в том, что медицинские работники могли видеть, сколько пациентов соответствовало сложным критериям фильтрации, прежде чем фактически применять фильтры к активному списку пациентов. В этом случае нам даже не пришлось настраивать сложные определения фасетов, а просто использовать общее количество, возвращаемое Solr. Отправив параметр «rows = 0» в Solr, мы незамедлительно предоставили нашим пользователям обратную связь, пока они находятся в процессе добавления и настройки фильтров, что важно для надежной фильтрации.

Высокая доступность с простой репликацией. Нам никогда не приходилось беспокоиться о сбоях в обслуживании из-за выхода из строя сервера Solr или несогласованности данных на разных серверах. Мы использовали SolrCloud, который использует несколько реплик (серверов), которые обрабатывают веб-запросы и реплицируются из основного источника. Если одна из реплик выходит из строя, другие реплики обрабатывают нагрузку, в то время как Solr автоматически создает новую реплику по мере необходимости.

Подобный опыт научил меня, что Solr может быть полезным решением для базы данных NoSQL и часто используется с другими службами больших данных. Благодаря этому опыту я подумал, что у меня есть все необходимое, чтобы присоединиться к O’Reilly Media и улучшить их поисковую систему на основе Solr. Я на собственном опыте выяснил, что использование Solr в качестве базы данных NoSQL радикально отличается от использования его в качестве поисковой системы, ориентированной на релевантность, несмотря на то, что ее функции фильтрации и фасетирования уходят корнями в технологию поиска (например, инвертированный индекс).

Для создания поисковой системы с хорошей релевантностью требуется гораздо больше, чем просто поддержка схемы Solr и поддержка фильтрации, сортировки и фасетирования. Я исследую это подробнее в моем следующем посте на Medium, где я расскажу о том, что важно для хорошей поисковой системы, основанной на релевантности, и о том, как команда поиска в O’Reilly отказалась от представления нашего Solr как базы данных NoSQL.