Комментарии 8
Вопрос по поводу колоночного хранения данных. Понятно, что sum(Sales) будет работать "ядерно".
Ну а вот такой запрос:
Тут же мало того, что таблицы надо соединять, бегая по кластеру, так еще и колонки тоже?
Если говорить про In-Memory OLAP, то там, как правило, все данные будут в памяти одной ноды, причем движок может даже сам заранее "сджойнить" таблицы. А если данные лежат в кластере, то там у всех аналитических СУБД свои стратегии шардирования. Но вообще принцип похожий — максимальная денормализация и объединение колонок в одной таблице. Иначе, как вы правильно заметили, джойны и функции от нескольких аргументов будут так замедлять исполнение запроса, что это будет уже не онлайн.
Если говорить про In-Memory OLAP, то там, как правило, все данные будут в памяти одной ноды, причем движок может даже сам заранее "сджойнить" таблицы.
Зачем тогда нужно именно "Колоночное хранение данных"? Выбираем все данные, как бы они не хранились, а затем в памяти раскладываем по колонкам.
Поднимать в In-Memory можно из любого хранилища, без разницы, вы правы. Имелось ввиду, что именно в памяти данные лежат по колонкам.
А вот в случае ROLAP архитектуры с запросами к распределенной СУБД колоночное дисковое хранилище становится очень актуальным, потому что помогает сильно уменьшить количество обращений к диску.
Читаю статью и невольно задаюсь вопросом — у вас уже заказчики на собственную аналитическую платформу есть? А можно привести примеры 5-7 инсталляций вашего продукта на хранилище хотя бы на 1000ТБ, причем чтобы можно было руками «пощупать», с админами поговорить? Интересно было бы взглянуть, какой фреймворк вы действительно держите «под капотом», с фрагментами кода, тестами и отзывами реальных пользователей (если можно, не из России и стран СНГ).
Основной кейс для ViQube — это работа с горячими данными, ориентировочно 200-300 ГБ. Для всего, что больше этого, мы как раз интегрируемся с распределенными аналитическими СУБД, такими как Vertica и ClickHouse. Эта интеграция у нас появилась в этом году, и мы только совсем недавно стартовали несколько проектов с серьезным объемом DWH (там, правда, поменьше петабайта все-таки планируется, скорее, 10-100 ТБ). Надеюсь, там все пройдет успешно, и сможем в следующем году про них публично рассказать.
ClickHouse, конечно, очень быстрый. В режиме одного узла скорость исполнения аналогичных запросов получается примерно одинаковая. Но если сравнивать производительность именно BI системы в целом, то Visiology на базе ViQube будет гораздо лучше работать, чем, например, Mondrian+ClickHouse за счет правильной работы с кэшем, более эффективной трансляции многомерных запросов в табличные и т.п. А вот когда нужен кластер с шардированием — тут ROLAP с ClickHouse (или его коммерческой версией Arenadata QuickMarts) вне конкуренции.
Что под капотом у BI? Детальный разбор технологии In-Memory OLAP