Возможно, не все знают, но Хабр не отстаёт от лидеров рынка в предоставлении хранилища данных на своих серверах всем зарегистрированным пользователям. Оно не такое большое, как у Гугла или Яндекса, всего лишь мегабайты, но позволит хранить десяток черновиков статей и другие данные, привязанные к сайту, чтобы использовать их вместе с материалами сайта без кроссдоменного доступа в скриптах. Будем считать, что на все нужды нам достаточно 1 МБ символов Unicode. Что предлагает система?
Предоставляемые типы и объёмы:
1) В виде черновиков статей (видимы только автору). Каждый черновик хранит не менее 100 тыс. символов. Черновиков — условно неограниченное количество.
2) В виде заметок к пользователям (видимы только автору, но никто не гарантирует уязвимостей, утечки и удаления при закрытии аккаунта пользователем). Одна заметка хранит до 65535 символов. Заметок — столько, сколько авторов (но не проверялось предельное число заметок системы). Нельзя написать заметку к себе.
3) В личных сообщениях собеседникам. (Нельзя написать самому себе).
4) В публичном сообщении на персональной странице, до 65 К (кроме того, что публичное, оно ещё на другом смежном домене 3-го уровня).
5) (немного публично (с)), в файлах habrastorage, если никому не говорить их имена, то можно хранить много данных довольно компактно и почти незаметно. Но они неизвестно когда удалятся, поэтому все версии будут открыты для чтения всем неопределённое время.
К этим богатым возможностям остаётся написать драйвера, чтобы обращаться примерно как к API localStorage браузера. Понадобятся оптимизационные прагмы (указания о будущем формате использования), чтобы распределение данных было эффективно.
Перечисленные способы не приведут к неудобствам других читателей, если только не рассматривать случаи ошибочных публикаций черновиков и личных сообщений другим без предупреждения. Даже публикация публичного сообщения на личной странице может быть скрыта тегом HTML и не будет видимой читателям.
Итого, чтобы хранить 1 МБ символов, нужно иметь 16 заметок или 10 (и меньше) черновиков. Наиболее защищённый от ошибок способ — создание заметок. Поэтому не будем рассматривать другие способы, хотя черновик может хранить блок информации большего размера.
Наоборот, не всегда нужны большие блоки информации. Чаще всего — небольшие, и здесь заметки тоже выигрывают, потому что они показываются с ограниченным сайдбаром, а черновики — с полным (в режиме чтения). В сумме, получается меньше нагрузочного оформления, лишнего траффика.
Не совсем удобно то, что заметки списком отображаются полностью, а не первые N символов. Это может быть удобно для дампа заметок или другой причины полного прочтения. Но неудобно для просмотра индексирующей информации, которая могла бы храниться в начале каждой заметки. Но раз такого нет, под индекс выделим 1-2 заметки (две — для дублирования индекса, как в настоящих дисковых системах) и будем читать почти всегда только отдельные заметки, заранее зная имена пользователей для них.
Тогда нам остаётся выбрать 16 имён пользователей, и, возможно, завести личный read-only аккаунт, чтобы быть уверенным в его неудалении, для содержания индексного файла. Поскольку бывакет нужно читать малые, но актуальные объёмы, несколько аккаунтов в нашей файловой системе надо выделить под файлы малого размера. Не все аккаунты будут содержать заметки большого объёма. Выгоднее иметь в несколько раз больше имён аккаунтов, чем писать в один длинные строки и быть вынужденным читать неизменяющиеся данные в строке. Поэтому для файловой системы нужно заготовить в несколько раз больше имён аккаунтов, чем 16. Например, 100.
В паре дублей индексов будем содержать таблицу распределения файлов по именам аккаунтов.
Надо заметить, что использование чьих-то имён никак не «нагружает» владельцев аккаунтов. Для них заметки не существуют, это — личная информация пользователя. Формально — о них, но на самом деле — произвольная. Пользователи могут повредить файлы, удалив свой аккаунт. То же может сделать администрация, удалив аккаунт пользоваля или постирав записи-заметки.
Для надёжности, а также, для поддержания такой же системы у пользователей без аккаунтов, нужно иметь дублирующий сервер для хранения заметок. Ведение системы из 20-100 текстовых файлов значительно упростит работу с этим мегабайтом информации. На самом деле, она будет сильно структурированной информацией наподобие локального хранилища браузера, но располагаемое в сети. Работать с ним будет возможно на тех же принципах — через обращение к одноуровневой структуре (хешу, словарю). Строки в ней могут быть сериализованными структурами.
Вся файловая система будет работать на JS и через Ajax-запросы.
Продолжение следует, а пока сформулируем пожелания к владельцам этого бесплатного хостинга — может быть, они успеют что-то доработать ко времени релиза.
1. Список заметок очень желательно составлять из начал текстов, чтобы их использовать как индексы (100-300 символов);
2. Иметь список из 100 гарантированно неудаляемых юзеров с вычисляемыми именами типа aa00..aa99.
3. Иметь режим чтения списка и заметок без оформления — сэкономится 18K Байт на каждом запросе!
4. Сделать удаление картинок из стораджа автором, чтобы его можно было бы использовать в качестве публичных данных — например, писать статьи в формате картинок и публиковать исправления и комментарии к ним. Тогда достаточно будет иметь скрипт разворачивания текстов статей и исправлений из бинарных данных картинок. Поскольку читать смогут тольк опользователи скрипта, этот формат станет популярным среди разработчиков, в картинках уменьшится доля обзоров телефонов.
5. Не дублировать данные в input hidden, чтобы не утяжелять страницу заметки.
Пока пройдут переговоры и согласования, мы успеем написать драйвера для файловой системы, использующие как минимум описанные существующие возможности сайта. Поскольку они будут кроссдоменными, то даже неиспользование мощностей сайта не помешает работе хранилища на другом домене в похожем формате.
Проект — краундсорсинговый (как этот), коды будут выложены на Гитхабе. В качестве практических задач читателям остаются вопросы:
1. Какой максимальный объём одного сообщения ЛС держит система?
2. Какой максимальный объём статьи в черновике поддерживается? (Я проверил, что 100К хранится.)
3. Какой максимальный объём приватных данных суммарно можно хранить?
Предоставляемые типы и объёмы:
1) В виде черновиков статей (видимы только автору). Каждый черновик хранит не менее 100 тыс. символов. Черновиков — условно неограниченное количество.
2) В виде заметок к пользователям (видимы только автору, но никто не гарантирует уязвимостей, утечки и удаления при закрытии аккаунта пользователем). Одна заметка хранит до 65535 символов. Заметок — столько, сколько авторов (но не проверялось предельное число заметок системы). Нельзя написать заметку к себе.
3) В личных сообщениях собеседникам. (Нельзя написать самому себе).
4) В публичном сообщении на персональной странице, до 65 К (кроме того, что публичное, оно ещё на другом смежном домене 3-го уровня).
5) (немного публично (с)), в файлах habrastorage, если никому не говорить их имена, то можно хранить много данных довольно компактно и почти незаметно. Но они неизвестно когда удалятся, поэтому все версии будут открыты для чтения всем неопределённое время.
К этим богатым возможностям остаётся написать драйвера, чтобы обращаться примерно как к API localStorage браузера. Понадобятся оптимизационные прагмы (указания о будущем формате использования), чтобы распределение данных было эффективно.
Перечисленные способы не приведут к неудобствам других читателей, если только не рассматривать случаи ошибочных публикаций черновиков и личных сообщений другим без предупреждения. Даже публикация публичного сообщения на личной странице может быть скрыта тегом HTML и не будет видимой читателям.
Как использовать?
Итого, чтобы хранить 1 МБ символов, нужно иметь 16 заметок или 10 (и меньше) черновиков. Наиболее защищённый от ошибок способ — создание заметок. Поэтому не будем рассматривать другие способы, хотя черновик может хранить блок информации большего размера.
Наоборот, не всегда нужны большие блоки информации. Чаще всего — небольшие, и здесь заметки тоже выигрывают, потому что они показываются с ограниченным сайдбаром, а черновики — с полным (в режиме чтения). В сумме, получается меньше нагрузочного оформления, лишнего траффика.
Не совсем удобно то, что заметки списком отображаются полностью, а не первые N символов. Это может быть удобно для дампа заметок или другой причины полного прочтения. Но неудобно для просмотра индексирующей информации, которая могла бы храниться в начале каждой заметки. Но раз такого нет, под индекс выделим 1-2 заметки (две — для дублирования индекса, как в настоящих дисковых системах) и будем читать почти всегда только отдельные заметки, заранее зная имена пользователей для них.
Тогда нам остаётся выбрать 16 имён пользователей, и, возможно, завести личный read-only аккаунт, чтобы быть уверенным в его неудалении, для содержания индексного файла. Поскольку бывакет нужно читать малые, но актуальные объёмы, несколько аккаунтов в нашей файловой системе надо выделить под файлы малого размера. Не все аккаунты будут содержать заметки большого объёма. Выгоднее иметь в несколько раз больше имён аккаунтов, чем писать в один длинные строки и быть вынужденным читать неизменяющиеся данные в строке. Поэтому для файловой системы нужно заготовить в несколько раз больше имён аккаунтов, чем 16. Например, 100.
В паре дублей индексов будем содержать таблицу распределения файлов по именам аккаунтов.
Надо заметить, что использование чьих-то имён никак не «нагружает» владельцев аккаунтов. Для них заметки не существуют, это — личная информация пользователя. Формально — о них, но на самом деле — произвольная. Пользователи могут повредить файлы, удалив свой аккаунт. То же может сделать администрация, удалив аккаунт пользоваля или постирав записи-заметки.
Для надёжности, а также, для поддержания такой же системы у пользователей без аккаунтов, нужно иметь дублирующий сервер для хранения заметок. Ведение системы из 20-100 текстовых файлов значительно упростит работу с этим мегабайтом информации. На самом деле, она будет сильно структурированной информацией наподобие локального хранилища браузера, но располагаемое в сети. Работать с ним будет возможно на тех же принципах — через обращение к одноуровневой структуре (хешу, словарю). Строки в ней могут быть сериализованными структурами.
Вся файловая система будет работать на JS и через Ajax-запросы.
Продолжение следует, а пока сформулируем пожелания к владельцам этого бесплатного хостинга — может быть, они успеют что-то доработать ко времени релиза.
1. Список заметок очень желательно составлять из начал текстов, чтобы их использовать как индексы (100-300 символов);
2. Иметь список из 100 гарантированно неудаляемых юзеров с вычисляемыми именами типа aa00..aa99.
3. Иметь режим чтения списка и заметок без оформления — сэкономится 18K Байт на каждом запросе!
4. Сделать удаление картинок из стораджа автором, чтобы его можно было бы использовать в качестве публичных данных — например, писать статьи в формате картинок и публиковать исправления и комментарии к ним. Тогда достаточно будет иметь скрипт разворачивания текстов статей и исправлений из бинарных данных картинок. Поскольку читать смогут тольк опользователи скрипта, этот формат станет популярным среди разработчиков, в картинках уменьшится доля обзоров телефонов.
5. Не дублировать данные в input hidden, чтобы не утяжелять страницу заметки.
Пока пройдут переговоры и согласования, мы успеем написать драйвера для файловой системы, использующие как минимум описанные существующие возможности сайта. Поскольку они будут кроссдоменными, то даже неиспользование мощностей сайта не помешает работе хранилища на другом домене в похожем формате.
Проект — краундсорсинговый (как этот), коды будут выложены на Гитхабе. В качестве практических задач читателям остаются вопросы:
1. Какой максимальный объём одного сообщения ЛС держит система?
2. Какой максимальный объём статьи в черновике поддерживается? (Я проверил, что 100К хранится.)
3. Какой максимальный объём приватных данных суммарно можно хранить?
