The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Первый релиз wZD 1.0.0, сервера компактного хранения мелких ..., opennews (??), 19-Янв-20, (0) [смотреть все] +1

Сообщения [Сортировка по времени | RSS]


8. "Первый релиз wZD 1.0.0, сервера компактного хранения мелких ..."  +8 +/
Сообщение от raver (ok), 19-Янв-20, 21:53 
А задумка-то у автора не плохая, взял и решил проблему кластерных фс как 2х2. Мелочь и большие файлы шустро будут работать, и амазон не нужен. Да ему не плохо было бы сделать авторизацию свою, хотя на старте я бы тоже предостерег всех и выпустил софт с рекомендацией ставить за nginx. Да и нечему ему торчать наружу, там же заливаются файлы.

Было бы неплохо если бы автор добавил именно "клиентскую" компрессию и шифрование а не на стороне сервера, чтобы пользователь сам мог хоть на php сжать, зашифровать, притом чем угодно и послать данные и хеадеры с указанием того чем сжато, зашифровано итп.

А обратно получать эти же хеадеры с инфой данными, чтобы логика клиента сразу могла узнать тип компрессии, шифрования и расшифровать. А то в его todo написано об этом, но не указано как именно он будет делать компрессию и шифрование. Было бы идеально, так как тогда на стороне сервера не будет хранится ни ключ ни пароль.

Ответить | Правка | Наверх | Cообщить модератору

9. "Первый релиз wZD 1.0.0, сервера компактного хранения мелких ..."  +1 +/
Сообщение от xm (ok), 19-Янв-20, 22:31 
> Было бы неплохо если бы автор добавил именно "клиентскую" компрессию

Зачем клиенту делать то, что из коробки делает HTTP/2 в канале и сама файловая система в хранилище? Пустое это.

Ответить | Правка | Наверх | Cообщить модератору

10. "Первый релиз wZD 1.0.0, сервера компактного хранения мелких ..."  +/
Сообщение от syslinuxemail (ok), 19-Янв-20, 23:49 
>> Было бы неплохо если бы автор добавил именно "клиентскую" компрессию
> Зачем клиенту делать то, что из коробки делает HTTP/2 в канале и
> сама файловая система в хранилище? Пустое это.

Не в защите транспортного уровня дело, а чтобы предоставить такую возможность, хочешь сам зашифровал чем тебе надо конкретный файл или даже значение и отправил это в хранилище. Гибкость. Тем более на фс далеко не во всех есть шифрование, и оно там на стороне сервера только оверхед создаст. Клиент же не только curl обычный может быть, а и целое приложение типа CRM системы или еще что, которой потребуется ключи у себя держать а не на сервере хранения. Сервер лишь при выдаче зашифрованных данных отдаст сразу в заголовках тот тип шифрования который был применен к данному конкретному файлу или значению.

Ответить | Правка | Наверх | Cообщить модератору

11. "Первый релиз wZD 1.0.0, сервера компактного хранения мелких ..."  +1 +/
Сообщение от xm (ok), 20-Янв-20, 00:04 
Шифровать это один вопрос, а сжатие - другой.
По поводу шифрования, если это хранилка то ей должно быть по барабану шифрованный файл вы ей отправляете или нет. Её задача принять, сохранить и выдать по запросу не особенно вникая в подробности.
Ответить | Правка | Наверх | Cообщить модератору

12. "Первый релиз wZD 1.0.0, сервера компактного хранения мелких ..."  +/
Сообщение от syslinuxemail (ok), 20-Янв-20, 00:13 
> Шифровать это один вопрос, а сжатие - другой.

А что сжатие - все тоже самое - сжали у себя конкретный файл или значение и отправили указав тип сжатия в хеадере, сервер запомнил. При обратном запросе тоже самое, сервер выдал сжатые данные и тип сжатия, который был указан вначале. Серверов хранения может быть мало, а клиентов которые заливают много, у них CPU больше, чтобы и жать и шифровать, зачем оверхед сжатия на сервере хранения делать? Единственно что на сервере надо предусмотреть, так это настраиваемый параметр добавления заголовка для выдачи обычному браузеру сжатого контента типа gzip, чтобы браузер автоматом распаковал и отобразил содержимое, а не выдал мусор gz.

В том числе можно объединить сжатие и шифрование для конкретного файла при такой схеме если это требуется.

Ответить | Правка | Наверх | Cообщить модератору

14. "Первый релиз wZD 1.0.0, сервера компактного хранения мелких ..."  +/
Сообщение от xm (ok), 20-Янв-20, 00:16 
> А что сжатие - все тоже самое

Нет, всё не то же самое, потому что сжимать сжатое смысла, как правило, нет, как я на это и указал выше.
Резюмируя, ваши предложения при гипотетическом внедрении лишь способны существенно снизить производительность системы ради призрачных и, по сути, бессмысленных целей.

Ответить | Правка | Наверх | Cообщить модератору

15. "Первый релиз wZD 1.0.0, сервера компактного хранения мелких ..."  –2 +/
Сообщение от syslinuxemail (ok), 20-Янв-20, 00:29 
>> А что сжатие - все тоже самое
> Нет, всё не то же самое, потому что сжимать сжатое смысла, как
> правило, нет, как я на это и указал выше.

а) Вы посылаете текстовый файл 100KB , он запишется как есть, тип сжатия 0(посылать в хеадере не надо).

