Энтропийная система хранения данных или супер-сжатие до размера нескольких байт без потерь
Здравствуйте, меня зовут Соловьенко Сергей. Я не являюсь особо крутым специалистом или же ученым. Я специалист в области ИТ среднего уровня в одной несильно крупной американской компании медиа-провайдинга. Кроме того, я не люблю математику и не особо люблю оперировать абстрактными цифрами. Не так давно мне в голову пришла чудесная идея, которую я развивал в своем воображении. Гуглеж не привел ни к каким особым результатам. Я не смог обнаружить ничего близкого к тому, о чем собираюсь рассказать. Если это окажется действительно важным или действенным, то прошу считать данную систему не подлежащей монопольному использованию или коммерческому патентованию. То есть, я хочу чтобы это было доступно всем и каждому на безвозмездной основе. Если же моя идея окажется бесполезной, постарайтесь сильно не злиться. Я пытаюсь сделать мир немного лучше и делаю это так, как умею. Заранее спасибо за критику или изменения. Если вы считаете, что система не работает, то скажите, что нужно чтобы она заработала.
p.s. Чукча - не писатель и ни разу не рисователь, так что имеем то, что имеем.
И так к делу
Представим что у нас есть стандартный ПК, который имеет у себя на борту - программу, которая может:
Индексировать;
Извлекать данные из индекса;
Складывать извлеченные при помощи де-индексации данные на диск буфер.
На жестком диске данного ПК также имеется некий абстрактный файл - Энтропийный контейнер данных, объемом примерно 10гб. Он содержит бессмысленный абстрактный набор символов в Шестнадцатеричной системе счисления
Так же у нас есть быстрый диск-буфер для хранения де-индексированных файлов
У нас также есть фильм, хранить который (не говоря уже о передачи по сети) очень накладно. Он весит 12 гигабайтов. Как насчет сжатия его до размера 40-50 килобайт? И такой же распаковке на лету без использования сложных систем сжатия или математических вычислений? Такое возможно?
Представим, что фильм - это набор данных в Шестнадцатеричной системе.
Наш энтропийный файл имеет структуру таблицы, где есть номер строки и номер символа, помимо информации записанной в строках. Так же есть более высокий уровень - это блоки и кластеры (то есть структуры высшего уровня, которые мы описывать не будем).
Нехитрыми действиями мы можем записать информацию файла фильма, разбив его на блоки. Теперь запишем эти блоки короткими индексами, где первая цифра до точки, - это порядковый номер блока данных, вторая цифра, та, что после точки - это номер строки в таблице энтропийного хранилища, третья и четвертая в скобках через тире - это начало и конец неразрывной строки данных в той же таблице. Фрагментация нужна для того, чтобы файл хранилища был меньшего объема и нагрузка при индексировании и сборке была не слишком высокой.
Теперь наш фильм это не 12 гигабайт данных, а небольшой файл, содержащий некие индексы. Данная операция, равно, как и обратная, содержит минимум математических действий, которые не особо нагружают процессор. В обратном представлении файл фильма собирается налету из энтропийного хранилища по индекс-инструкциям во временный буфер и сразу же при необходимости воспроизводится.
Вы можете сказать, что количества символов в энтропийном файле не хватит для индексации файлов большого объема или же индекс-файл инструкций будет слишком велик из-за малого числа совпадений, потому что короткие неразрывные строки будут иметь всего по 3-4 символа. Получается, что этот метод хоть и сжимает файл, но несущественно. На этот случай есть инструкции чтения "Через". То есть, мы начинаем читать те же строки, но к примеру через символ или через два, или 2 через 2, или 5 через 12 и т.д. и получаем еще один массив данных из первого. В таком случае увеличивая число "через" и используя разные комбинации, мы получаем исчислимо бесконечный массив данных. В данном случае мы получаем уже достаточное количество совпадений, чтобы индексировать практически любой файл.
Это уже неплохо, но как насчет файла индекс-инструкций фильма состоящего из всего нескольких символов? Мы можем сделать и так. Для этого берем наш индекс, состоящий из символов десятичной системы, точек и скобок, конвертируем его в шестнадцатеричный код и индексируем при помощи нашего энтропийного файла. Затем просто указываем какого уровня эта инструкция. Например, нулевой уровень - это файл индекса, из которого собирается конечный файл и таких уровней может быть столько, сколько нужно для сжатия файла до нужного нам размера, причем абсолютно БЕЗ ПОТЕРЬ!
Скажите, реально ли это? Почему бы не использовать это везде? Представьте теперь какие возможности это нам дает? Если на двух оконечных устройствах находятся идентичные энтропийные хранилища, передавая по сети лишь индекс-инструкцию, мы можем передавать огромные количества данных, фактически их не передавая. Связь в дальних уголках стран третьего мира на основе 2g поколения связи, видеосвязь через континенты в ультра качестве и при минимальных задержках, дальняя космическая связь без потерь и передача данных в огромных объемах (например, передача данных в колонию на марсе), отказ от волоконно-оптических магистралей и сложных физических кабельных систем, освобождение огромных систем хранилищ файлов, после полной индексации всех данных.
На все это изначально меня натолкнули две вещи:
1. Когда-то мой отец научил меня шифру, который ни один дешифратор не может взломать, не имея инструкций. Берутся две газеты периодического издания и раздаются двум людям. Один из них шифрует таким образом, что каждая буква шифруется алгоритмом: номер страницы, номер строки и номер цифры слева направо. Таким образом, тот, кто перехватит данные, не сможет прочитать их, не имея инструкций и при условии, что текст будет не слишком длинным, исключая возможность применения метода совпадений. Также каждый раз можно менять газету на сегодняшнюю или покупать газету и ждать ровно две недели.
2. Вавилонская библиотека. Что это такое можете загуглить. Если вкратце, то могу попробовать описать одну часть аспекта. Допустим если посадить тысячу обезьян за тысячу пишущих машинок, и они будут иметь бесконечное количество времени, то одна из них, рано или поздно, напишет второй том мертвых душ Гоголя, просто бессмысленно барабаня по кнопкам машинки. Но на самом деле, структура библиотеки несколько сложнее.
Спасибо, что дочитали до этого момента, мне приятно :-) Пишите, что вы об этом думаете.