Как стать автором
Обновить

Комментарии 4

Про OLAP не, не слышали...
ROLAP - вообще не существует!

Вообще думал ознакомлюсь с чем-то новым и интересным в области хранения и обработки данных, примерные сравнительные цифры увижу, помечтаю о применении, может быть коллегам предложу попробовать. Но даже нигде в тексте не встретил названия хоть одной МБД, относительно которой всё писалось и сравнивалось. Разочарование да и только, как и куча вопросов к тексту и уровню интеллекта целевой аудитории, для которой предназначалься текст.

В отличие от традиционных баз данных, где данные хранятся в виде таблиц, в МБД основное внимание уделяется анализу данных и созданию быстрых и эффективных запросов.

Нальзя сказать, что традиционные (в данном контексте реляционные базы - РСУБД) хранят данные в виде таблиц. Физический движок хранения у всех разный и представляет данные на носителе по разному и таблицами там мало пахнет. И это не главное. Непонятно другое: какое отношение имеет способ хранения данных РСУБД к основному вниманию уделяемому анализу данных и созданию быстрых и эффективных запросов? Как данные хранятся в МБД и в чём отличие от хранения в РСУБД?

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

Из курса математики знаю про матрицы, про тензоры слышал, многомерные вектора. Но тут сдаюсь и не могут представить описанную топологию. Картинок по тексту ни одной.

В отличие от реляционных баз данных, где каждая операция над данными включает в себя чтение и фильтрацию отдельных строк таблицы

Множество операций в РСУБД побольше будет.

Еще одним важным преимуществом МБД является их способность обрабатывать большие объемы данных. Благодаря оптимизации архитектуры базы данных и использованию сжатия данных, МБД обладают высокой скоростью выполнения запросов и масштабируемостью.

Это в том или ином ввиде размазано и повторяется по всей статье. При этом нет ни слова про какие такие оптимизации идёт речь. Сжатие данных умеют многие базы данных, которые совсем даже не реляционные.
Масштабируемость интересная тема. Какая она в МБД, в чём преимущетво перед РСУБД?

Также МБД предоставляют возможность создания сложных и гибких отчетов и дашбордов.

Эх...

Представьте себе гигантскую таблицу, где каждая строка олицетворяет собой уникальный набор данных, а каждый столбец – это отдельный атрибут или измерение. Многомерные базы данных добавляют третье измерение, называемое «кубом».

Несколько вопросов.
1 куда и как добавляется третье измерение, называемое кубом?
2 можно ли называть реляционную базу многомерной у которой две идентичные по числу кортежей и атрибутам таблицы, только с различающимися данными в ячейках?

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

А не надо к базе делать сложные и медленные запросы, чтобы терять время необходимое для деловых решений. То что к базе делают сложные и медленные запросы, совершенное не её беда.

В МБД данные агрегируются ....

Довольно часто по тексту встречается эта фраза, такое впечатление, что МБД агрегируют данные перманентно, и даже когда к ним не делают никакие запросы.

Агрегирование происходит путем суммирования, усреднения или иной обработки данных внутри куба.

Агрегирование вообще от чего-то зависит? Как и кем решается, что и как будет агрегироваться?

Это позволяет сократить количество данных, которые необходимо обрабатывать для анализа, что повышает производительность и ускоряет время выполнения запросов.

Насколько точен будет анализ после сокращения количества данных? Ничто не мешает сократить количество данных для анализа в любой базе данных для повышения производительности и ускорения времени выполнения запросов.

Вообще текст напоминает статью написанную ИИ с беглым просмотром результата без всяких попыток осмысления написанного. При этом удивляет другое.

Не суть скольки мерное хранилище представляет из себя мозг, какие и как выполняются там запросы. Это не имеет никакого значения, чтобы провести небольшой анализ. Статья по сути никакая. Вообще. Нет ни примерных цифр для сравнения, нет ни одного маломальского рисунка, для удобства восприятия многомерной (вообще, по заголовку расчитывал на размерность большую трёх) структуры базы данных, нет даже названия МБД, которая бралась для рассмотрения. Есть только постоянные увещевания в той или иной форме, что "Важным преимуществом многомерных баз данных является способность быстро агрегировать данные и проводить сложные аналитические операции". Только при этом статья висит в топах, где и приметил её. Что-то мне подсказывает, выложи такое обыкновенный смертный пользователь, а не сотрудник корпаративного блога, плюсов сталье вряд ли столько поставили, может быть и минусов напихали. И в топах ей не светиться.

Хабр, я понимаю, ничего личного -- просто бизнес (не зря домен .com). Только это статья уровня реферата студента кулинарного техникума (отсыл к лирическому образу Г. Хазанова). Что дальше? Сочинения школьников на тему...? Зашквар про ИТ от Дани Милохина?

Всё верно сказано - тема не раскрыта - но это, судя по всему, и не ставилось целью.

В моём представлении главное отличие многомерных БД от реляционных - в иной архитектуре физической (и логической) компоновки данных и выстраивания индексов (особенно на фоне того, для анализа данные обычно фиксируются и не изменяются, случаи гибридной фиксации изменений в отдельном кэше не учитываю). Так же тут обычно заранее задаются разрезы аналитики, по которым возможно проведение анализа, и требуемое агрегирование ресурсов - и только затем строится куб (обычно на основе иного источника данных, т.е. это копия - зато обычно сюда тянутся все вложенные реквизиты аналитик, и располагаются вместе с основными данными). И вся СУБД ориентируется на работу с этой фиксированной структурой с кучей дублируемой детализации (хранение которой так же оптимизируют, но обычно кубы весят на порядки больше, чем исходные данные на не МБД).

Вообще сейчас МБД стал очень размытым понятием - ранее это были отдельные системы (их порой даже СУБД не называли - так специальные программные надстройки над реальными СУБД). Сейчас же все крупные производители СУБД стараются внедрить поддержку кубического анализа в традиционные СУБД. И, наверное, это правильно.

А какое отношение имеют многомерные базы данных к бесплатному уроку курса PostgreSQL для администраторов БД, который рекламируется в конце статьи?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий