Недавно я наконец зарелизил akumuli. Все что планировалось - сделано.Дальше я планирую улучшить компрессию для real значений, избавиться от зависимости из библиотеки boost, оставить только header-only библиотеки оттуда, чтобы упростить deployment. Ну и наконец допилить враппер для Golang.
Теперь о том, что будет дальше. Если кто-то внимательно изучил принцип работы моего движка для хранения данных, то этот человек мог заметить, что он организован не совсем так, как это обычно бывает. Обычно, такие вещи оптимизируются для запросов, возвращающих один временной ряд, чтобы иметь возможность быстро построить по нему график. Это здорово, но это могут делать graphite, influxedb, open tsdb, kairosdb, seriesly и тд. Но это не то что делает time series БД, по сути все вышеперечисленные решения, они не time-series а metrics databases. Они нужны в основном для devops применений, что хорошо, так как количество таких применений растет, но вот делать yet another metrics storage мне не очень интересно.
Akumuli не может быстро вернуть один временной ряд, это все выливается в полное сканирование тома. Это все именно так и задумывалось, потому что я пытаюсь построить TSDB, которая не предназначена для построения графиков, вместо этого, она должна уметь делать similarity search. Мой поинт в том, что чем больше time-series данных вы собираете, тем более бесполезными становятся обычные способы работы с ними ну и тем более бесполезным становится построение графиков по ним. Для того, чтобы работать с такими объемами информации, нужно уметь их эффективно майнить. Именно это akumuli и научится делать в ближайшем будущем. Для mining-а этих данных не нужны ни point-запросы ни способность быстро извлечь одну серию, для этого нужно уметь быстро строить индексы, а для этого нужны уметь быстро сканировать все данные.
Можно коротко описать принцип работы TSDB для майнинга следующим образом:
Теперь о том, что будет дальше. Если кто-то внимательно изучил принцип работы моего движка для хранения данных, то этот человек мог заметить, что он организован не совсем так, как это обычно бывает. Обычно, такие вещи оптимизируются для запросов, возвращающих один временной ряд, чтобы иметь возможность быстро построить по нему график. Это здорово, но это могут делать graphite, influxedb, open tsdb, kairosdb, seriesly и тд. Но это не то что делает time series БД, по сути все вышеперечисленные решения, они не time-series а metrics databases. Они нужны в основном для devops применений, что хорошо, так как количество таких применений растет, но вот делать yet another metrics storage мне не очень интересно.
Akumuli не может быстро вернуть один временной ряд, это все выливается в полное сканирование тома. Это все именно так и задумывалось, потому что я пытаюсь построить TSDB, которая не предназначена для построения графиков, вместо этого, она должна уметь делать similarity search. Мой поинт в том, что чем больше time-series данных вы собираете, тем более бесполезными становятся обычные способы работы с ними ну и тем более бесполезным становится построение графиков по ним. Для того, чтобы работать с такими объемами информации, нужно уметь их эффективно майнить. Именно это akumuli и научится делать в ближайшем будущем. Для mining-а этих данных не нужны ни point-запросы ни способность быстро извлечь одну серию, для этого нужно уметь быстро строить индексы, а для этого нужны уметь быстро сканировать все данные.
Можно коротко описать принцип работы TSDB для майнинга следующим образом:
- Собираем данные и записываем их на диск.
- Делаем из длинных серий короткие с помощью sliding window.
- Делаем dimensionality reduction, есть много методов основанных на преобразовании Фурье, wavelet transform и даже преобразовании в текст.
- Индексируем то что получилось с помощью R-tree, VA-files или чего-нибудь еще.
- Выполняем запросы с погрешностью используя полученные индексы, если нужно - читаем оригинальные данные.
Комментариев нет:
Отправить комментарий