Евгений, точно, если эти данные есть там в этом датасете, значит они там нужны. Да, как раз проблема в том что мускул может отсечь часть данных. В этом случае конечно можно опять бежать в эластик за второй страницей, потом опять в мускул, но выглядит это не очень, как костыль.
Евгений, я написал в самом запросе что если данные денормализовать и затолкать все в эластик (все 300 млн записей каждый день), то индекс получается очень большим, а если записать только нужных для поиска 80 млн за все время, то индекс получается разумным, а остальные данные либо в мускул либо в кликхаус
Евгений, запрос с mysql должен быть не select * from tbl where id in (1,2,3), где 1,2,3 - id записей из эластика, а select * from tbl where id in (1,2,3) and field1 in (5,6,7) and field2 in (7,8,9), где field1 и field2 поля, по которым тоже должен осуществлятся фильтр записей из эластика. Ожидается, что эластик выдаст N первых релевантных записей по текстовому полю, но mysql не вернет уже N записей, так как field1 и field2 могут не подойти. Например, ищем мы Телевизор (текстовое поле из эластика) для Москвы (числовое поле из мускула) со статусом В наличии (числовое поле из мускула), эластик возвращает релевантные результаты 10 первых записей, но получается что вернул результаты которые есть только в Питере и Нет в наличии, а для Москвы и В наличии, он на 11 месте в эластике. То есть есть ли технологии заджоинить релультаты выдачи эластика и мускул в одном запросе?
В этом случае эластик не будет учитывать числовые фильтры и возможна ситуация, при которой по текстовому полю результат релевантный, по числовому - нет. Как одновременно учитывать оба фильтра в разных базах данных?
динамическая типизация... если при выполнении скрипта $_POST['number'] не существует, то оно принимает значение NULL, при операции сравнения с 5 NULL конвертируется в int, то есть 0, а 0 < 5, условие выполняется
Click House если таблица партицирована, можно удалять партициями старые данные например, либо добавить TTL. Либо спроектировать с каким либо видом Merge-таблицы, чтобы данные мержились самостоятельно, обновляя нужные данные. В elastic search смотря что будете удалять, если часть документа, будет переиндексация его, весьма затратная операция.
dimonchik2013: вариант в gzip рассматривался, но тоже есть минусы:
1. Что если сервер не поддерживает gzip? В ответ придет неза`gzip`ованная строка .Проблема остается актуальной
2. При варианте с gzip при обрыве контента и при распаковке строки тело ответа будет пустым. Но как проверить что ответ должен был быть вообще? Сервер всегда отправляет Content-Length: 0 в случае отправки только заголовков?
3. gzip все-таки не желателен, так как приходится расходовать ресурсы ЦП на распаковку. Но пока это самый лучший вариант решения данной проблемы(((
Павел Волынцев: пока только есть этот вариант (по закрывающим тегам типа body или html), но хотелось бы что-то более надежного, потому что если в ответ придет json или просто текст?
Павел Волынцев: Дело в том что используются самые разные прокси (платные - бесплатные) из разных источников. Притом чем прокси "бесплатнее", тем сильнее это выражено. Можно ли как-то тогда абсолютно точно определить что контент оборвался при получении ответа?
Данная ситуация обрабатывается тут - https://github.com/bagder/curl/blob/c5d060cab47037... Может поможет правка исходников cUrl (чтобы выкидывал ошибку или предупреждение какое), но не будет ли "ложных" срабатываний?
Запросы на самые разные сайта, от некоторых очень часто такие страницы идут, от других почти никогда. Если отключить прокси, страницы всегда корректны с любых сайтов.
