알고리아 Sending And Managing Data(2-6)

Preparing Your Data for Indexing(인덱싱을 위한 너의 데이터 준비하기)

 

Before sending anything to Algolia, you need to think about where your data lives and what information you want to make searchable. For a retail outlet, it’s products. For a music store, it’s records and artists. For a real estate company, it’s houses and locations.

The next question is what information you need to build a search experience. You don’t need everything from your data source, just what’s necessary to create a search experience.

 

알골리아에 어떤 것을 보내기 전에, 당신은 당신의 데이터가 어디에 있고 어떤 정보를 검색 가능하게 만들고 싶은지 생각할 필요가 있다. 소매점으로 말하면 제품이죠. 음반 가게로 말하면 음반과 아티스트. 부동산 회사치고는 집과 위치입니다.
다음은 검색 환경을 구축하는 데 필요한 정보가 무엇인지 알아야 한다는 것입니다. 데이터 소스의 모든 것이 필요한 것이 아니라 검색 환경을 만드는 데 필요한 것만 있으면 됩니다.

Fetching data(데이터 가져오기)

To get started, you need to extract your data and send it to Algolia’s servers. The data can come from a relational database, a collection of XML files, a set of Excel spreadsheets, etc. The original data format doesn’t matter, what you need is a way to fetch and transform your data into a format that Algolia understands.

You likely want to write a script to fetch, transform, and send your data to Algolia. This script runs on your computer or server. You can access Algolia’s servers via the Search API, using one of the official API clients, framework integrations and platform extensions to help you send and manage your data depending on your technical stack.

For example, imagine you have a custom PHP blog with a MySQL database, and you want to make your blog posts searchable. You can create a script that fetches the posts from your database (for example, within PDO or an object-relational mapping tool), picks, and transforms the data, and rearranges it into records. Later on, you can use the PHP API client to send the objects to Algolia, and keep the data up to date when you add, update, or delete a post.

 

시작하려면 데이터를 추출해서 알골리아의 서버로 보내야 합니다. 데이터는 관계형 데이터베이스, XML 파일 모음, Excel 스프레드시트 집합 등에서 가져올 수 있습니다. 원본 데이터 형식은 중요하지 않으며, 필요한 것은 데이터를 가져와 알고리아가 이해하는 형식으로 변환하는 방법입니다.
당신은 아마도 당신의 데이터를 가져오고 변환하고 알고리아로 보내는 스크립트를 작성하기를 원할 것이다. 이 스크립트는 컴퓨터 또는 서버에서 실행됩니다. 공식 API 클라이언트, 프레임워크 통합 및 플랫폼 확장 중 하나를 사용하여 기술 스택에 따라 데이터를 보내고 관리할 수 있도록 Search API를 통해 알골리아의 서버에 액세스할 수 있습니다.
예를 들어 MySQL 데이터베이스가 있는 사용자 지정 PHP 블로그가 있고 블로그 게시물을 검색할 수 있도록 한다고 가정해 보십시오. 데이터베이스에서 게시물을 가져오고(예: PDO 또는 객체 관계 매핑 도구) 데이터를 선택 및 변환하고 레코드로 재정렬하는 스크립트를 작성할 수 있습니다. 나중에 PHP API 클라이언트를 사용하여 개체를 Algolia로 보내고 게시물을 추가, 업데이트 또는 삭제할 때 데이터를 최신 상태로 유지할 수 있습니다.

 

 

 

Structuring records(레코드 구조화하기)

When adding data to your records, you need to be selective. For example, if you’re working with a product line, you don’t need to send every piece of information about your products. Algolia only needs what serves the purposes of search. It includes all the necessary information to find products, rank them, and display them on your website or application.

Building records involves extracting the right data, reworking it to remove unnecessary data and add or compute extra information that can improve the chances of finding the most relevant results.

레코드에 데이터를 추가할 때는 선별이 필요합니다. 예를 들어, 제품군을 사용하는 경우 제품에 대한 모든 정보를 보낼 필요는 없습니다. 알고리아는 검색의 목적에 부합하는 것만을 필요로 한다. 여기에는 제품을 찾고 순위를 매기고 웹 사이트나 응용 프로그램에 표시하는 데 필요한 모든 정보가 포함되어 있습니다.
기록 작성에는 (올바른 데이터를 추출하고, 이를 재작업하여 불필요한 데이터를 제거하고, 가장 관련성이 높은 결과를 찾을 가능성을 높일 수 있는 정보를 추가하거나 계산하는 작업)이 포함됩니다.