б) Вы послаете "уже" сжатый на клиенте текстовый файл размером 25KB в формате zstd и указываете тип сжатия допустим номер 2. Этот номер 2 запишется на хранилке в бинарный заголовок приклеенный к самому сжатому файлу. Сам файл запишется как есть. При выдаче информации сервер пошлет в response header "Compressed: 2", ваш "специализированный" клиент запрограммированый на получение этого хеадера распакует сжатый zstd файл.

в) Вы посылаете "уже" сжатый на клиенте текстовый файл размером 40KB в формате gzip и указываете тип сжатия допустим номер 1. Этот номер 1 запишется на хранилке в бинарный заголовок приклеенный к самому сжатому файлу. Сам файл запишется как есть. При выдаче информации сервер пошлет в response header "Compressed: 1", ваш "специализированный" клиент запрограммированый на получение этого хеадера распакует сжатый gzip файл, или "обычный" браузер сам распакует и выдаст содержимое, если сервер настроен на выдачу штатного Content-Encoding хеадера.

Сам сервер ничего не жмет и ничего не распаковывает. Какая еще проблема производительности? Пишется 1 байт и все, на стороне сервера.

Ответить | Правка | Наверх | Cообщить модератору

17. "Первый релиз wZD 1.0.0, сервера компактного хранения мелких ..."  –1 +/
Сообщение от xm (ok), 20-Янв-20, 00:38 
Беда нашего образования в том, что писать оно учит, а вот читать и, тем более, понимать, не очень.
Повторяю: сжимать в канале умеет HTTP/2, сжимать на диске - файловая система. Делать это в других местах - ненужный оверхед.

З.Ы. 1. 100K это не мелкий файл который прекрасно может эффективно хранится без каких-либо ухищрения практически в любой файловой системе.
З.Ы. 2. И уже пишите по-русски "заголовок" вместо корявого "хеадер" (который даже в оригинале транскрибируется иначе).

Ответить | Правка | Наверх | Cообщить модератору

18. "Первый релиз wZD 1.0.0, сервера компактного хранения мелких ..."  –7 +/
Сообщение от syslinuxemail (ok), 20-Янв-20, 00:43 
> Беда образования, что писать оно учит, а вот читать и, тем более,
> понимать не очень.
> Повторяю: сжимать в канале умеет HTTP/2, сжимать на диске - файловая система.
> Делать это в других местах - ненужный оверхед.
> З.Ы. И уже пишите по-русски "заголовок" вместо корявого "хеадер" (который даже в
> оригинале транскрибируется иначе).

Не все фс умеют сжимать.
Это опция, а не обязаловка.
Кому надо, будет использовать.
Гибкость. Выше очень подробно расписано.

Сленговое слово хеадер обсуждать не намерен.

Ответить | Правка | Наверх | Cообщить модератору

29. "Первый релиз wZD 1.0.0, сервера компактного хранения мелких ..."  +/
Сообщение от Sokoloff (?), 20-Янв-20, 15:14 
>а)... он запишется как есть
>б) ... Сам файл запишется как есть.
>в) ... Сам файл запишется как есть.

Не совсем понятно зачем серверу знать про компрессию если он всегда хранит файл как есть? По сути Вы хотите хранить дополнительные метаданные к файлу, я не знаю WebDav такое умеет или нет. Но накойняк, всегда можно запихать сжатие в имя файла. Пишите
a) data.txt
б) data.txt.zstd
в) data.txt.gzip
И обрабатывайте в зависимости от расширения.

Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

38. "Первый релиз wZD 1.0.0, сервера компактного хранения мелких ..."  +/
Сообщение от syslinuxemail (ok), 21-Янв-20, 15:32 
>[оверквотинг удален]
>>б) ... Сам файл запишется как есть.
>>в) ... Сам файл запишется как есть.
> Не совсем понятно зачем серверу знать про компрессию если он всегда хранит
> файл как есть? По сути Вы хотите хранить дополнительные метаданные к
> файлу, я не знаю WebDav такое умеет или нет. Но накойняк,
> всегда можно запихать сжатие в имя файла. Пишите
> a) data.txt
> б) data.txt.zstd
> в) data.txt.gzip
> И обрабатывайте в зависимости от расширения.

Сделано будет просто для унификации как и с типом шифрования, любой способ будет работать, даже если без доп.метаданных и без расширения залить все равно определится тип сжатия по первым 512 байтам, за исключением совсем редких типов.

Для чего надо у типа шифрования, да банально обмен ссылками, если кто-то будет использовать без единой базы, и будет уже известен тип шифрования.

Ответить | Правка | Наверх | Cообщить модератору

13. "Первый релиз wZD 1.0.0, сервера компактного хранения мелких ..."  –2 +/
Сообщение от syslinuxemail (ok), 20-Янв-20, 00:15 
> Шифровать это один вопрос, а сжатие - другой.
> По поводу шифрования, если это хранилка то ей должно быть по барабану
> шифрованный файл вы ей отправляете или нет. Её задача принять, сохранить
> и выдать по запросу не особенно вникая в подробности.

Так так оно и есть сейчас, за исключением того что хранилка будет получать от клиента кроме самого зашифрованного файла, еще и тип в хеадере, Чтобы обратно при запросе выдать хеадер с этим же типом. Таким образом клиент будет сразу знать что ему летит в каком зашифрованном формате, то есть логику клиента можно гибко программировать.

Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру