Comments 14
Хороший лайфхак, благодарю, надо будет запомнить :)
Оооочень важная информация, спасибо! )
Несколько раз уже натыкался на такие грабли, благо размер поменьше был. Теперь буду вооружен.
Несколько раз уже натыкался на такие грабли, благо размер поменьше был. Теперь буду вооружен.
Только сегодня наткнулся на подобный совет о быстром удалении сообщений из Amazon SQS:
Просто установите `Message Retention period` (как долго сообщения должны храниться в очереди) равным 1 минуте.
stackoverflow.com/questions/7713626/best-way-to-delete-messages-from-sqs-during-development
Просто установите `Message Retention period` (как долго сообщения должны храниться в очереди) равным 1 минуте.
stackoverflow.com/questions/7713626/best-way-to-delete-messages-from-sqs-during-development
Всего-то надо не забывать, что файлы — не файлы в понимании десктопной файловой системы, а чуть большее, что к ним еще и вся мощь Амазона прилагается. И что иные вещи можно делать не из прикладного софта, а просто средствами систем, составляющих S3.
За что S3 и интересна порой, притом даже до того, что переехать с нее уже не сильно легко становится :)
За что S3 и интересна порой, притом даже до того, что переехать с нее уже не сильно легко становится :)
DELETE хоть и бесплатный, но LIST стоит денег
~ $ ls Select payment method: 1 - Visa 2 - Mastercard 3 - Paypal
Подскажите, если у кого есть хотя бы 10 миллионов файлов в бакете, сколько времени уходит на добавление в бакет ещё одного очень маленького файла?
Столько же, сколько и обычно. У нас на 400М файлах замедления не было.
Бакет это не физическая папка на жестком диске, поэтому и заметно замедляться не должен.
Бакет — это список, при добавлении нового объекта в бакет обязательно нужно этот список обновлять, так что не могу однозначно согласиться с вами. Обновлять структурку на 400 млн элементов — это не тривиальная задача, у которой есть несколько путей решения. Я пытался найти какие либо презентации Амазона по поводу внутреннего устройства S3, но, к сожалению, ничего дельного не нашлось, поэтому вот приходится вот такие косвенные свидетельства искать.
Зачем обновлять все? Можно только последнему элементу добавить `next`
Теоретически да. Но тут есть подводные камни, основной из которых звучит так: какое количество объектов разумно хранить в одном пространстве ключей. Представьте себе, что у вас есть некий key-value сторадж, который одинаково хорошо хранит как большие, так и мелкие объекты (что уже не правда, но допустим).
Если все-все объекты всех пользователей хранить с таком сторадже, то при попытке пользователя получить доступ к своему файлу, нужно будет найти его среди триллиона остальных. Расширять такое хранилище будет очень сложно. Условно запись файла можно представить как запись строки в таблицу, и есть только одна таблица на всех. Сами понимаете, хранить триллион строк в таблице не очень здорово. Можно шардировать, но нужно будет уметь перешардировать на лету, это тяжёлая операция. А количество данных у успешного хранилища растёт по экспоненте.
Логично предположить, что файлы, лежащие в одном бакете, не имеют ничего общего с файлами, лежащими в других бакетах. Тогда можно изолировать пространства имён, делая новое для каждого бакета. Правда, тогда создание бакета станет не слишком простой операцией, и ограничения могут возникнуть из-за количества бакетов. Если продолжить аналогию с таблицами — каждый бакет это своя таблица, и проблема может быть с количеством таблиц. Особенно расточительно так делать для мелких бакетов.
Третий вариант — гибридный, использовать одно пространство ключей для нескольких бакетов. Как вы понимаете, есть как плюсы, так и минусы от обоих вариантов. При этом можно иметь возможность хранить один бакет в нескольких «таблицах».
Но какой бы вариант не использовали, количество ключей будет проблемой. Увеличивать его просто так, на ровном месте, используя цепочку, я бы не стал. Ну и слишком дорого будет делать листинг, удалять элементы и прочее. А если вспомнить о том, что эта штука должна быть распределённой, и нужно как-то консистентность листинга поддерживать… Лучше уж какое-нибудь b-tree, чем цепочка.
Если все-все объекты всех пользователей хранить с таком сторадже, то при попытке пользователя получить доступ к своему файлу, нужно будет найти его среди триллиона остальных. Расширять такое хранилище будет очень сложно. Условно запись файла можно представить как запись строки в таблицу, и есть только одна таблица на всех. Сами понимаете, хранить триллион строк в таблице не очень здорово. Можно шардировать, но нужно будет уметь перешардировать на лету, это тяжёлая операция. А количество данных у успешного хранилища растёт по экспоненте.
Логично предположить, что файлы, лежащие в одном бакете, не имеют ничего общего с файлами, лежащими в других бакетах. Тогда можно изолировать пространства имён, делая новое для каждого бакета. Правда, тогда создание бакета станет не слишком простой операцией, и ограничения могут возникнуть из-за количества бакетов. Если продолжить аналогию с таблицами — каждый бакет это своя таблица, и проблема может быть с количеством таблиц. Особенно расточительно так делать для мелких бакетов.
Третий вариант — гибридный, использовать одно пространство ключей для нескольких бакетов. Как вы понимаете, есть как плюсы, так и минусы от обоих вариантов. При этом можно иметь возможность хранить один бакет в нескольких «таблицах».
Но какой бы вариант не использовали, количество ключей будет проблемой. Увеличивать его просто так, на ровном месте, используя цепочку, я бы не стал. Ну и слишком дорого будет делать листинг, удалять элементы и прочее. А если вспомнить о том, что эта штука должна быть распределённой, и нужно как-то консистентность листинга поддерживать… Лучше уж какое-нибудь b-tree, чем цепочка.
Лайфхак любопытный.
> 9 дней работы браузера без выключения, да еще и заплатить придется за каждую операцию (DELETE хоть и бесплатный, но LIST стоит денег).
Зачем браузер держать открытым? зачем LIST делать часто?
docs.aws.amazon.com/cli/latest/reference/s3/rm.html
А это не быстрее будет?
> 9 дней работы браузера без выключения, да еще и заплатить придется за каждую операцию (DELETE хоть и бесплатный, но LIST стоит денег).
Зачем браузер держать открытым? зачем LIST делать часто?
docs.aws.amazon.com/cli/latest/reference/s3/rm.html
А это не быстрее будет?
UFO just landed and posted this here
Sign up to leave a comment.
Как удалить bucket с 400 миллионами файлов на Amazon S3