Reworking and formatting data(데이터 재작업 및 형식 지정)

Imagine you want to create a search experience around movies, which means you may need to search and display movie titles, synopses, and cast. You also want to display (but not search) images and country of release, filter on genre or a range of dates, and rank based on review scores. However, you don’t care about technical information, such as how long the movie is.

Given your data comes from a relational database, with the information you need in different tables. You need to query the data from these tables. After fetching it, a record for one movie may look like the following:

 

영화 제목, 시놉스 및 캐스팅을 검색 및 표시해야 할 수 있는 동영상 검색 환경을 만든다고 상상해 보십시오. 또한 이미지 및 릴리스 국가를 표시하고 장르 또는 날짜 범위를 필터링하며 검토 점수를 기준으로 순위를 매길 수 있습니다. 하지만 당신은 영화의 길이와 같은 기술적인 정보에 대해서는 신경 쓰지 않습니다.
데이터가 관계형 데이터베이스에서 가져온 경우 필요한 정보가 서로 다른 테이블에 있습니다. 이 테이블에서 데이터를 쿼리해야 합니다. 가져온 후 한 영화의 레코드는 다음과 같이 보일 수 있습니다.

 

 

[
  {
    "title": "Spirited Away",
    "synopsis": "During her family's move to the suburbs, a sullen 10-year-old girl wanders into a world ruled by gods, witches, and spirits, and where humans are changed into beasts.",
    "director": "Hayao Miyazaki",
    "cast": [
      {
        "name": "Rumi Hiiragi",
        "birth_date": "August 1, 1987",
        "birth_place": "Tokyo, Japan"
      },
      {
        "name": "Miyu Irino",
        "birth_date": "February 19, 1988",
        "birth_place": "Tokyo, Japan"
      },
      {
        "name": "Mari Natsuki",
        "birth_date": "May 2, 1952",
        "birth_place": "Tokyo, Japan"
      }
    ],
    "release_year": 2001,
    "country": "Japan",
    "genres": [
      "Animation",
      "Adventure",
      "Family",
      "Fantasy",
      "Mystery"
    ],
    "runtime": 125,
    "aspect_ratio": "1.85:1",
    "content_rating": "PG",
    "review_scores": {
      "imdb": 8.6,
      "rotten_tomatoes": {
        "critics": 97,
        "audience": 96
      }
    },
    "images": [
      "https://example.com/spirited-away/image1.jpg",
      "https://example.com/spirited-away/image2.jpg"
    ]
  }
]

 

 

Here, there are all kinds of content, some of which are useful for a search experience as is, others in need of reformatting, and some that aren’t useful. For example, you don’t need to keep runtimeor aspect_ratio. While this is useful in other contexts, they have little value when searching, filtering, ranking, or displaying search results.

Same goes with some information in the cast attribute: while the names of the voice actors are useful, you don’t need their birth date and place. Therefore, you can safely remove them and just keep the names. This lets you remove noise, and save room in records for more useful data.

 

 

여기에는 모든 종류의 컨텐츠가 있으며, 그 중 일부는 검색 환경에 유용하고, 일부는 다시 포맷해야 하며, 일부는 유용하지 않습니다. 예를 들어 runtimeor aspect_ratio를 유지할 필요가 없습니다. 다른 컨텍스트에서는 유용하지만 검색 결과를 검색, 필터링, 순위 지정 또는 표시할 때는 거의 가치가 없습니다.
성우들의 이름은 유용하지만, 그들의 생년월일과 장소는 필요하지 않다. 따라서 안전하게 제거하고 이름만 유지할 수 있습니다. 이를 통해 노이즈를 제거하고 더 유용한 데이터를 위한 레코드의 공간을 절약할 수 있습니다.

 

{
  "cast": [
    "Rumi Hiiragi",
    "Miyu Irino",
    "Mari Natsuki"
  ]
}

 

