Ответы пользователя по тегу Хранение данных
  • Как лучше разместить файлы для сайта?

    @rPman
    Видеохостинг - основная нагрузка на сеть, поэтому считайте нагрузку (какой средний размер видео, просматриваемого одним клиентом в сутки умножить на количество умножить на 30 - получаете терабайты в месяц), к примеру если фильм 1.2гб и все 2к человек смотрят в сутки по одному фильму, то нужно 2.4 терабайта в сутки, это 27мбайт в секунду в среднем (а пиковые легко зайдут за 100мбит).

    Гигабитный хостинг без лимитов по скорости, и наверное еще и абузоустойчивый, что у вас там за терабайты видео которые будут смотреть столько людей?

    p.s. раскидайте видео по нескольких слабым хостингам, это может неплохо сэкономить на разруливание нагрузки в пиковые моменты (дублируя размещение популярного контента заранее), читай десяток другой слабых впсок с 100мбитным каналом, лимитом в 10Тбит в месяц и сотней гигабайт на диске могут обойтись в десяток баксов каждая.
    Ответ написан
    Комментировать
  • Как лучше реализовать структуру файлохранилища для средней (200-250 человек) организации?

    @rPman
    200 пользователей, нагрузка может оказаться приличная. Вы готовы до хранилища 10гигабит тянуть? Или у вас 6тб ssd?

    Мой совет, подумайте о разделении хранилища на несколько, по задачам. Не все же 200 человек лезут к одним и тем же данным, наверняка там по подразделениям легко все поделить. Речь не о доступе а о физическом размещении данных по железу (диски и сервера со своими сетевыми подключениями).

    Даже если все это железо будет в одной стойке сидеть, главное физически разделить данные. Из-за этого вместо 3тб hdd и больше дисков иногда оправданы 1тб размеры (меньше уже цены за гигабайт грустные).
    Ответ написан
    Комментировать
  • Где и как безопаснее хранить свои личные, конфедициальные файлы, пикантные фото, секретные материалы?

    @rPman
    Безопасность - это вопрос аутентификации пользователя и выбор инструмента доступа к файлам, а надежность - это выбор технологии.

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

    Если ваши объемы порядка сотен гигабайт или несколько терабайт, лучше своей системы ничего нет. Не обязательно поднимать целый файловый сервер, можно обойтись простыми подключаемыми дисками (пофиг флешки это или жесткие диски), но настоятельно рекомендую использовать не одно устройства а несколько (RAID 1,5,6,...). Поддержка RAID и шифрования есть во всех современных популярных операционных системах, так что в несколько шевелений мышки вы можете настроить то же зеркалирование и поднять шифрование, чтобы для доступа к файлам требовалось ввести пароль.
    Ответ написан
    Комментировать
  • Что это за ошибка "Error during file system creation", и как её исправить?

    @rPman
    возможно разработчики криптоматор умудрились неправильно работать файлами и глючат с нестандартными символами в именах, например ':'? протестируйте, убрав такие файлы.
    Ответ написан
    3 комментария
  • Как обезопасить бухгалтерию работающую с разными банковскими счетами и криптоплагинами?

    @rPman
    Соглашусь со всеми отписавшимися в ответах и комментариях, но все же отвечу одним советом, который возможно в вашем случае может сильно помочь.

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

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

    Самое простое и дешевое решение для изоляции, это виртуализация и сервера терминалов. Поверьте, если вы посадите пользователей лазить в абстрактном интернете на отдельной машине, подключаясь к ней по терминалу (rdp/vnc/..), которое не имеет никакого доступа к вашей локальной сети и машине, то это станет почти непреодолимым препятствием для вирусов любого толка (есть свои ньюансы), причем эти машины могут штатными средствами средств виртуализации автоматически очищаться (сбрасываться на дефолтное состояние, с автоматическими обновлениями по ночам), это будет наилучшим противовирусным и достаточно просто с настройкой.

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

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

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

    p.s. меня сейчас тут запопсуют, но я повторяю, изоляция песочницами (на базе виртуальных машин и нескольких независимых сегментов сети) не самое верное, но самое простое и дешевое решение, доступное мелким организациям, не готовым платить за готовые ЕРП решения.
    Ответ написан
  • Стоит ли делать резервное копирование в облако?

    @rPman
    Онлайн, помимо удобства и высоких цен дает еще один момент - низкая скорость восстановления после сбоя. Если у вас терабайты данных, вы можете столкнуться с проблемой единомоментной выгрузкой всех данных обратно, когда это станет необходимо. Поймите, это и так будет момент стресса для компании, где лишние сутки другие могут стоить столько денег, что кажущиеся затраты на локальный сервер покажутся копейками.

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

    p.s. СВОЙ локальный сервер для хранения бакапов будет по определению дешевле, удобнее,.. и размещать его можно в соседнем датацентре а не у себя в подсобке.
    Кстати, в 90% случаев, для мелких организаций бакапом может являться просто последовательная запись дисков, подключаемых по usb

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

    Формат, в зависимости от того, что у вас за данные, может быть от простого архива 7zip (изменения файлов могут быть оценены по дате или файловому атрибуту - архивирован) до красивого архиватора на базе rsync, теневых копий и символических ссылок (одно время пользовался простейшим bat файлом, который создавал в целевом каталоге, с датой архивации, полную копию моих файловых разделов, где для не изменившихся файлов использовалась символическая ссылка на предыдущую копию, дико удобно, старую реплику можно было удалить просто удалив каталог, а восстановление - обычное копирование, плюс можно по каталогам пройтись и взять любой файл не только последней версии но и по дате архивации).
    Ответ написан
    Комментировать
  • Как хранить данные на сервере?

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

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

    Если вам нужно дать пользователям возможность заливать файлы на сервер, то начинайте смотреть в сторону ftp/webdav (браузер и windows проводник с авторизацией) или совсем просто sftp (удобные клиенты есть подо все, а в linux штатно доступно пользователям)

    Все технические заморочки начинаются, когда ваша нагрузка становится критичной для стандартных тарифных планов у вашего провайдера, а это обычно с тысячами активных клиентов начинается)
    Ответ написан
    Комментировать
  • Какое облачное хранилище использовать для сервиса с миллионами мелких файлов?

    @rPman
    Запилите простое облачное приложение на том же amazon использующее их же хранилище, по вашей задаче не изучал, но обычно для запросов внутри их 'локального' облака там много послаблений в тарифных планах.

    Вообще то у amazon очень дорогой сетевой трафик, и использовать его для подобных задач выгодно очень сложно (соотношение месячного трафика к общему объему у вас должно быть сильно маленьким чтобы использовать их системы было выгоднее 'своих', т.е. хранить много отдавать редко).

    Если деньги вам дороги и ваши объемы не больше сотен гигабайт (речь об активном окне данных), арендуйте пару ssd vps-ок (в разных датацентрах), ставьте одну резервной (с репликацией) и используйте любую key-value базу данных.
    Ответ написан
    Комментировать
  • Стоит ли брать облачное хранилище?

    @rPman
    Чтобы вы не посчитали, приобрести свой сервер и поставить его в своей серверной будет дешевле во много раз.
    Если вас требуется канал (т.е. только в датацентре) то возможен вариант - самостоятельное приобретение сервера и размещение его у провайдера (есть способ сэкономить, покупая desktop железо и размещая его у 'не серьезных' провайдеров).
    Аренда готового сервера может быть выгодна только при аренде на короткие сроки, ну и для сравнения - готовое облачное хранилище становится дороже решений выше уже через 2-3 месяца.

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

    Из больших минусов - большие стартовые траты, не размазанные на весь срок эксплуатации.
    Ответ написан
    Комментировать
  • Как хранить в БД права доступа?

    @rPman
    'Доступно всем' без вариантов нужно хранить в виде bolean у content, даже хотя бы в виде копии, заполняемой тригером у таблицы content_share.

    'Доступно друзьям' и 'Доступно конкретному пользователю'… так ли важно разделять эти понятия. это бы имело смысл, если бы количество действий по созданию нового пользователя и добавлению прав было бы сравнимо с количеством запросов на права доступа, а это маловероятно, наверняка в вашей задаче количество запросов на чтение на порядок (или обычно это логарифм) больше изменений.
    Может быть достаточно правила 'Доступно конкретному пользователю', а значит обойдетесь таблицей content_share_user {user_id,content_id}

    Дальше, никогда не нужно надеяться на чистую реляционную модель. Делайте дополнительную копию на все, что читается чаще чем пишется в удобном для этого месте. Сериализованный список идентификаторов user_id в content.authorised_list (если это числа, то к примеру через ',' с обязательным ',' в конце), если их количество меньше определенного, удобен для запросов вида like '%12345,%', и ведь его можно заполнять не сразу, а периодически отдельным процессом и очищать по триггеру на изменении. Тогда основная нагрузка ляжет не на выполнение тригера, а на запросы только последних измененных данных, а их обычно не так много.
    content
    .authorised_list varchar = '123,234,345,' или null — для данных, которые нужно запросить из content_share_user
    .authorised_all boolean
    content_share_user {user_id,content_id}
    Ответ написан
  • Облачное хранилище значений key-value, RESTful?

    @rPman
    amazon s3
    без json конечно… а зачем? сериализацию можно и скриптом на клиенте делать.
    Ответ написан
    2 комментария
  • Как правильнее поступать с ненужными записями в БД - удалять или помечать их флагом "deleted"?

    @rPman
    Ответы очевидны.
    Помечать флагом — растет база, удалять — понижение производительности (фрагментация, сама операция удаления может оказаться дорогой) и часто усложнение бизнеслогики.

    Я бы не рекомендовал удалять данные из сложных баз данных, особенно если это справочники, например выставив в freign key — RESTRICT, чтобы разрешить удаление только для 'свободных' записей. Удаление записей в сложных базах данных, обычно очень сложная операция, обычно перед этим приходится проводить кучу проверок и изменений для связанных данных, поэтому флаг 'deleted' используется как упрощение или даже часть механизма для введения временной составляющей в хранение данных (база данных может являться как средством для хранения текущего состояния, так и для хранения лога изменений данных во времени)

    В зависимости от задач:
    1. Если удаление происходит сравнительно редко, т.е. если оверхед на размер базы незначителен — то лучше помечать флагом.
    2. Если удаления и создания записей очень частые (в результате база не очень растет), то лучше удалять, плюсы от отсутствия фрагментации может оказаться недостаточным, чтобы перебить рост индексов (кстати и кэш в оперативной памяти будет зря занят).
    3. Если и скорость и данные критичны, то лучше помечать флагом и удалять по крону, а чтобы минимизировать вероятность задержек на время обслуживания — разделить таблицу на кластеры (можно 'вручную' в классе работы с БД) и очищать каждый кусок отдельно, а разделение сделать с целью отделить часто используемые данные от редко используемых.
    Ответ написан
    Комментировать
  • Структура таблиц БД: хранение списков значений наряду с обычными значениями

    @rPman
    Описанное вами — это развитие реляционной модели в сетевую… в mysql как я знаю средств для этого нет, в postgresql есть поддержка массивов, только производительность не ля всех случаев оптимальна.

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

    Так же не стоит закрывать глаза штатную реализацию списков второй таблицей M-1.

    И конечно же никто не мешает совместить оба подхода (хранить данные в 2 таблицах и кешировать дополнительными полями в главной, например информация о количестве элементов в списке, значение первого элемента,..)
    Ответ написан
    1 комментарий