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

Handling Data Relationships

When you want to index relational data into Algolia, deciding on how to structure it can be a head-scratcher. Algolia is schemaless, so there are no right or wrong answers: it’s all about what search experience you want to create.

Imagine you’re developing a marketplace for third-parties to sell second-hand games. There are many ways you could build your search experience:

• you could display sellers and their full game catalogs,
• you could display games titles and a list of people who sell them,
• or you could display classified ads, ranked by business relevance (seller’s popularity, etc.)

Depending on the experience, you need to represent data relationships differently.

The good news is, Algolia doesn’t impose a data schema. You can organize your data the way you want. Therefore, depending on what you want to achieve, you can rearrange your data as you see fit.

 

관계형 데이터를 Algolia로 인덱싱하려는 경우 해당 데이터를 구조화하는 방법을 결정하는 것이 헤드 스크래처가 될 수 있습니다. 알골리아는 도식적이기 때문에 정답과 오답은 없습니다. 즉, 여러분이 어떤 검색 경험을 만들고 싶은지에 대한 것입니다.
당신이 타사에서 중고 게임을 판매할 수 있는 시장을 개발하고 있다고 상상해 보세요. 다음과 같은 다양한 방법으로 검색 환경을 구축할 수 있습니다.
-당신은 판매자와 그들의 전체 게임 카탈로그를 보여줄 수 있다.
-당신은 게임 타이틀과 그것들을 판매하는 사람들의 목록을 표시할 수 있다.
-또는 비즈니스 관련성(판매자의 인기 등)에 따라 순위가 매겨진 광고를 표시할 수 있습니다.
경험에 따라 데이터 관계를 다르게 표현해야 합니다.
좋은 소식은 알골리아는 데이터 스키마를 강요하지 않는다는 것입니다. 원하는 방식으로 데이터를 구성할 수 있습니다. 따라서 원하는 작업에 따라 적합하다고 판단되는 대로 데이터를 재정렬할 수 있습니다.

Data source

When you’re fetching from a relational database like as MySQL, you usually have one entity per table and join tables for many-to-many mappings. After making a JOIN request, serialized data might look like this:

MySQL과 같은 관계형 데이터베이스에서 가져오는 경우 일반적으로 테이블당 하나의 엔티티를 가지고 다대다 매핑을 위해 테이블을 조인합니다. JOIN 요청을 한 후 직렬화된 데이터는 다음과 같을 수 있습니다.

Displaying sellers and their catalog(판매자와 카탈로그 보여주기)

A nested data structure would work well to create a search experience where you would display a list of sellers and their associated games.

From there, you could streamline the data by removing unnecessary attributes, and index it as follows:

내제 데이터 구조는 판매자 및 관련 게임 목록을 표시하는 검색 환경을 만드는 데 적합합니다.
여기서 불필요한 특성을 제거하여 데이터를 간소화하고 다음과 같이 인덱싱할 수 있습니다.

Searchable attributes

This experience focuses on sellers, which means you might want to search seller data in priority. For example, when a user searches for “mass effect”, you may want seller Mass Effect Fan to show up before sellers who sell Mass Effect 3, even if Mass Effect Fan doesn’t sell this game. To do so, you can create an order of priority in your searchableAttributes, by setting name first and gamessecond.

이 경험은 셀러에 초점을 맞추고 있으므로 셀러 데이터를 우선적으로 검색하는 것이 좋습니다. 예를 들어 사용자가 '매스 이펙트'를 검색할 때 매스 이펙트 팬이 이 게임을 판매하지 않더라도 매스 이펙트 3을 판매하는 셀러 앞에 매스 이펙트 팬이 나타나길 원할 수 있다. 이렇게 하려면 searchableAttributes에서 이름을 먼저 설정하고 gamessecond를 설정하여 우선 순위 순서를 만들 수 있습니다.

Displaying game titles and their sellers(게임 제목과 판매자 보여주기)

You can use the same structure to create a search experience where you would display a list of games and their associated sellers.

To achieve this, all you would need to do is to reverse the relationship: instead of nesting games per seller, you would nest sellers per game.

 

동일한 구조를 사용하여 게임 및 관련 판매자 목록을 표시할 수 있는 검색 환경을 만들 수 있습니다.
이를 위해서는 관계를 되돌리기만 하면 됩니다: 판매자에게 각각의 게임을 내포하는 대신 게임마다 판매자를 내포를 할 수 있습니다.

 

 

Searchable attributes

