Здравствуйте, Cyberax, Вы писали:
C>Где "локальную"? Все запросы идут через один URL, который скрыт за тонной балансировщиков нагрузки.
В текущей реализации — нигде. Но что мешало ее сделать, чтобы получить нормальную производительность?
C>То есть? Это два разных теста — пропускная способность одной машины и пропускная способность одного bucket'а.
Вопрос был один и тот же — сколько нужно потоков для скачивания (на клиенте), чтобы получить терабит.
Здравствуйте, Codealot, Вы писали:
C>Немного быстрее, но не то чтобы очень сильно. Даже обычный потребительский SSD быстрее раз в 20.
Еще раз — некорректно сравнивать по скорости NAS и локальный диск, это разные по функционалу вещи.
НС>>кластер MinIO, кластер CEF. C>Ты хотел сказать Ceph или это что-то другое? Оба несовместимы по API, нужно велосипедить.
Оба они предоставляют S3 API.
НС>>В том что HTTP API предполагает работу по HTTP с его ограничениями и накладными расходами, и схему апдейта с поддержкой атомарности, что совсем не бесплатно. C>Что мешало сделать не-HTTP API?
Ничего. Поэтому есть UltraDisk. Но тебе же надо именно HTTP.
НС>>Сложности вполне ведомые и задача на практике очень непростая. Хочешь досконально разобраться — попробуй сам реализовать поверх локального диска. Думаю, на этапе осознания необходимости распределенных блокировок ты многое начнешь понимать. C>А кто сказал, что они нужны?
Без них сложно соблюсти атомарность апдейтов.
C>В данном случае — данные читаются и меняются только в одной реплике. Которую в теории можно создать локально, на том же сервере. Остальные реплики обновляются асинхронно или вообще не нужны, потому что сверх-надежность здесь не нужна.
Зачем тебе тогда storage account?
НС>>Именно со storage account API — максимально это premium storage (гиг в секунду), все доступные альтернативные реализации медленнее. Если подойдет S3 API — вариантов больше. C>Точно гиг? Throughput per Disk — P30 — 200 MB/sec
Почему Р30? Это не максимум.
НС>>Предлагай C>Нунжно какой-то части пользователей.
Какой?
C> Причем многие из них даже не осознают свою проблему.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Еще раз — некорректно сравнивать по скорости NAS и локальный диск, это разные по функционалу вещи.
Меня бы вполне устроил и локальный диск, но с тем же API. И без ненужного функционала, но зато быстро.
НС>Оба они предоставляют S3 API.
А у меня — Azure.
НС>Ничего. Поэтому есть UltraDisk. Но тебе же надо именно HTTP.
Не мне. Системе, которая уже есть в наличии и ограничена реализацией в Azure.
НС>Без них сложно соблюсти атомарность апдейтов.
Не вижу особых проблем. Объясни, в чем у тебя сложность.
НС>Зачем тебе тогда storage account?
В системе используется Synapse и data lake, вроде я уже про это писал. А оно по другому не умеет, насколько мне известно.
НС>Почему Р30? Это не максимум.
Там другие не указаны. А где есть спеки для других?
НС>Какой?
Здравствуйте, Codealot, Вы писали:
НС>>Еще раз — некорректно сравнивать по скорости NAS и локальный диск, это разные по функционалу вещи. C>Меня бы вполне устроил и локальный диск, но с тем же API.
MinIO.
НС>>Оба они предоставляют S3 API. C>А у меня — Azure.
Значит не повезло. Есть онпрем решения сторонние, но они на питонах и js, со всеми вытекающими в плане перфоманса.
НС>>Ничего. Поэтому есть UltraDisk. Но тебе же надо именно HTTP. C>Не мне. Системе, которая уже есть в наличии и ограничена реализацией в Azure.
Это что то меняет?
НС>>Без них сложно соблюсти атомарность апдейтов. C>Не вижу особых проблем. Объясни, в чем у тебя сложность.
Как ты без блокировок обеспечишь атомарность при условии, что у тебя несколько инстансов сервиса?
НС>>Почему Р30? Это не максимум. C>Там другие не указаны.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Значит не повезло. Есть онпрем решения сторонние, но они на питонах и js, со всеми вытекающими в плане перфоманса.
Неа, это не "не повезло". Это разработчики Azure не смогли сделать качественный продукт.
НС>Как ты без блокировок обеспечишь атомарность при условии, что у тебя несколько инстансов сервиса?
Ну во первых, несколько инстансов в данном случае просто не нужны.
Во вторых — в качестве разминки для мозгов, попробуем все же рассмотреть вариант, когда это нужно.
Вариант 1 — как я уже писал, асинхронное обновление. Пишем данные в одну реплику, и уже потом пересылаем их на другие реплики в том же порядке. Здесь может быть проблемой неконсистентность чтения с разных реплик. Но это необязательно важно. Для бэкапа вполне достаточно, например. Влияние на производительность записи и чтения около нуля.
Вариант 2 — перед записью или обновлением блоба, блокируем его на всех репликах. Это ухудшает производительность при записи, но влияние на скорость чтения практически нулевое.
Где ты видишь здесь проблемы?
НС>https://docs.microsoft.com/en-us/azure/virtual-machines/premium-storage-performance#premium-storage-disk-sizes
900 MB/sec
Лучше, но всё еще мало по сравнению с возможностями современного железа. Значит, косяки в реализации. Ну и не говоря о цене, которая наверняка конская.
НС>С чего ты взял что удивляет?
Здравствуйте, Codealot, Вы писали:
НС>>Значит не повезло. Есть онпрем решения сторонние, но они на питонах и js, со всеми вытекающими в плане перфоманса. C>Неа, это не "не повезло". Это разработчики Azure не смогли сделать качественный продукт.
При чем тут разработчики Azure? У них такой задачи не стояло, как и у разработчиков S3, к примеру. Хранилища для big data это отдельная большая история, и она не про storage account. Есть заточенные под такие сценарии вещи типа MinIO, но тут тебе не повезло, они за основу выбрали протокол S3.
НС>>Как ты без блокировок обеспечишь атомарность при условии, что у тебя несколько инстансов сервиса? C>Ну во первых, несколько инстансов в данном случае просто не нужны.
Тогда при чем тут вообще azure storage, который принципиально распределенный?
C>Вариант 1 — как я уже писал, асинхронное обновление. Пишем данные в одну реплику, и уже потом пересылаем их на другие реплики в том же порядке. Здесь может быть проблемой неконсистентность чтения с разных реплик. Но это необязательно важно.
Конкретно протокол Azure Storage гарантирует атомарность апдейтов, так что пофик что там тебе лично неважно, но если тебе приспичило оставаться в рамках этого протокола, то консистентность нужна.
C>Вариант 2 — перед записью или обновлением блоба, блокируем его на всех репликах.
А для этого, тадам, нужна распределенная блокировка.
C>Где ты видишь здесь проблемы?
Распределенная блокировка это что то из области белого кита.
C>Лучше, но всё еще мало по сравнению с возможностями современного железа.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>При чем тут разработчики Azure? У них такой задачи не стояло, как и у разработчиков S3, к примеру. Хранилища для big data это отдельная большая история, и она не про storage account. Есть заточенные под такие сценарии вещи типа MinIO, но тут тебе не повезло, они за основу выбрали протокол S3.
Их задачей было сделать продукт, удобный для разных сценариев.
НС>Тогда при чем тут вообще azure storage, который принципиально распределенный?
Synapse / data lake умеет работать с другими хранилищами данных, кроме azure storage? Насколько мне известно — нет.
НС>Конкретно протокол Azure Storage гарантирует атомарность апдейтов, так что пофик что там тебе лично неважно, но если тебе приспичило оставаться в рамках этого протокола, то консистентность нужна.
Меня интересует в первую очередь почему оно так сделано и что там у нее под капотом. "Делай как приказали и без разговорчиков" — это нормально для армии, а не для хайтека.
НС>А для этого, тадам, нужна распределенная блокировка.
Я так и написал. Но ты не ответил, почему в их реализации она так сильно бьет по скорости чтения. По идее — не должна.
НС>Распределенная блокировка это что то из области белого кита.
Я в курсе, но это опять не ответ на вопрос выше.
НС>Мне надоело разговаривать с глухим.
Не хами только из-за того, что с тобой не согласились.
Здравствуйте, Codealot, Вы писали:
НС>>При чем тут разработчики Azure? У них такой задачи не стояло, как и у разработчиков S3, к примеру. Хранилища для big data это отдельная большая история, и она не про storage account. Есть заточенные под такие сценарии вещи типа MinIO, но тут тебе не повезло, они за основу выбрали протокол S3. C>Их задачей было сделать продукт, удобный для разных сценариев.
Чем больше сценариев поддерживает продукт, тем хуже он поддерживает конкретный сценарий. Универсальность небесплатна. Поэтому никто не делает сервисы всемогутеры, делают сервисы, решающие конкретные проблемы.
НС>>Тогда при чем тут вообще azure storage, который принципиально распределенный? C>Synapse / data lake умеет работать с другими хранилищами данных, кроме azure storage? Насколько мне известно — нет.
Ну вот я и говорю — значит тебе не повезло. Ну и гугль подсказывает, что варианты есть.
НС>>Конкретно протокол Azure Storage гарантирует атомарность апдейтов, так что пофик что там тебе лично неважно, но если тебе приспичило оставаться в рамках этого протокола, то консистентность нужна. C>Меня интересует в первую очередь почему оно так сделано
Потому что основные сценарии использования azstorage сильно выигрывают от наличия возможности атомарных апдейтов. А использование хранилища в эксклюзивном режиме строго с одной единственной ноды — это сильно далеко за пределами тех сценариев, под которые оно заточено.
C>Я так и написал. Но ты не ответил, почему в их реализации она так сильно бьет по скорости чтения. По идее — не должна.
Это был просто пример того, что возможности и режимы azstorage сильно отличаются от возможностей и режимов локальных дисков.
НС>>Мне надоело разговаривать с глухим. C>Не хами только из-за того, что с тобой не согласились.
Я не замлю, просто надоело когда ты постоянно задаешь один и тот же вопрос, игнорируя ответ. Других ответов у меня нет.
Здравствуйте, Codealot, Вы писали:
C>>Где "локальную"? Все запросы идут через один URL, который скрыт за тонной балансировщиков нагрузки. C>В текущей реализации — нигде. Но что мешало ее сделать, чтобы получить нормальную производительность?
Мешает то, что реализация должна поддерживать терабиты исходящего трафика и атомарные обновления с гарантией целостности. Одновременно.
C>>То есть? Это два разных теста — пропускная способность одной машины и пропускная способность одного bucket'а. C>Вопрос был один и тот же — сколько нужно потоков для скачивания (на клиенте), чтобы получить терабит.
У нас это достигается при нескольких десятках тысяч параллельных потоков.
Здравствуйте, Codealot, Вы писали:
НС>>Как ты без блокировок обеспечишь атомарность при условии, что у тебя несколько инстансов сервиса? C>Ну во первых, несколько инстансов в данном случае просто не нужны.
Нужны, так как даже самый гигантский инстанс не справится с потоком в терабит.
C>Во вторых — в качестве разминки для мозгов, попробуем все же рассмотреть вариант, когда это нужно. C>Вариант 1 — как я уже писал, асинхронное обновление. Пишем данные в одну реплику, и уже потом пересылаем их на другие реплики в том же порядке. Здесь может быть проблемой неконсистентность чтения с разных реплик.
Только вот S3 и SA гарантируют целостность, это очень важная фича.
C>Вариант 2 — перед записью или обновлением блоба, блокируем его на всех репликах. Это ухудшает производительность при записи, но влияние на скорость чтения практически нулевое.
Только вот блоб могут сразу кинуться читать 100500 клиентов после разблокировки. Когда будет ещё всего одна физическая копия.
Это вполне реальный пример — мы используем S3 для передачи входных данных в задачи, которые работают на кластере. Так что уже через миллисекунды после создания блоб начинают читать несколько сотен потоков.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Чем больше сценариев поддерживает продукт, тем хуже он поддерживает конкретный сценарий. Универсальность небесплатна. Поэтому никто не делает сервисы всемогутеры, делают сервисы, решающие конкретные проблемы.
Необязательно. Наличие RAID 0 никак не мешает RAID 1, или RAID 5, и так далее.
НС>Ну вот я и говорю — значит тебе не повезло. Ну и гугль подсказывает, что варианты есть.
А зачем мне S3? Мне S3 не нужен. Мне нужно хранить данные в локальном диске и скармливать их оттуда синапсу, раз уж со storage account он так тормозит.
НС>А использование хранилища в эксклюзивном режиме строго с одной единственной ноды — это сильно далеко за пределами тех сценариев, под которые оно заточено.
Но внятных альтернатив в Azure нет.
C>>Я так и написал. Но ты не ответил, почему в их реализации она так сильно бьет по скорости чтения. По идее — не должна. НС>Это был просто пример того, что возможности и режимы azstorage сильно отличаются от возможностей и режимов локальных дисков.
Ты на вопрос вообще не ответил. Какое отношение распределенные блокировки имеют к скорости чтения? Похоже, что ты просто ничего не знаешь как оно работает, но твердо уверен, что всё сделано единственно верным способом.
НС>Я не замлю, просто надоело когда ты постоянно задаешь один и тот же вопрос, игнорируя ответ.
Ты не отвечаешь, ты уклоняешься. См выше, например.
Здравствуйте, Cyberax, Вы писали:
C>Нужны, так как даже самый гигантский инстанс не справится с потоком в терабит.
Не везде это нужно. Мне например нет, вполне хватит пары гигабайтов.
C>Только вот S3 и SA гарантируют целостность, это очень важная фича.
Как я уже написал — не для всех сценариев.
C>Только вот блоб могут сразу кинуться читать 100500 клиентов после разблокировки. Когда будет ещё всего одна физическая копия.
Значит, разблокировать — только когда уже есть копии.
Может, хоть ты сможешь объяснить, как оно так реализовано, что скорость чтения любого блоба в отдельности становится такой днищенской?
Здравствуйте, Cyberax, Вы писали:
C>Мешает то, что реализация должна поддерживать терабиты исходящего трафика и атомарные обновления с гарантией целостности. Одновременно.
См мой вопрос в другой ветке.
C>У нас это достигается при нескольких десятках тысяч параллельных потоков.
И сколько для этого нужно ядер и оперативки? Именно для того, чтобы получить терабит при чтении, а не в каком-то другом тесте?
C>А зачем мне S3? Мне S3 не нужен. Мне нужно хранить данные в локальном диске и скармливать их оттуда синапсу, раз уж со storage account он так тормозит.
тебе надо смирится, что ты туп и заучить данный тебе ответ. не старайся вникнуть, твой уровень это не позволит. просто заучи, считать в разнобой пару блоков с SSD не подходит дата лейкам. не надо вникать почему им нужно консистентное чтение, это это надо заучить и прекратить отнимать время.
Здравствуйте, Gt_, Вы писали:
Gt_>тебе надо смирится, что ты туп и заучить данный тебе ответ. не старайся вникнуть, твой уровень это не позволит. просто заучи, считать в разнобой пару блоков с SSD не подходит дата лейкам. не надо вникать почему им нужно консистентное чтение, это это надо заучить и прекратить отнимать время.
Во первых — не хами. Во вторых — когда ты просто повторяешь заученное тобой "объяснение", которое на самом деле ничего не объясняет — это не делает тебя умным. Совершенно наоборот.
Gt_>>тебе надо смирится, что ты туп и заучить данный тебе ответ. не старайся вникнуть, твой уровень это не позволит. просто заучи, считать в разнобой пару блоков с SSD не подходит дата лейкам. не надо вникать почему им нужно консистентное чтение, это это надо заучить и прекратить отнимать время.
C>Во первых — не хами. Во вторых — когда ты просто повторяешь заученное тобой "объяснение", которое на самом деле ничего не объясняет — это не делает тебя умным. Совершенно наоборот.
чувак, ты хочешь "хранить данные в локальном диске и скармливать их оттуда синапсу, раз уж со storage account он так тормозит." и это объясняет твою тупость. у синапса поднимется спарк с десятками и сотнями экзекуторами и все они что должны будут сделать ? ломануться на один единственный диск ? тебе на стройку надо с такими хотелками, а не задаваться вопросами почему дата лейки строят на распределенной файловой системе и хотят от нее консистетности. не трать свое и остальных время, иди на стройку. там все проще.
Здравствуйте, Codealot, Вы писали:
C>Ты на вопрос вообще не ответил. Какое отношение распределенные блокировки имеют к скорости чтения?
Чтение тоже требует взятия блокировки для гарантии получения последних данных.
Здравствуйте, Codealot, Вы писали:
C>>У нас это достигается при нескольких десятках тысяч параллельных потоков. C>И сколько для этого нужно ядер и оперативки? Именно для того, чтобы получить терабит при чтении, а не в каком-то другом тесте?
Без понятия. Я вообще не понимаю причём тут ядра и оперативка, чтение блобов — это обычный HTTPS-запрос, который в современных клиентах реализуется вообще с минимальными накладными расходами на поток.
Здравствуйте, Cyberax, Вы писали:
C>Чтение тоже требует взятия блокировки для гарантии получения последних данных.
1) и как блокировка работает при чтении? клиент пытается соединиться со всеми репликами и получить у каждого блокировку, что ли? судя по тому, как это тормозит.
2) это должно сильно бить по производительности для множества мелких блобов, но не играть большой роли для одного большого блоба. Не так ли?
