Keen.io вычисляет ограниченный набор данных

Итак, я начал писать некоторые базовые вычислительные запросы для seek.io по набору данных, состоящему примерно из 170 000 событий, каждое из которых может иметь не более 10 свойств.

Просто протестировав это, мы уже разобрали около 600 миллионов запрошенных свойств, хотя большинство этих запросов были для моих собственных локальных данных с небольшим количеством сохраненных событий, поэтому я предполагаю, что вычислительные запросы выполняются. все 170 тыс. событий, а не набор отфильтрованных результатов 50-100.

Есть ли способ запускать вычислительные запросы к отфильтрованному набору данных? Должен ли я (например) назначать каждому пользователю свою собственную коллекцию событий или что-то в этом роде?


person hobberwickey    schedule 29.01.2018    source источник


Ответы (1)


Примечание. Я инженер платформы и архитектор в Keen IO.

Краткий ответ: нет, нет прямого способа отфильтровать события, за которые вы будете платить, кроме как уменьшить количество событий в коллекции и запрашиваемых временных рамок.

Keen выставляет счета на основе отсканированных свойств. Вы можете перейти по ссылке для подробностей, но краткая версия: Properties Scanned = [# of events matching collection and timeframe] * [# of properties needed to evaluate your query]`.

В некоторых случаях разумным решением может быть разделение событий на разные коллекции. Но будьте осторожны, потому что это эффективно устраняет возможность оценки запросов, которые охватывают несколько/все коллекции. Один из вариантов, если вы хотите дважды записать каждое событие, состоит в том, чтобы записать как в одну глобальную коллекцию, так и в одну коллекцию для каждого идентификатора (или что-то еще, что вы хотите «индексировать»). Эта денормализация может создать некоторые другие сложности, как это всегда бывает с денормализацией, но она может значительно сократить использование ваших вычислений.

(Что бы это ни стоило, мы заметили, что в последнее время многие клиенты начинают сталкиваться с этим моментом трения. Мы активно изучаем варианты добавления некоторой встроенной поддержки «вторичного индексирования», чтобы решить эту проблему непосредственно в продукте. , Но, к сожалению, сейчас я не могу зафиксировать какую-либо конкретную функциональность/временную шкалу.)

Еще одна вещь, которую следует отметить, это то, что в некоторых случаях вы можете получить хорошее решение, используя Кэшированные наборы данных, которая эффективно предварительно вычисляет результат запроса для каждого наблюдаемого значения некоторого проиндексированного свойства. Это несколько более продвинутая функция, но в правильных сценариях она может стать значительным преимуществом по сравнению с другими вариантами с точки зрения стоимости, скорости и простоты.

Наконец: если вам нужна более подробная помощь в определении наилучшего технического подхода к вашей проблеме, [email protected] — отличный ресурс. Надеюсь, это поможет!

person Kevin Litwack    schedule 03.02.2018