Ковыряясь в одной облачной системе с большим количеством баззвордов на предмет "выяснить, почему оно так бешено тормозит", я решил сделать небольшой тест — скачивать данные из storage account на виртуальную машину, которая хостится в том же регионе. Скорость — около 60 мб в секунду То есть даже на гигабитный эзернет не тянет. В связи с чем возник вопрос — это вообще нормально?
Здравствуйте, Codealot, Вы писали:
C>Скорость — около 60 мб в секунду То есть даже на гигабитный эзернет не тянет. В связи с чем возник вопрос — это вообще нормально?
Ну так "облака" — это и есть виртуальные машины! Три блэйда, на которых вертится тысяча виртуалок Есессно, всё это фуфло тормозит. Я делал совсем уж примитивный тест — простая консолька делала SELECT из базы (MS SQL). Разница с "нативным десктопом" была точно в 2 раза медленнее (точно не скажу, может и в три — я просто тогда охренел и понял, что такие облака мне даром не нужны). Причём не факт, что если ты проапгрэйдишься на более дорогой план, что-то станет намного лучше — РЕАЛЬНОГО железа тебе всё равно не видать — всё будет так же крутиться в виртуалках.
Облака — очевидная ловушка, причём из говна и палок. Кто на это вообще ведётся?!
Здравствуйте, Kolesiki, Вы писали:
K>Ну так "облака" — это и есть виртуальные машины!
Ну про скорость самих ВМок — это понятно. Но скорость коммуникаций между ними, которая получилась в моем тесте — это совсем полный абзац. Вот я и удивляюсь.
Допустим, на одном ноде их хостится 8 штук (считая по числу ядер), и этот нод соединяется с сетью 100 гигабит. Тогда на одну ВМку должно приходится около 1.5 гигабайт в секунду. А получается — всего 60 мегабайт.
Здравствуйте, Codealot, Вы писали:
C>Ковыряясь в одной облачной системе с большим количеством баззвордов на предмет "выяснить, почему оно так бешено тормозит", я решил сделать небольшой тест — скачивать данные из storage account на виртуальную машину, которая хостится в том же регионе. Скорость — около 60 мб в секунду То есть даже на гигабитный эзернет не тянет. В связи с чем возник вопрос — это вообще нормально?
А у тебя в виртуалке ssd? Если hdd — то вот в скорость записи все и уперлось.
C>Ну про скорость самих ВМок — это понятно. Но скорость коммуникаций между ними, которая получилась в моем тесте — это совсем полный абзац. Вот я и удивляюсь. C>Допустим, на одном ноде их хостится 8 штук (считая по числу ядер), и этот нод соединяется с сетью 100 гигабит. Тогда на одну ВМку должно приходится около 1.5 гигабайт в секунду. А получается — всего 60 мегабайт.
Значит, наверное, твои допущения неправильные. Либо там 800 штук, а не 8, либо 100 мбит а не гигабит, либо оба сразу. Либо storage account на лентах, для дешевизны.
Здравствуйте, Sharowarsheg, Вы писали:
S>Значит, наверное, твои допущения неправильные. Либо там 800 штук, а не 8, либо 100 мбит а не гигабит, либо оба сразу. Либо storage account на лентах, для дешевизны.
Учитывая расценки, это было бы особо циничным издевательством над облакофилами.
Здравствуйте, Codealot, Вы писали:
КБ>>А у тебя в виртуалке ssd? C>Естественно.
Учитывая что storage точно так же виртуализируется то не имея доступа к hypervisor на этот вопрос ответить в общем то нельзя.
Здравствуйте, Codealot, Вы писали:
C>Ковыряясь в одной облачной системе с большим количеством баззвордов на предмет "выяснить, почему оно так бешено тормозит", я решил сделать небольшой тест — скачивать данные из storage account на виртуальную машину, которая хостится в том же регионе. Скорость — около 60 мб в секунду То есть даже на гигабитный эзернет не тянет. В связи с чем возник вопрос — это вообще нормально?
Нет, [обычно] это не нормально. Спроси у своего провайдера.
Здравствуйте, Codealot, Вы писали:
C>Ковыряясь в одной облачной системе с большим количеством баззвордов на предмет "выяснить, почему оно так бешено тормозит", я решил сделать небольшой тест — скачивать данные из storage account на виртуальную машину, которая хостится в том же регионе. Скорость — около 60 мб в секунду То есть даже на гигабитный эзернет не тянет. В связи с чем возник вопрос — это вообще нормально?
Да как везде — комбинация из уплаченных денег/политки владельцев облака/текущей нагрузки на облачную инфраструктуру.
Кто-то честно указывает пропускную способность сети и как ей поднять https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html
А кто-то экономит на железе и суровую правду (а также расценки на выделенный линк под ваши виртуалки) можно узнать только через техподдержку.
Здравствуйте, Codealot, Вы писали:
C>Допустим, на одном ноде их хостится 8 штук (считая по числу ядер), и этот нод соединяется с сетью 100 гигабит. Тогда на одну ВМку должно приходится около 1.5 гигабайт в секунду. А получается — всего 60 мегабайт.
Нет гарантии, что storage и созданная VM топологически локальны друг другу. А значит — трафик медленный. Но даже если машины топологически локальны — всё будет упираться в квоты (потому что нельзя дать "всем всё", любой ресурс конечен).
Собственно, межузловое взаимодействие и его latency — это ещё один фактор, который надо держать в уме при проектировании распределённых систем. Это может быть как сетевой трафик, так и доступ к, например, RAM в случае NUMA-платформ, когда логическая распределённость появляется на физически одной и той же материнской плате.
Здравствуйте, Codealot, Вы писали:
C>Ковыряясь в одной облачной системе с большим количеством баззвордов на предмет "выяснить, почему оно так бешено тормозит", я решил сделать небольшой тест — скачивать данные из storage account на виртуальную машину, которая хостится в том же регионе. Скорость — около 60 мб в секунду То есть даже на гигабитный эзернет не тянет. В связи с чем возник вопрос — это вообще нормально?
У казахстанского провайдера, которым я пользуюсь, скорость порта на виртуальной машине и на выделенной машине — сто мегабитов. Хотелось бы гигабит, конечно, но вообще пока не упирался в эту скорость. На мой взгляд это не критично.
Здравствуйте, Codealot, Вы писали:
C>Ковыряясь в одной облачной системе с большим количеством баззвордов на предмет "выяснить, почему оно так бешено тормозит", я решил сделать небольшой тест — скачивать данные из storage account на виртуальную машину, которая хостится в том же регионе. Скорость — около 60 мб в секунду То есть даже на гигабитный эзернет не тянет. В связи с чем возник вопрос — это вообще нормально?
Какие "машины", какие "storage account"?
В AWS (или GCP/Azure) получаем то, за что платим. Нужно быстрое нелокальное блочное хранилище — берём соответствующий тип узла. Нужно быстрое локальное хранилище — берём другой. В AWS их уже около тысячи штук вариантов: https://ec2instances.info/
Здравствуйте, Codealot, Вы писали:
C>Ковыряясь в одной облачной системе с большим количеством баззвордов на предмет "выяснить, почему оно так бешено тормозит", я решил сделать небольшой тест — скачивать данные из storage account на виртуальную машину, которая хостится в том же регионе. Скорость — около 60 мб в секунду То есть даже на гигабитный эзернет не тянет. В связи с чем возник вопрос — это вообще нормально?
У нас на dev скорость раза в полтора повыше, но да, тоже не фонтан. Но, в целом, это не доставляет больших неприятностей
Подобные операции обрабатываются асинхронно (то есть пользователь не ожидает получить результат мнгновенно). Вот когда требуется провести какое-то обслуживание (например, вычитать кучу всего, поменять и сохранить обратно), то тут уже да — приходится выдумывтаь как бы это сделать так, не помешав пользователям. Но повседневным, основным задачам не мешает.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, Codealot, Вы писали:
C>Ковыряясь в одной облачной системе с большим количеством баззвордов на предмет "выяснить, почему оно так бешено тормозит", я решил сделать небольшой тест — скачивать данные из storage account на виртуальную машину, которая хостится в том же регионе.
Тип и tier у твоего аккакунта какой? Если хочешь мегаскорость — тогда Premium (не путать с Block Premium) и размер побольше (скорость зависит от размера). Но там доступное API сильно ограничено. Если хочешь полноценное API — тогда Premium Block.
А эзернет тут не причем, Azure Storage это SaaS, разделяемый между всеми потребителями, в монополное владение никто тебе его не отдаст.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Тип и tier у твоего аккакунта какой? Если хочешь мегаскорость — тогда Premium (не путать с Block Premium) и размер побольше (скорость зависит от размера). Но там доступное API сильно ограничено. Если хочешь полноценное API — тогда Premium Block.
И сколько составляет эта мегаскорость в реальности?
НС>А эзернет тут не причем, Azure Storage это SaaS, разделяемый между всеми потребителями, в монополное владение никто тебе его не отдаст.
То есть там всё упирается в одно бутылочное горлышко?
Здравствуйте, Codealot, Вы писали:
C>И сколько составляет эта мегаскорость в реальности?
https://azure.microsoft.com/en-us/pricing/details/managed-disks/
НС>>А эзернет тут не причем, Azure Storage это SaaS, разделяемый между всеми потребителями, в монополное владение никто тебе его не отдаст. C>То есть там всё упирается в одно бутылочное горлышко?
Нет, все упирается в то, сколько ты заплатил. Платишь за P80 и получаешь гигабайт в секунду.
Здравствуйте, Codealot, Вы писали:
НС>>Нет, все упирается в то, сколько ты заплатил. Платишь за P80 и получаешь гигабайт в секунду. C>Всего лишь? Даже недорогой SSD может в разы больше.
Это NAS, при чем тут локальный SSD? Локальный диск у тебя в temp drive.
Здравствуйте, Codealot, Вы писали:
C>Azure Managed Disks are high-performance, durable block storage designed to be used with Azure Virtual Machines and Azure VMware Solution. C>Ну и в каком месте это NAS?
В прямом. Это диск, который можно подключать к любым VM. Физически это классический NAS. А физический диск в ажуре это temp drive, который при сбое или переезде ВМ будет весь протерян.
C>2) если современные диски намного быстрее и сеть тоже, то почему storage account такой медленный?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>В прямом. Это диск, который можно подключать к любым VM. Физически это классический NAS. А физический диск в ажуре это temp drive, который при сбое или переезде ВМ будет весь протерян.
Ну это странно, потому что для этой задачи делать его как NAS смысла очень мало. storage account — там еще понятно, зачем.
НС>Потому что это NAS, а не локальный диск.
Здравствуйте, Codealot, Вы писали:
C>Ну это странно, потому что для этой задачи делать его как NAS смысла очень мало.
Там не то что смысла много, это обязательное требование. Потому что иначе, когда твоя ВМ уйдет на обслуживание или накроется вместе с диском, ты весь диск потеряешь. А так системный диск просто подключается к другой живой ВМ.
НС>>Потому что это NAS, а не локальный диск. C>Даже для NAS он тормозит совершенно неприлично.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Там не то что смысла много, это обязательное требование. Потому что иначе, когда твоя ВМ уйдет на обслуживание или накроется вместе с диском, ты весь диск потеряешь. А так системный диск просто подключается к другой живой ВМ.
Постоянный бэкап, если что случилось — скопировал на новый узел и запустил ВМку. Зачем там делать NAS?
НС>1 гиг в секунду это тормозит?
Я про storage account, если ты не заметил. И про реальную скорость, а не "до 100500 гиг в секунду. И пусть кто попробует сказать, что 1 мегабайт — это не до 100500 гиг."
Но и гиг в секунду, для современного железа — тоже не особо.
storage account и managed disk, про который ты толкуешь — разные вещи.
НС>Ну так померяй реальную, раз не веришь.
Именно это я и сделал, о чем с самого начала и написал.
А ты видимо чукча-писатель?
НС>Что ты понимаешь под современным железом и насколько ему соответствует то железо, на котором работает тво ВМ?
Обычное, даже не самое навороченное.
А ВМ — точнее, хранилище данных — не мое, а мелко-мягких. Они же софт для хранилища данных делали, не я.
Здравствуйте, Codealot, Вы писали:
C>Ну это странно, потому что для этой задачи делать его как NAS смысла очень мало.
Оно там скорее не NAS а SAN
И да, именно так и надо делать.
Видимо все же ты. Потому что ты явно померял standard, который ограничен совсем не железом.
НС>>Что ты понимаешь под современным железом и насколько ему соответствует то железо, на котором работает тво ВМ? C>Обычное, даже не самое навороченное.
Оно там вполне конкретное и вполне понятно какое. Оно для тебя достаточно современно?
Здравствуйте, Codealot, Вы писали:
C>Чтобы более лучше тормозило?
Я не пойму что тебя не устраивает? Нравится периодически терять данные — пиши на temp drive, его у тебя никто не отбирает. Хочешь чтобы данные жили дольше чем ВМ — придется использовать внешнее хранилище. Хочешь чтобы это хранилище было дешевым — мирись с определенными тормозами.
Отвечая на твой исходный вопрос — да, это нормально, по определению. У обоих основных поставщиков облачных решений ситуация в этом плане примерно одинаковая (и у Azure, кстати, топовый tier (Ultra disks, 2Гб/с. Через storage api, емнип, недоступно по понятным причинам) заметно быстрее топового S3, это на сейчас самое быстрое решение на рынке).
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Видимо все же ты. Потому что ты явно померял standard, который ограничен совсем не железом.
Default maximum egress for general-purpose v2 and Blob storage accounts
120 Gbps
А теперь расскажи мне, как из этого числа получается 60 мегабайт в секунду.
НС>Оно там вполне конкретное и вполне понятно какое. Оно для тебя достаточно современно?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Я не пойму что тебя не устраивает? Нравится периодически терять данные — пиши на temp drive, его у тебя никто не отбирает.
А что, репликацию данных они не умеют?
Но на самом деле, меня даже сохранность данных не особо волнует. Это всего лишь аналитика, которая нужна только пока обрабатывается. Но. Система сделана так, что там нужен именно storage account, потому что там используется Synapse и прочий говно-data-science, который завязан на конкретно этот API. А просто так взять и создать локальное хранилище с тем же API, я так понимаю, нельзя. Это было бы слишком просто
НС>Хочешь чтобы данные жили дольше чем ВМ — придется использовать внешнее хранилище. Хочешь чтобы это хранилище было дешевым — мирись с определенными тормозами.
Ты вообще всё в кучу смешал. Не нужен никакой SAN, чтобы данные не терялись с перезагрузкой ВМ. VirtualBox никогда не пользовался?
И никакая "дешевизна" (в кавычках, потому что оно вовсе не дешевое относительно стоимости самого железа) не оправдывает такую днищенскую производительность.
Здравствуйте, Codealot, Вы писали:
C>Ты вообще всё в кучу смешал. Не нужен никакой SAN, чтобы данные не терялись с перезагрузкой ВМ. VirtualBox никогда не пользовался?
Здравствуйте, CreatorCray, Вы писали:
C>>Ты вообще всё в кучу смешал. Не нужен никакой SAN, чтобы данные не терялись с перезагрузкой ВМ. VirtualBox никогда не пользовался? CC>
Здравствуйте, Codealot, Вы писали:
НС>>Видимо все же ты. Потому что ты явно померял standard, который ограничен совсем не железом. C>Default maximum egress for general-purpose v2 and Blob storage accounts C>120 Gbps C>А теперь расскажи мне, как из этого числа получается 60 мегабайт в секунду.
Storage accounts (или S3) достаточно тормозные, так как обеспечивают высокую надёжность хранения (овердофига девяток гарантии сохранности).
Но при этом они практически безгранично масштабируются горизонтально. Т.е. можно одновременно закачивать или скачивать десятки тысяч блобов, с суммарным потоком в терабиты в секунду (ничуть не преувеличение, я сам проверял).
Для высокой скорости для одного потока нужно что-то другое. Или локальное хранилище, или блочное хранилище (EBS на AWS или Azure Managed Disks). Они имеют другие ограничения, по числу IOPS и пропускной способности.
НС>>Оно там вполне конкретное и вполне понятно какое. Оно для тебя достаточно современно? C>Раз так тормозит — значит, недостаточно.
Нет, просто не то выбираешь.
Здравствуйте, Codealot, Вы писали:
C>А просто так взять и создать локальное хранилище с тем же API, я так понимаю, нельзя. Это было бы слишком просто
Чего ж нельзя, можно. У нас, емнип, на реализациею этого API поверх файловых шар ушло где то человекомесяц, причем большая часть была потрачена на войну с шарами. На локальном диске можно было меньше чем за неделю справится.
Если же именно ажурное API не принципиально и подойдет S3 — есть MinIO.
C>И никакая "дешевизна" (в кавычках, потому что оно вовсе не дешевое относительно стоимости самого железа) не оправдывает такую днищенскую производительность.
Здравствуйте, CreatorCray, Вы писали:
CC>Чувак, я занимался как раз storage для виртуализации, так что твои фантазии как оно должно быть кроме фейспалма ничего не вызывают.
Мне твое надувание щек еще меньше интересно. Если ты действительно чем-то там таким занимался, то у тебя не должно вызывать ни малейших проблем дать ясный и четкий ответ на мой вопрос.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Чего ж нельзя, можно.
Напедалить самому всегда можно. Другой вопрос — почему продукт, который пытаются представить последним достижением технологии, требует так много велосипедостроения.
НС>На локальном диске можно было меньше чем за неделю справится.
Остается только удивляться, куда пропадает весь софт, написанный такими форумными сверхчеловеками, и почему на рынке вместо него одно говно
Здравствуйте, Cyberax, Вы писали:
C>Storage accounts (или S3) достаточно тормозные, так как обеспечивают высокую надёжность хранения (овердофига девяток гарантии сохранности).
И отключить это конечно нельзя. Также, непонятно, почему это должно так сильно бить по производительности, особенно по чтению.
C>Но при этом они практически безгранично масштабируются горизонтально. Т.е. можно одновременно закачивать или скачивать десятки тысяч блобов, с суммарным потоком в терабиты в секунду (ничуть не преувеличение, я сам проверял).
И сколько ядер и оперативки для этого надо?
C>Для высокой скорости для одного потока нужно что-то другое. Или локальное хранилище, или блочное хранилище (EBS на AWS или Azure Managed Disks). Они имеют другие ограничения, по числу IOPS и пропускной способности.
А кто говорил про один поток? 120 мб/с — это для 16 потоков. А если поток один, то получаются совсем позорные 12 мб/сек.
C>Нет, просто не то выбираешь.
А выбора особо и нет. API у них вообще разный, просто так взять и заменить одно на другое нельзя, нужно перелопатить много кода.
Здравствуйте, Codealot, Вы писали:
C>>Storage accounts (или S3) достаточно тормозные, так как обеспечивают высокую надёжность хранения (овердофига девяток гарантии сохранности). C>И отключить это конечно нельзя. Также, непонятно, почему это должно так сильно бить по производительности, особенно по чтению.
Магии нет. В S3/SA данные попадают на физические серверы хранения, и при скачивании клиент подключается к тому серверу, который хранит данные. Эти серверы хранения имеют конечную пропускную способность, да ещё и разделяются между множеством потребителей услуг AWS.
Так что индивидуальная скорость потока получается ограниченной.
C>>Но при этом они практически безгранично масштабируются горизонтально. Т.е. можно одновременно закачивать или скачивать десятки тысяч блобов, с суммарным потоком в терабиты в секунду (ничуть не преувеличение, я сам проверял). C>И сколько ядер и оперативки для этого надо?
Нисколько. Серверная часть S3 работает на стороне AWS, клиентам пофиг как оно там внутри устроено.
C>>Для высокой скорости для одного потока нужно что-то другое. Или локальное хранилище, или блочное хранилище (EBS на AWS или Azure Managed Disks). Они имеют другие ограничения, по числу IOPS и пропускной способности. C>А кто говорил про один поток? 120 мб/с — это для 16 потоков. А если поток один, то получаются совсем позорные 12 мб/сек.
Значит кто-то пишет не так. Я легко получаю гигабайты в секунду с S3 на инстансе с 40Gb сетью, отдельные потоки — где-то 10-40 мегабайт в секунду. Оно скачивает быстрее, чем пишет на локальный диск, блин.
C>>Нет, просто не то выбираешь. C>А выбора особо и нет. API у них вообще разный, просто так взять и заменить одно на другое нельзя, нужно перелопатить много кода.
Managed Disks/EBS — это обычные диски.
Здравствуйте, Cyberax, Вы писали:
C>Магии нет. В S3/SA данные попадают на физические серверы хранения, и при скачивании клиент подключается к тому серверу, который хранит данные. Эти серверы хранения имеют конечную пропускную способность, да ещё и разделяются между множеством потребителей услуг AWS. C>Так что индивидуальная скорость потока получается ограниченной.
А кто им запрещал сделать локальную реплику? Раз уж всё равно данные распределены?
C>Нисколько. Серверная часть S3 работает на стороне AWS, клиентам пофиг как оно там внутри устроено.
Я имел в виду, сколько ядер и оперативки на клиенте?
C>>А кто говорил про один поток? 120 мб/с — это для 16 потоков. А если поток один, то получаются совсем позорные 12 мб/сек. C>отдельные потоки — где-то 10-40 мегабайт в секунду
Я ровно это и написал. Позорненькая скорость то.
Это сколько надо потоков, чтобы получился терабит?
C>Managed Disks/EBS — это обычные диски.
Тут в соседней ветке доказывали, что на самом деле это SAN и по другому никак нельзя делать.
Здравствуйте, Codealot, Вы писали:
C>Напедалить самому всегда можно. Другой вопрос — почему продукт, который пытаются представить последним достижением технологии, требует так много велосипедостроения.
Нет, это ты хочешь чего то, для чего продукт не предназначался.
НС>>На локальном диске можно было меньше чем за неделю справится. C>Остается только удивляться, куда пропадает весь софт, написанный такими форумными сверхчеловеками
Почему пропадает? Никуда не пропадает, успешно продается в составе большого продукта.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Нет, это ты хочешь чего то, для чего продукт не предназначался.
Этого хочу не я, а конечный потребитель.
Если вообще хоть немного подумать, то возможность выбрать между "супер-надежностью" и скоростью, раз уж нельзя иметь и то и другое — это очевидное требование к продукту.
Хотя, почему надежность так сильно бьет по скорости в этом случае, никто так и не смог внятно объяснить. RAID, например, позволяет не только улучшить надежность, но и повысить скорость. А не убить ее до скорости смертельно раненой улитки, как в облаке.
НС>Почему пропадает? Никуда не пропадает, успешно продается в составе большого продукта.
Да, говно — успешно продается, за неимением лучшего. А где нормальный продукт?
Здравствуйте, Cyberax, Вы писали:
C>>А выбора особо и нет. API у них вообще разный, просто так взять и заменить одно на другое нельзя, нужно перелопатить много кода. C>Managed Disks/EBS — это обычные диски.
У AWS есть разные "обычные диски" — EBS и Instance Storage. И то и другое выглядит на инстансе как обычный диск (блочное устройство).
EBS — это больше похоже на сетевой диск. Данные хранятся где-то на серверах AWS и передаются по сети. Данные сохраняются при переездах инстанса.
Instance Storage — данные хранятся на дисках, физически подключенные к серверу, на котором работает инстанс. Информация на них теряется при переездах.
Здравствуйте, Codealot, Вы писали:
C>Если вообще хоть немного подумать, то возможность выбрать между "супер-надежностью" и скоростью, раз уж нельзя иметь и то и другое — это очевидное требование к продукту.
Из трех вещей, надежность, скорость и цена, тебе придется выбрать две.
C>Хотя, почему надежность так сильно бьет по скорости в этом случае, никто так и не смог внятно объяснить.
Потому что надежность, даже LRS, предполагает размещение копий в разных стойках, а не на двух соседних дисках на одной шине. А GRS предполагает копии в разных регионах со всеми вытекающими.
C> RAID, например, позволяет не только улучшить надежность, но и повысить скорость.
RAID это не надежность, а профанация. Сдох контроллер — и привет вся твоя надежность.
НС>>Почему пропадает? Никуда не пропадает, успешно продается в составе большого продукта. C>Да, говно — успешно продается, за неимением лучшего.
Ну напиши лучше, делов то. Заработаешь несколько сотен миллионов баксов.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Из трех вещей, надежность, скорость и цена, тебе придется выбрать две.
Меня вполне устроит скорость и цена. Ну так что, как мне это сделать в Azure без необходимости велосипедить?
НС>Потому что надежность, даже LRS, предполагает размещение копий в разных стойках, а не на двух соседних дисках на одной шине. А GRS предполагает копии в разных регионах со всеми вытекающими.
Ну и читаем данные из ближайшей копии. В чем проблема?
НС>RAID это не надежность, а профанация. Сдох контроллер — и привет вся твоя надежность.
Облака — это не надежность, а профанация. Ложились подолгу уже все крупные облачные провайдеры.
НС>Ну напиши лучше, делов то. Заработаешь несколько сотен миллионов баксов.
- Представьте, шо ви в поле. Упереди вас араб. Ваши действия?
— Хватаю автомат и таки убиваю араба.
— Правильно. Следующая ситуация: ви в поле, впереди вас араб, слева и справа тоже по арабу. Ваши действия?
— Хватаю автомат и таки убиваю их всех.
— Правильно. Такая ситуация: ви в поле, перед вами три араба, сзади тоже три араба, справа/слева опять же по три араба, и еще танк едет. Ваши действия?
— Хватаю автомат и убиваю арабов. Потом бросаю гранату и подрываю танк.
— Правильно. А вот такая ситуация: ви в поле, впереди сотня арабов, справа/слева/сзади по сотне, три танка из-за холма показались и пяток вертолетов пикируют. Ваши действия?
— А можно вопрос?
— Можно.
— Я шо, один в израильской армии???
Здравствуйте, Codealot, Вы писали:
НС>>Из трех вещей, надежность, скорость и цена, тебе придется выбрать две. C>Меня вполне устроит скорость и цена.
Ну вот тогда premium это примерно максимум того, что можно получить в виде SaaS. Если и этого мало — придется развернуть свой CEF или MinIO на temp drives или UltraDisk.
НС>>Потому что надежность, даже LRS, предполагает размещение копий в разных стойках, а не на двух соседних дисках на одной шине. А GRS предполагает копии в разных регионах со всеми вытекающими. C>Ну и читаем данные из ближайшей копии. В чем проблема?
Ни в чем. Но гиг в секунду поверх HTTPS в этом случае вполне соответствует возможностям современного железа. Быстрее — это уже точно не про HTTPS.
НС>>RAID это не надежность, а профанация. Сдох контроллер — и привет вся твоя надежность. C>Облака — это не надежность, а профанация. Ложились подолгу уже все крупные облачные провайдеры.
Тут вопрос не бинарный, а вероятностный. Вероятность что у тебя в облаках накроются сразу несколько регионов и ты останешься без хранилища на несколько порядков ниже, чем вероятность того что у тебя единственный RAID контроллер гикнется, утянув потенциально за собой еще и диски с данными.
НС>>Ну напиши лучше, делов то. Заработаешь несколько сотен миллионов баксов.
C>- Я шо, один в израильской армии???
Получается что один, раз никому еще такая гениальная идея не пришла в голову.
Здравствуйте, Буравчик, Вы писали:
C>>Managed Disks/EBS — это обычные диски. Б>У AWS есть разные "обычные диски" — EBS и Instance Storage. И то и другое выглядит на инстансе как обычный диск (блочное устройство). Б>EBS — это больше похоже на сетевой диск. Данные хранятся где-то на серверах AWS и передаются по сети. Данные сохраняются при переездах инстанса. Б>Instance Storage — данные хранятся на дисках, физически подключенные к серверу, на котором работает инстанс. Информация на них теряется при переездах.
В Ажуре ровно тоже самое. Называется, соотв., managed disks и temp drive.
Здравствуйте, Codealot, Вы писали:
C>>Так что индивидуальная скорость потока получается ограниченной. C>А кто им запрещал сделать локальную реплику? Раз уж всё равно данные распределены?
S3 даёт гарантии целостности. Т.е. после записи в файл следующее чтение вернёт те же данные. Повторить такое локально невозможно, без фактического дублирования инфраструктуры S3.
C>>Нисколько. Серверная часть S3 работает на стороне AWS, клиентам пофиг как оно там внутри устроено. C>Я имел в виду, сколько ядер и оперативки на клиенте?
Я тестировал, по-моему, на c5n.2xlarge — 8 vCPU и 21Гб ОЗУ. Сам по себе код скачивания создаёт несущественную нагрузку.
C>>>А кто говорил про один поток? 120 мб/с — это для 16 потоков. А если поток один, то получаются совсем позорные 12 мб/сек. C>>отдельные потоки — где-то 10-40 мегабайт в секунду C>Я ровно это и написал. Позорненькая скорость то.
Почему? Более чем внушительно, учитывая все гарантии, которые даёт S3. Я имел счастье работать с локальными SAN, и такая производительность там была мечтой.
C>Это сколько надо потоков, чтобы получился терабит?
Ну так раздели сам. Несколько десятков тысяч (не на одной машине, понятное дело). Я вижу эти цифры в нашем мониторинге в пиковые часы для приложения. Сохраняемые данные — большие изображения (результат трассировки лучей с учётом позиции солнца для каждого светлого часа года).
C>>Managed Disks/EBS — это обычные диски. C>Тут в соседней ветке доказывали, что на самом деле это SAN и по другому никак нельзя делать.
Ну да. Это обычные диски (в RAID-е), доступные через SAN. Соответственно, они дают те же ограничения, что и любые другие диски — больше IOPS, больше полосы для отдельных запросов, но суммарная полоса ограничена железом.
Здравствуйте, Буравчик, Вы писали:
C>>>А выбора особо и нет. API у них вообще разный, просто так взять и заменить одно на другое нельзя, нужно перелопатить много кода. C>>Managed Disks/EBS — это обычные диски. Б>У AWS есть разные "обычные диски" — EBS и Instance Storage. И то и другое выглядит на инстансе как обычный диск (блочное устройство).
Ну да, я и называл Instance Store "локальным хранилищем".
Б>Добавлено: Б>Вот например тесты производительности. Хоть и старые, но соотношение, думаю, верное: Б>https://gist.github.com/ktheory/3c3616fca42a3716346b
Очень устарело. Вот немного более новое: https://www.scalebench.com/blog/index.php/2020/06/03/aws-ebs-vs-aws-instance-storelocal-disk-storage/
Здравствуйте, Cyberax, Вы писали:
C>S3 даёт гарантии целостности. Т.е. после записи в файл следующее чтение вернёт те же данные. Повторить такое локально невозможно, без фактического дублирования инфраструктуры S3.
Я имел в виду — реализацию у самого облачного провайдера. Почему они не могли сделать локальную реплику данных?
C>Я тестировал, по-моему, на c5n.2xlarge — 8 vCPU и 21Гб ОЗУ. Сам по себе код скачивания создаёт несущественную нагрузку. C>Ну так раздели сам. Несколько десятков тысяч (не на одной машине, понятное дело).
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ну вот тогда premium это примерно максимум того, что можно получить в виде SaaS. Если и этого мало — придется развернуть свой CEF или MinIO на temp drives или UltraDisk.
Но поскольку API совершенно другой, то нужно велосипедить. То есть, без велосипедостроения совершенно элементарная задача у них не решается.
НС>Ни в чем. Но гиг в секунду поверх HTTPS в этом случае вполне соответствует возможностям современного железа. Быстрее — это уже точно не про HTTPS.
1) Не знаю, сам не проверял. А нафига тогда все эти 100-гигабитные эзернеты за очень много денег?
2) Кто запрещает сделать одну реплику данных прямо на том же хосте?
НС>Тут вопрос не бинарный, а вероятностный. Вероятность что у тебя в облаках накроются сразу несколько регионов и ты останешься без хранилища на несколько порядков ниже, чем вероятность того что у тебя единственный RAID контроллер гикнется, утянув потенциально за собой еще и диски с данными.
Никакие RAID контроллеры у меня никогда не гикались, а вот облачные провайдеры ложились все, и не по одному разу.
НС>Получается что один, раз никому еще такая гениальная идея не пришла в голову.
С чего ты решил, что нет?
Ну и ты вроде как сам писал, что делал велосипед ровно для этой задачи.
Здравствуйте, Codealot, Вы писали:
НС>>Ну вот тогда premium это примерно максимум того, что можно получить в виде SaaS. Если и этого мало — придется развернуть свой CEF или MinIO на temp drives или UltraDisk. C>Но поскольку API совершенно другой, то нужно велосипедить.
Нет, в случае premium базовый API тот же. А блочный API уже с поддержкой параллельного доступа с нескольких машин и атомарности апдейтов, что, сам понимаешь, скажется на перфомансе.
C> То есть, без велосипедостроения совершенно элементарная задача у них не решается.
Какая такая элементарная задача? Получение скорости локального диска на распределенном хранилище? Нет, это совсем не элементарная задача.
C> А нафига тогда все эти 100-гигабитные эзернеты за очень много денег?
А с чего ты взял что все упирается в эзернеты?
C>2) Кто запрещает сделать одну реплику данных прямо на том же хосте?
Это ты называешь элементарным решением? Ну ну.
Вообще, тебе, судя по всему, надо не решение, а поныть. Если тебе нужна скорость локального диска — бери MinIO, там есть режим кеширования на базе возможностей HTTP. Ставишь его сайдкаром в режиме кеша, в качестве volume используешь temp drive. Код писать не нужно, все готовое.
C>Никакие RAID контроллеры у меня никогда не гикались
У меня все работает? Ну ну.
НС>>Получается что один, раз никому еще такая гениальная идея не пришла в голову. C>С чего ты решил, что нет?
Ну если все как ты расписываешь — можно поднять много сотен гигабаксов, не?
C>Ну и ты вроде как сам писал, что делал велосипед ровно для этой задачи.
Я свой велосипед делал для строго ограниченных условий — запуск cloud native решения в условиях on prem. Универсального всемогутера как ты хочешь там нет.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Нет, в случае premium базовый API тот же. А блочный API уже с поддержкой параллельного доступа с нескольких машин и атомарности апдейтов, что, сам понимаешь, скажется на перфомансе.
Ну нет, не выкручивайся. Как мне получить "два из трех", о которых ты говорил, для системы, которая требует storage account API? И без велосипедостроения, естественно.
НС>А с чего ты взял что все упирается в эзернеты?
А вот что упирается?
НС>Это ты называешь элементарным решением? Ну ну.
А в чем проблема? Постарайся ответить внятно, а не ссылаться опять на какие-то неведомые сложности, которые слишком сложны, чтобы о них говорить.
НС>Вообще, тебе, судя по всему, надо не решение, а поныть.
Мне надо более быстрое хранилище, совместимое по API со storage account. Супер-большая надежность не требуется, достаточно обычной.
НС>У меня все работает? Ну ну.
Скажи ка мне, какова по твоему вероятность, что рейд-контроллер сломается?
НС>Ну если все как ты расписываешь — можно поднять много сотен гигабаксов, не?
Ты других вариантов кроме "не нужно никому" и "нужно всем" вообще не можешь себе представить?
Здравствуйте, Codealot, Вы писали:
НС>>Нет, в случае premium базовый API тот же. А блочный API уже с поддержкой параллельного доступа с нескольких машин и атомарности апдейтов, что, сам понимаешь, скажется на перфомансе. C>Ну нет, не выкручивайся.
Ты не подумал — зачем мне вообще выкручиваться? Я ничего не продаю. Хочешь разобраться — велкам, хочешь побрюзжать — на здоровье.
C> Как мне получить "два из трех", о которых ты говорил, для системы, которая требует storage account API? И без велосипедостроения, естественно.
Я тебе несколько решений предложил. Premium storage account, кластер MinIO, кластер CEF.
НС>>Это ты называешь элементарным решением? Ну ну. C>А в чем проблема?
В том что HTTP API предполагает работу по HTTP с его ограничениями и накладными расходами, и схему апдейта с поддержкой атомарности, что совсем не бесплатно.
C> Постарайся ответить внятно, а не ссылаться опять на какие-то неведомые сложности
Сложности вполне ведомые и задача на практике очень непростая. Хочешь досконально разобраться — попробуй сам реализовать поверх локального диска. Думаю, на этапе осознания необходимости распределенных блокировок ты многое начнешь понимать.
НС>>Вообще, тебе, судя по всему, надо не решение, а поныть. C>Мне надо более быстрое хранилище, совместимое по API со storage account.
Именно со storage account API — максимально это premium storage (гиг в секунду), все доступные альтернативные реализации медленнее. Если подойдет S3 API — вариантов больше.
НС>>У меня все работает? Ну ну. C>Скажи ка мне, какова по твоему вероятность, что рейд-контроллер сломается?
Если у тебя в кластере сотня дисков — очень высокая.
НС>>Ну если все как ты расписываешь — можно поднять много сотен гигабаксов, не? C>Ты других вариантов кроме "не нужно никому" и "нужно всем" вообще не можешь себе представить?
Здравствуйте, Codealot, Вы писали:
C>>S3 даёт гарантии целостности. Т.е. после записи в файл следующее чтение вернёт те же данные. Повторить такое локально невозможно, без фактического дублирования инфраструктуры S3. C>Я имел в виду — реализацию у самого облачного провайдера. Почему они не могли сделать локальную реплику данных?
Где "локальную"? Все запросы идут через один URL, который скрыт за тонной балансировщиков нагрузки.
C>>Я тестировал, по-моему, на c5n.2xlarge — 8 vCPU и 21Гб ОЗУ. Сам по себе код скачивания создаёт несущественную нагрузку. C>>Ну так раздели сам. Несколько десятков тысяч (не на одной машине, понятное дело). C>Что-то у тебя показания не сходятся
То есть? Это два разных теста — пропускная способность одной машины и пропускная способность одного bucket'а.
Ты хотел сказать Ceph или это что-то другое? Оба несовместимы по API, нужно велосипедить.
НС>В том что HTTP API предполагает работу по HTTP с его ограничениями и накладными расходами, и схему апдейта с поддержкой атомарности, что совсем не бесплатно.
Что мешало сделать не-HTTP API?
НС>Сложности вполне ведомые и задача на практике очень непростая. Хочешь досконально разобраться — попробуй сам реализовать поверх локального диска. Думаю, на этапе осознания необходимости распределенных блокировок ты многое начнешь понимать.
А кто сказал, что они нужны? В данном случае — данные читаются и меняются только в одной реплике. Которую в теории можно создать локально, на том же сервере. Остальные реплики обновляются асинхронно или вообще не нужны, потому что сверх-надежность здесь не нужна.
НС>Именно со storage account API — максимально это premium storage (гиг в секунду), все доступные альтернативные реализации медленнее. Если подойдет S3 API — вариантов больше.
Точно гиг? Throughput per Disk — P30 — 200 MB/sec
НС>Предлагай
Нунжно какой-то части пользователей. Причем многие из них даже не осознают свою проблему.
Здравствуйте, 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) это должно сильно бить по производительности для множества мелких блобов, но не играть большой роли для одного большого блоба. Не так ли?
Здравствуйте, Cyberax, Вы писали:
C>Без понятия. Я вообще не понимаю причём тут ядра и оперативка, чтение блобов — это обычный HTTPS-запрос, который в современных клиентах реализуется вообще с минимальными накладными расходами на поток.
Они точно не нулевые, эти расходы. И на создание каждого треда нужна оперативка под стек.
Кстати, когда ты говорил про терабиты, то это какое хранилище имелось в виду? А то Azure P80 обещает всего лишь 1,000 MB/sec максимум, да и то в прыжке.
Здравствуйте, Codealot, Вы писали:
НС>>Ну вот я и говорю — значит тебе не повезло. Ну и гугль подсказывает, что варианты есть. C>А зачем мне S3?
Чтобы воспользоваться MinIO.
НС>>А использование хранилища в эксклюзивном режиме строго с одной единственной ноды — это сильно далеко за пределами тех сценариев, под которые оно заточено. C>Но внятных альтернатив в Azure нет.
Здравствуйте, Codealot, Вы писали:
C>Кстати, когда ты говорил про терабиты, то это какое хранилище имелось в виду? А то Azure P80 обещает всего лишь 1,000 MB/sec максимум, да и то в прыжке.
В AWS обещают.
Здравствуйте, Cyberax, Вы писали:
C>Без понятия. Я вообще не понимаю причём тут ядра и оперативка, чтение блобов — это обычный HTTPS-запрос, который в современных клиентах реализуется вообще с минимальными накладными расходами на поток.
А как перегонка данных между 2мя io операциями может без памяти обходится? DMA один на всех или для каждого процесса своя область?
Здравствуйте, Sharov, Вы писали:
C>>Без понятия. Я вообще не понимаю причём тут ядра и оперативка, чтение блобов — это обычный HTTPS-запрос, который в современных клиентах реализуется вообще с минимальными накладными расходами на поток. S>А как перегонка данных между 2мя io операциями может без памяти обходится? DMA один на всех или для каждого процесса своя область?
Пропускная способность памяти и кэша — заведомо превышает сетевую скорость.
Здравствуйте, Codealot, Вы писали:
C>Ковыряясь в одной облачной системе с большим количеством баззвордов на предмет "выяснить, почему оно так бешено тормозит", я решил сделать небольшой тест — скачивать данные из storage account на виртуальную машину, которая хостится в том же регионе. Скорость — около 60 мб в секунду То есть даже на гигабитный эзернет не тянет. В связи с чем возник вопрос — это вообще нормально?
Tы замерил throughput. А какой паттерн доступа основной в твоей системе, стриминг, или обмен запросами?
Если стриминг, то тебе нужен throughput и тогда ограничение в 60мб. Тут только закупать более продвинутые инстанцы-стораджы и тд.
А если обмен запросами, то твои замеры нерелевантны, т.к. при обмене запросами основное препятствие это задержки, т.е. latency. Througput влияет а это относительно слабо, скажем, условных 10кб на запрос — твои 60мб в секунду дают условно тыщ 6 запросов в секунду между двумя этими точками при последовательном обмен. При этом latency имеет намного бОльшее влияние. Скажем, задерка всего в 1мс ограничивает количество запросов до 1000 штук при последовательном взаимодействии если используется 1 ядро. На самом деле в клауде задержки гораздо больше 1мс.
Здравствуйте, Codealot, Вы писали:
I>>На самом деле в клауде задержки гораздо больше 1мс.
C>Да уж кто бы сомневался. Реальная скорость чтения — около 50 блобов в секунду на тред.
Так а паттерн взаимодействия какой? Ты сделал на самом деле некоторый микробенчмарк для измерения какой то пропускной способности. А приложение то что представляет собой? Сильно вряд ли в приложухе скачивание файлов из одной зоны в другую.
Здравствуйте, Codealot, Вы писали:
C>Ковыряясь в одной облачной системе с большим количеством баззвордов на предмет "выяснить, почему оно так бешено тормозит", я решил сделать небольшой тест — скачивать данные из storage account на виртуальную машину, которая хостится в том же регионе. Скорость — около 60 мб в секунду То есть даже на гигабитный эзернет не тянет. В связи с чем возник вопрос — это вообще нормально?
вот буквально вчера наблюдал как кластер из трех машин читает из GCS примерно 2.5Гб/с не напрягаясь даже
Здравствуйте, Ikemefula, Вы писали:
I>Так а паттерн взаимодействия какой? Ты сделал на самом деле некоторый микробенчмарк для измерения какой то пропускной способности. А приложение то что представляет собой? Сильно вряд ли в приложухе скачивание файлов из одной зоны в другую.
Случайное чтение данных, в основном.
При чем тут "из одной зоны в другую"?
C>Во первых — три машины с черт знает каким количеством тредов. Во вторых — это в разы меньше, чем скорость даже самого обычного потребительского SSD
топовые десктопные m2 зачастую не вытягивают игры, без спец мер, а при постоянных 2.5Gbs оно уже в первые 10 минут перегреется и уйдет в тротлинг. у меня samsung 98 pro на alder lake, это сейчас топ. 3.4Gbs выдает на рандомном чтении по 65 мб. т.е. не в разы даже на фоне топа.
Здравствуйте, Gt_, Вы писали:
Gt_>топовые десктопные m2 зачастую не вытягивают игры, без спец мер, а при постоянных 2.5Gbs оно уже в первые 10 минут перегреется и уйдет в тротлинг. у меня samsung 98 pro на alder lake, это сейчас топ. 3.4Gbs выдает на рандомном чтении по 65 мб. т.е. не в разы даже на фоне топа.
Это не проблема SSD, это проблема твоей сборки. Сделай нормальное охлаждение — и будет в разы. Один (!) SSD, даже не RAID. К тому же потребительский (!!).
C>Во первых — три машины с черт знает каким количеством тредов. Во вторых — это в разы меньше, чем скорость даже самого обычного потребительского SSD
48 тредов, если правильно помню, я не утверждал что это топ, нам просто больше не надо было, сколько в систему писали, столько и уходило в GCS. Сколько всего туда может пролезть я не измерял, подозреваю что сильно больше, особенно если использовать под это дело отдельный NIC.
Обычный потребительский SSD столько не потянет, для этого нужен NVMe через PCIe, разница в том, что такой сторадж имеет космическую стоимость за TiB, особенно если машина в облаке. Bare metal инстансы с быстрым стораджем в облаке стоят очень дорого если тебе нужно хранить сотни террабайт. AWS S3 или GCS по сравнению с этим стоит копейки и масштабируется до тех же самых GiB/sec скоростей. При этом надежность хранения у тебя намного выше чем в случае локального стораджа. Если это не понятно, зачем ты вообще взялся что-то такое использовать?
C>Это не проблема SSD, это проблема твоей сборки. Сделай нормальное охлаждение — и будет в разы. Один (!) SSD, даже не RAID. К тому же потребительский (!!).
учитывай размер своего потребительского SSD, за сколько он заполнится при записи 2.4GiB/s?
скорость может падать не только из-за теплового троттлинга, но и из-за сборки мусора в FTL
C>Это не проблема SSD, это проблема твоей сборки. Сделай нормальное охлаждение — и будет в разы. Один (!) SSD, даже не RAID. К тому же потребительский (!!).
это проблема в отсутствии у тебя опыта. у меня Fractal Design Define R5, это считай топ. потребительская дребедень рассчитана лишь на кратковременные пиковые нагрузки игр, не более того.
я так понимаю у тебя даже игрового пк в жизни не было, отсюда и глупые ожидания.
Здравствуйте, bitboi, Вы писали:
B>48 тредов, если правильно помню, я не утверждал что это топ, нам просто больше не надо было, сколько в систему писали, столько и уходило в GCS. Сколько всего туда может пролезть я не измерял, подозреваю что сильно больше, особенно если использовать под это дело отдельный NIC.
А, то есть ты подозреваешь. С этим конечно хрен поспоришь.
B>Обычный потребительский SSD столько не потянет, для этого нужен NVMe через PCIe, разница в том, что такой сторадж имеет космическую стоимость за TiB
Цифры где?
B>особенно если машина в облаке.
Без сомнений. Сколько с тебя сдерут, столько и заплатишь.
B>Если это не понятно, зачем ты вообще взялся что-то такое использовать?
Я уже раз 10 писал, что особая надежность нужна далеко не всегда. Чукчанечитатель?
Здравствуйте, Gt_, Вы писали:
Gt_>у меня Fractal Design Define R5, то считай топ.
А, то есть ты реально думаешь что достаточно иметь топовый корпус чтобы решить все проблемы
Gt_> потребительская дребедень рассчитана лишь на кратковременные пиковые нагрузки игр, не более того.
Ну во первых, если ты не заметил, именно я писал, что это всего лишь потребительское устройство.
Во вторых, необходимость делать нормальное охлаждение таки никто не отменял.
В третьих, упомянутый тобой 980 Pro — так себе топ, поскольку это TLC.
Здравствуйте, Codealot, Вы писали:
B>>48 тредов, если правильно помню, я не утверждал что это топ, нам просто больше не надо было, сколько в систему писали, столько и уходило в GCS. Сколько всего туда может пролезть я не измерял, подозреваю что сильно больше, особенно если использовать под это дело отдельный NIC.
C>А, то есть ты подозреваешь. С этим конечно хрен поспоришь.
никто с тобой не спорит, я всего лишь написал что в текущем проекте данные уходят с такой вот скоростью без особых проблем, что-то ради этого специально бенчмаркать я не собираюсь
B>>Обычный потребительский SSD столько не потянет, для этого нужен NVMe через PCIe, разница в том, что такой сторадж имеет космическую стоимость за TiB C>Цифры где?
C>Я уже раз 10 писал, что особая надежность нужна далеко не всегда. Чукчанечитатель?
ты не потрудился написать об этом в первом сообщении (я не читал весь тред), из первого сообщения понятно только что ты сам не читатель и понятия не имеешь как и для чего все эти облачные технологии используют, но при этом почему-то возмущаешься тому, что реальность не соответствует твоим представлениям о ней
Здравствуйте, Codealot, Вы писали:
I>>Так а паттерн взаимодействия какой? Ты сделал на самом деле некоторый микробенчмарк для измерения какой то пропускной способности. А приложение то что представляет собой? Сильно вряд ли в приложухе скачивание файлов из одной зоны в другую.
C>Случайное чтение данных, в основном.
Хорошо, случайное чтение. А софтина то что собой представляет? Сколько запросов в секунду между компонентами, какой характер взаимодействия и какие там задержки?
C>При чем тут "из одной зоны в другую"?
Здравствуйте, Ikemefula, Вы писали:
I>Хорошо, случайное чтение. А софтина то что собой представляет? Сколько запросов в секунду между компонентами, какой характер взаимодействия и какие там задержки?
На самом деле, там сплошные доказательства твоей неправоты. Иди и сам убедись.
B>ты не потрудился написать об этом в первом сообщении (я не читал весь тред), из первого сообщения понятно только что ты сам не читатель и понятия не имеешь как и для чего все эти облачные технологии используют, но при этом почему-то возмущаешься тому, что реальность не соответствует твоим представлениям о ней
Э нет. Не я эту хрень писал, так что не надо теперь вешать собак на меня.
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, Ikemefula, Вы писали:
I>>Хорошо, случайное чтение. А софтина то что собой представляет? Сколько запросов в секунду между компонентами, какой характер взаимодействия и какие там задержки?
C>https://en.wikipedia.org/wiki/Azure_Data_Lake
Я честно не знаю, что это такое, как внутри устроено.
I>>Предположение.
C>Оно говорит главным образом о тебе
Разумеется. Раз я предполагаю, это говорит о том, что телепатия не работает
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, bitboi, Вы писали:
B>>здесь
C>На самом деле, там сплошные доказательства твоей неправоты. Иди и сам убедись.
ты писал "потребительский SSD в разы больше потянет", в разы больше потянет например Samsung PM1653 (если их хотя бы два, лол), но это не потребительский SSD, потребительский SSD использует SATA 3, который ограничен 600MiB/s
единственное из потребительского, что может потянуть 2.5GiB/s, это PCIe NVMe диски, но опять же, ты написал SSD
это все SSD, Кэп, вот только никто никогда не ссылается на NVMe и optane устройства как просто на "потребительский SSD", но даже если ты не такой как все и ты имел ввиду Optane за 3-4 килобакса, черта с два ты с моей нагрузкой обойдешься одним устройством, потому что это непрерывные 2.5GiB/s, ну и даже если отбросить простую арифметику как незначительную деталь, там еще есть чтение (ты же не думал что его нет?), значит один единственный SSD встанет колом из-за read/write interference, и чтение и запись у него будут в разы медленнее при такой нагрузке
Здравствуйте, bitboi, Вы писали:
B>это все SSD, Кэп, вот только никто никогда не ссылается на NVMe и optane устройства как просто на "потребительский SSD",
Да ладно? NVMe уже давно вполне обычный потребительский мейнстрим. И стоит совсем недорого. И выдает при чтении раза в 2.5 больше, чем 2.5GiB/s
Здравствуйте, Codealot, Вы писали:
C>Да ладно? NVMe уже давно вполне обычный потребительский мейнстрим. И стоит совсем недорого. И выдает при чтении раза в 2.5 больше, чем 2.5GiB/s
ты же в курсе, что современные потребительские NVMe дают тебе 600-800 TBW максимум? это значит что у тебя диск умрет через три-четыре дня при такой непрерывной записи
ну и плюс, эти 5-6GiB/s у топовых NVMe, это не sustained write throughput и это не при любой нагрузке, а только при удобной
Здравствуйте, bitboi, Вы писали:
B>ты же в курсе, что современные потребительские NVMe дают тебе 600-800 TBW максимум? это значит что у тебя диск умрет через три-четыре дня при такой непрерывной записи B>ну и плюс, эти 5-6GiB/s у топовых NVMe, это не sustained write throughput и это не при любой нагрузке, а только при удобной
1) А ты в курсе, что непрерывно писать нужно далеко не всем?
2) что у тебя за данные, если ты их непрерывно пишешь и тут же стираешь и перезаписываешь по новой?
3) когда ты говорил о твоем любимом облаке и 2.5 гб/с, то речь шла о чтении. А какая у него скорость записи тебе вообще известно?
C>1) А ты в курсе, что непрерывно писать нужно далеко не всем?
я написал что у меня приложение вот столько непрерывно пишет|читает, ты написал — ерунда, обычный SSD может еще больше, теперь ты пишешь что столько нужно далеко не всем
C>2) что у тебя за данные, если ты их непрерывно пишешь и тут же стираешь и перезаписываешь по новой?
это не у меня, а у клиента (клиент занимается интернет чумой рекламой), данные — горячие пиксели всякие, они не перезаписываются, а постоянно добавляются
C>3) когда ты говорил о твоем любимом облаке и 2.5 гб/с, то речь шла о чтении. А какая у него скорость записи тебе вообще известно?
запись более менее постоянная, где-то на уровне 0.7-1.2GiB/s в зависимости от дня недели и времени суток, чтение по разному, фоново постоянно что-то читается, но есть еще всякие batch штуки, которые могут перечитать весь бакет разок-другой, новые данные пишутся непрерывно, есть ретеншн который удаляет все что старше нескольких месяцев
Здравствуйте, bitboi, Вы писали:
B>я написал что у меня приложение вот столько непрерывно пишет|читает, ты написал — ерунда, обычный SSD может еще больше, теперь ты пишешь что столько нужно далеко не всем
Ты писал про читает. Про "постоянно пишет" ты добавил уже намного позже
B>это не у меня, а у клиента (клиент занимается интернет чумой рекламой), данные — горячие пиксели всякие, они не перезаписываются, а постоянно добавляются
Вообще без понятия, что это за горячие писксели такие, кроме тех что на дешманских мониторах.
Если данные постоянно только добавляются, то
— о TBW тебе точно не стоит беспокоиться
— сколько там петабайт данных уже?
B>запись более менее постоянная, где-то на уровне 0.7-1.2GiB/s в зависимости от дня недели и времени суток, чтение по разному, фоново постоянно что-то читается, но есть еще всякие batch штуки, которые могут перечитать весь бакет разок-другой, новые данные пишутся непрерывно, есть ретеншн который удаляет все что старше нескольких месяцев
То есть никаких постоянных 2.5 гб/с на запись, которых ты требовал.
Здравствуйте, Codealot, Вы писали:
C>Ты писал про читает. Про "постоянно пишет" ты добавил уже намного позже
если что-то читают то и писать наверное тоже должны, тебе так не кажется?
C>Вообще без понятия, что это за горячие писксели такие, кроме тех что на дешманских мониторах.
пиксели которыми трекают загрузку страниц, горячими я их по ошибке обозвал, тип данных тут вообще роли никакой не играет
C>Если данные постоянно только добавляются, то C>— о TBW тебе точно не стоит беспокоиться C>— сколько там петабайт данных уже?
мне не нужно, но ты же говорил что в один SSD можно с такими вот большими скоростями писать
я тебе просто показал, что с такими большими скоростями в один SSD писать можно, но не долго, даже если тебе не нужно все хранить и ты постоянно данные можешь перезаписывать
C>То есть никаких постоянных 2.5 гб/с на запись, которых ты требовал.
да, я в какой-то момент запутался в показаниях, но сути это не меняет, комментарий про "потребительский SSD" отношения к реальности иметь не может
как только данных становится хоть сколько нибудь много (десятки-сотни TiB) локальных сторадж становится очень нетривиальной и дорогой задачей, сколько там отдельный SSD может тебе дать в прыжке — вообще к делу отношения не имеет
ну и не то чтобы один GiB/s это мало, просто сравнивать этот один GiB/s с максимальной пропускной способностью локально диска, это как сравнивать яблоки с апельсинами, единицы измерения одни и те же, но смысл совершенно разный
Здравствуйте, bitboi, Вы писали:
C>>Ты писал про читает. Про "постоянно пишет" ты добавил уже намного позже B>если что-то читают то и писать наверное тоже должны, тебе так не кажется?
Вполне типичный сценарий — записать один раз и потом много раз читать.
Не слышал?
B>пиксели которыми трекают загрузку страниц, горячими я их по ошибке обозвал, тип данных тут вообще роли никакой не играет
Все равно непонятно, что это такое.
B>мне не нужно, но ты же говорил что в один SSD можно с такими вот большими скоростями писать B>я тебе просто показал, что с такими большими скоростями в один SSD писать можно, но не долго, даже если тебе не нужно все хранить и ты постоянно данные можешь перезаписывать
А в облако можно? Так сколько у вас петабайт данных уже?
B>как только данных становится хоть сколько нибудь много (десятки-сотни TiB) локальных сторадж становится очень нетривиальной и дорогой задачей
Ты таки хочешь сказать, что в облаке это будет дешевле?
B>ну и не то чтобы один GiB/s это мало, просто сравнивать этот один GiB/s с максимальной пропускной способностью локально диска, это как сравнивать яблоки с апельсинами, единицы измерения одни и те же, но смысл совершенно разный
Данные пишем, данные читаем. В чем конкретно он "совершенно разный"?
И я так и не увидел ни одного внятного объяснения, почему чтение из облака так тормозит.
То есть даже на гигабитный эзернет не тянет. В связи с чем возник вопрос — это вообще нормально?
Есессно, всё это фуфло тормозит. Я делал совсем уж примитивный тест — простая консолька делала SELECT из базы (MS SQL). Разница с "нативным десктопом" была точно в 2 раза медленнее (точно не скажу, может и в три — я просто тогда охренел и понял, что такие облака мне даром не нужны). Причём не факт, что если ты проапгрэйдишься на более дорогой план, что-то станет намного лучше — РЕАЛЬНОГО железа тебе всё равно не видать — всё будет так же крутиться в виртуалках.
