Сравните хранение файлов на компьютере и книг в библиотеке
Обновлено: 03.07.2024
Если верить научным журналистам, экспертам в области ИТ и поставщикам цифровых хранилищ и сетевой инфраструктуры, уже сейчас проходят лабораторные испытания устройства, способные хранить все данные в Библиотеке Конгресса или передавать их по сети за считанные секунды. моменты. К этому списку невероятных утверждений я хотел бы добавить еще одно: по самым скромным оценкам, я ежемесячно передаю в Библиотеку Конгресса данных на сумму, превышающую объем Библиотеки Конгресса.
От пользователя Flickr MysteryBee (Хенрик Беннетсен) согласно лицензии CC BY-SA 2.0
Очевидно, что это не имеет никакого смысла, но позвольте мне объяснить. Вы, возможно, заметили, что «данные, хранящиеся в Библиотеке Конгресса» стали популярной, хотя и необычной, единицей измерения емкости (и темой предыдущего сообщения в блоге Библиотеки Конгресса). Вместо этого более осторожные комментаторы используют «данные, представленные оцифрованными коллекциями печатных изданий Библиотеки Конгресса». Мое неполное исследование (тем не менее, подтвержденное Википедией) предполагает, что в тех случаях, когда цитируется конкретное число, это число чаще всего составляет 10 терабайт (и, что любопытно, программа веб-архивирования Библиотеки Конгресса упоминается в Википедии, чтобы проиллюстрировать, что такое «терабайт»). Откуда 10 терабайт?
Самое раннее официальное упоминание числа 10 терабайт относится к масштабному исследованию, проведенному в 2000 году профессорами iSchool Калифорнийского университета в Беркли Питером Лайманом и Хэлом Вэрианом, в ходе которого они попытались измерить, сколько информации было произведено в мире за тот год. В нем они с небольшой помпой отмечают, что 10 терабайт — это размер печатных коллекций Библиотеки Конгресса. Впоследствии они уточняют свои предположения в приложении: в среднем книга состоит из 300 страниц, сканируется как TIFF с разрешением 600 DPI и, наконец, сжимается, в результате чего размер книги оценивается в 8 мегабайт. На момент публикации исследования они предполагали, что коллекция печатных изданий Библиотеки Конгресса насчитывала 26 миллионов книг. Даже принимая эти предположения как должное, математика дает число, намного более близкое к 200 терабайтам. Разумеется, авторы отмечают в скобках в другом месте исследования, что размер коллекции печатных изданий Библиотеки Конгресса составляет 208 терабайт. Никакого объяснения расхождению с другим указанным числом не предлагается.
От пользователя Flickr mandiberg согласно лицензии CC BY-SA 2.0
Однако по какой-то причине в воображении публики закрепилась именно цифра в 10 терабайт. Безусловно, 10 терабайт — это впечатляющий объем данных, но он гораздо менее впечатляющий, чем объем данных, который на самом деле содержится в Библиотеке Конгресса (и, я подозреваю, даже если считать только печатные коллекции). Хотя я недостаточно умен и наивен, чтобы предложить более реалистичную цифру, возвращаясь к своей первоначальной провокации, я хотел продолжить обсуждение цифровой коллекции, которую хорошо знаю: веб-архив Библиотеки Конгресса.
Как объяснялось ранее в The Signal, в настоящее время мы заключаем договор с Интернет-архивом на выполнение крупномасштабного веб-сканирования. Одной из дополнительных задач, вытекающих из этой договоренности, является то, что сгенерированные данные веб-архива (примерно 5 терабайт в месяц) должны передаваться с Западного побережья в Библиотеку Конгресса. Это оказывается нетривиальным; может потребоваться большая часть месяца при почти постоянной передаче данных через Интернет2 для перемещения 10 терабайт данных. При всем оптимизме в отношении передачи данных «Библиотеки Конгресса» по сетям размещение данных на физических носителях и последующая отправка этих носителей остается удивительно конкурентоспособной альтернативой. Показательный пример: несмотря на всю эфирность и технологическую изощренность так называемых облачных сервисов, по крайней мере один из крупных провайдеров позволяет пользователям загружать свои данные сравнительно обыденным способом отправки по почте на жесткий диск.
Конечно, перенос — это только начальный этап в нашем управлении данными веб-архива; инфраструктура требует комплексного подхода, если учесть требования к избыточному хранилищу на ленте и/или вращающемся диске, полосе пропускания внутренней сети и циклам процессора для копирования, индексирования, проверки и т. д. Подводя итог, я сомневаюсь, что у нас есть резервные мощности для хранения и обработки гораздо большего количества данных «библиотек Конгресса», чем сейчас (хотя, возможно, это самоочевидно).
Достаточно сказать, что я с нетерпением жду того дня, когда производители ИТ-оборудования смогут законно заявлять, что обрабатывают объемы данных, соизмеримые с тем, что фактически хранится в Библиотеке Конгресса (каким бы ни был этот объем). Тем временем, однако, я полагаю, что согласился бы на популярное принятие дробных единиц емкости «Библиотеки Конгресса» (например, «0,000001% данных, хранящихся в Библиотеке Конгресса») — скорее всего, не более или менее реалистичнее, чем может быть фактическое число, но, по крайней мере, оно более уместно увеличит объем данных, которыми располагает Библиотека Конгресса.
10 комментариев
У меня всегда были проблемы с объемом 10 ТБ. Это одно из тех чисел, которые вы видите со слишком большой частотой, без какой-либо ссылки (что-то вроде «мы используем только 10% нашего мозга», чему я действительно склонен верить в случае с некоторыми звездами реалити-шоу) относиться серьезно. Библиотека Конгресса, по сути, является мистикой, неизвестной большинству американцев, и представляет собой романтический идеал сохранения и данных, и, как таковая, вызывает воспоминания о данных.
Только текст Британской энциклопедии 2002 года без форматирования занимает около 264 ГБ, поэтому нелепо предполагать, что размер LoC превышает этот показатель всего в 40 раз.
Даже при работе с необработанным текстом кодировка может иметь большое значение. Unicode UTF-8 и UTF-16 могут значительно увеличить размеры, используемые в документе. Для большинства документов на английском и других языках, использующих латиницу, кодировка Unicode автоматически удваивает размер файла. По общему признанию, это необходимо только тогда, когда в исходном документе используются символы, отсутствующие в ASCII, но это, безусловно, заслуживает внимания.
Я использую это число в качестве примечания к проекту, который, если я ошибаюсь, ни на кого не повлияет каким-либо важным образом, и я позволю себе привести число 208 ТБ. как «Очень консервативная оценка около 2000 года», что, на мой взгляд, гораздо лучше отражает реальность, чем цифра в 10 ТБ.
Спасибо за сообщение!
Мне очень нравится этот район. Большое спасибо!
Персонажи или изображения…. 26 миллионов книг по 500 страниц по 2000 символов на страницу при 1 байте на символ — это 26 ТБ
Если мы собираемся быть настолько техническими во всем, почему бы не определить реальное количество ТБ, исходя из 8 МБ на книгу, в 26 миллионов книг, что ближе к 198 ТБ.
26 000 000 * 8 / 1024 / 1024 = 198,36 ТБ, а не 208 ТБ, где использовалось ленивое деление (1000 вместо 1024).
Мне нравится Оргкомитет, но я также рассматриваю его как щупальце государственной власти с мертвой хваткой информации. Так что меня интересует его размер и соответствующий размер интернета, точно так же, как меня интересовал бы размер двух бойцов при размещении ставок перед матчем. Жаль, что админы Оргкомитета, по-видимому, решили, что взвесить их бойца слишком сложно.
Эти числа предполагают полный символ ASCII 256 для каждой буквы, цифры и пробела.
Базовое сжатие без потерь уменьшило бы эти размеры файлов примерно в 8 раз, что дало бы чуть более 3 ТБ для коллекции печатного текста LoC
Спасибо, Джим Майклс, за один из немногих разумных расчетов… по общему признанию, без учета диаграмм и рисунков в этих книгах. Тем не менее, если мы просто смотрим на хранящуюся информацию, представленную языком, то число 3 ТБ кажется подходящим.
Что действительно интересно, так это то, как технические возможности превзошли создание реальных данных (а не таких вещей, как статические потоки видеонаблюдения или веб-записи для каждой покупки бананов), реальных знаний, потерять которые было бы преступлением. В качестве примера можно привести недавнее объявление Toshiba о флэш-памяти емкостью 1,33 Тбит, которая может быть сложена по 16 штук в одном полукорпусе (одна микросхема) и имеет емкость 2,66 терабайт = примерно 1 LOC 🙂
Возможно, "расхождение" — это разница в размере между:
a) Просто текст книги
1 байт на букву.
26 миллионов * 1 МБ на книгу = 26 ТБ в сжатом виде ~ 10 ТБ
b) Сохранение отсканированного изображения каждой страницы
«TIFF 600 DPI» может означать «изображение» каждой страницы,
где вы увидите каждую складку и изменение шрифта.
26 миллионов * 500 страниц * 50 КБ страница в формате TIFF = 650 ТБ
при сжатии ~200 ТБ
(Изображения сжимаются хуже, чем текст.)
Можем ли мы посчитать картинки в книге, используя эквивалентность «картинка стоит тысячи слов» (и используя 5 букв в слове плюс пробел в качестве приближения)?
Графика более сложна, но часто может быть представлена меньшим количеством информации, чем требуется для сканирования с высоким разрешением — например, графики данных могут быть даже менее информативными, чем текст, занимающий то же место, и только штриховые рисунки. немного больше.
Художественные произведения и фотографии с высоким разрешением могут содержать даже больше информации, чем способны воспринять человеческий глаз и мозг, но является ли такой уровень детализации «информацией»? В целях сбора знаний (например,, для книги об искусстве эпохи Возрождения), скан «Моны Лизы» Да Винчи в среднем разрешении не уступает оригиналу. Для художественной оценки, конечно, другое дело.
Для книг моим стандартом будет следующий: "Минимальный объем информации, который потребуется для точного воспроизведения печатного оригинала с исходным разрешением", будь то сканирование, распознавание символов или математическое представление (например, векторная графика).
Добавить комментарий
Данный блог регулируется общими правилами уважительной гражданской беседы. Вы несете полную ответственность за все, что публикуете. Содержание всех комментариев становится общественным достоянием, если прямо не указано иное. Библиотека Конгресса не контролирует публикуемый контент. Тем не менее, Библиотека Конгресса может отслеживать любой пользовательский контент по своему усмотрению и оставляет за собой право удалять контент по любой причине без согласия. Бесплатные ссылки на сайты расцениваются как спам и могут привести к удалению комментариев. Кроме того, мы оставляем за собой право по собственному усмотрению лишить пользователя права размещать контент на сайте Библиотеки. Ознакомьтесь с нашей Политикой комментариев и публикаций.
Файлы, блоки и объекты – это форматы хранения, которые хранят, организуют и представляют данные по-разному, каждый со своими возможностями и ограничениями. Хранилище файлов организует и представляет данные в виде иерархии файлов в папках; блочное хранилище разбивает данные на произвольно организованные тома одинакового размера; а объектное хранилище управляет данными и связывает их со связанными метаданными.
Контейнеры очень гибкие и обеспечивают невероятное масштабирование доставки приложений и хранилища.
Что такое хранилище файлов?
Хранилище файлов, также называемое файловым или файловым хранилищем, — это именно то, о чем вы думаете: данные хранятся в виде единого фрагмента информации внутри папки, точно так же, как вы упорядочиваете листы бумаги внутри папка манила. Когда вам нужно получить доступ к этому фрагменту данных, ваш компьютер должен знать путь, чтобы найти его. (Осторожно — это может быть долгий и извилистый путь.) Данные, хранящиеся в файлах, упорядочиваются и извлекаются с использованием ограниченного количества метаданных, которые сообщают компьютеру, где именно хранится сам файл. Это как библиотечный каталог для файлов данных.
Представьте себе чулан, полный картотечных шкафов. Каждый документ расположен в некоторой логической иерархии — по шкафу, по ящику, по папке, затем по листу бумаги. Вот откуда взялся термин иерархическое хранилище, и это файловое хранилище. Это самая старая и наиболее широко используемая система хранения данных для прямых и сетевых систем хранения, и вы, вероятно, использовали ее на протяжении десятилетий. Каждый раз, когда вы получаете доступ к документам, сохраненным в файлах на вашем персональном компьютере, вы используете хранилище файлов. Хранилище файлов имеет широкие возможности и может хранить что угодно. Он отлично подходит для хранения массива сложных файлов и обеспечивает довольно быструю навигацию для пользователей.
Проблема в том, что, как и в случае с картотекой, виртуальный ящик открывается только до определенного предела. Файловые системы хранения должны масштабироваться за счет добавления новых систем, а не за счет увеличения емкости.
Что такое блочное хранилище?
Блочное хранилище разбивает данные на блоки — понимаете? — и сохраняет их как отдельные части. Каждому блоку данных присваивается уникальный идентификатор, который позволяет системе хранения размещать меньшие фрагменты данных там, где это наиболее удобно. Это означает, что некоторые данные могут храниться в среде Linux®, а некоторые — в модуле Windows.
Блочное хранилище часто настраивается таким образом, чтобы отделить данные от среды пользователя и распределить их по нескольким средам, которые могут лучше обслуживать данные. А затем, когда данные запрашиваются, базовое программное обеспечение хранилища повторно собирает блоки данных из этих сред и представляет их обратно пользователю. Обычно он развертывается в средах сети хранения данных (SAN) и должен быть привязан к функционирующему серверу.
Поскольку в блочном хранилище нет единого пути к данным, как в файловом хранилище, их можно быстро извлечь. Каждый блок живет сам по себе и может быть разделен, чтобы к нему можно было получить доступ в другой операционной системе, что дает пользователю полную свободу настройки своих данных. Это эффективный и надежный способ хранения данных, простой в использовании и управлении. Он хорошо работает с предприятиями, выполняющими крупные транзакции, и с теми, которые развертывают огромные базы данных. Это означает, что чем больше данных вам нужно хранить, тем лучше вы будете использовать блочное хранилище.
Однако есть и недостатки. Блочное хранилище может быть дорогим.Он имеет ограниченные возможности обработки метаданных, а это означает, что с ним нужно работать на уровне приложения или базы данных, а это еще одна проблема, о которой должен беспокоиться разработчик или системный администратор.
Что такое хранилище объектов?
Объектное хранилище, также известное как объектное хранилище, представляет собой плоскую структуру, в которой файлы разбиты на части и распределены по оборудованию. В объектном хранилище данные разбиваются на отдельные блоки, называемые объектами, и хранятся в одном репозитории, а не в виде файлов в папках или блоков на серверах.
Тома хранилища объектов работают как модульные единицы: каждый из них представляет собой автономный репозиторий, которому принадлежат данные, уникальный идентификатор, позволяющий найти объект в распределенной системе, и метаданные, описывающие данные. Эти метаданные важны и включают такие детали, как возраст, конфиденциальность/безопасность и непредвиденные обстоятельства доступа. Метаданные хранилища объектов также могут быть чрезвычайно подробными и способны хранить информацию о том, где было снято видео, какая камера использовалась и какие актеры представлены в каждом кадре. Для извлечения данных операционная система хранилища использует метаданные и идентификаторы, что позволяет лучше распределять нагрузку и позволяет администраторам применять политики, обеспечивающие более надежный поиск.
Конечно, есть и недостатки. Объекты не могут быть изменены — вы должны написать объект полностью сразу. Хранилище объектов также плохо работает с традиционными базами данных, потому что написание объектов — это медленный процесс, а написание приложения для использования API хранилища объектов не так просто, как использование хранилища файлов.
Почему Red Hat?
Не знаете, какой формат хранения подходит для вашего проекта? С Red Hat Data Services вам не нужно выбирать. Red Hat Ceph Storage предоставляет SDS на стандартном для отрасли оборудовании по вашему выбору. Благодаря блочному, объектному и файловому хранилищу, объединенному в 1 платформу, оно эффективно и автоматически управляет всеми вашими данными. Red Hat Gluster Storage — это платформа SDS, предназначенная для удовлетворения требований традиционного файлового хранилища — задач с большой емкостью, таких как резервное копирование и архивирование, а также высокопроизводительных задач аналитики и виртуализации.
Как читать телефонные номера в академической библиотеке
Библиотеки используют системы классификации для организации книг на полках. В системе классификации используются буквы и/или цифры (номера звонков), чтобы упорядочить книги так, чтобы книги по одной и той же теме были вместе. Такое расположение приводит к «случайному просмотру»: вы находите одну книгу в каталоге, подходите к полке, а рядом с ней лежит еще лучшая книга.
Из онлайн-каталога на полку
Библиотеки в Соединенных Штатах обычно используют либо Систему классификации Библиотеки Конгресса (LC), либо Систему десятичной классификации Дьюи для организации своих книг. Большинство академических библиотек используют LC, а большинство публичных библиотек и школьных библиотек K-12 используют Dewey.
Анатомия телефонного номера Библиотеки Конгресса
Название книги: Война без цензуры: СМИ и Вьетнам
Автор: Дэниел С. Халлин
Номер телефона: DS559.46 .H35 1986
Первые две строки описывают тему книги.
DS559.45 = Вьетнамский конфликт
Третья строка часто представляет фамилию автора.
H = Халлин
Последняя строка представляет дату публикации.
Советы по поиску книг на полке
Читать телефонные номера построчно.
LB
Прочитайте первую строку в алфавитном порядке:
A, B, BF, C, D. L, LA, LB, LC, M, ML.
2395
Прочитайте вторую строку как целое число:
1, 2, 3, 45, 100, 101, 1000, 2000, 2430.
.C65
Третья строка представляет собой комбинацию буквы и цифры. Прочитайте письмо по алфавиту. Прочитайте число как десятичное, например:
.C65 = .65 .C724 = .724
Некоторые телефонные номера содержат более одной комбинации букв и цифр.
1991
Последняя строка — год издания книги. Читать в хронологическом порядке:
1985, 1991, 1992.
Если верить научным журналистам, экспертам в области ИТ и поставщикам цифровых хранилищ и сетевой инфраструктуры, уже сейчас проходят лабораторные испытания устройства, способные хранить все данные в Библиотеке Конгресса или передавать их по сети за считанные секунды. моменты. К этому списку невероятных утверждений я хотел бы добавить еще одно: по самым скромным оценкам, я ежемесячно передаю в Библиотеку Конгресса данных на сумму, превышающую объем Библиотеки Конгресса.
От пользователя Flickr MysteryBee (Хенрик Беннетсен) согласно лицензии CC BY-SA 2.0
Очевидно, что это не имеет никакого смысла, но позвольте мне объяснить. Вы, возможно, заметили, что «данные, хранящиеся в Библиотеке Конгресса» стали популярной, хотя и необычной, единицей измерения емкости (и темой предыдущего сообщения в блоге Библиотеки Конгресса). Вместо этого более осторожные комментаторы используют «данные, представленные оцифрованными коллекциями печатных изданий Библиотеки Конгресса». Мое неполное исследование (тем не менее, подтвержденное Википедией) предполагает, что в тех случаях, когда цитируется конкретное число, это число чаще всего составляет 10 терабайт (и, что любопытно, программа веб-архивирования Библиотеки Конгресса упоминается в Википедии, чтобы проиллюстрировать, что такое «терабайт»). Откуда 10 терабайт?
Самое раннее официальное упоминание числа 10 терабайт относится к масштабному исследованию, проведенному в 2000 году профессорами iSchool Калифорнийского университета в Беркли Питером Лайманом и Хэлом Вэрианом, в ходе которого они попытались измерить, сколько информации было произведено в мире за тот год. В нем они с небольшой помпой отмечают, что 10 терабайт — это размер печатных коллекций Библиотеки Конгресса. Впоследствии они уточняют свои предположения в приложении: в среднем книга состоит из 300 страниц, сканируется как TIFF с разрешением 600 DPI и, наконец, сжимается, в результате чего размер книги оценивается в 8 мегабайт. На момент публикации исследования они предполагали, что коллекция печатных изданий Библиотеки Конгресса насчитывала 26 миллионов книг. Даже принимая эти предположения как должное, математика дает число, намного более близкое к 200 терабайтам. Разумеется, авторы отмечают в скобках в другом месте исследования, что размер коллекции печатных изданий Библиотеки Конгресса составляет 208 терабайт. Никакого объяснения расхождению с другим указанным числом не предлагается.
От пользователя Flickr mandiberg согласно лицензии CC BY-SA 2.0
Однако по какой-то причине в воображении публики закрепилась именно цифра в 10 терабайт. Безусловно, 10 терабайт — это впечатляющий объем данных, но он гораздо менее впечатляющий, чем объем данных, который на самом деле содержится в Библиотеке Конгресса (и, я подозреваю, даже если считать только печатные коллекции). Хотя я недостаточно умен и наивен, чтобы предложить более реалистичную цифру, возвращаясь к своей первоначальной провокации, я хотел продолжить обсуждение цифровой коллекции, которую хорошо знаю: веб-архив Библиотеки Конгресса.
Как объяснялось ранее в The Signal, в настоящее время мы заключаем договор с Интернет-архивом на выполнение крупномасштабного веб-сканирования. Одной из дополнительных задач, вытекающих из этой договоренности, является то, что сгенерированные данные веб-архива (примерно 5 терабайт в месяц) должны передаваться с Западного побережья в Библиотеку Конгресса. Это оказывается нетривиальным; может потребоваться большая часть месяца при почти постоянной передаче данных через Интернет2 для перемещения 10 терабайт данных. При всем оптимизме в отношении передачи данных «Библиотеки Конгресса» по сетям размещение данных на физических носителях и последующая отправка этих носителей остается удивительно конкурентоспособной альтернативой. Показательный пример: несмотря на всю эфирность и технологическую изощренность так называемых облачных сервисов, по крайней мере один из крупных провайдеров позволяет пользователям загружать свои данные сравнительно обыденным способом отправки по почте на жесткий диск.
Конечно, перенос — это только начальный этап в нашем управлении данными веб-архива; инфраструктура требует комплексного подхода, если учесть требования к избыточному хранилищу на ленте и/или вращающемся диске, полосе пропускания внутренней сети и циклам процессора для копирования, индексирования, проверки и т. д. Подводя итог, я сомневаюсь, что у нас есть резервные мощности для хранения и обработки гораздо большего количества данных «библиотек Конгресса», чем сейчас (хотя, возможно, это самоочевидно).
Достаточно сказать, что я с нетерпением жду того дня, когда производители ИТ-оборудования смогут законно заявлять, что обрабатывают объемы данных, соизмеримые с тем, что фактически хранится в Библиотеке Конгресса (каким бы ни был этот объем). Тем временем, однако, я полагаю, что согласился бы на популярное принятие дробных единиц емкости «Библиотеки Конгресса» (например, «0,000001% данных, хранящихся в Библиотеке Конгресса») — скорее всего, не более или менее реалистичнее, чем может быть фактическое число, но, по крайней мере, оно более уместно увеличит объем данных, которыми располагает Библиотека Конгресса.
10 комментариев
У меня всегда были проблемы с объемом 10 ТБ.Это одно из тех чисел, которые вы видите со слишком большой частотой, без какой-либо ссылки (что-то вроде «мы используем только 10% нашего мозга», чему я действительно склонен верить в случае с некоторыми звездами реалити-шоу) относиться серьезно. Библиотека Конгресса, по сути, является мистикой, неизвестной большинству американцев, и представляет собой романтический идеал сохранения и данных, и, как таковая, вызывает воспоминания о данных.
Только текст Британской энциклопедии 2002 года без форматирования занимает около 264 ГБ, поэтому нелепо предполагать, что размер LoC превышает этот показатель всего в 40 раз.
Даже при работе с необработанным текстом кодировка может иметь большое значение. Unicode UTF-8 и UTF-16 могут значительно увеличить размеры, используемые в документе. Для большинства документов на английском и других языках, использующих латиницу, кодировка Unicode автоматически удваивает размер файла. По общему признанию, это необходимо только тогда, когда в исходном документе используются символы, отсутствующие в ASCII, но это, безусловно, заслуживает внимания.
Я использую это число в качестве примечания к проекту, который, если я ошибаюсь, ни на кого не повлияет каким-либо важным образом, и я позволю себе привести число 208 ТБ. как «Очень консервативная оценка около 2000 года», что, на мой взгляд, гораздо лучше отражает реальность, чем цифра в 10 ТБ.
Спасибо за сообщение!
Мне очень нравится этот район. Большое спасибо!
Персонажи или изображения…. 26 миллионов книг по 500 страниц по 2000 символов на страницу при 1 байте на символ — это 26 ТБ
Если мы собираемся быть настолько техническими во всем, почему бы не определить реальное количество ТБ, исходя из 8 МБ на книгу, в 26 миллионов книг, что ближе к 198 ТБ.
26 000 000 * 8 / 1024 / 1024 = 198,36 ТБ, а не 208 ТБ, где использовалось ленивое деление (1000 вместо 1024).
Мне нравится Оргкомитет, но я также рассматриваю его как щупальце государственной власти с мертвой хваткой информации. Так что меня интересует его размер и соответствующий размер интернета, точно так же, как меня интересовал бы размер двух бойцов при размещении ставок перед матчем. Жаль, что админы Оргкомитета, по-видимому, решили, что взвесить их бойца слишком сложно.
Эти числа предполагают полный символ ASCII 256 для каждой буквы, цифры и пробела.
Базовое сжатие без потерь уменьшило бы эти размеры файлов примерно в 8 раз, что дало бы чуть более 3 ТБ для коллекции печатного текста LoC
Спасибо, Джим Майклс, за один из немногих разумных расчетов… по общему признанию, без учета диаграмм и рисунков в этих книгах. Тем не менее, если мы просто смотрим на хранящуюся информацию, представленную языком, то число 3 ТБ кажется подходящим.
Что действительно интересно, так это то, как технические возможности превзошли создание реальных данных (а не таких вещей, как статические потоки видеонаблюдения или веб-записи для каждой покупки бананов), реальных знаний, потерять которые было бы преступлением. В качестве примера можно привести недавнее объявление Toshiba о флэш-памяти емкостью 1,33 Тбит, которая может быть сложена по 16 штук в одном полукорпусе (одна микросхема) и имеет емкость 2,66 терабайт = примерно 1 LOC 🙂
Возможно, "расхождение" — это разница в размере между:
a) Просто текст книги
1 байт на букву.
26 миллионов * 1 МБ на книгу = 26 ТБ в сжатом виде ~ 10 ТБ
b) Сохранение отсканированного изображения каждой страницы
«TIFF 600 DPI» может означать «изображение» каждой страницы,
где вы увидите каждую складку и изменение шрифта.
26 миллионов * 500 страниц * 50 КБ страница в формате TIFF = 650 ТБ
при сжатии ~200 ТБ
(Изображения сжимаются хуже, чем текст.)
Можем ли мы посчитать картинки в книге, используя эквивалентность «картинка стоит тысячи слов» (и используя 5 букв в слове плюс пробел в качестве приближения)?
Графика более сложна, но часто может быть представлена меньшим количеством информации, чем требуется для сканирования с высоким разрешением — например, графики данных могут быть даже менее информативными, чем текст, занимающий то же место, и только штриховые рисунки. немного больше.
Художественные произведения и фотографии с высоким разрешением могут содержать даже больше информации, чем способны воспринять человеческий глаз и мозг, но является ли такой уровень детализации «информацией»? Для целей сбора знаний (например, для книги об искусстве эпохи Возрождения) отсканированное изображение «Моны Лизы» да Винчи в среднем разрешении не уступает оригиналу. Для художественной оценки, конечно, другое дело.
Для книг моим стандартом будет следующий: "Минимальный объем информации, который потребуется для точного воспроизведения печатного оригинала с исходным разрешением", будь то сканирование, распознавание символов или математическое представление (например, векторная графика).
Добавить комментарий
Данный блог регулируется общими правилами уважительной гражданской беседы. Вы несете полную ответственность за все, что публикуете. Содержание всех комментариев становится общественным достоянием, если прямо не указано иное.Библиотека Конгресса не контролирует публикуемый контент. Тем не менее, Библиотека Конгресса может отслеживать любой пользовательский контент по своему усмотрению и оставляет за собой право удалять контент по любой причине без согласия. Бесплатные ссылки на сайты расцениваются как спам и могут привести к удалению комментариев. Кроме того, мы оставляем за собой право по собственному усмотрению лишить пользователя права размещать контент на сайте Библиотеки. Ознакомьтесь с нашей Политикой комментариев и публикаций.
Читайте также: