Comments 11
Есть в меру дурацкие вопросы:
1) Как производится резервное копирование?
2) Что значит колоночная БД и при каком условии колоночная БД становится TSDB? Или иначе: каие задачи решает колоночная БД а какие TSDB? И неявляются ли «сверхвозможности колоночной БД» отягащующими для решения задач TSDB?
- Просто rsync на корневом каталоге. В подобной файловой структуре меняются только файлы за последний день, потому можно легко сделать инкрементальный backup. Если таки поменяли данные в середине — то rsync заметит эти изменения
- Тут я не отвечу, так как подобное разделение — скорее теоретическое, нежели практическое. Например, если объем небольшой и порядка 60 Гб, то задачу Time Series влегкую решит с реляционная база, которая будет хранить все данные в памяти.
Формально, из описания KDB на сайте разработчика:
With kdb+ the powerful combination of an in-memory database, a time-series enhanced superset of SQL, tight integration to external systems, and a fully featured programming language embedded directly on the data allows Kx to deliver in a uniquely cost-effective and performant fashion.
В реальности KDB прекрасно для нас решает задачи Time Series, так как:
- Система позволяет быстро поднять данные в память
- Есть встроенные аналитические фукнции
- Можно сделать ряд функций, которые будут доступны из R.
2b) вы пишите "(rdbms) которая будет хранить все данные в памяти" — я правильно понимаю вы имеетве ввиду что запрос вида Where MyCategory=theCategory and MyTime between theTime1 and theTime2 с RDBMS будет эффективен только тогда? Или что-то еще? (просто в случае такого вопроса — если быть до конца точными не совсем все данные, поэтому хочется уточнить)
2с) вы пишите «Система позволяет быстро поднять данные в память» — тут тоже хочется уточнить будет ли она поднимать под запрос «Where MyCategory=theCategory and MyTime between theTime1 and theTime2» данные используя эффетктивно оба предиката или только по периоду времени — а потом фильтр по категории фулсканом?
Т.е. мне хочется надеятся что RTDB так хранит данные что запрос «Where MyCategory=theCategory and MyTime between theTime1 and theTime2» действительно неэффективный на RDBMS выполняется максимально эффективно и с диска на TSDB (в частности представления позволяют отфильтровать категорию). Прямым текстом об этом не говорится, аргументов для умозаключений доказывающих это я тоже не вижу. Поэтому распрашиваю.
2b При хранении последнего дня в памяти, данные хранятся в неотсортированном виде, т.е. по ним запрос отработает линейно. Однако из-за того, что всё и так в памяти, скорость поиска в нем будет высокой. Если этой скорости недостаточно, можно всегда сделать in-memory table, которую периодически обновлять (и вот её уже оптимизировать под чтение).
2c KDB не умеет оптимизировать запросы, к сожалению. И не делает ничего дополнительного для оптимизиции. Т.е. если Oracle/MSSQL для индекса еще сделает статистику, будет выбирать план запроса, то KDB не сделает ничего. Более того, условия в where выполняются ровно в том порядке, как написаны. И если KDB видит, что можно сделать index seek, так как в where первые колонки — это ключи индекса (говоря терминами SQL), то KDB достанет данные быстро. Иначе — скорости уже не будет.
Т.е. в SQL эти две строчки отработают за одинаковое время:
select * from table where date = in_date and key = in_key
select * from table where key = in_key and date = in_dateА KDB — первая строчка именно так, как написано, т.е. если у нас partition по дате и сортировка/группировка по ключу, то запрос сработает очень быстро. Если на той же таблице вызвать второй запрос, то он в каждой дате (т.е. в каждой папке) сначала возьмет в память ключ, а потом профильтрует в памяти результат.
Хмм, хороший вопрос, если честно… Насколько я знаю — в partition можно использовать только одну колонку, она должна быть не больше int'а и она единая для всех таблиц в базе.
В вашем примере — лучше именно сортировать/групповать по колонке "id станка". Здесь уже надо сравнивать скорость, однако я подозреваю, что так будет работать быстрее, ибо:
- KDB умеет быстро прыгать в середину файла, так что сгруппированная по id таблица позволит получать данные с той же скоростью, что и таблица, в которой id вынесен в partition
- Возможно, операционная система будет работать неэффективно с задачей открытия большого числа файлов. Т.е. выгоднее прочитать пять раз из одного, чем по одному разу из нескольких файлов.
Но тут уже надо сравнивать..
У вас ошибочка:
f: {[i_d, i_k]..и
f[2017.01.01, 12]параметры функции разделяются точкой с запятой, а не запятой. Запятая — это join. Точно так же с вызовом функции.
например вы пишите
Если у вас есть ежесекундные колебания курса валют на последние 20 лет, то реляционная база данных На практике, у вас может быть несколько тысяч тиков за одну секунду… Оракл просто захлебнется
Так же не лишним будет упомянуть, что 32-х, битная версия бесплатна и на практике ее никто не использует, так как основные вычисления идут в realtime и очень быстро… Для этого требуется много памяти. 64х битная версия оч дорогая и позволить ее могут только большие организации
хорошо бы упомянуть и базовую структуру тогда, а не отдельно rdb и hdb (отдельно их не используют или используют редко)
базовый набор это feed handler+ ticker plant+rdb+hdb+gateway
KDB