Previous Entry Share Next Entry
2016-01

on databases

...мда, как сегодня выяснилось, способность читать и кое-как понимать код на Q вовсе не означает способности понимать код на K :/

а еще это очень хорошая иллюстрация, что любой эээ ммм оптимальный в смысле теории информации способ кодирования данных без интерпретатора неотличим от шума %)

но, тем не менее, Kdb+ всё-таки очень крутая штука, да. намного более простая, логичная и по-моему более мощная чем весь этот ваш SQL.

This entry was originally posted at http://wizzard.dreamwidth.org/419809.html. It has comment count unavailable comments. Please comment there using OpenID.

  • 1
ufm February 3rd, 2015
(!R)@&{&/x!/:2_!x}'!R
Ужас какой.

wizzard0 February 3rd, 2015
Ага, именно такой.

jakobz February 3rd, 2015
Она ж вроде тупо про массивы, там ни консистентности, ни работы с диском толком... Загрузил готовые данные, и быстро по ним лупишь. Или я ошибаюсь?

wizzard0 February 3rd, 2015
Это ты, наверное, про J.

А тут foreign ключи, триггеры, репликация, кластеризация, http, вебсокеты, индексы, всё там в порядке. Персистить можно и автоматически, и руками. Руками появляются возможности ему помочь (например, разложить часть на ssd, часть на hdd), но вроде и так всё работает. Ну и бинарничек на 500 кбайт ;-)

Ну то есть я так навскидку не нашел, чего там нету по сравнению с "обычным порошком".

Edited at 2015-02-03 08:57 am (UTC)

jakobz February 3rd, 2015
Не, я как раз про тот бинарничек на 500кб, который kdb+. Там же нету ни оптимизатора запросов, ни транзакций. Короче нельзя это сравнивать с OLTP/SQL-базами.

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

slobin February 3rd, 2015
Некоторое время соображал, что :/ не является правильным кодом на K. Теперь боюсь смайлик ставить.

... Вы сбиваете с толку весь Париж! ...


wizzard0 February 3rd, 2015
Ну да, это adverb!

enternet February 3rd, 2015
Ну так а почему? Что делает продукт крутым? А ответ прост. Там есть понятие последовательности. Упс. И внезапно неприятные задачи для SQL становятся элементарны.

Уже не первый раз пишу: давно пора отходить от "чистой" реляционной теории в СУБД. В реальной жизни идущие на вход данные практически всегда имеют порядок. И обрабатываются в соответствии с ним.

wizzard0 February 3rd, 2015
Все-таки то, что это column-oriented БД - тоже очень сильно влияет.

enternet February 3rd, 2015
Колоночное хранение есть и в Оракле и в MSSQL и, наверное, ещё много где. Но вот сделать ещё шаг...

sorcerer_ February 3rd, 2015
Для OLAP императивный код всегда заруливал реляционный.
В OLTP все уже не так.

109 February 3rd, 2015
хи-хи.

wizzard0 February 3rd, 2015
Ась?

109 February 3rd, 2015
ну я предположил, что словами "этот ваш SQL" ты обозначил традиционные rdbms типа oracle или ms sql?

wizzard0 February 3rd, 2015
Не, ну я, конечно, набрасываю, но...

я Пастернака не читал, но...

Serge Shikov February 3rd, 2015
У нас широко используется такая фиговина, как OneTick. Для тех же целей.

Так я вам вот что скажу - пока оно живет само по себе, оно может и неплохое. Но рано или поздно любые данные нужно связывать или сравнивать с какими-то другими данными, для которых оная time-series база не годится по каким-то причинам. И тут, сюрприз, почему-то внезапно начинается полная опа. И становится проще плюнуть на все, выкачать эти гигабайты сделок на бирже в обычную SQL базу (тем более что всем как правило интереснее всего тенденции и сделки свежие, за сегодня/вчера, а их не так и много), и делать там что хочешь. Хочешь - join, хочешь - pivot, хочешь так выпендришься, хочешь эдак. А захочется странного - куда-нибудь и в Hadoop засунуть можно.

  • 1
?

Log in

No account? Create an account