+7 495 142 04 22
welcome@gals.software
© 2021 Gals Software
welcome@gals.software
© 2021 Gals Software
Политика конфиденциальности персональных данных
Общество с ограниченной ответственностью "ГАЛС СОФТВЭР"
ИНН: 5047195298
ОГРН: 1175029006404
Настоящая Политика конфиденциальности персональных данных (далее – Политика конфиденциальности) действует в отношении всей информации, расположенной на доменном имени gals.software, которую можно получить о Пользователе во время использования данного сайта, программ и продуктов.
1. ОПРЕДЕЛЕНИЕ ТЕРМИНОВ
1.1. В настоящей Политике конфиденциальности используются следующие термины:
1.1.1. «Администрация сайта gals.software (далее – Администрация сайта, Оператор)» – ООО "ГАЛС СОФТВЭР", которое организуют и (или) осуществляет обработку персональных данных, а также определяет цели обработки персональных данных, состав персональных данных, подлежащих обработке, действия (операции), совершаемые с персональными данными.
1.1.2. «Персональные данные» – любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу (субъекту персональных данных).
1.1.3. «Обработка персональных данных» – любое действие (операция) или совокупность действий (операций), совершаемых с использованием средств автоматизации или без использования таких средств с персональными данными, включая сбор, запись, систематизацию, накопление, хранение, уточнение (обновление, изменение), извлечение, использование, передачу (распространение, предоставление, доступ), обезличивание, блокирование, удаление, уничтожение персональных данных.
1.1.4. «Конфиденциальность персональных данных» – обязательное для соблюдения Оператором или иным получившим доступ к персональным данным лицом требование не допускать их распространения без согласия субъекта персональных данных или наличия иного законного основания.
1.1.5. «Пользователь сайта (далее Пользователь, Субъект персональных данных)» – лицо, имеющее доступ к сайту, посредством сети Интернет и использующее сайт.
1.1.6. "Форма обратной связи" - html-форма, которую Пользователь заполняет своими персональными данными на сайте.
1.1.7. "Подписка" - html-форма, которую Пользователь заполняет на сайте, для получения рассылок.
1.1.8. "Рассылка" - электронные письма с информацией об услугах/работах, направляемые Пользователю на указанный им адрес электронной почты.
1.1.9. «IP-адрес» – уникальный сетевой адрес узла в компьютерной сети, построенной по протоколу IP.
1.1.10. «Блокирование персональных данных» – временное прекращение обработки персональных данных (за исключением случаев, если обработка необходима для уточнения персональных данных).
1.1.11. «Распространение персональных данных» – действия, направленные на раскрытие персональных данных неопределенному кругу лиц.
1.1.12. «Предоставление персональных данных» – действия, направленные на раскрытие персональных данных определенному лицу или определенному кругу лиц.
2. ОБЩИЕ ПОЛОЖЕНИЯ
2.1. Заполнение Пользователем формы обратной связи, подписки и отправка данных означает согласие Пользователя на обработку персональных данных, а также согласие с настоящей Политикой конфиденциальности и условиями обработки персональных данных Пользователя. Оформление отдельного согласия на обработку персональных данных Пользователя не требуется.
2.2. В случае несогласия с условиями Политики конфиденциальности Пользователь должен прекратить использование сайта.
2.3. Настоящая Политика конфиденциальности применяется только к сайту gals.software. Администрация сайта не контролирует и не несет ответственность за сайты третьих лиц, на которые Пользователь может перейти по ссылкам, доступным на сайтах.
2.4. Администрация сайта не проверяет достоверность персональных данных, предоставляемых Пользователем.
3. ПРЕДМЕТ ПОЛИТИКИ КОНФИДЕНЦИАЛЬНОСТИ
3.1. Настоящая Политика конфиденциальности устанавливает обязательства Администрации сайта по неразглашению и обеспечению режима защиты конфиденциальности персональных данных, которые Пользователь предоставляет при заполнении формы обратной связи, подписки на сайтах, а также для оформления заказов на услуги/работы.
3.2. Персональные данные, разрешённые к обработке в рамках настоящей Политики конфиденциальности, предоставляются Пользователем путём заполнения html-форм на сайте и включают в себя следующую информацию:
3.2.1. фамилию, имя, отчество Пользователя;
3.2.2. адрес электронной почты (e-mail);
3.2.3. домашний, рабочий, мобильный телефоны;
3.3. Любая иная персональная информация не оговоренная выше подлежит надежному хранению и нераспространению, за исключением случаев, предусмотренных в п.п. 5.2. и 5.3. настоящей Политики конфиденциальности.
4. ЦЕЛИ СБОРА ПЕРСОНАЛЬНЫХ ДАННЫХ ПОЛЬЗОВАТЕЛЕЙ
4.1. Персональные данные Пользователя Администрация сайта может использовать в целях:
4.1.1. Идентификации Пользователя для оформления заказа и (или) заключения Договоров оказания услуг/выполнения работ.
4.1.2. Установления с Пользователем обратной связи, включая направление уведомлений, запросов, касающихся использования сайта, оказания услуг, обработка запросов и заявок от Пользователя.
4.1.3. Предоставления Пользователю эффективной клиентской и технической поддержки при возникновении проблем связанных с использованием сайта.
4.1.4. Предоставления Пользователю специальных предложений, информации о ценах, новостной рассылки и иных сведений от имени Администрации сайта или от имени партнеров.
4.1.5. Осуществления рекламной деятельности.
4.1.6. Предоставления доступа Пользователю на сайты или сервисы партнеров с целью получения продуктов, обновлений и услуг.
5. СПОСОБЫ И СРОКИ ОБРАБОТКИ ПЕРСОНАЛЬНОЙ ИНФОРМАЦИИ
5.1. Обработка персональных данных Пользователя осуществляется не дольше срока, отвечающего целям обработки персональных данных, любым законным способом, в том числе в информационных системах персональных данных с использованием средств автоматизации или без использования таких средств.
5.2. Персональные данные Пользователя могут быть предоставлены уполномоченным органам государственной власти Российской Федерации только по основаниям и в порядке, установленным законодательством Российской Федерации.
5.3. При утрате или разглашении персональных данных Администрация сайта информирует Пользователя об утрате или разглашении персональных данных.
5.4. Администрация сайта принимает необходимые организационные и технические меры для защиты персональной информации Пользователя от неправомерного или случайного доступа, уничтожения, изменения, блокирования, копирования, распространения, а также от иных неправомерных действий третьих лиц.
5.5. Администрация сайта совместно с Пользователем принимает все необходимые меры по предотвращению убытков или иных отрицательных последствий, вызванных утратой или разглашением персональных данных Пользователя.
6. ОБЯЗАТЕЛЬСТВА СТОРОН
6.1. Пользователь обязан:
6.1.1. Предоставить информацию о персональных данных, необходимую для пользования сайтом.
6.1.2. Обновить, дополнить предоставленную информацию о персональных данных в случае изменения данной информации.
6.2. Администрация сайта обязана:
6.2.1. Использовать полученную информацию исключительно для целей, указанных в п. 4 настоящей Политики конфиденциальности.
6.2.2. Обеспечить хранение конфиденциальной информации в тайне, не разглашать без предварительного письменного разрешения Пользователя, а также не осуществлять продажу, обмен, опубликование, либо разглашение иными возможными способами переданных персональных данных Пользователя, за исключением п.п. 5.2. и 5.3. настоящей Политики Конфиденциальности.
6.2.3. Принимать меры предосторожности для защиты конфиденциальности персональных данных Пользователя согласно порядку, установленному законодательством РФ.
6.2.4. Осуществить блокирование персональных данных, относящихся к соответствующему Пользователю, с момента обращения или запроса Пользователя или его законного представителя либо уполномоченного органа по защите прав субъектов персональных данных на период проверки, в случае выявления недостоверных персональных данных или неправомерных действий.
7. ОТВЕТСТВЕННОСТЬ СТОРОН
7.1. Администрация сайта, не исполнившая свои обязательства, несёт ответственность за убытки, понесённые Пользователем в связи с неправомерным использованием персональных данных, в соответствии с законодательством Российской Федерации, за исключением случаев, предусмотренных п.п. 5.2., 5.3. и 7.2. настоящей Политики Конфиденциальности.
7.2. В случае утраты или разглашения персональных данных Администрация сайта не несёт ответственность, если данные персональные данные:
7.2.1. Стали публичным достоянием до их утраты или разглашения.
7.2.2. Были получены от третьей стороны до момента её получения Администрацией сайта.
7.2.3. Были разглашены с согласия Пользователя.
8. РАЗРЕШЕНИЕ СПОРОВ
8.1. До обращения в суд с иском по спорам, возникающим из отношений между Пользователем и Администрацией сайта, обязательным является предъявление претензии (письменного предложения о добровольном урегулировании спора).
8.2. Получатель претензии в течение 30 календарных дней со дня получения претензии, письменно уведомляет заявителя претензии о результатах рассмотрения претензии.
8.3. При недостижении соглашения спор будет передан на рассмотрение в судебный орган по месту нахождения Оператора, в соответствии с действующим законодательством Российской Федерации.
8.4. К настоящей Политике конфиденциальности и отношениям между Пользователем и Администрацией сайта применяется действующее законодательство Российской Федерации.
9. ДОПОЛНИТЕЛЬНЫЕ УСЛОВИЯ
9.1. Администрация сайта вправе вносить изменения в настоящую Политику конфиденциальности без согласия Пользователя.
9.2. Новая Политика конфиденциальности вступает в силу с момента ее размещения на сайте, если иное не предусмотрено новой редакцией Политики конфиденциальности.
9.3. Все предложения или вопросы по настоящей Политике конфиденциальности следует адресовать на адрес Оператора, указанный на сайте.
9.4. Действующая Политика конфиденциальности размещена на странице по адресу gals.software.
ИНН: 5047195298
ОГРН: 1175029006404
Настоящая Политика конфиденциальности персональных данных (далее – Политика конфиденциальности) действует в отношении всей информации, расположенной на доменном имени gals.software, которую можно получить о Пользователе во время использования данного сайта, программ и продуктов.
1. ОПРЕДЕЛЕНИЕ ТЕРМИНОВ
1.1. В настоящей Политике конфиденциальности используются следующие термины:
1.1.1. «Администрация сайта gals.software (далее – Администрация сайта, Оператор)» – ООО "ГАЛС СОФТВЭР", которое организуют и (или) осуществляет обработку персональных данных, а также определяет цели обработки персональных данных, состав персональных данных, подлежащих обработке, действия (операции), совершаемые с персональными данными.
1.1.2. «Персональные данные» – любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу (субъекту персональных данных).
1.1.3. «Обработка персональных данных» – любое действие (операция) или совокупность действий (операций), совершаемых с использованием средств автоматизации или без использования таких средств с персональными данными, включая сбор, запись, систематизацию, накопление, хранение, уточнение (обновление, изменение), извлечение, использование, передачу (распространение, предоставление, доступ), обезличивание, блокирование, удаление, уничтожение персональных данных.
1.1.4. «Конфиденциальность персональных данных» – обязательное для соблюдения Оператором или иным получившим доступ к персональным данным лицом требование не допускать их распространения без согласия субъекта персональных данных или наличия иного законного основания.
1.1.5. «Пользователь сайта (далее Пользователь, Субъект персональных данных)» – лицо, имеющее доступ к сайту, посредством сети Интернет и использующее сайт.
1.1.6. "Форма обратной связи" - html-форма, которую Пользователь заполняет своими персональными данными на сайте.
1.1.7. "Подписка" - html-форма, которую Пользователь заполняет на сайте, для получения рассылок.
1.1.8. "Рассылка" - электронные письма с информацией об услугах/работах, направляемые Пользователю на указанный им адрес электронной почты.
1.1.9. «IP-адрес» – уникальный сетевой адрес узла в компьютерной сети, построенной по протоколу IP.
1.1.10. «Блокирование персональных данных» – временное прекращение обработки персональных данных (за исключением случаев, если обработка необходима для уточнения персональных данных).
1.1.11. «Распространение персональных данных» – действия, направленные на раскрытие персональных данных неопределенному кругу лиц.
1.1.12. «Предоставление персональных данных» – действия, направленные на раскрытие персональных данных определенному лицу или определенному кругу лиц.
2. ОБЩИЕ ПОЛОЖЕНИЯ
2.1. Заполнение Пользователем формы обратной связи, подписки и отправка данных означает согласие Пользователя на обработку персональных данных, а также согласие с настоящей Политикой конфиденциальности и условиями обработки персональных данных Пользователя. Оформление отдельного согласия на обработку персональных данных Пользователя не требуется.
2.2. В случае несогласия с условиями Политики конфиденциальности Пользователь должен прекратить использование сайта.
2.3. Настоящая Политика конфиденциальности применяется только к сайту gals.software. Администрация сайта не контролирует и не несет ответственность за сайты третьих лиц, на которые Пользователь может перейти по ссылкам, доступным на сайтах.
2.4. Администрация сайта не проверяет достоверность персональных данных, предоставляемых Пользователем.
3. ПРЕДМЕТ ПОЛИТИКИ КОНФИДЕНЦИАЛЬНОСТИ
3.1. Настоящая Политика конфиденциальности устанавливает обязательства Администрации сайта по неразглашению и обеспечению режима защиты конфиденциальности персональных данных, которые Пользователь предоставляет при заполнении формы обратной связи, подписки на сайтах, а также для оформления заказов на услуги/работы.
3.2. Персональные данные, разрешённые к обработке в рамках настоящей Политики конфиденциальности, предоставляются Пользователем путём заполнения html-форм на сайте и включают в себя следующую информацию:
3.2.1. фамилию, имя, отчество Пользователя;
3.2.2. адрес электронной почты (e-mail);
3.2.3. домашний, рабочий, мобильный телефоны;
3.3. Любая иная персональная информация не оговоренная выше подлежит надежному хранению и нераспространению, за исключением случаев, предусмотренных в п.п. 5.2. и 5.3. настоящей Политики конфиденциальности.
4. ЦЕЛИ СБОРА ПЕРСОНАЛЬНЫХ ДАННЫХ ПОЛЬЗОВАТЕЛЕЙ
4.1. Персональные данные Пользователя Администрация сайта может использовать в целях:
4.1.1. Идентификации Пользователя для оформления заказа и (или) заключения Договоров оказания услуг/выполнения работ.
4.1.2. Установления с Пользователем обратной связи, включая направление уведомлений, запросов, касающихся использования сайта, оказания услуг, обработка запросов и заявок от Пользователя.
4.1.3. Предоставления Пользователю эффективной клиентской и технической поддержки при возникновении проблем связанных с использованием сайта.
4.1.4. Предоставления Пользователю специальных предложений, информации о ценах, новостной рассылки и иных сведений от имени Администрации сайта или от имени партнеров.
4.1.5. Осуществления рекламной деятельности.
4.1.6. Предоставления доступа Пользователю на сайты или сервисы партнеров с целью получения продуктов, обновлений и услуг.
5. СПОСОБЫ И СРОКИ ОБРАБОТКИ ПЕРСОНАЛЬНОЙ ИНФОРМАЦИИ
5.1. Обработка персональных данных Пользователя осуществляется не дольше срока, отвечающего целям обработки персональных данных, любым законным способом, в том числе в информационных системах персональных данных с использованием средств автоматизации или без использования таких средств.
5.2. Персональные данные Пользователя могут быть предоставлены уполномоченным органам государственной власти Российской Федерации только по основаниям и в порядке, установленным законодательством Российской Федерации.
5.3. При утрате или разглашении персональных данных Администрация сайта информирует Пользователя об утрате или разглашении персональных данных.
5.4. Администрация сайта принимает необходимые организационные и технические меры для защиты персональной информации Пользователя от неправомерного или случайного доступа, уничтожения, изменения, блокирования, копирования, распространения, а также от иных неправомерных действий третьих лиц.
5.5. Администрация сайта совместно с Пользователем принимает все необходимые меры по предотвращению убытков или иных отрицательных последствий, вызванных утратой или разглашением персональных данных Пользователя.
6. ОБЯЗАТЕЛЬСТВА СТОРОН
6.1. Пользователь обязан:
6.1.1. Предоставить информацию о персональных данных, необходимую для пользования сайтом.
6.1.2. Обновить, дополнить предоставленную информацию о персональных данных в случае изменения данной информации.
6.2. Администрация сайта обязана:
6.2.1. Использовать полученную информацию исключительно для целей, указанных в п. 4 настоящей Политики конфиденциальности.
6.2.2. Обеспечить хранение конфиденциальной информации в тайне, не разглашать без предварительного письменного разрешения Пользователя, а также не осуществлять продажу, обмен, опубликование, либо разглашение иными возможными способами переданных персональных данных Пользователя, за исключением п.п. 5.2. и 5.3. настоящей Политики Конфиденциальности.
6.2.3. Принимать меры предосторожности для защиты конфиденциальности персональных данных Пользователя согласно порядку, установленному законодательством РФ.
6.2.4. Осуществить блокирование персональных данных, относящихся к соответствующему Пользователю, с момента обращения или запроса Пользователя или его законного представителя либо уполномоченного органа по защите прав субъектов персональных данных на период проверки, в случае выявления недостоверных персональных данных или неправомерных действий.
7. ОТВЕТСТВЕННОСТЬ СТОРОН
7.1. Администрация сайта, не исполнившая свои обязательства, несёт ответственность за убытки, понесённые Пользователем в связи с неправомерным использованием персональных данных, в соответствии с законодательством Российской Федерации, за исключением случаев, предусмотренных п.п. 5.2., 5.3. и 7.2. настоящей Политики Конфиденциальности.
7.2. В случае утраты или разглашения персональных данных Администрация сайта не несёт ответственность, если данные персональные данные:
7.2.1. Стали публичным достоянием до их утраты или разглашения.
7.2.2. Были получены от третьей стороны до момента её получения Администрацией сайта.
7.2.3. Были разглашены с согласия Пользователя.
8. РАЗРЕШЕНИЕ СПОРОВ
8.1. До обращения в суд с иском по спорам, возникающим из отношений между Пользователем и Администрацией сайта, обязательным является предъявление претензии (письменного предложения о добровольном урегулировании спора).
8.2. Получатель претензии в течение 30 календарных дней со дня получения претензии, письменно уведомляет заявителя претензии о результатах рассмотрения претензии.
8.3. При недостижении соглашения спор будет передан на рассмотрение в судебный орган по месту нахождения Оператора, в соответствии с действующим законодательством Российской Федерации.
8.4. К настоящей Политике конфиденциальности и отношениям между Пользователем и Администрацией сайта применяется действующее законодательство Российской Федерации.
9. ДОПОЛНИТЕЛЬНЫЕ УСЛОВИЯ
9.1. Администрация сайта вправе вносить изменения в настоящую Политику конфиденциальности без согласия Пользователя.
9.2. Новая Политика конфиденциальности вступает в силу с момента ее размещения на сайте, если иное не предусмотрено новой редакцией Политики конфиденциальности.
9.3. Все предложения или вопросы по настоящей Политике конфиденциальности следует адресовать на адрес Оператора, указанный на сайте.
9.4. Действующая Политика конфиденциальности размещена на странице по адресу gals.software.
Elasticsearch
Как выбрать правильное количество и объём шардов индекса Elasticsearch
"Залог высокой производительности Elasticsearch —корректная настройка количества и объема шардов."
Индекс Elasticsearch состоит из одного или нескольких основных шардов, которые могут быть реплицированы для минимизации последствий аппаратных сбоев. Начиная с Elasticsearch 7, значение по умолчанию для количества первичных шардов на индекс — 1. В более ранних версиях по умолчанию было 5 первичных шардов. А вот количество реплик по умолчанию как было так и осталось равно 1. Как это ни странно, но некоторые заказчики, которых мне приходилось консультировать, оставляли эти значения по умолчанию. Если ваша цель выжать максимум производительности от железа, дефолтные значения стоит изменить.
У каждого индекса и сегмента есть накладные расходы, и, если данные будут распределены на слишком большое количество шардов, накладные расходы начнут оказывать значительное влияние на производительность. Кластер с избыточным количеством индексов или шардов будет страдать от овершардинга. Кластер с овершардингом будет менее эффективен при поиске, а в крайних случаях может работать нестабильно. В этой статье поговорим о том, как избежать всех этих ужасных последствий и возможностях кастомизации конфигурации индексов, чтобы у вашего кластера Elasticsearch было здоровое пищеварение.
Поиск оптимального количества шардов и их размера зависит от набора факторов. Эти факторы включают в себя: объем данных, формат использования, формат запросов, сложность документов и SLA. Может что-то ещё, но это не точно. Существует два основных подхода к поиску правильного размера сегмента:
У каждого индекса и сегмента есть накладные расходы, и, если данные будут распределены на слишком большое количество шардов, накладные расходы начнут оказывать значительное влияние на производительность. Кластер с избыточным количеством индексов или шардов будет страдать от овершардинга. Кластер с овершардингом будет менее эффективен при поиске, а в крайних случаях может работать нестабильно. В этой статье поговорим о том, как избежать всех этих ужасных последствий и возможностях кастомизации конфигурации индексов, чтобы у вашего кластера Elasticsearch было здоровое пищеварение.
Поиск оптимального количества шардов и их размера зависит от набора факторов. Эти факторы включают в себя: объем данных, формат использования, формат запросов, сложность документов и SLA. Может что-то ещё, но это не точно. Существует два основных подхода к поиску правильного размера сегмента:
- Бенчмаркинг — проведение экспериментов
- Общие рекомендации – следование общепринятым методам
How many shards should I have?
Well, it depends (evil giggles)...
Какая там польза от нескольких шардов при индексации
А пользы очень даже много. Шарды используются для распараллеливания работы над индексом. Когда вы отправляете запрос на индексацию списка документов, они будут разделены между всеми доступными первичными шардами.
Таким образом, если у вас есть 5 основных шардов и вы отправляете запрос со 100 документами, каждый шард проиндексирует по 20 документов. Как только все документы проиндексированы, ответ отправляется обратно клиенту. Затем может быть проиндексирован следующий пакет документов. Индексирование происходит быстрее, когда больше шардов, так как каждый документ хранится в единственном экземпляре на шарде. Если нужно быстрое получение данных, у вас должен быть как минимум один шард на каждую ноду кластера Elasticsearch. Ну, или можно иметь число шардов, которое без остатка делится на количество нод. Например, если есть 3 ноды в кластере, у вас должно быть 3, 6 или 9 шардов. Это важно. Если есть 3 ноды и вы решите использовать 4 основных шарда, то процесс индексации будет медленнее, чем при использовании 3 сегментов, потому что 1 нода (она же сервер) будет выполнять двойную работу, а две другие будут простаивать.
Таким образом, если у вас есть 5 основных шардов и вы отправляете запрос со 100 документами, каждый шард проиндексирует по 20 документов. Как только все документы проиндексированы, ответ отправляется обратно клиенту. Затем может быть проиндексирован следующий пакет документов. Индексирование происходит быстрее, когда больше шардов, так как каждый документ хранится в единственном экземпляре на шарде. Если нужно быстрое получение данных, у вас должен быть как минимум один шард на каждую ноду кластера Elasticsearch. Ну, или можно иметь число шардов, которое без остатка делится на количество нод. Например, если есть 3 ноды в кластере, у вас должно быть 3, 6 или 9 шардов. Это важно. Если есть 3 ноды и вы решите использовать 4 основных шарда, то процесс индексации будет медленнее, чем при использовании 3 сегментов, потому что 1 нода (она же сервер) будет выполнять двойную работу, а две другие будут простаивать.
Эмпирическое правило для быстрого индексирования: вы должны выбрать как минимум столько первичных шардов, сколько у вас есть нод в кластере, при условии, что количество нод данных соответствует вашим требованиям.
Какая там польза от нескольких шардов при поиске
Как работает распараллеливание для поиска? Каждый шард содержит только часть документов, это означает, что каждый сегмент содержит только частичный индекс. Можно думать об этом как о книге с несколькими томами — в каждом томе есть свой частичный индекс.
Когда вы отправляете поисковый запрос, узел, получивший запрос, действует как координирующая нода, которая затем ищет, какие шарды принадлежат этому индексу в соответствии с состоянием кластера. Затем координирующая нода отправит этот запрос всем обнаруженным шардам.
После этого каждый шард локально вычисляет список результатов с идентификаторами документов и оценками («фаза запроса»). Эти частичные результаты отправляются обратно на координирующую ноду, которая объединяет их в общий результат. Затем начинается вторая фаза («фаза выборки»), когда извлекается список документов. Если вы выберете размер по умолчанию 10, будет получено 10 документов. Фаза выборки также должна быть выполнена для всех шардов. Когда все документы возвращены, может быть выполнена некая постобработка, например, выделение (highlighting), чтобы затем весь ответ отправить обратно клиенту. Очевидно, что распараллеливание запроса сопряжено с некоторыми накладными расходами.
Когда вы отправляете поисковый запрос, узел, получивший запрос, действует как координирующая нода, которая затем ищет, какие шарды принадлежат этому индексу в соответствии с состоянием кластера. Затем координирующая нода отправит этот запрос всем обнаруженным шардам.
После этого каждый шард локально вычисляет список результатов с идентификаторами документов и оценками («фаза запроса»). Эти частичные результаты отправляются обратно на координирующую ноду, которая объединяет их в общий результат. Затем начинается вторая фаза («фаза выборки»), когда извлекается список документов. Если вы выберете размер по умолчанию 10, будет получено 10 документов. Фаза выборки также должна быть выполнена для всех шардов. Когда все документы возвращены, может быть выполнена некая постобработка, например, выделение (highlighting), чтобы затем весь ответ отправить обратно клиенту. Очевидно, что распараллеливание запроса сопряжено с некоторыми накладными расходами.
Поиск выполняется в одном потоке на шарду. Большинство поисковых запросов попадают в несколько шардов. Каждый шард выполняет поиск в одном потоке CPU. Хотя шард может выполнять несколько одновременных поисков, поиск по большому количеству шардов приведет к истощению пула поисковых потоков узла. А это будет причиной для низкой пропускной способности и, соответственно, низкой скорости поиска.
В этот момент пора бы задаться вопросом: каково правильное количество шардов для самой быстрой операции поиска? Если данных мало, то шардов должно быть как можно меньше.
Но сколько данных слишком много? Нелегко определить золотую середину. В общем случае хватит 1 шарда для быстрого поиска, до тех пор, пока большее их количество не начнет более эффективно распараллеливать работу между несколькими потоками. В общем, ответ как всегда «it depends»...
Но сколько данных слишком много? Нелегко определить золотую середину. В общем случае хватит 1 шарда для быстрого поиска, до тех пор, пока большее их количество не начнет более эффективно распараллеливать работу между несколькими потоками. В общем, ответ как всегда «it depends»...
Запись vs. чтение
Как видите, уже есть конфликт. Для быстрой индексации нужно как можно больше шардов, а для быстрого поиска лучше иметь как можно меньше шардов. Вопрос сводится к приоритетам. Вы должны решить, что важнее: быстрая индексация или быстрый поиск. Elasticsearch поддерживает и то, и другое, но когда дело доходит до оптимизации, нужно понять что наиболее важно.
Как определить идеальный размер шарда
1. Сравнительный анализ
Лучший способ определить идеальный размер сегмента — провести эксперименты. Выберите сервер, который максимально идентичен будущему боевому серверу, а затем:
2. Общие рекомендации
Эксперименты, конечно, хорошо, но есть также и общие рекомендации:
Используйте механизм Index Lifecycle Management (ILM). Преимущество этого механизма — автоматический перенос индексов, который создает новые индексы, когда текущий соответствует определенному порогу: max_primary_shard_size, max_age, max_docs или max_size. Когда индекс больше не нужен, можно использовать ILM для его автоматического удаления и освобождения ресурсов.
ILM также позволяет легко менять стратегию шардирования с течением времени:
Управляйте размером шардов. Ключевая причина: большие шарды дольше восстанавливаются после сбоя. Когда нода выходит из строя, Elasticsearch перераспределяет шарды узла по оставшимся нодам с ролью data. Процесс восстановления обычно включает копирование содержимого шарда по сети, поэтому для восстановления шарда размером 100 ГБ потребуется в два раза больше времени, чем для шарда размером 50 ГБ. Напротив, маленькие шарды несут пропорционально больше накладных расходов и менее эффективны для поиска. Поиск по пятидесяти шардам размером 1 ГБ потребует значительно больше ресурсов, чем поиск по одному шарду размером 50 ГБ, содержащего те же данные. Золотую середину никто не отменял.
Жестких ограничений на размер шарда нет, но опыт показывает, что шарды размером от 10 до 50 ГБ обычно хорошо подходят для логов и данных временных рядов. Никто не запрещает использовать более крупные шарды в зависимости от возможностей сети и подходам к использованию Elasticsearch. Шарды меньшего размера могут подойти, например, для корпоративного поиска. Если вы используете ILM, установите пороговое значение max_primary_shard_size для действия переноса равным 50 ГБ, чтобы избежать сегментов размером более 50 ГБ.
Текущий размер шардов можно узнать через API:
Лучший способ определить идеальный размер сегмента — провести эксперименты. Выберите сервер, который максимально идентичен будущему боевому серверу, а затем:
- Настройте кластер Elasticsearch с 1 узлом.
- Индексируйте свои производственные данные.
- Измерьте скорость индексации с помощью инструмента сравнительного анализа (например, Rally).
2. Общие рекомендации
Эксперименты, конечно, хорошо, но есть также и общие рекомендации:
- Удалять индексы вместо отдельных документов;
- Использовать политику управления индексами (ILM);
- Для логирования обычно хорошо подходят шарды размером от 10 до 50 ГБ, а для операций поиска достаточно 20-25 ГБ;
- Учитывать общий размер JVM Heap. Нужно стремиться иметь 20 шардов на каждый ГБ JVM Heap;
- Избегать овершардинга на ноде;
- Следить за корректностью типов полей.
Используйте механизм Index Lifecycle Management (ILM). Преимущество этого механизма — автоматический перенос индексов, который создает новые индексы, когда текущий соответствует определенному порогу: max_primary_shard_size, max_age, max_docs или max_size. Когда индекс больше не нужен, можно использовать ILM для его автоматического удаления и освобождения ресурсов.
ILM также позволяет легко менять стратегию шардирования с течением времени:
- Хотите уменьшить количество шардов для новых индексов? Измените параметр index.number_of_shards в соответствующем шаблоне индекса потока данных.
- Хотите больше шардов или меньше реплицированных индексов? Увеличьте порог переноса в ILM.
- Нужны индексы, охватывающие более короткие интервалы? Компенсируйте увеличение количества шардов, удаляя старые индексы раньше. Это можно сделать, снизив пороговое значение min_age на фазе удаления удаления.
Управляйте размером шардов. Ключевая причина: большие шарды дольше восстанавливаются после сбоя. Когда нода выходит из строя, Elasticsearch перераспределяет шарды узла по оставшимся нодам с ролью data. Процесс восстановления обычно включает копирование содержимого шарда по сети, поэтому для восстановления шарда размером 100 ГБ потребуется в два раза больше времени, чем для шарда размером 50 ГБ. Напротив, маленькие шарды несут пропорционально больше накладных расходов и менее эффективны для поиска. Поиск по пятидесяти шардам размером 1 ГБ потребует значительно больше ресурсов, чем поиск по одному шарду размером 50 ГБ, содержащего те же данные. Золотую середину никто не отменял.
Жестких ограничений на размер шарда нет, но опыт показывает, что шарды размером от 10 до 50 ГБ обычно хорошо подходят для логов и данных временных рядов. Никто не запрещает использовать более крупные шарды в зависимости от возможностей сети и подходам к использованию Elasticsearch. Шарды меньшего размера могут подойти, например, для корпоративного поиска. Если вы используете ILM, установите пороговое значение max_primary_shard_size для действия переноса равным 50 ГБ, чтобы избежать сегментов размером более 50 ГБ.
Текущий размер шардов можно узнать через API:
GET _cat/shards?v=true&h=index,prirep,shard,store&s=prirep,store&bytes=gb
Значение pri.store.size показывает общий размер всех основных шардов индекса.
index prirep shard store
.ds-my-data-stream-2022.05.06-000001 p 0 50gb
...
Учитывайте размер JVM Heap. Используйте правило 20 шардов на 1 Гб JVM Heap. Количество шардов, которые может хранить нода, пропорционально памяти JVM Heap. Например, нода с 30 ГБ оперативной памяти должна иметь не более 600 шардов. Чем ниже этого порога вы будете держать ноды, тем лучше. Если выяснилось, что на ноде превышаются 20 шардов на ГБ JVM Heap, рассмотрите возможность добавления еще одной ноды.
Некоторые индексы почти пусты и редко используются. Можно, конечно, не учитывать шарды для этих индексов в расчетах, но лучше их удалить. Чтобы проверить настроенный размер JVM Heap на ноде, используйте API:
Некоторые индексы почти пусты и редко используются. Можно, конечно, не учитывать шарды для этих индексов в расчетах, но лучше их удалить. Чтобы проверить настроенный размер JVM Heap на ноде, используйте API:
GET _cat/nodes?v=true&h=heap.max
Либо можно посмотреть количество шардов на ноде:
GET _cat/shards?v=true
Избегайте овершардинга на ноде. Если на определенной ноде скучковалось слишком много шардов, может произойти овершардинг. Например, если одна нода содержит слишком много шардов индекса с большим объемом, на ноде могут возникнуть проблемы. Чтобы предотвратить овершардинг, используйте параметр индекса index.routing.allocation.total_shards_per_node для явного ограничения количества шардов на одном узле. Можно настроить index.routing.allocation.total_shards_per_node, используя API:
PUT my-index-000001/_settings
{
"index" : {
"routing.allocation.total_shards_per_node" : 5
}
}
Избегайте некорректного сопоставления полей (mapping). По умолчанию, Elasticsearch автоматически создает сопоставление для каждого поля в каждом документе, который он индексирует. Каждое отображаемое поле соответствует некоторым структурам данных на диске, которые необходимы для эффективного поиска, извлечения и агрегирования по этому полю. Подробная информация о каждом отображаемом поле также хранится в памяти. Часто эти накладные расходы не нужны, поскольку поле не используется ни при поиске, ни при агрегировании. Используйте статическое сопоставление вместо динамического, чтобы избежать создания полей, которые никогда не используются. Если набор полей обычно используется совместно, посмотрите в сторону использования copy_to для их объединения во время индексирования. Если поле редко используется, может лучше сделать его runtime-полем.
Можно получить информацию о том, какие поля используются с помощью API статистики использования полей. После этого можно проанализировать использование диска сопоставленными полями с помощью API анализа использования диска.
Спасибо за внимание! Надеюсь, статья была для вас полезна. Если хотите больше узнать об Elastic, приходите к нам на семинар-инструктаж. Ниже ссылка на ближайший, а также ссылки на другие наши статьи.
Можно получить информацию о том, какие поля используются с помощью API статистики использования полей. После этого можно проанализировать использование диска сопоставленными полями с помощью API анализа использования диска.
Спасибо за внимание! Надеюсь, статья была для вас полезна. Если хотите больше узнать об Elastic, приходите к нам на семинар-инструктаж. Ниже ссылка на ближайший, а также ссылки на другие наши статьи.
Что дальше
Приглашаем наши тренинги по Zabbix, OpenSearch, ElasticSearch
Максимум знаний за короткое время
Другие наши статьи об Elastic
Статья на Хабре
Статья на Хабре
Статья на Хабре
Статья на Хабре
Есть вопросы или предложения?
Вы можете написать здесь и при необходимости приложить файлы.
Нажимая на кнопку, вы даете согласие на обработку персональных данных и соглашаетесь c политикой конфиденциальности.