Какие есть варианты реляционных связей между документами в разных индексах?

есть же тип поля join, правда только один на индекс

хорошо, как вообще в таких случаях поступают, как поддерживают консистентность?

Где можно найти полный рубрикатор яндекс маркета?

Алексей Горбунов, спасибо, вроде как то, что нужно.
напишите плз первым уровнем коммент, отмечу решением.

Где можно найти полный рубрикатор яндекс маркета?

это сильно урезанный

Обязательно ли заполнять матрицу с примерами всем словарем возможных слов?

А насколько это широкая практика, использовать такие матрицы? в документации ничего не нашел про такую возможность.

Обязательно ли заполнять матрицу с примерами всем словарем возможных слов?

Данил, Проверил ваше предложение. Исключил из выборки все слова, чей вес меньше, чем AVG по всем товарам, так же исключил все предлоги, союзы и т.д.

В итоге качество распознавания уменьшилось с 0.98 до 0.64. Но самое плохое в том, что на потреблении ресурсов (ЦПУ + память) никак не сказалось ощутимо. Таким образом получается, что нет смысла уменьшать размерность ширины матрицы.

Спасибо за предложенный вариант, но не подходит, увы (

Обязательно ли заполнять матрицу с примерами всем словарем возможных слов?

Спасибо, попробую почитать про такой способ, насколько его возможно применить.

Обязательно ли заполнять матрицу с примерами всем словарем возможных слов?

Спасибо, я в задачке описал, что уже использую его, правда не стал применять эту библиотеку, т.к. словарь лежит в базе. Я считаю TF-IDF по формуле одним запросом к базе, получается существенно быстрее, чем если прогонять эти данные через TfIdfTransformer (как понимаю аналог вашей либы, только встроенный в PHP-ML).

Но спасибо, не подумал про то, что можно исключить слова со слабой "силой".

Но я правильно понимаю, при изменении словаря возможных слов, придется полностью заново составлять датасет и переобучать заново? Нет каких-то методик "пополнения"? Обучение всегда происходит "заново"?

Как реализовать пагинацию на elasticsearch через scroll / slice?

вообще, если я правильно понял, slice делит всю выдачу на max кусков и через id возвращает нужный кусок. Таким образом получается надо бить всю выдачу на total/index.max_result_window кусков и каждый из них пагинировать. Я правильно понял смысл срезов?

Как реализовать пагинацию на elasticsearch через scroll / slice?

у меня в эластике пока 5 млн записей, со временем будут и все 100. Пагинация через from/size уже не работает на страницах более 10к, в тексте ошибки сам эластик пишет:

Result window is too large, from + size must be less than or equal to: [10000] but was [3804800]. See the scroll api for a more efficient way to request large data sets.

Количество проиндексированных страниц сильно прыгает. Как правильно?

Александр Денисов, поясните пожалуйста, как это можно сделать?

Количество проиндексированных страниц сильно прыгает. Как правильно?

про сайтмап не понял
сайтмап товаров
вот ссылка на него, там вроде все разбито как нужно

Как посчитать среднее значение по сгруппированным данным?

Алексей Черемисин, не за период, просто с нуля и до момента, когда я запрашиваю данные с АПИ. Сегодня запросил, у игрока 100 боев суммарно сделано, через месяц запрашиваю, там 300. Т.е. этого итоговое число всегда на конкретную дату. Но задача от этого вроде же не меняется. Если задача вычислить среднее число боев среди всех игроков.

Как посчитать среднее значение по сгруппированным данным?

Алексей Черемисин, так и есть, все счетчики растут всегда. Только их очень много. Сейчас в эластике почти 400 млн записей, 50 GB данных.

Как посчитать среднее значение по сгруппированным данным?

Алексей Черемисин, у меня данные лежат в том виде, в котором отдает АПИ источника данных. Спасибо, подумаю насколько это возможно, каждый раз вычислять дельты между срезами и хранить только саму разницу за дату.

Как посчитать среднее значение по сгруппированным данным?

Алексей Черемисин
> Так, а как исказятся данные, если я например считаю среднее за предыдущий месяц? Туда же не попадут данные за другие даты.

Ну смотрите, предположим есть игрок 1, 2 и 3. У них есть такие срезы:

игрок 1, дата 2019-02-01, боев 10
игрок 1, дата 2019-02-10, боев 11
игрок 2, дата 2019-02-01, боев 5
игрок 3, дата 2019-02-21, боев 7

Да, забыл сказать, количество боев всегда увеличивается, т.е. это не сколько боев он провел за месяц, а сколько у него их было в начале месяца и сколько стало в конце.

Итого получается, если посчитать среднее по всем данным, то будет (10+11+5+7)/4 = 8.25
А если сделать так как было бы "правильней", когда от каждого игрока по последнему срезу учитывается, то получится (11+5+7)/3 = 7.6

Как посчитать среднее значение по сгруппированным данным?

Алексей Черемисин,
> Дата: от - до , среднее battles

С небольшим нюансом. На одного игрока только одна запись должна участвовать в расчете среднего значения, самая свежая. Причем не факт, что у всех игроков будут срезы статистики попадать в рейндж по датам. У кого-то последняя статистика год назад, у кого-то месяц назад или день назад.

На самом деле я сильно упростил задачу, среднее количество боев довольно бессмысленны, как данные. В реальности мне нужно посчитать среднее количество побед и среднее количество поражений, из этих чисел я смогу вычислить средний винрейт для периода времени, но как вы понимаете, если не использовать группировку по юзерам, то данные будут сильно искажены в зависимости от того как много в выборку попадут срезы за другие даты в рамках одного игрока.

Как посчитать среднее значение по сгруппированным данным?

Алексей Черемисин
>И зачем вам is_last вообще

у меня его разумеется нет, я просто для наглядности привел пример какого рода мне нужна выборка. Не все правильно понимают задачу, для иллюстрации и придумал поле is_last, которого конечно нет, вместо него поле с датой.

> И почеме нельзя сделать запрос по дате чернз range?!
Потому что в этот рейндж могут попасть несколько записей одного игрока и среднее количество "боев" будет уже не корректным.

Речь идет именно о том, чтоб посчитать просто среднее количество боев
на sql это выглядело бы так:

select AVG(battles) from (select * from stats group by player_id)

только тут не учитывается, что нужно не просто сгруппировать по игроку, но еще и желательно, чтоб это была свежайшая строка с этим игроком.

Как посчитать среднее значение по сгруппированным данным?

Спасибо за ответ, но, если я вас правильно понял, то так не сработает.

Фильтр по дате невозможен, дата всегда разная.

можно представить более простой вариант, предположим у меня еще есть поле
is_last: boolean
у каждого игрока есть только одна запись с is_last=true, очевидно с самой максимальной датой и самыми свежими данными Но максимальная дата всегда разная у всех.
При такой схеме среднее считалось бы элементарно, через выборку term is_last=1 и агрегацией avg по всем данным, которые отфильтровались. Но такого поля нет и заводить его очень не хочется, не так просто держать его актуальным будет.

Кластеризация взаимных связей. Какие варианты?

Отлично. То, что нужно. Большое спасибо,

Скролл внутри страницы?

Breeze1, нет, вы не совсем меня поняли. Я рассказывал про процесс написания коммента. Пока печатал вам сообщение - проверил: навел мышку на соседнее окно, где была возможность скроллить и без клика (без потери фокуса из текстового блока коммента) смог проскроллить эту область.