>> А у этой хрени, похоже, вопрос сохранения данных вообще не стоит ;-)
> Ну вот опять "не читал, но осуждаю"...дык, а чего читать-то - данные профайлера? Они у вас разьве есть?
Документации нет, вывален какой-то непойми как работающий код и непойми что тестирующие тесты. (насколько они в чей-то конкретный use-case ложатся с их фиксированным размером блока, которого в жизни не бывает примерно никогда?)
> Эта "хрень" (aka HSE) работает быстрее на 99% из-за mpool (модуль ядра).
проверяли? И если да - то как? Может она не из-за mpool, а из-за того что половина операций п[р]опадает в память, например? Монга, заметьте, тоже умеет и любит память, но писать на диск старается надежно, и недаром у нее такая большая любовь к единственно-верной xfs.
> В свою очередь, mpool реализует примерно две (нужные для LSM+WAL) вещи, но
> делает это гораздо оптимальнее чем можно сделать через традиционное API POSIX.
ну вот этот момент и стоит разобрать подробнее - чем оптимальнее и насколько. Учитывая что от апи posix используется в нужном нам случае весьма небольшая часть, и та в основном в обход типичных средств ос, не для нас предназначенных.
> Чтение "через mpool" получается быстрее, во многом, из-за непосредственного отображения
> данных в память (memory mapped I/O). В этом есть схожесть с
ну и чем это отличается от банального mmap() ? Да, в случае обычной fs наверняка чуть побольше оверхед, но если там все сделано правильно - он приведет только к десятку передач указателей, не должно это обеспечивать потери в восемь раз.
> Запись "через mpool" тоже выходит быстрее, так как без лишнего копирования и
> засорения страничного кэша ядра. Отдельная принципиальная фишка в дозаписи WAL "в
> одну страницу флеша" без её стирания (хотя многое еще не реализовано).
для этого надо знать размер страницы и уметь попасть в нее. Я хз как это сделать надежно, не имея внутрифирменной документации, которой обычно никто делиться не хочет. И об этом, собственно, уже говорилось. Ну и результат, как я понимаю, таки тот, что мы теперь сообщаем о записи до того как она на самом деле произошла, не?
> К этому добавьте асинхронность и распараллеливание (внутри ядра) между разными носителями,
тут, кстати, да, непонятно с чем они сравнивали (опять вопрос к "качеству" информации). Если с lvm stripe + xfs (а то и чем похуже) - то я легко поверю в 8x без всяких махинаций с кэшированием. А если все же это честный тест на single device - то непонятно (зачем он нужен ;-)
> а также автоматические идеальные write barriers.
это я не понял, но не читать же чудо-код...
> Т.е. фактически Micron предложил специфическое API для хранения LSM+WAL на solid-носителях,
> и на примере HSE показал его в действии.
все еще остается вопрос, насколько оно поддерживает целостность, и какую. Похоже, о транзакционной речь не идет? (ну а повредить структуру в lsm+wal, наверное, и не выйдет)
> "Но" здесь только одно - в моем понимании вся затея сильно обесценивается
> при выходе на рынок персистентной памяти и Micron можно заподозрить в
> "выбрасывании в open-source" проекта, который вот-вот потеряет актуальность.
полагаю,этого мы еще доооолго можем не бояться - поскольку персистентная память потребует очень специальных железок (которые не micron производит), а значит будет использоваться только в безумно дорогих специальных случаях. Ну или как вариант - каждый модный-современный сервер будет оснащаться слотом, но целым одним.
а для nvme, как я понимаю, никаких принципиальных отличий от ssd нет.