This experience focuses on games, meaning you might want to search game data in priority. For example, when a user searches for “mass effect”, you may want game Mass Effect 3 to show up before seller Mass Effect Fan, especially if they don’t sell that game. For this, you can create an order of priority in your searchableAttributes, by setting name first and sellers.name second.

이 경험은 게임에 중점을 두므로 게임 데이터를 우선적으로 검색할 수 있습니다. 예를 들어, 사용자가 "매스 이펙트"를 검색할 때, 특히 게임을 판매하지 않는 경우, 매스 이펙트 팬 앞에 게임 매스 이펙트 3이 나타나기를 원할 수 있습니다. 이렇게 하려면 이름을 먼저 설정하고 sellers.name을 두 번째로 설정하여 searchableAttributes에서 우선 순위 순서를 만들 수 있습니다.

 

Displaying classified ads ranked by business relevance(사업 연관성으로 ranked 된 광고를 분류하여 보여주기)

The first two experiences focus on exhaustiveness. No matter what the user is looking for, they should get all possible options (all sellers per game or all games per seller). Another approach to building search is to be relevance-oriented: instead of showing all possibilities, you only show the best ones.

For example, if users search for “grand theft auto”, they may not need to see all classified ads for Grand Theft Auto V. Instead, you could only show them the ones from the most popular sellers.

In this case, you need to split your data and use a flat structure.

 

처음 두 경험은 철저함에 초점을 맞추고 있습니다. 사용자가 무엇을 찾든 간에 가능한 모든 옵션(게임당 모든 셀러 또는 셀러당 모든 게임)을 얻어야 합니다. 검색을 구축하는 또 다른 방법은 관련성 중심입니다. 모든 가능성을 보여주는 대신 가장 좋은 가능성만 보여주는 것입니다.
예를 들어, 사용자가 "그랜드 테프트 오토"를 검색하면 그랜드 테프트 오토 V의 모든 기밀 광고를 볼 필요가 없을 수 있다. 대신, 당신은 가장 인기 있는 판매자의 것만 보여줄 수 있습니다.
이 경우 데이터를 분할하여 평평한 구조를 사용해야 합니다.(실제 문서를 찾아보면 평평한 구조가 무엇인지 이해가 감)

 

 

By breaking up games by seller, you can add more granular popularity attributes to each record. This way, you ensure that the game with the best seller ranks better by leveraging the customRanking attribute.

This structure involves data duplication, so you can use Algolia’s distinct feature to de-duplicate records on game_title.

판매자별로 게임을 나누면 각 레코드에 더 세분화된 인기 속성을 추가할 수 있습니다. 이렇게 하면 customPring 특성을 활용하여 베스트 셀러가 있는 게임의 순위를 높일 수 있습니다.
이 구조는 데이터 중복을 포함하므로 game_title의 레코드 중복을 제거하기 위해 알골리아의 고유한 기능을 사용할 수 있습니다.

 

Searchable attributes

This experience focuses on classified ads, so you may want to prioritize searching on game data. For example, when a user searches for “mass effect”, you may want ads for game Mass Effect 3 to show up before ads by user Mass Effect Fan. For this, you can create an order of priority in your searchableAttributes, by setting game_title first and seller_name second.

이 경험은 분류된 광고에 초점이 맞추어져 있으므로 게임 데이터 검색을 우선시하는 것이 좋습니다. 예를 들어, 사용자가 "매스 효과"를 검색할 때 게임 매스 이펙트 3의 광고가 사용자 매스 이펙트 팬이 광고하기 전에 나타나기를 원할 수 있습니다. 이를 위해 game_title을 먼저 설정하고 seller_name을 다음으로 설정하여 searchableAttributes에서 우선 순위를 만들 수 있습니다.

Indexing Long Documents

 

If you want to index long documents with Algolia, you need to split them into smaller records. There’s a record size limit for performance reasons, meaning each new “chunk” should realistically be a paragraph or two.

Consider the case of a lengthy Wikipedia page with people adding new content all the time. If you indexed the whole page as a single record, you might hit the record size limit. Besides, it’s better to avoid indexing much content in a single record, as it degrades search relevance. A better approach is to create small, hierarchical objects based on the structure of the page.

This approach results in some redundancy of data. For that reason, you can leverage Algolia’s distinct feature to de-duplicate records based on a single attribute.

