Column-oriented DBMS

Понимая разницу в архитектуре организации хранения записей по столбцам, не понимаю на уровне реализации. То есть в каких реально местах проявляются проблемы, связанные с эффективностью — по объему памяти или времени доступа. А может просто в сложности реализации, например, динамических массивов. Но вопрос принципиальный. Так по разному организованы массивы в языках программирования и в принципе, если в этом есть определенные преимущества для специальных условий, то тогда можно и рассмотреть файловую систему, организованную по такому принципу. Тема стоит того, чтобы найти какой-то более подробный анализ. Возможно, что на этом принципе реализованы все языки типа APL. Любопытно, как дело обстоит в AWK.

Можно поставить вопрос шире. Или целый набор вопросов. Имеет ли смысл распределять файл пакетами или ввести принцип единого адресного пространства для целого файла. Имеет ли смысл, наконец, выделить файл как особую структуру памяти. Имеет ли смысл, формализовать понятие строки файла. И так далее. Очевидно, что для динамически изменяющихся, в размерах файлов, и в целях плотной записи на внешних носителях при записи файла надо перезаписывать все последующие файлы, но почему бы так и не делать. Зато никакой дефрагментации памяти. И, вообще, странно, что в языках и во внешнем окружении приложений, за редким исключением, неотъемлемая структура данных повсеместно используется без строгих определений и официальной стандартизации! Следующая «терминологическая жертва» — файл!

Метки: Архитектура, Вопросы, Издержки, Модель, Память, Распределение, Ресурсы