Судя по описанию Vertica - колончатая СУБД. Из этого следует что она работает только
in memory (или наиболее эффективна при работе с сегментом данных in memory)

?

Я так рассуждаю. В традиционной R-DBMS мы кластеризуем все атомы каждого кортежа рядышком.
Тоесть примерно так:




Нет накладных на связи между атомами строки (кортежа).

В колоночных RDBMS (С-DBMS) мы обязаны для каждого атома ссылку на следующий атом
или в двунаправленных в обе стороны. Это накладные. Они могут быть коротким
указателем (32 бит в памяти или 64 бит) или ROWID/*ID идентификатором записи/
строки/блока/файла для файлово-ориентированной колоночной системы.

Я полагаю что в последнем варианте мы несём БОЛЬШИЕ накладные расходы
на хранение заполненной на 100% таблице (NOT NULL) для колоночной
системы.

У меня пока нет цифр. Это только инженерная интуиция но я думаю что это так.

Поэтому я считал что колоночные (like Qliki) системы эффективны для
расколбаса поисков и вставок in-memory. И еще эффективнее когда
мы заведомо работает с 2-3 столбцами а другие не трогаем.

Аргуменнты в пользу компрессии я читал. Не впечатляют.
Очень трудно прогнозировать в какой системе и где нужно
будет жать колонку а где нет. И трудно посчитать оверхед по ЦПУ
в этом случае. Поэтому интересует самый общий подход для 100% линейных
и шумящих данных без энтропии. Тоесть наихудший вариант.

iv_an_ruХм, а зачем? Вы же в строковом представлении не делаете для каждого атома-поля двунаправленные сслыки на соседей слева и справа? Зачем вам в колонке вдруг понадобились ссылки вверх-вниз?
Я и говорю про сcылки влево-вправо. Они весьма материальны. Весьма.

iv_an_ruТо же самое и со строками. И решение в обоих случаях одно и то же --- жать всё подряд и надеяться на лучшее.
Я уже знаю как DDOS-ить подобную систему. У меня есть данные по измерениям (binary_float, binary_double). Они
жмуться (в идеале) дифференциальным алгоритмом+арифметика. Но random доступ к произвольному элементу
там отсутствует. Тоесть если я буду такую колонку бомбить обычными точеччными поисками я либо просажу
производительность нахер либо загужу CPU и память выше крыши ненужными разархивациями. Что вобщем-то
в обоих случаях - epic fail и пистон создателю системы.

iv_an_rumaytonпропущено...

Я и говорю про сcылки влево-вправо. Они весьма материальны. Весьма.Да нету их вообще. И без них понятно, что 5-е значение в одной колонке соответствует 5-му значению в другой --- они оба в одной и той же 5-й строке.
Трудно с вами. Будто говорим на разных языках.

iv_an_ruТрудно с вами. Будто говорим на разных языках.Я вижу, что у вас какое-то странное представление о колоночном хранении, но ещё не понял, с какого момента оно начинает расходиться со всеми стандартными реализациями (точнее, со всеми стандартными после диссертации Абади).[/quot]
Дайте ссылки на материалы по внутренней организации С-RDBMS где описаны
способы хранения атомов, кортежей, сегментов таблиц. Желательно коротко.
Для ознакомления.