긴 문서를 알골리아로 인덱싱하려면 더 작은 레코드로 분할해야 합니다. 성능상의 이유로 기록적인 크기 제한이 있는데, 이는 각각의 새로운 "청크"가 현실적으로 한 두 단락이어야 한다는 것을 의미합니다.
사람들이 항상 새로운 내용을 추가하는 긴 위키피디아 페이지의 경우를 생각해보세요. 전체 페이지를 단일 레코드로 색인화한 경우 레코드 크기 제한에 도달할 수 있습니다. 또한 단일 레코드의 많은 콘텐츠를 인덱싱하는 것은 검색 관련성을 떨어뜨리기 때문에 피하는 것이 좋습니다. 더 나은 접근법은 페이지의 구조에 따라 작은 계층적 객체를 만드는 것입니다.
이 접근 방식은 데이터의 이중화를 초래한다. 따라서 Algolia의 고유한 기능을 사용하여 단일 속성을 기반으로 레코드 중복을 제거할 수 있습니다.

Modifying the data 데이터 수정

If you took the approach of creating one record per page, your dataset could look like this:

페이지당 하나의 레코드를 생성하는 방법을 사용할 경우 데이터 세트는 다음과 같이 나타날 수 있습니다.

 

코드 생략.....

 

 

This isn’t an optimal approach. As more and more people add new content, you might hit the record size limit. Also, this doesn’t make for a great search experience. Full pages contain too much text, which leads to returning irrelevant results when a user performs searches.

The right approach would be to split content into smaller records, by paragraph. With this strategy, a single page would result in several Algolia records. Here’s an example of what this might look like:

이것은 최적의 접근법이 아닙니다. 점점 더 많은 사람들이 새로운 콘텐츠를 추가함에 따라, 당신은 기록적인 크기 제한을 받을 수 있습니다. 또한, 이것은 좋은 검색 경험을 만들어 주지 않습니다. 전체 페이지에는 텍스트가 너무 많아 사용자가 검색을 수행할 때 관련 없는 결과가 반환됩니다.
올바른 접근법은 문단에 따라 내용을 더 작은 레코드로 나누는 것입니다. 이 전략으로, 한 페이지가 여러 개의 알골리아 기록을 남길 수 있었다. 다음은 이러한 상황을 보여주는 예입니다.

 

..코드 생략

 

With this approach, you’re eliminating the risk of ever hitting the record size limit. You’re also allowing for search results to be much more precise. Besides, you can handle the duplicate data with Algolia’s distinct feature by, for example, only retrieving one result per section.

이러한 접근 방식을 통해 기록적인 크기 제한에 도달하는 위험을 제거할 수 있습니다. 또한 검색 결과를 훨씬 더 정확하게 만들 수 있습니다. 또한, 예를 들어 섹션당 하나의 결과만 검색하여 알골리아의 고유한 기능으로 중복 데이터를 처리할 수 있습니다.

 

Enabling the distinct feature(고유 기능 사용)

Using the API

At indexing time

To use distinct you first need to set section as attributeForDistinct during indexing time. Then, you can set distinct to true to de-duplicate your results. Note that setting distinct at indexing time is optional. If you want to, you can set it at query time instead.

구별을 사용하려면 먼저 인덱싱 시간 동안 섹션을 attributeForDistinct로 설정해야 합니다. 그런 다음 distrent를 true로 설정하여 결과의 중복을 제거할 수 있습니다. 색인 작성 시 구분 설정은 선택사항입니다. 원하는 경우 쿼리 시간에 대신 설정할 수 있습니다.

 

At query time

Once you’ve set attributeForDistinct, you can enable distinct by setting it to true. Note that you can set distinct to true or 1 interchangeably.

index.search('query', {
  distinct: true
}).then(({ hits }) => {
  console.log(hits);
});

 

Using the dashboard(대시보드 사용하기)

You can also set your attribute for distinct and enable distinct in your Algolia dashboard.

• Go to your dashboard, select the Search product and then select your index.
• Click the Configuration tab.
• In the Search behavior section, select Deduplication and Grouping.
• Set the Distinct dropdown to true.
• Select your attribute in the Attribute for Distinct dropdown.
• Don’t forget to save your changes.

고유 속성을 설정하고 Algolia 대시보드에서 고유 속성을 활성화할 수도 있습니다.
-대시보드로 이동하여 Search product를 선택한 다음 인덱스를 선택합니다.
-구성 탭을 클릭합니다.
-Search behavior 섹션에서 중복 제거 및 그룹화를 선택합니다.
-Distinct 드롭다운을 true로 설정합니다.
-Attribute for Distinct드롭다운에서 속성을 선택합니다.
-변경 사항을 저장하는 것을 잊지 마십시오.