Data for searching(검색할 데이터)

Attributes for searching are the ones that contain the terms that your users look for. If you want to search for a movie by title, plot, genre, or cast, you need attributes that contain these terms. In the example, such attributes are title, synopsis, director, cast, and genres.

Algolia lets you define in which specific attributes to search, using the searchableAttributesparameter. By default, the engine searches within the entire record, but you want to adjust this: this better for performance, and allows you to remove noise. You don’t want to search into attributes like images, release_year or review_scores, which aren’t textually relevant, or country, which may result in false positives. For example, when searching for “japan”, users most likely want to find movies that either have the term in the title or takes place in Japan, rather than Japanese movies.

You can therefore set title, synopsis, director, cast, and genres as searchableAttributes, and leave out the rest for displaying, filtering, and custom ranking.

Also, you can add some extra data to improve the discoverability of your record. For example, some users may try to look for it by its original title, or by the translation in their own language. Unless the translations are in the record, searching for these terms would return no results, so it’s a good idea to retrieve them and add them to your objects. You can fetch them from your database if you have them, or a third-party source such as an API or a website.

 

검색 속성은 사용자가 찾는 용어를 포함하는 속성입니다. 제목, 줄거리, 장르 또는 캐스팅별로 동영상을 검색하려면 이러한 용어를 포함하는 속성이 필요합니다. 예를 들어, 그러한 속성은 제목, 줄거리, 감독, 출연진, 그리고 장르이다.
Algolia를 사용하면 searchableAttributes 매개 변수를 사용하여 검색할 특정 특성을 정의할 수 있습니다. 기본적으로 엔진은 전체 레코드 내에서 검색하지만 이 기능을 조정하려고 합니다. 이 기능을 사용하면 성능이 향상되고 노이즈를 제거할 수 있습니다. 텍스트적으로 관련이 없는 이미지, release_year 또는 review_scores와 같은 특성 또는 잘못된 긍정 결과를 초래할 수 있는 국가에 대해서는 검색하지 않는 것이 좋습니다. 예를 들어 '재팬'을 검색할 때 이용자들은 일본 영화가 아닌 제목에 해당 용어가 있거나 일본에서 벌어지는 영화를 찾고 싶어할 가능성이 높다.
따라서 제목, 줄거리, 감독, 캐스팅 및 장르를 searchableAttributes로 설정하고 나머지는 표시, 필터링 및 사용자 지정 순위를 제외시킬 수 있습니다.
또한 레코드의 검색 가능성을 높이기 위해 데이터를 추가할 수 있습니다. 예를 들어, 일부 사용자는 원래 제목 또는 자신의 언어로 번역된 문서를 검색하려고 할 수 있습니다. 번역된 내용이 기록되지 않는 한 이러한 용어를 검색해도 결과가 나타나지 않으므로 해당 용어를 검색하여 객체에 추가하는 것이 좋습니다. 데이터베이스 또는 API 또는 웹 사이트와 같은 타사 소스가 있는 경우 데이터베이스에서 가져올 수 있습니다.

 

{
  "display_title": "Spirited Away",
  "original_title": "千と千尋の神隠し",
  "alternative_title": [
    "Le voyage de Chihiro",
    "El viaje de Chihiro",
    "Chihiros Reise ins Zauberland"
  ]
}

Data for filtering and faceting

When you have a significant amount of data, you can improve your search experience and let users fine-tune their query by filtering it down. For example, they may want to find all movies by directorHayao Miyazaki, find new adventure movies to watch or look for the best motion pictures of the past year.

Algolia lets you filter down results based on attributes. In this case, you could use director, cast, country, content_rating, and genres and display them as refinement lists in your search experience, as well as release_year to display a range slider. You can declare them with the attributesForFaceting parameter.

Filterable attributes can be anything, but you want to make sure to normalize the content. For example, if you have attribute genres with the term “Animation” in one record and “Animated picture” in another, these would result in two different facet values.

상당한 양의 데이터가 있는 경우 검색 환경을 개선하고 사용자가 쿼리를 필터링하여 미세 조정할 수 있습니다. 예를 들어, 그들은 미야자키 하야오 감독의 모든 영화를 찾거나, 새로운 모험 영화를 찾거나, 지난 해의 최고의 영화들을 찾고 싶어할지도 모른다.
Algolia를 사용하면 속성에 따라 결과를 필터링할 수 있습니다. 이 경우 감독, 캐스팅, 국가, content_rating 및 장르를 사용하여 검색 환경에서 세분화 목록으로 표시하고 릴리스_year를 사용하여 범위 슬라이더를 표시할 수 있습니다. 이 값을 특성ForFaceting 매개 변수로 선언할 수 있습니다.
필터링 가능한 특성은 무엇이든 될 수 있지만 내용을 정규화해야 합니다. 예를 들어, 한 레코드에는 "Animation"이라는 용어가 있고 다른 레코드에는 "Animated picture"이라는 용어가 있는 속성 장르가 있다면, 이는 두 가지 다른 측면의 값을 갖게 될 것이다.

 

 

Custom ranking

Algolia ensures that the most textually relevant results come first, but there might be ties in terms of relevance. For example, if a user looks for “james bond”, all James Bond movies would match equally. Without anything else to break the tie, Algolia falls back on the objectID in alphanumeric order, which isn’t relevant. A better way to break the tie is to rely on a piece of information that’s meaningful for this use case. For movies, it can be review scores, or likes on a given platform. For a retail store, it could be number of sales.

Algolia lets you inject business metrics to influence the ranking formula via the customRankingattribute. Attributes for custom ranking can be either numeric or boolean.

In this case, you can leverage the review_scores attribute. However, since you have several scores, you may want to compute them into a global one and use it in customRanking. The computed attribute would look like this:

 

알골리아는 텍스트적으로 가장 관련성이 높은 결과가 먼저 나오도록 보장하지만, 관련성 측면에서는 연관성이 있을 수 있다. 예를 들어, 만약 사용자가 "제임스 본드"를 찾는다면, 모든 제임스 본드 영화는 동등하게 일치할 것이다. 알골리아는 더 이상 동률을 깨지 못하고 그 물체 위로 떨어진다.ID는 영숫자 순서로 되어 있지만 관련이 없습니다. 이러한 관계를 타파하는 더 나은 방법은 이 사용 사례에 유용한 정보에 의존하는 것입니다. 영화의 경우 주어진 플랫폼에서 평점일 수도 있고 좋아요일 수도 있다. 소매점의 경우, 판매 건수가 될 수 있습니다.
Algolia를 사용하면 customParting 속성을 통해 비즈니스 메트릭을 주입하여 순위 공식에 영향을 줄 수 있습니다. 사용자 지정 순위의 속성은 숫자 또는 부울일 수 있습니다.
이 경우 review_scores 특성을 활용할 수 있습니다. 그러나 점수가 여러 개이므로 점수를 글로벌 점수로 계산하여 customParting에서 사용할 수 있습니다. 계산된 특성은 다음과 같습니다.

 

{
  "computed_score": 201.6
}

Depending on whether you plan to display the individual scores in the search results, you may decide to keep the original review_scores or get rid of it altogether to further simplify your records.

 

검색 결과에 개별 점수를 표시할 계획인지에 따라 기록을 더욱 단순화하기 위해 원래 review_scores를 유지할지 또는 아예 삭제할지 결정할 수 있습니다.

 

Handling record hierarchy(레코드 계층 처리)

Simplifying and restructuring your records doesn’t mean you have to lose hierarchy or relationships. For example, if you want your users to search for movies and see them organized by director, you need to store this relationship in your index. Algolia doesn’t impose a data schema. You can organize your data in any way you want, and keep it straightforward without losing complexity.

Now look at an example that simplifies hierarchical records. A director and all the movies they directed could either be one or several objects. A single record can represent a director, but it’s not useful for searching individual movies. While in a traditional database, you wouldn’t want to repeat data, this is perfectly okay in your Algolia index.

Take the following record, with nested movies:

 

