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

Manage Your Indices

 

https://www.algolia.com/doc/guides/sending-and-managing-data/manage-your-indices/

Manage your indices | Algolia

 

Once you’ve sent your data to Algolia, it resides in indices. You can rename indices, copy them within the same or across different applications, clear them, and delete them, either from the Algolia dashboard or using an API client.

알고리아로 데이터를 전송하면 인덱스에 저장됩니다. Algolia 대시보드에서 또는 API 클라이언트를 사용하여 인덱스의 이름을 변경하고, 동일한 응용 프로그램 내에서 또는 다른 응용 프로그램에서 인덱스를 복사하고, 지우고, 삭제할 수 있습니다.

 

 

 

Replicating an index(인덱스 복제)

By design, Algolia allows one ranking formula per index. If you want to offer different rankings for the same data, use replica indices.

Replica indices let you replicate an index’s data (the primary) into other indices (the replicas). Replicas have the same records as their primary index, and Algolia automatically synchronizes data changes for you. Every time you add, update, or delete records in your primary index, it also updates its replicas.

When you create a replica, it starts as an exact copy of its primary index: they have the same data and the same settings. While you can’t change a replica index’s data, you can change its settings. It allows you to provide different sorts for the same data, run A/B tests, experiment with new settings, etc.

 

설계상 알고리아는 index당 하나의 순위 공식을 허용한다. 동일한 데이터에 대해 다른 순위를 제공하려면 복제본 index을 사용하십시오.
복제본 인덱스를 사용하면 인덱스의 데이터(주)를 다른 인덱스(복제본)로 복제할 수 있습니다. 복제본은 기본 색인과 동일한 레코드를 가지고 있으며, Algolia는 자동으로 데이터 변경사항을 동기화합니다. 기본 색인의 레코드를 추가, 업데이트 또는 삭제할 때마다 복제본도 업데이트됩니다.
복제본을 작성할 때 복제본은 기본 색인의 정확한 복사본으로 시작됩니다. 즉, 복제본은 동일한 데이터와 동일한 설정을 가집니다. 복제본 색인의 데이터는 변경할 수 없지만, 복제본 색인의 설정은 변경할 수 있습니다. 동일한 데이터에 대해 서로 다른 정렬을 제공하고, A/B 검정을 실행하고, 새로운 설정을 실험하는 등의 작업을 수행할 수 있습니다.

 

 

 

Replicas for sorting(정렬을 위한 복제본)

The primary use case for replicas is to create alternative sorts. Whenever you want to offer different sorting options for the same data (for example, from lowest to highest price), you need to create replicas with different ranking settings.

복제본의 주요 사용 사례는 대체 정렬 작성입니다. 동일한 데이터에 대해 다른 정렬 선택사항(예: 최저 가격에서 최고 가격)을 제공하려면, 다른 순위 설정으로 복제본을 작성해야 합니다.

Algolia provides two types of sorting:

• Exhaustive or hard sorting
• Relevant sort

알골리아는 두 가지 종류의 정렬을 제공한다.
-전체 또는 하드 정렬
-관련 정렬

 

Your use case determines which is a better fit.

어떤 것이 더 적합한지는 사용 사례에 따라 결정됩니다.

 

 

Exhaustive sorting strategy(철저한 정렬 전략)

Exhaustive sorting is a “strict” strategy because it re-orders all results based on attributes. It’s intended for use cases that require exhaustivity or where relevance isn’t key, like for an inventory app or a database. Exhaustive sorting uses standard replicas.

철저한 정렬은 속성을 기준으로 모든 결과의 순서를 다시 정하기 때문에 "엄격한" 전략입니다. 인벤토리 앱이나 데이터베이스와 같이 모든 기능이 필요하거나 관련성이 중요하지 않은 사용 사례를 대상으로 합니다. 전체 정렬은 표준 복제본을 사용합니다.

Relevant sorting strategy(관련 정렬 전략)

Relevant sorting only reorders relevant results. This behavior is the preferred sorting experience for ecommerce, marketplace, and media content discovery. Relevant sorting uses virtual replicas.

관련 정렬은 관련 결과의 순서만 변경합니다. 이 동작은 전자 상거래, 마켓플레이스 및 미디어 콘텐츠 검색에 선호되는 정렬 경험입니다. 관련 정렬은 가상 복제본을 사용합니다.

 

 

Replicas for testing(테스트용 복제본)

Another use case for replica indices is testing. You can create a replica for pre-production testing (user acceptance, quality assurance), to experiment with different settings, or to perform A/B testing. If the parameters you’re testing use virtual replicas this will save space but if you want separate indices for separate environments, you should use standard replicas.

복제본 인덱스의 또 다른 사용 사례는 테스트입니다. 사전 프로덕션 테스트(사용자 승인, 품질 보증)를 위해 복제본을 작성하거나 다른 설정을 실험하거나 A/B 테스트를 수행할 수 있습니다. 테스트할 매개변수가 가상 복제본을 사용할 경우 공간이 절약되지만, 별도의 환경에 대해 별도의 색인을 원할 경우 표준 복제본을 사용해야 합니다.

Managing replica indices(복제본 index 관리하기)

A replica is no different from any other kind of index, which means you can rename, copy, or delete it. When you rename or copy a replica, you detach it from its primary index. The replica becomes a primary index itself and is no longer synchronized with its former primary index.

