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