기록을 단순화하고 재구성한다고 해서 계층구조나 관계가 없어지는 것은 아니다. 예를 들어 사용자가 동영상을 검색하고 감독별로 구성한 동영상을 보려면 이 관계를 인덱스에 저장해야 합니다. 알골리아는 데이터 스키마를 강요하지 않습니다. 원하는 방식으로 데이터를 정리하고 복잡성에 영향을 주지 않으면서 쉽게 유지할 수 있습니다.
이제 계층 레코드를 단순화하는 예를 살펴보십시오. 감독과 그들이 연출한 모든 영화는 한 가지 혹은 여러 가지 대상이 될 수 있다. 한 장의 음반이 감독을 대변할 수는 있지만 개별 영화 검색에는 유용하지 않다. 전통적인 데이터베이스에서는 데이터를 반복하고 싶지 않지만, Algolia 색인에서는 이 방법이 완벽하게 좋습니다.
중첩된 동영상과 함께 다음 레코드를 촬영합니다.검색 결과에 개별 점수를 표시할 계획인지에 따라 기록을 더욱 단순화하기 위해 원래 review_scores를 유지할지 또는 아예 삭제할지 결정할 수 있습니다.

 

{
  "director": "Hayao Miyazaki",
  "movies": [
    {
      "title": "Spirited Away",
      "score": 201.6
    },
    {
      "title": "My Neighbor Totoro",
      "score": 196
    },
    {
      "title": "Princess Mononoke",
      "score": 195.4
    }
  ]
}

This is only useful if your search experience focuses on finding directors, not on movies. Now take a look at that same information in three flatter, less hierarchical records:

이것은 당신의 검색 경험이 영화가 아닌 감독을 찾는 것에만 유용하다. 이제 동일한 정보를 세 가지 더 단순하고 덜 계층적인 기록에서 살펴보십시오.

[
  {
    "title": "Spirited Away",
    "score": 201.6,
    "director": "Hayao Miyazaki"
  },
  {
    "title": "My Neighbor Totoro",
    "score": 196,
    "director": "Hayao Miyazaki"
  },
  {
    "title": "Princess Mononoke",
    "score": 195.4,
    "director": "Hayao Miyazaki"
  }
]

 

This format lets you find movies more easily. Additionally, if you wanted to show a limited number of movies per director, like the most popular ones, you could leverage Algolia’s distinct feature on the director along with custom ranking on score. This way, searching for “miyazaki” would only return Miyazaki’s most popular movie.

Note that flattening data adds more records to your index. If you have 10,000 directors with an average of ten movies each, this results in an index with 100,000 records. It may sound like a lot, but it’s not. Besides what your plan allows, Algolia has no prescribed limit to the number of records, only disk size.

 

이 형식을 사용하면 동영상을 더 쉽게 찾을 수 있습니다. 덧붙여 가장 인기 있는 영화들처럼 감독당 제한된 수의 영화를 보여주고 싶다면, 감독에 대한 알골리아의 뚜렷한 특징과 함께 맞춤형 점수 순위를 활용할 수 있다. 이런 식으로, "미야자키"를 검색하는 것은 미야자키의 가장 인기 있는 영화만 돌려줄 것이다.
데이터를 평탄화하면 인덱스에 더 많은 레코드가 추가됩니다. 각각 평균 10편씩 1만 명의 감독이 있다면 이는 10만 개의 기록을 가진 인덱스가 된다. 많은 것처럼 들릴지 모르지만, 그렇지 않습니다. 당신의 계획이 허용하는 것 외에도, 알골리아는 레코드 수에 규정된 제한이 없고 디스크 크기만 있습니다.

 

 

Structuring indices(인덱스 구조화 하기)

An index is a collection of records. When you perform a search, you look into the records of an Algolia index.

An important principle that comes from relational databases is to distribute data across different tables. You break information into small, meaningful units to avoid redundancy. With Algolia, these principles don’t matter. As seen earlier, with record structure and data hierarchy, flattened data is best for searching. This applies at the index level too. It might seem reasonable to create several indices and map them to your tables, where each index represents a different kind of entity. For example, you may want to separate movies from actors and create an index for each. However, this might not serve the purposes of your search. What if you want your users to search for both movies and actors at the same time, and for them to appear in the same results? In that case, a single index works better.

The main reason for this is relevance. Algolia searches one index at a time, it doesn’t perform cross-index searches. Searching two indices at once produces two sets of results, each with their own internal relevance configuration. Algolia doesn’t merge these results and trying to do this yourself would break the relevance. That’s because combining Algolia’s results after a search requires understanding and re-implementing Algolia’s ranking algorithm. You would invariably be undoing the work that Algolia does for you.