복제본은 다른 종류의 색인과 다르지 않으므로, 복제본의 이름을 바꾸거나 복사 또는 삭제할 수 있습니다. 복제본의 이름을 바꾸거나 복제본을 복사할 때 복제본의 기본 색인에서 분리합니다. 이름을 바꾼 복제본은 기본 인덱스가 되고 더 이상 이전의 기본 인덱스와 동기화되지 않습니다.

If you want to reattach an index as a replica, you need to follow the same steps as creating a replicafor the first time. In other words, you need to declare the index as a replica of the primary, either through the dashboard or API using the replicas setting.

색인을 복제본으로 다시 첨부하려면 처음 복제본을 작성할 때와 동일한 단계를 수행해야 합니다. 즉, 대시보드 또는 복제본 설정을 사용하는 API를 통해 인덱스를 Primary의 복제본으로 선언해야 합니다.

If you delete a primary index, you need to delete its replicas manually. Otherwise, they remain on your application as primary indices: you can change their data, and create replicas from them.

주 인덱스를 삭제할 경우 주 인덱스의 복제본을 수동으로 삭제해야 합니다. 그렇지 않은 경우, 데이터는 응용프로그램에 기본 색인으로 남아 있으므로, 데이터를 변경하고 복제본을 작성할 수 있습니다.

Standard replicas, unlike virtual replicas, take up the same disk space as their primary index. They also add to your record count. To keep your application at a reasonable size, make sure to remove unused replicas. You shouldn’t exceed ten replicas unless necessary. The higher the number of replicas, the longer the total indexing update time.

가상 복제본과 달리 표준 복제본은 기본 색인과 동일한 디스크 공간을 차지합니다. 또한 레코드 수에도 추가됩니다. 응용프로그램을 적당한 크기로 유지하려면 사용하지 않는 복제본을 삭제해야 합니다. 필요 없는 한 복제품을 10개 초과해서는 안 됩니다. 복제본 수가 많을수록 전체 색인화 업데이트 시간이 길어집니다.

 

 

 

Indices and analytics(인덱스와 분석)

Algolia stores analytics data on dedicated servers, separate from the indices. Algolia collects Search and Click and Conversion Analytics asynchronously, in parallel to search processing. This way, gathering analytics never impacts the speed of search.

There’s no hard link between your indices and their analytics. They’re two different sets of data stored on separate servers. Consequently, index management methods such as copying, moving, and deleting have no effect on analytics data. For example, if you delete an index, it doesn’t remove its associated analytics data.

Analytics data is referred to by the name of its index. This reference never changes.

 

알고리아는 인덱스와는 별개로 분석 데이터를 전용 서버에 저장합니다. 알고리아는 검색 처리와 병행하여 검색 및 클릭 및 변환 분석을 비동기적으로 수집한다. 이렇게 하면 분석 수집이 검색 속도에 영향을 미치지 않습니다.
당신의 인덱스와 그들의 분석 사이에는 명확한 연관성이 없습니다. 서로 다른 서버에 저장된 두 개의 데이터 집합입니다. 따라서 복사, 이동 및 삭제와 같은 인덱스 관리 방법은 분석 데이터에 영향을 미치지 않습니다. 예를 들어 인덱스를 삭제해도 관련 분석 데이터는 제거되지 않습니다.
분석 데이터는 인덱스 이름으로 참조됩니다. 이 참조는 절대 변하지 않습니다.

Renaming an index(index 이름 바꾸기)

Changing the name of an index doesn’t change the name of the index’s analytics. The new name references new analytics—the old and new analytics aren’t merged. If you want to preserve an index’s analytics history, you need to keep using the old name.

Conversely, this mechanism ensures that you never lose analytics data when you atomically reindex your records.

인덱스 이름을 변경해도 인덱스의 analytics 이름이 변경되지 않습니다. 새로운 이름은 기존 analytics과 새 analytics이 병합되지 않는 새로운 analytics을 지칭합니다. 인덱스의 analytics 기록을 보존하려면 이전 이름을 계속 사용해야 합니다.
반대로, 이 메커니즘은 기록을 원자적으로 다시 인덱싱할 때 analytics 데이터가 손실되지 않도록 보장합니다.

Deleting an index(Index 삭제)

When you delete an index, it doesn’t delete the associated analytics data. It remains available under the deleted index’s name, allowing you to export it using the Analytics REST API.

인덱스를 삭제해도 관련 analytics 데이터는 삭제되지 않습니다. 삭제된 인덱스 이름으로 계속 사용할 수 있으므로 Analytics REST API를 사용하여 내보낼 수 있습니다.

Copying an index(인덱스 복사)

When you copy an index, it doesn’t copy the associated analytics data. The new index starts fresh. Be careful when using the copyIndex method to overwrite an existing index, as it associates the existing analytics data of the overwritten index with the new one.

인덱스를 복사할 때 관련 analytics 데이터는 복사되지 않습니다. 새 색인이 새로 시작됩니다. 복사본을 사용할 때 주의하십시오.덮어쓴 인덱스의 기존 analytics 데이터를 새 인덱스와 연결하므로 기존 인덱스를 덮어쓰는 인덱스 방법입니다.