Комментарии 4
Хороший велосипед:) но сразу возникают вопросы:
— как пользователи или приложения будут формировать произвольные запросы к данным?
— есть ли оптимизация хранения агрегатов? Например, если имеются 10 измерений с сотней уникальных значений в каждом, то это уже 10^100 комбинаций агрегатов.
— и если не секрет, чем не подошли существующие olap сервера?
— как пользователи или приложения будут формировать произвольные запросы к данным?
— есть ли оптимизация хранения агрегатов? Например, если имеются 10 измерений с сотней уникальных значений в каждом, то это уже 10^100 комбинаций агрегатов.
— и если не секрет, чем не подошли существующие olap сервера?
На самом деле — если говорить о произвольных запросах к данным, необходимо создавать еще один слой, например интерпретации SQL запросов между DataWarehouse классом и «приложением-клиентом».
Ввиду того, что данные уже агрегированные в хранилище — практически отсутствует необходимость написания аналитических функций агрегации.
Что касается данной модели — нужно просто разработать протокол «запросов» или «функций» обращения к классу DataWarehouse. Как я уже описал — этот протокол будет состоять из ограниченного списка функций, которые легко написать и дальше ими пользоваться как API для произвольного доступа.
Да, оптимизация имеется — она описана в статье, как 2 шага оптимизации — превращение матрицы в одномерный массив и использование битового массива для описания этой матрицы. На практике, я забыл описать — такие матрицы из всего объема данных занимают лишь 10%. Т.е. Вариант из 10^100 степени крайне маловероятен. Однако, если такой имеется — необходимо данную задачи решать иначе. Использовать другие пути оптимизации.
Существующие OLAP сервера отлично подходят в 99% случаев, описанных в этой статье. Описанная модель может быть использована даже как надстройка к таким OLAP серверам. Данная статья описывает случай, когда кубы данных приходили уже в агрегированном виде (в случае OLAP серверов — данные хранятся как факты, обработка их и генерация агрегатов производится аналитическими инструментами внутри решения OLAP. Как устроено кэширование данных внутри таких решений мне не известно). Так же данная статья описывает случай крайне интенсивного доступа к данным множеством пользователей, что в конечном счете упиралось в скорость чтения данных с жесткого диска. Предложенная модель считывает данные лишь единожды — когда стартует приложение. Дальше все находится в оперативной памяти.
Ввиду того, что данные уже агрегированные в хранилище — практически отсутствует необходимость написания аналитических функций агрегации.
Что касается данной модели — нужно просто разработать протокол «запросов» или «функций» обращения к классу DataWarehouse. Как я уже описал — этот протокол будет состоять из ограниченного списка функций, которые легко написать и дальше ими пользоваться как API для произвольного доступа.
Да, оптимизация имеется — она описана в статье, как 2 шага оптимизации — превращение матрицы в одномерный массив и использование битового массива для описания этой матрицы. На практике, я забыл описать — такие матрицы из всего объема данных занимают лишь 10%. Т.е. Вариант из 10^100 степени крайне маловероятен. Однако, если такой имеется — необходимо данную задачи решать иначе. Использовать другие пути оптимизации.
Существующие OLAP сервера отлично подходят в 99% случаев, описанных в этой статье. Описанная модель может быть использована даже как надстройка к таким OLAP серверам. Данная статья описывает случай, когда кубы данных приходили уже в агрегированном виде (в случае OLAP серверов — данные хранятся как факты, обработка их и генерация агрегатов производится аналитическими инструментами внутри решения OLAP. Как устроено кэширование данных внутри таких решений мне не известно). Так же данная статья описывает случай крайне интенсивного доступа к данным множеством пользователей, что в конечном счете упиралось в скорость чтения данных с жесткого диска. Предложенная модель считывает данные лишь единожды — когда стартует приложение. Дальше все находится в оперативной памяти.
А Вы не рассматривали NoSQL базы данных? HBase с Pig и Hive, например.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Агрегаты многомерных кубов OLAP в оперативной памяти