It doesn’t mean that there are no reasons for having multiple indices. Yet, splitting data per entity isn’t a relevant use case.

색인은 레코드의 모음입니다. 검색을 수행할 때 알고리아 인덱스의 기록을 살펴봅니다.
관계형 데이터베이스에서 오는 중요한 원칙은 데이터를 다른 테이블에 분산시키는 것이다. 중복을 방지하기 위해 정보를 의미 있는 작은 단위로 나눕니다. 알골리아와 함께라면, 이 원칙들은 중요하지 않다. 앞서 살펴본 바와 같이 기록 구조와 데이터 계층 구조에서는 평평한 데이터가 검색에 가장 적합합니다. 이것은 index level에서도 적용됩니다. 여러 인덱스를 만들어 각 인덱스가 서로 다른 종류의 엔티티를 나타내는 테이블에 매핑하는 것이 합리적일 수 있습니다. 예를 들어 배우에서 영화를 분리하고 각각에 대한 인덱스를 만들 수 있습니다. 그러나 검색 목적에 부합하지 않을 수 있습니다. 사용자가 영화와 배우를 동시에 검색하여 동일한 결과에 나타나도록 하려면 어떻게 해야 합니까? 그럴 경우 단일 인덱스가 더 잘 작동합니다.
이것의 주된 이유는 관련성 때문입니다. 알골리아는 한 번에 하나의 인덱스를 검색하지만 교차 인덱스를 검색하지 않습니다. 두 개의 인덱스를 한 번에 검색하면 각각 고유한 내부 관련 구성이 있는 두 개의 결과 세트가 생성됩니다. 알골리아는 이 결과들을 병합하지 않으며 스스로 이것을 하려고 하면 관련성이 깨질 것이다. 검색 후 알골리아의 결과를 종합하면 알골리아의 순위결정 알고리즘을 이해하고 다시 구현해야 하기 때문이다. 당신은 언제나 알골리아가 당신을 위해 하는 일을 되돌리고 있을 것입니다.
index가 여러 개일 이유가 없다는 뜻은 아니다. 그러나 엔티티별로 데이터를 분할하는 것은 관련 사용 사례가 아닙니다.

결론 -> rdb 형식이 아니라 nosql형식의 데이터 폼으로 만들면 되는 듯. 

When to use multiple indices(multiple indice를 사용할 때)

Keeping separate indices tends to be a user interface question. If you want your search experience to display movies and actors separately, it’s better to use different indices.

Another case is when you want to showcase popular queries with an autocomplete menu, which you can do with Algolia’s Query Suggestions feature. For that, you need two indices: one for your content, and one for the common queries.

You also need to use separate indices when you want to let your users switch between different rankings, such as ascending or descending popularity. While you can’t dynamically change the ranking of an index, you can use replica indices with the same data and different ranking strategies.

You shouldn’t hesitate using several indices when necessary. The guiding principle is that a search is performed on a single index at a time. It means that every index must contain all the necessary records to retrieve exhaustive results. For two objects to appear in the same result set and be weighed against each other in the same relevance computation, they need to be in the same index.

 

별도의 인덱스를 유지하는 것은 사용자 인터페이스 문제인 경향이 있다. 검색 환경에서 영화와 배우를 별도로 표시하려면 다른 인덱스를 사용하는 것이 좋습니다.
또 다른 경우는 자동 완성 메뉴를 사용하여 인기 있는 쿼리를 보여주려는 경우인데, 이는 Algolia의 Query Progestions 기능으로 수행할 수 있습니다. 이렇게 하려면 내용에 대한 인덱스와 공통 쿼리에 대한 인덱스의 두 가지 인덱스가 필요합니다.
또한 사용자가 오름차순 또는 내림차순 인기와 같은 다른 순위 간에 전환할 수 있도록 하려면 별도의 색인을 사용해야 합니다. 색인의 순위를 동적으로 변경할 수는 없지만, 동일한 데이터와 다른 순위 전략을 가진 복제본 색인을 사용할 수 있습니다.
당신은 필요할 때 여러 index를 사용하는 것을 주저해서는 안 됩니다. 기본 원칙은 검색이 한 번에 하나의 인덱스에서 수행된다는 것입니다. 즉, 모든 인덱스는 모든 결과를 검색하기 위해 필요한 모든 레코드를 포함해야 합니다. 두 물체가 동일한 결과 집합에 나타나고 동일한 관련성 계산에서 서로에 대해 가중치를 측정하려면 두 물체가 동일한 지수에 있어야 한다.

