Я использую ElasticSearch для компонента поиска на сайте. Данные, которые индексируются и, в конечном итоге, подвергаются поиску, – это те же данные, которые сохраняются в базе данных MySQL.
Мой подход к этому заключается в добавлении / удалении / изменении данных в индексе, когда происходит соответствующая операция CRUD MySQL.
Например, операция создания выглядит примерно так:
public function savePost(Request $request) { //Firstly, create the object and save it to MySQL $post = new Post(); $post->title = $request->title; $post->body = $request->body; //... //and so on $post->save(); //Secondly, index this new data: $elasticSearchClient = ClientBuilder::create()->build(); $params = [ 'index' => 'some_index_elasticsearch', 'id' => $post->id, 'type' => 'post', 'timestamp' => time(), 'body' => [ 'id' => $post->id, 'title' => $post->title, 'body' => $post->body, //... and so on ], ]; $elasticSearchClient->index($params); } Если данные удаляются / обновляются в MySQL, я просто удаляю его или обновляю его из индекса.
Это правильный подход к использованию MySQL с ElasticSearch (или любой другой сопоставимой технологией, такой как Sphinx)? или вы порекомендовали бы лучший подход к использованию MySQL в качестве источника данных для ElasticSearch? (что действительно не происходит вообще, потому что взаимодействия между ElasticSearch и MySQL вообще нет).
Я использую https://github.com/elastic/elasticsearch-php для взаимодействия с ElasticSearch, если это имеет значение.
Просто уточнить: этот подход действительно работает до сих пор – я просто не уверен, что это правильный путь, или если кто-нибудь может увидеть проблемы, с которыми я могу столкнуться с этим способом делать что-то.
Для использования Elasticsearch нет «правильного пути». «Правый» относительный, поэтому «правильный путь» – это способ, который поддерживает ваш случай (ы) использования. Elasticsearch работает не только в одном конкретном случае использования, но и во много раз больше, чем один случай использования.
Случай, который вы описываете, является совершенно достоверным, то есть индексирование в ES любого содержимого, которое у вас есть в другой СУБД, такой как MySQL, и убедитесь, что проиндексированный контент синхронизирован с основным источником правды.
Одна сложная вещь в вашем случае использования, которую вы должны иметь в виду, заключается в том, что вы должны гарантировать, что MySQL и ES всегда синхронизируются 1: 1, и это не всегда легко сделать по разным причинам:
Есть другие пути для синхронизации MySQL и ES, которые менее хрупкие, например , используя binlog .
Вы должны задать себе эти вопросы и выяснить стратегию смягчения этих потенциальных проблем, потому что я могу заверить вас, что они (и другие) обязательно возникнут.
Подводя итог, нет проблем с вашей архитектурой, тысячи компаний делают то же самое, однако вам нужно иметь план, если ваш план синхронизации будет идти на юг.
ElasticSearch не очень подходит для обновления / удаления документов в больших масштабах.
Существует много апробаций, которые пытаются свести к минимуму перегрузку этого недостатка на его архитектуре, но если вы думаете, что увеличивает сложность вашего решения.
Я предлагаю, чтобы вы выполняли операции CRUD только на MySQL и использовали ES как append-only. Фактически, сам StackOverflow и многие другие компании TI используют этот подход.