Если купить в гугл диске 5тб и расшарить на условно 50 человек?

Question

[Павел]

У меня к примеру 3тб данных, есть тарифный план на 5ТБ , если я куплю акк, затем дам доступ к этот папке на 30-50 человек у которых обычные бесплатные аккаунты, мне нужно будет платить только за свой акк или каждый должен купить недостающий обьем или ... ? Я запутался, кто покупал, подскажите

Comments

[rPman]

Настоятельно рекомендую не мучиться с googl drive и аналогами, а поднять свой next cloud или даже самодельный аналог (зачем неудобный браузерный интерфейс если можно webdav сделать) на более дешевых vps-ках или даже облачных (осторожнее там может быть дорого)

[Павел]

rPman, у меня уже есть nextcloud, но на этих же 50 человек работа слишком медленная, даже перейдя на postgresql и с хорошим сервером, не знаю может что то я недонастроил но проблема с большим количеством документов, много мелких файлов, когда я ставлю офф клиент, он даже для облачного хранения все файлы должен "проиндексировать" (хотя сложно это индексацией назвать...), прежде чем можно будет работать, а этот процесс может занять до двух дней, что = бред. Я пробовал использовать программы которые аля webdav (raidrive) , но скорость по этому протоколу ну просто ппц маленькая , например через веб 10 мб/сек , клиент 2-5 мб/сек , а webdav 200 кб/сек и если мелких файлов много то еще медленнее..

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

[rPman]

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

если мелких файлов много

вот тут кроется 99% проблем, из-за удаленности сервера от пользователей никакой протокол тебе не поможет, все упирается в физику скорости света и высокие пинги. Сервер буквально должен стоять максимально близко к пользователям, тогда и nfs/smb протоколы будут отлично работать.

я тут уже советовал решение, которое может помочь, если каждый пользователь работает монопольно на запись только со своим каталогом и может быть сверху общий readonly архив (можно это расширить через какой-то интерфейс отключения диска после работы чтобы к нему подключиться мог другой человек). Через использование протоколов раздачи блочных устройств по сети (nbd, iscsi), так как в этом случае кеширование критичных мест в файловой системе значительно повышает скорость работы именно с мелкими файлами, вплоть до максимума пропускной способности (зависит от процессора сервера)

[Павел]

rPman, как сейчас построена система:
есть документация за многие годы, документы эти копятся и множатся, но в архив перемещать не выйдет потому как многие документы используются как образец, выходит нужен доступ ко всем документам но без скачивания (ясное дело 2ТБ никто даже частично не осилит
нагрузка на сервер редко бывает одновременной, максимум 10 человек работает
чаще всего это открытие одного - пяти документов и сохранение их же обратно , реже загрузка новых документов прямо пачкой и очень редко загрузка прямо 20+ гб архивов (не в плане сжатых, а просто много)

при обычно работе хватает webdav , хотя скорость скачивания тоже не ахти но терпимо, а вот при загрузке уже такое себе, ну и косяки когда люди работают с одним и тем же документом

по пингам ну максимум 2-3мс у 90% людей так как сейчас сервер стоит очень рядом , у некоторых прямо lan + гигабитный интернет

я тут уже советовал решение, которое может помочь

можно подробнее?

[rPman]

Будет неудобно.

Это подходит только если работа с каталогом (шарой и т.п.) будет монопольна для человека (после он какое то телодвижение совершает, ну к примеру ярлык на рабочем столе нажимает чтобы отключить диск, ну точно так же и для подключить), плюс отдельный архив readonly, к нему могут подключаться сколько угодно человек.

Каждый каталог (всегда можно выделить такие группы файлов, работа с которыми объединена) организуется в виде iscsi/nbd тома, который монтируется по мере необходимости на клиенте (его нельзя смонтировать сразу на нескольких машинах кроме readonly варианта). Благодаря тому что операционные системы такие устройства кешируют на локальной машине в оперативную память (а на linux можно многоуровневый кеш, например на ssd меньшего размера организовать) работа с ними может быть на уровне пропускной способности сети (для гигабитных сетей iscsi могут упираться уже в скорость процессора сервера, для nbd требований меньше но windows клиента нет).

по пингам ну максимум 2-3мс у 90% людей так как сейчас сервер стоит очень рядом

на кой хрен вы рядом стоящий сервер подключаете по webdav!? кто вам посоветовал это извращение.
Подключайте smb/nfs, все будет летать! никаких извращений.

[Павел]

rPman, потому что удобно когда один сервер для всех людей сразу, я не сказал всех, а человек 20 всегда находятся в другом городе + мобильные клиенты

[rPman]

webdav отправляет много лишних запросов, плюс клиенты как я понимаю однопоточные, без кеширования и буферов (отсюда 200кб на соседнюю машину)

исключай его

smb работает и удаленно, лучше конечно его в vpn, с мобильными клиентами хз, я помню total commander с собой таскает модуль, все работает удобно (помню даже фильмы давал смотреть без загрузки), правда я с 20гб файлами там не работал, не думаю что мобильным пользователям это будет актуально.

[Alexander Ivanov]

Если у вас нет возможности использовать Google Workspace, придется "переносить" (если файлов много, то придется делать программно или писать интерфейс для загрузки на ваш Диск - пишите в личку) эти файлы на ваш Диск, иначе будет заниматься место того, кто загрузил файл. По поводу "мучений" с облаками - поставьте NextCloud, ага, попробуйте. Если вы в этом не шарите, у вас нет отдельного сетевого диска, то это еще то приключение.

Answer 1

[rPman]

увы, будет тратиться их место

https://support.google.com/drive/answer/7166529

Объем свободного пространства в хранилище уменьшается у пользователя, загрузившего файл, а не у владельца папки.

p.s. вообще то будет тратиться место только для заново загружаемых файлов, но вот редактирование файлов (как минимум документы google docs) будет тратить место того кто изначально загрузил файл.
Что будет с местом если файлы редактируются через расширения, хз, надо изучать их способ работы

Comments

[Bruzon]

Вот это реально попадос! А способов обойти это никаких нет? Я просто гружу видеофайлы, много. Владелец папки - директор компании, у него 200 гигов там, а у меня 15. И расходуется мое место, хотя он создал папки и каталоги. Какая-то несправедливость получается, почему видосы не грузятся в его место, в его 200 гигов?

[rPman]

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

вполне возможно какое-нибудь расширение работы с архивами zip/tar (особенно без сжатия) вполне именно так и работает

Answer 2

[Tatyana Inarsh]

В этом случае покупать так много не нужно, если будут обычные юзеры.
Если же нужно места побольше и улучшенные инструменты, безопасность и полный контроль, то тогда только Google Workspace.