Best formatting practices(최적의 형식 지정 방법)

Custom ranking(사용자 지정 순위)

High on the list of relevance tuning is custom ranking. When two records rank the same based on textual relevance, you want to tie break based on meaningful metrics, such as popularity, number of views, or number of sales. Including business metrics in your records is crucial to create a relevant search experience.

The documentation goes more in depth on the topic of custom ranking later on. Yet, it’s a good idea to start thinking about such metrics when fetching your data and structuring your records.

관련성 tuning 목록의 맨 위에는 사용자 지정 순위가 있습니다. 텍스트 관련성을 기준으로 두 레코드의 순위가 같으면 인기, 조회 수 또는 판매 수와 같은 의미 있는 메트릭을 기준으로 구분선을 묶을 수 있습니다. 관련 검색 환경을 구축하려면 비즈니스 메트릭을 당신의 records에 포함해야 합니다.
이 문서에서는 나중에 사용자 지정 순위 지정에 대해 자세히 설명합니다. 그러나 데이터를 가져오고 기록을 구성할 때는 이러한 메트릭스에 대해 생각해 보는 것이 좋습니다.

Filters and facets(필터 및 패싯)

Including attributes for filtering and faceting helps with relevance, because it helps users refine their search and narrow down results. While you can rely on existing categories from your data, you can also reuse your searchable or ranking data to create new filters and facets. Going back to the movies example, you can leverage numeric attributes like year to display a range filter on the front end, or string attributes like country to refine movies by country.

A good rule of thumb is to add attributes based on what your end users want to fine-tune their search with. If you’re selling movies online, useful categories include distribution system (DVD, Blu-Ray, Video on Demand, etc.) or content rating (PG, PG-13, etc.) If you have a movie reviews website, users likely want to refine on review score or popularity.

 

필터링 및 패싱 속성을 포함하면 사용자가 검색을 세분화하고 결과를 좁히는 데 도움이 되기 때문에 관련성에 도움이 됩니다. 데이터의 기존 카테고리에 의존할 수도 있지만 검색 가능 또는 순위 지정 데이터를 재사용하여 새 필터 및 패싯을 만들 수도 있습니다. 동영상 예제로 돌아가 연도와 같은 숫자 속성을 활용하여 전면 끝에 범위 필터를 표시하거나 국가와 같은 문자열 속성을 활용하여 국가별로 동영상을 세분화할 수 있습니다.
최종 사용자가 검색을 세부적으로 조정하려는 항목에 따라 속성을 추가하는 것이 좋습니다. 온라인으로 영화를 판매하는 경우 유용한 범주에는 배급 시스템(DVD, Blu-Ray, 주문형 비디오 등) 또는 콘텐츠 등급(PG, PG-13 등)이 포함됩니다. 영화 리뷰 웹사이트가 있다면, 사용자들은 리뷰 점수나 인기도를 다듬고 싶어할 것이다.

Advanced data formatting(고급 데이터 형식 지정)

While Algolia provides a vast collection of settings to help with relevance, many of these work in combination with how you format your content. Examples of this are whether to use one or several attributes for a single piece of information, include long or short descriptions (or both), repeat the same words in the title and description, round custom ranking attributes, etc.

Algolia는 관련성에 도움이 되는 방대한 설정 컬렉션을 제공하지만 이러한 설정 중 대부분은 콘텐츠 형식 지정 방식과 함께 작동합니다. 예를 들어 단일 정보에 하나 또는 여러 속성을 사용할지, 긴 설명 또는 짧은 설명(또는 둘 다 포함), 제목과 설명에 동일한 단어를 반복할지, 라운드 사용자 지정 순위 속성 등이 있습니다.