タグ

2022年7月14日のブックマーク (3件)

  • SQLとElasticsearchとのクエリの比較 - Qiita

    SQLとElasticsearchのクエリがそれぞれどう対応しているのか、よく使われると思うものについて大体まとめました。 環境 Elasticsearch 6.2.4 〜 7.5 前提条件 記載する内容は以下の条件を前提とします。 Elasticsearchで検索する際のURLの記載は省略 Elasticsearchでは検索を行う際に以下のようなURLへリクエストします。 {ElasticsearchのURL}/{index名}/_search 例えばSQLでproductというテーブルに対して索引を行っている場合、Elasticsearchでは以下のURLへリクエストを行っています。 http://localhost:9200/product/_search 以降Elasticsearchのリクエスト先URLは記載しませんが、上述のようなURLへリクエストしている前提です。 文字列のデ

    SQLとElasticsearchとのクエリの比較 - Qiita
  • Elasticsearchで検索結果に多様性を持たせる

    Elasticsearchで検索結果に多様性を持たせるElasticsearchで表示順序を「良い感じ」にするためのアプローチ なにをしたいのか Elasticsearchを使って検索機能を提供する場合、結果を表示するページのコンテンツには検索条件の有無に関わらずElasticsearchの検索結果を用いるのではないでしょうか。 ここで特定のユーザーが1つ以上のコンテンツを投稿できるサイトを考えてみましょう。 このサイトでは上述のようにコンテンツ一覧ページにおいてElasticsearchを使用しておりユーザーのコンテンツを投稿日時の降順で並べることで「賑わい」を演出しています。 ところがある日、特定のユーザーが連続で投稿するとそのユーザーのコンテンツばかりが表示されてしまうことに気が付きました。これではコンテンツ一覧ページを見た人からは特定のユーザーばかりが投稿しているように見えてしまい

  • GitLabがRuby on Railsを使い続ける理由(翻訳)|TechRacho by BPS株式会社

    概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Why we're sticking with Ruby on Rails | GitLab2022/06/08にthenewstack.ioに掲載されました) 原文公開日: 2022/07/06 原著者: Sid Sijbrandij -- GitLab, Inc.の共同創業者、CEO、取締役会議長 Ruby on Railsを作ったときのDavid Heinemeier Hansson(DHH)が道しるべとしたのは、それまでに経験していたPHPJavaでした(インタビュー)。DHHにとって、JavaのWebフレームワークはJavaが冗長で柔軟性が低く使いにくい点が好みでなかったものの、構造的に統一されている点が高く評価できるものでした。一方、PHPについては敷居の低さが好みだったものの、プロジェクトが泥沼化しがちな点をあま

    GitLabがRuby on Railsを使い続ける理由(翻訳)|TechRacho by BPS株式会社