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

Data Sanitization(데이터 검사)

https://www.algolia.com/doc/guides/sending-and-managing-data/prepare-your-data/in-depth/data-sanitization/

Data sanitization | Algolia

Algolia accepts all data, without any alteration. Same goes with the response, Algolia returns all data in your index as is. For example, it includes HTML and XML tags, along with their properties.

However, Algolia’s search algorithm ignores HTML and XML. Users can’t search tag content.

For example, Algolia can save a record that contains the HTML tag <strong>.

알골리아는 아무런 변경 없이 모든 데이터를 받아들인다. 응답도 마찬가지이며, Algolia는 당신의 인덱스에 있는 모든 데이터를 있는 그대로 반환합니다. 예를 들어 HTML 및 XML 태그와 해당 속성을 포함합니다.
그러나 알골리아의 검색 알고리즘은 HTML과 XML을 무시하며 사용자는 태그 콘텐츠를 검색할 수 없습니다.
예를 들어, 앨골리아는 HTML 태그 <strong>을 포함하는 레코드를 저장할 수 있다.

 

{
  "description": "She is amazingly <strong>powerful</strong>, deeply visionary."
}

 

Yet, because the engine strips tags during search, searching for the word “strong” wouldn’t return this record.

Some characters are systematically removed, not escaped, from the APIs response:

• Control characters (U+0000 to U+001F)
• Delete (U+007F)

그러나 검색 중에 엔진이 태그를 삭제하기 때문에 "strong"이라는 단어를 검색해도 이 기록이 반환되지 않습니다.
일부 문자는 API 응답에서 이스케이프가 아닌 체계적으로 제거됩니다.
제어 문자(U+0000 ~ U+001F)
삭제(U+007F)

Cleaning your indices(인덱스 청소)

Since Algolia doesn’t sanitize your data and returns it as is, you need to manage sanitization yourself. Otherwise, you run the risk of an cross-site scripting (XSS) attack.

To avoid it, you have two options for escaping or stripping dangerous characters: doing it before indexing, or when displaying results.

Algolia는 데이터를 삭제하지 않고 그대로 반환하기 때문에 사용자가 직접 검사 관리를 해야 합니다. 그렇지 않으면 사이트 간 스크립팅(XSS) 공격의 위험이 있습니다.
위험한 문자를 회피하거나하거나 stripping하는 두 가지 옵션(인덱싱을 하기 전 또는 결과를 표시할 때)이 있습니다.

Cleaning your users’ search input(유저 검색 input 청소)

It’s also essential for you to sanitize what users type in the search input. Any HTML or code they may enter in the search bar exposes you to an XSS attack because Algolia sends the query back in the API response. You should escape or strip tags and code before displaying them.

또한 사용자가 검색 입력에 입력하는 내용을 소독하는 것이 중요합니다. Algolia가 API 응답에서 쿼리를 다시 보내기 때문에 그들이 검색란에 입력할 수 있는 HTML이나 코드는 당신을 XSS 공격에 노출시킨다. 태그와 코드를 표시하기 전에 이스케이프하거나 제거해야 합니다.

 

 

Data, Record Size, and Usage Limits(데이터, 레코드 사이즈, 사용 한도)

https://www.algolia.com/doc/guides/sending-and-managing-data/prepare-your-data/in-depth/index-and-records-size-and-usage-limitations/

Data, record size, and usage limits | Algolia

 

Size limits

Record size limits

Records can’t go beyond a certain size limit. This limit might depend on your plan—see the Algolia pricing page for more details. If you try to index a record that exceeds the limit, Algolia returns the Record is too big error.

There are techniques to help you break up your records into smaller ones if needed.

 

Records는 일정한 크기 제한을 초과할 수 없습니다. 이 한도는 plan에 따라 달라질 수 있습니다. 자세한 내용은 Algolia 가격 페이지를 참조하십시오. 제한을 초과하는 레코드를 인덱싱하려고 하면 레코드가 너무 큰 오류를 반환합니다.
필요한 경우 records를 더 작은 것으로 나누는 데 도움이 되는 기술들이 있습니다.

Index size limits(인덱스 크기 제한)

You only need to worry about index size if your application runs on dedicated hardware—that is, if your plan has the Single Tenancy add-on. Though there is no strict upper limit to an index’s size, you should keep your indices’ total size smaller than 102 GB. This represents 80% of the RAM capacity (128 GB) of dedicated servers, which leaves 20% of the RAM capacity to handle your indexing tasks. If the index size exceeds the 128 GB capacity, performance degrades severely: data swaps back and forth between temporary and permanent memory, which is a costly operation.

There is no limit on the number of records an index can have, only on the memory capacity of the hardware.

 

application이 지정된 하드웨어에서 실행되는 경우, 즉 plan에 Single Tenancy 추가 기능이 있는 경우에만 인덱스 크기를 걱정하면 됩니다. index 크기에 엄격한 상한은 없지만 인덱스의 총 크기를 102GB 미만으로 유지해야 합니다. 이는 전용 서버의 RAM 용량(128GB) 중 80%를 차지하므로 인덱싱 작업을 처리할 RAM 용량의 20%가 남습니다. 인덱스 크기가 128GB 용량을 초과할 경우 성능이 심각하게 저하됩니다. 즉, 임시 메모리와 영구 메모리 간에 데이터를 교환하려면 비용이 많이 듭니다.
인덱스가 가질 수 있는 레코드의 수에는 제한이 없으며 하드웨어의 메모리 용량에만 제한이 있습니다.

 

 

Indexing usage limits(인덱싱 사용 제한)

Maximum indexing operations(인덱싱 최대 사용)

Algolia counts the number of operations performed every month. When you hit your plan’s limit, you’re charged for the extra operations, based on your plan’s over-quota pricing.

알고리아는 매달 수행되는 작업의 수를 세고 있다. plan의 한계에 도달하면 계획의 초과 쿼터 가격에 따라 추가 작업에 대한 비용이 청구됩니다.

 

Indexing rate limit(인덱싱 최대 사용)

Algolia delays or rejects indexing operations whenever a server is overloaded. If Algolia determines that indexing operations can negatively impact search requests, it takes action to favor search over indexing. This rate limit exists to protect the server’s search capacity.

Algolia는 서버가 오버로드될 때마다 인덱싱 작업을 지연시키거나 거부합니다. 인덱싱 작업이 검색 요청에 부정적인 영향을 미칠 수 있다고 판단되는 경우 인덱싱보다 검색을 선호하는 조치를 취합니다. 이 속도 제한은 서버의 검색 용량을 보호하기 위해 존재합니다.

Query usage(쿼리 사용)

Algolia counts a search operation whenever you perform a search. In search-as-you-type implementations, this happens on every keystroke. If you’re querying several indices at each keystroke, then one keystroke triggers as many operations as queried indices, unless you use the multipleQueries method to do this.

Algolia는 검색을 수행할 때마다 검색 작업을 카운트합니다. 유형별 검색 구현에서는 모든 키 입력에서 이 작업이 수행됩니다. 각 키 입력에서 여러 인덱스를 쿼리하는 경우 다중 쿼리 방법을 사용하지 않는 한 한 한 번의 키 입력이 쿼리된 인덱스만큼 작업을 트리거합니다.