Если я вас правильно понимаю, вас больше интересуют проблемы хранения и извлечения, а не вопросы DDL и определения, категории баз данных, ориентированных на столбцы, верно?
Я приму васСледует понимать, что практически все хранилища, независимо от поставщика, представляют собой некоторую форму:
- B-дерева для индексов
- Кучи для неорганизованных данных
Помимо этого, у каждого поставщика есть свои оптимизации и запатентованные специализации.Например.Sybase (строка) имеет:
- Кластерный индекс, который объединяет строки данных с B-деревом и удаляет кучу.
Следующая проблема заключается в том, что все производители (кроме oracle) имеют достаточно сложные двигатели с модульной конструкцией, а ввод / вывод обрабатывается асинхронно, на низком уровне, для получения скорости.Единица ввода / вывода - это страница.Обычно от 2 до 8 КБ для систем OLTP и от 8 до 64 КБ для DSS.(обратите внимание, что я избегаю проблемы Row vs Column.) Таким образом, независимо от строки / столбца, механизмы DSS создаются для массового извлечения из-за получения большего количества строк или столбцов Index / Data в больших блоках с меньшим количеством запросов ввода-вывода.*
«Большой ввод / вывод» можно выполнить, считав экстенты (8 страниц) и более крупные блоки AllocationUnits (256 страниц) в память с помощью одного запроса ввода / вывода.Но основной единицей является Page.
Строка против столбца
- Строка
- Каждая строка представляет собой непрерывную единицу на странице, а числостроки упакованы в страницы.
- Для индексов это не имеет значения, потому что вся структура данных - это составные столбцы в ключе;индексная запись или запись - это небольшая индексная запись + указатель, и гораздо больше индексных записей упаковывается в одни и те же страницы.
- Они очень быстрые для небольшого числа строк;медленно суммирует совокупность столбцов
.
- Столбец
- Каждый столбец является непрерывной единицей на странице.И поскольку столбец может иметь длину в миллионы записей (строк), он работает для многих, многих страниц.
- Индексы такие же, как в строке выше.С добавлением специальной формы индекса, которая должна быть более быстрой для столбчатой навигации.
- Они феноменальны для столбчатых агрегатов;очень медленно конструирует строки из данных на основе столбцов
Все запросы, выполняемые к ядру, должны перемещаться по индексам, извлекать строки / столбцы данных из вышеуказанных структур хранения данных.
Результатом является умножение вышеприведенного;
малый / большой размер блока, раз
базовых физических структур, раз
Ориентация строки / столбца
Это то, что вы искали?Существует набор технических (не теплых и нечетких) диаграмм выше для Sybase ASE, строго ориентированного на строки движка OLTP / DSS, который я могу получить, если вам интересно.
Ответык комментариям
.
Вы хотите сказать, что в конечном итоге мы перейдем к странице независимо от типа базы данных.
Да.
Если это так, то как будет выполняться кластеризация базы данных.Давайте возьмем базу данных, в которой хранятся данные в строках.Если я делаю кластеризацию для этого типа баз данных, то как именно структура таблицы будет переноситься на разные узлы (если у меня более одного узла).Будет ли эта структура таблицы связана со страницей или будет с помощью другого механизма.
Знаете, прежде чем я отвечу на вопрос, я должен вас поблагодарить.Для кого-то с вашим уровнем знаний, это прекрасно, что вы достигли этой критической точки, получили это понимание.Шива ки Джай!
Да, это критическая проблема проектирования кластерной СУБД, критическая проблема ограничения, прежде всего различных проблем проектирования, связанных с кластеризацией;что если поставщик хорошо справится с этой проблемой, кластер будет работать хорошо;а если нет, то это собачий завтрак.
Все в ЭТОМ регулируется законами физики.Ничто не является бесплатным, каждая функция имеет стоимость, обработку или хранение.В этом нет ничего волшебного, разве что в маркетинговых брошюрах MS.
Хорошая кластерная архитектура БД
Я не знаю всех кластерных СУБД;Я очень хорошо знаю Sybase CE и Oracle RAC.Знание Sybase IQ.
- Oracle RAC существует намного дольше и является более зрелым.Это решает эту критическую проблему довольно плохо.Таким образом, он в конечном итоге борется с самим собой и требует гораздо больше ресурсов процессора (ядра, процессоры, а не узлы), чем первоначальная оценка.Чем больше узлов, тем больше разногласий.
.
Следует отметить, что архитектура Oracle без RAC является дерьмом или, точнее, не существует;таким образом, у RAC есть песчаная основа для строительства.
.
Не говоря уже, стабильность сосет мертвых медведей.
. Sybase CE всего один год.Но архитектура великолепна, она решает эту критическую проблему очень хорошо.В SAN существует только одна версия страницы.Все узлы подключены к SAN.Любой узел может читать или писать страницу.Узлы связаны частной локальной сетью (в дополнение к обычной клиент-серверной локальной сети, используемой всем остальным в сети).Узлы координируют блокировки и немного связи между узлами для балансировки и т. Д.
.
В конце дня, для максимального параллелизма, даже с Sybase CE, вам необходимо логически разделитьбазы данных, так что рабочая нагрузка на каждом узле разделена, имеет доступ к различным путям файлов или отдельным физическим областям общей базы данных.
Sybase IQ уже ориентирован на 100% столбцов.Это их предложение DW.Он уже выполняет полную балансировку нагрузки.Может использоваться кластер, но не кластеризация в смысле CE, описанном выше.Я должен был включить его в
Плохая кластеризованная архитектура БД
Собачий завтрак типа кластеризованных баз данных делает глупые вещи.Чтобы перечислить некоторые из них:
хранят страницы на каждом узле [массовое дублирование], но затем перемещают обновленные страницы по кластеру
использовать MVCC для преодоления проблемы (но MVCC намного больше загружает и на самом деле замедляет параллелизм, поэтому борется сам с собой)
Кластер не подходит для выделенного сервера БД
В основном кластеры хороши для некоторых приложений, но это глупая идея для выделенных серверов БД (один факт в одном месте; общие ресурсы, которые администрируются вместе; конфликт блокировок, который наиболее эффективен при управлении в одномместо, потому что данные находятся в одном месте).Я никогда не рекомендовал бы кластер для сервера базы данных.
То же, что проблема SAN.Конечно, у многих людей хранилище БД находится внутри SAN, но для максимальной скорости и изоляции от проблем нагрузки других серверов, подключенных к SAN, ничто не близко к локальному диску.
То же, что и проблема VMWare.Конечно, у многих людей установлен db-сервер в качестве хост-модуля VMWare, но для обеспечения максимальной скорости снимите служебную нагрузку с VMWare;для изоляции от проблем с нагрузкой других хост-блоков в шасси вытащите его оттуда на выделенный жесткий ящик.
Почему поставщики БД беспокоятся о кластере
О, в этом есть ценность, но не сейчас, в будущем.AFAIC, архитектура Sybase будет преобладать со временем, а все остальные отойдут на второй план.Каждый поставщик будет копировать его как обычно.
Реальная сила Sybase CE заключается в следующем:
истинное 100% время безотказной работы (возможность добавить узел в кластер и принятьстарый узел отключен для обслуживания) и
полностью динамическая балансировка нагрузки (скажем, существующий узел 4-х четырехъядерный; добавить временный 4-х четырехъядерный узел; снять старый узел; вставить 2 х четырехъядерный; поднять его; снять темп узел вниз), а затем в течение 60 секунд, без пальцев на клавиатуре, весь зверь перебалансируется.
Магазин, который может шататься по ночному графику обслуживания БД своих нескольких одноузловых серверов, может сэкономить приличную сумму денег; у них просто есть пара дополнительных машин для включения / выключения.
Хранилища данных немного отличаются. Они в основном только для чтения. Таким образом, не проблема разместить его в кластере (много узлов чтения, только один узел записи, нет конфликтов, никого не волнует, что страницы пишутся так, как они читаются). Sybase IQ - такой продукт.
Sybase CE для колонн
Sybase IQ уже ориентирован на столбцы и может быть развернут в кластере, но не кластеризация в смысле CE, описанном выше. Столбцы отображаются на страницах. Я должен был включить его в Good Clustered Db Architecture выше, исправлено сейчас.
Мне неизвестны гибриды, сочетающие ориентированность на столбцы и строки.
Но полный ответ на этот вопрос заключается в том, чтобы использовать чистый Db (не DW), такой как Sybase ASE или ASE / CE, и реализовать настоящую базу данных шестой нормальной формы. Это предельная нормализация, неприводимая NF, с несколькими существенными преимуществами, включая скорость и простоту поворота. Это обеспечивает ориентированное на столбцы хранение на страницах. Из-за того, что SQL не поддерживает 6NF полностью, вам необходимо предоставить представления для предоставления строк 5NF из (сохраненных) структур 6NF. Я написал расширение для каталога, чтобы можно было генерировать код SQL для разработчиков.