Как низкоуровнево работать с SSD жестким диском?

Question

[mitaichik]

Всем привет!

Есть 500 млн записей, каждая ~2Kb, то есть всего примерно террабайт данных. Основной тип операции - запрос данных по id. Нужна скорость 20 000 операций чтения записей в секунду.

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

Затем приходит запрос, на основе id вычисляем адрес, читаем 2Кб данных (запись сделаем фиксированного размера), отдаем.

Для этого нужна низкуровневая работа с дисками, и вот куда копать в этой области я не представляю (само приложение написано на java, но этот функционал думаем написать на C)

Если кто знает как такое сделать, подскажите, пожалуйста.

Заранее спасибо.

Answer 1

[Melkij]

Ммм. Вопрос: а нафига вам низкоуровневая работа-то? Более чем высокоуровневого CRUD уровня файла достаточно.

Берёте любой *nix. Всё есть файл, следовательно задача решена. Открываете /dev/sd? на чтение-запись обычными файловыми операциями. fseek'ом перемещаетесь, пишете-читаете кусками по 2кб. Остальное взаимодействие с накопителем оставляете ядру.
Чего-нибудь только придумать с сисадмином, чтобы разрешить операции без запуска всего приложения от рута.

Вопрос номер следующий: у вас и ваших коллег действительно достаточно опыта проектирования и эксплуатации СУБД и файловый систем для реализации всего пласта журналирования, обеспечения восстановления после аварий и консистентности данных?

Answer 2

[Пума Тайланд]

ну просто аллоцируйте файл и сохраняйте в него , зачем тут какая то низкоуровневая работа с диском то ?

Answer 3

[АртемЪ]

Как низкоуровнево работать с SSD жестким диском?

Никак. С диском работает прошивка диска, и с ним можно работать только через стандартные команды интефейса.
Пока вы не разобрали SSD, и не выкинули оттуда память, процессор, и прочую электронику он сам будет работать на низком уровне с памятью, а от компьютера принимать только стандартные команды на запись и чтение.

Затем приходит запрос, на основе id вычисляем адрес, читаем 2Кб данных (запись сделаем фиксированного размера), отдаем.

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

Для этого нужна низкуровневая работа с дисками, и вот куда копать в этой области я не представляю (само приложение написано на java, но этот функционал думаем написать на C

Судя по описанию задачи вам нужна база данных, и не нужно лезть к железу.

Comments

[Oleg Shevelev]

Например aerospike, пишут что внутри оно как раз адаптированно к работе с SSD, но в теории всё верно - есть ограниченный набор инструкций которые можно выполнить и главное знать основные логические отличия и как бы всё. Больше особо ни на что не повлияешь. Ещё, возможно, речь идёт о том что бы читать/писать секторами без файловой системы - это действительно должно быть быстрее, но не на много, важно не наделать багов в софте.

Answer 4

[GavriKos]

Копать в сторону написания драйверов и своей файловой системы.

Answer 5

[Александр Чекалин]

А точно нет ни одной БД (nosql хотя бы), которая бы вам давала адекватную скорость, но все же позволила бы избежать работы с железом? Во-первых, данные все же будут более горячие и более холодные, БД все равно лучше закеширует нужное. Во-вторых, аварии железа вы сами ловить будете, но обработаете ли хорошо? Для этого ОС/драйвера и прочие слои и есть, чтобы вас от гемора избавить. Тем более что SSD - это не просто поле байтов, у него своя логика и "механика работы" (хоть электронная) есть.
Тем более, если уже очень хочется, кто мешает положить на SSD своп размера в 1.5 Тб, заказать ОС и начать работать с террабайтным куском памяти - пусть ОС сама выдавливает данные на диск, когда надо. Сурово конечно, но все равно там алгоритмы не самые тупые и не самыми кривыми руками прописанные - не хуже получится, чем самому писать ).

Comments

[mitaichik]

Безусловно есть, и сейчас так и работает (как раз таки noSQL). Просто думали побыстрому потестировать имеет ли вообще все это какой-либо смысл. Пока никто не собирается использовать это как рабочий вариант, и понятно что это не просто все сделать, но потестировать, имхо, стоит.

[mitaichik]

Но, видимо, не на низком уровне - оказывается там все довольно не просто, а действительно просто с файлом.