Как стать автором
Обновить
49
0
Виталий Исаев @vitalyisaev2

Разработчик

Отправить сообщение

Например, коннектор Greenplum в CedrusData умеет параллельно читать таблицу в несколько потоков.

Если не секрет, как именно CedrusData делит таблицу на фрагменты для параллельного скачивания? Делит количество строк в таблице на N , чтобы узнать размер 1 "блока", и далее эмулирует вычитку блоков с помощью LIMIT/OFFSET?

Например, коннектор Greenplum в CedrusData умеет параллельно читать таблицу в несколько потоков.

А эти читающие потоки видят консистентное состояние таблицы? Иными словами, они будут выполняться в единой "транзакции", изолирующей параллельное чтение от транзакций на запись, которые в момент чтения могли поменять данные в этой таблице?

Большое спасибо за интересную статью. В своём недавнем докладе вы упомянули, что JDBC-источники в Presto/Trino всегда состоят из одного сплита. Означает ли это, что параллельное вычитывание большой таблицы, например, из PostgreSQL невозможно?

Так сделали в Conner Chinook в 1994 г., возникли проблемы:

Two heads on a single platter introduced vibration issues under load, leading to higher failure rates.

Спасибо за интересную статью! Натолкнулся на информацию, что с конца 2000-х жёсткие диски постепенно переходят с кодов Рида-Соломона на LDPC. Как вы думаете, почему это происходит?

Как я понял из этой статьи, однозначного победителя нет.

Спасибо за развёрнутый рассказ, подскажите, пожалуйста:
1. Как часто между дорожками с данными располагаются сервотреки?
2. Вы рассказали, как происходит переход от неправильного сервотрека к правильному. Но как происходит переход от правильного сервотрека к нужной дорожке с данными? Откуда контроллер знает, как следовать за дорожкой с данными (ведь на ней сервометок нет)?
3. Встречали ли вы какие-то книги/пейперы/мануалы, где описывается, как работает сервосистема?

Спасибо, интересно, что было дальше.

Я подозреваю (но совсем не уверен), что в ленточных накопителях чтение идёт блоками, как и в HDD. Следовательно, за 1 IO-операцию можно либо записать, либо прочитать один физический блок. Если работаем с лентой последовательно, такие блоки вычитываются очень часто, и IOPS должен быть высокий (но какой? никто не пишет). Если работаем с лентой в режиме, описанном выше, то получаем IOPS сильно меньше 1. Есть ли ошибки в моём рассуждении?

Да, этот пример понятен, но, если не ошибаюсь, это пример как раз random IO (прочитали по одному смещению, потом читаем совсем по другому, и поэтому долго мотаем ленту). В последовательном IO (как минимум при записи благодаря serpentine recording) должно быть всё хорошо с IOPS, иначе откуда такой throughput?

Или последовательное чтение ленты от начала и до конца также приведёт к паузам в IO вплоть до нескольких минут?

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

Ведь Throughput = IOPS * BlockSize, следовательно, раз уж в стандартах LTO пропускная способность постулируется, значит, известны и IOPS, и BlockSize.

Кстати, что является элементарной единицей хранения данных для магнитной ленты (аналог сектора HDD и блока страниц NAND)?

Если не ошибаюсь, это произошло в 1964-1965 гг. в IBM 2310, то есть это скорее относится к первой статье цикла :)

Спасибо, да, по поводу ЕС ЭВМ понятно. Но интересно, были ли жёсткие диски у наших аутентичных ЭВМ, разработанных, например, школой Лебедева.

Возможно, потому, что Минио не особо юзабелен https://highload.ru/spb/2022/abstracts/9072

Подскажите, пожалуйста, правильно ли я понимаю, что на советских компьютерах до 1980-х не использовались магнитные жёсткие диски. То есть персистентных накопителей с произвольным доступом, кроме магнитных барабанов, не было. Но это странно - ведь если приняли решение всё копировать у IBM, то почему не скопировали диски, которые IBM производила с 1950-х годов? Магнитные барабаны им однозначно уступали в плотности записи и по ряду других характеристик.

Кто объяснит почему на SAS меньше iops?

Расскажите, пожалуйста, подробнее, за счёт какого алгоритма реализовано распределение данных по дискам.

Какие алгоритмы у вас используются для дедупликации?

У вас на сайте написано, что вы бекапите SWAP. Расскажите, пожалуйста, как вы это делаете, и зачем это может понадобиться?

А вам спасибо за прекрасный доклад на Highload, я почерпнул очень много нового!

Это субъективное ощущение. Я просто поймал себя на мысли о том, как тяжело мне переключаться на С/С++ после длительного периода работы на Go (а переключаться раз в несколько месяцев всё же приходится). Каждый раз обязательно наступаешь на грабли из стандартного набора (NPD, висячие указатели...). Но думаю, что это не проблема одного Go, это относится ко всем языкам с автоматическим управлением памятью.

1

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность