… продолжение IPCT Part I.
(IPCT расшифровывается как Infinite Power Computing Theory).
4. Память и хранилище
… о, ничего особенного, просто….
Пользователь: › Скажите, пожалуйста, Мой Компьютер, в чем разница между файловыми системами и системами управления базами данных?
Мой компьютер: › Пожалуйста, дождитесь ответа….
.
.
.
[До сих пор нет ответа… Пожалуйста, подождите… ]
.
.
.
^C
Пользователь: › mail -s У меня нет ответа на мой последний вопрос [email protected]
Итак, почему же люди все еще пишут все больше и больше БД Системы управления?
^D
Мой компьютер:› почта хранится в базе данных MyOs.
Пользователь:› Что?!!
Боюсь, это был гипотетический сценарий из нашего ближайшего будущего. Ничего особенного, кроме того, что MyOs — это обычная система ИИ (chatGPT?), которая понимает человеческий язык.
Но я спрошу то, чего вы действительно не ожидали:
— Вопрос 1: Что бы вы сделали, чтобы найти местоположение этой почты в MyOs?
— Вопрос 2: Что бы вы сделали, чтобы найти эту почту в следующий раз позже?
Я пока оставлю эти вопросы без ответа и подожду вашего ответа.
Жду ответа…
.
.
.
Хмм. Где здесь моя клавиша «break»… Ох… Это ^\ (намного мощнее, чем ^C)
Я слышу, как вы спрашиваете, почему у нас два API хранилища? И файлы, и базы данных хранят информацию, так что же делает хранение электронной почты в базе данных более (или менее) подходящим, чем в файловой системе? Я думаю, что на самом деле были попытки объединить их, но из этого ничего не вышло. Я думаю, почему люди используют БД вместо файлов, потому что в БД есть система для связывания одного фрагмента данных с другим. В файлах приходится придумывать свою систему.
Но да. Это все хранилище. Должен быть единый способ доступа ко всем данным. Кроме того, должен быть единый способ доступа к неограниченному пространству для хранения.
Текущая ситуация с хранилищем следующая: DB API находится поверх API файловой системы, поэтому у нас есть еще два уровня абстракции от земли, которые являются драйвером логического диска для получения большого количества дискового пространства, которое, в свою очередь, зависит от физического водители уровня.
Из своего опыта я знаю, что большинство систем баз данных тесно взаимодействует с файловой системой, создавая один-два файла, которые содержат все данные базы данных. Этот подход используется в MongoDB, Oracle, Navision, Progress. Существуют и другие базы данных, такие как MySQL, Dbase, которые используют набор файлов или даже один файл для одной таблицы. И я знаю только одну систему баз данных — Informix — которая создала специальный раздел и работала с ним на уровне API, эквивалентном API файловой системы. Это единственный пример, когда API базы данных работает горизонтально с API файловой системы или через него.
База данных Informix работала хорошо, но пользователь не мог видеть даже части хранимых данных — разделы были скрыты и доступны только для чтения извне. Более того, раздел не монтировался и показывался менеджерам разделов как пустое место.
Но это была первая попытка трактовать базу данных как файловую систему или даже сделать так, чтобы файловая система действовала как база данных.
Но давайте теперь посмотрим, сколько памяти у нас есть перед появлением новых суперкомпьютеров: Этот мощный компьютер имеет 12 ТБ ОЗУ. Для нашей теории IPCT это означает, что мы уже имеем примерно бесконечную силовую ситуацию, которую можно и нужно запрограммировать иначе. Еще один пример постоянно растущей вычислительной мощности я нашел здесь: компьютер [пока это только материнская плата] от Gigabait. Он имеет 120 ТБ общего хранилища. Он также выглядит хорошим кандидатом на бесконечную мощность.
Другая тенденция, связанная с использованием нового API и связанная с безграничной мощностью, началась уже сегодня (или даже вчера). Знаменитая аббревиатура «CRUD» стала «cRu.», потому что сейчас, в нашем современном обществе, появился новый тренд — все массивные данные (и мы все это даже понимаем) работают в режиме в основном для чтения. Данные имеют тенденцию только расти: сначала создается запись («c»), затем она считывается («R») сотни раз. Иногда данные обновляются («u») и почти никогда не удаляются («.»).
Я хочу сказать здесь, что при бесконечном хранении информация только растет, поэтому удаление будет запрещено, а иногда и помечено как удаленное. Нет необходимости повторно использовать дисковое пространство, если оно неограниченно. То же самое для обновлений: — каждое новое обновление будет переходить к следующему свободному блоку диска, а старые блоки связаны друг с другом для сохранения истории версий.
Современные файловые системы будут избыточны перед лицом бесконечного пространства для хранения. Все они иерархические (двумерные), как это было с 1980 года. Так что на уровне представления некоторые данные превышают все инструменты. Дело не в скорости (она бесконечна), а в поиске по базе файловых систем, что становится нетривиальным. Чтобы сделать прозрачным доступ к данным и одновременно реализовать файловую систему и базу данных, нам нужна трехмерная файловая система. И такая файловая система может быть реализована, если мы будем основывать каталоги не на иерархии, а на тегах:
Итак, я вижу будущее управления хранилищем с tagfs, которое будет иметьтри среза в каждый момент: базу данных, файловую систему и представление, как это делает mc (Midnight Commander). Ходят слухи об использовании tagfs на Amazon или eBay, но у них обоих нет уровней файловой системы и представления.
Все свои мысли об управлении памятью я раскрываю в следующих частях своих статей.
продолжение следует…
