Компания Micron Technology, специализирующаяся на производстве DRAM и флеш-памяти, представила новый движок хранения HSE (Heterogeneous-memory Storage Engine), разработанный с учётом специфики использования на SSD-накопителях, основанных на NAND flash (X100, TLC, QLC 3D NAND) или постоянной памяти (NVDIMM). Движок выполнен в форме библиотеки для встраивания в другие приложения и поддерживает обработку данных в формате ключ-значение. Код HSE написан на языке Си и распространяется под лицензией Apache 2.0...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52827
хмм, а ничего что монга - ни разу не про "ключ-значение", кэширование данных в оперативке делает сама и вряд ли тут что-то можно улучшить без радикальной переделки?В результате - неясно ни что и на чем они тестировали (ок, wired tiger, загадочный яхин тест на не менее загадочном maven - хз как ложится в чью-то реальную задачу, допустим) - а дальше-то что, может вы там lvm+xfs ненастроенные тестировали?
Ну и дайте угадаю - если ты не сотрудник micron - хрен тебе это удастся настроить, потому что опять нужны сокровенные знания о внутреннем устройстве ssd/nvme "диска", которые тщательно прячутся.
> хмм, а ничего что монга - ни разу не про "ключ-значение"В рамках каждого документа очень даже ключ-значение. Просто сперва надо понять, что значение может быть ссылкой на другой документ
> Ну и дайте угадаю - если ты не сотрудник micron - хрен тебе это удастся настроить, потому что опять нужны сокровенные знания о внутреннем устройстве ssd/nvme "диска", которые тщательно прячутся.
Шок! От нас скрывают внутреннее устройство nvme! И драйверов тоже нет! Уже скоро джва года как нет
> Шок! От нас скрывают внутреннее устройство nvme!знаешь, ты, кажется, зря включал компьютер. Тебя тут шокирует не только и не столько это...
> И драйверов тоже нет!
драйвер nvme ничего не знает о внутреннем устройстве, в том и дело.
У ssd вообще нет никакого специального драйвера. И у "advanced format hdd" тоже. А знать почему-то надо, как ты думаешь (впрочем, было бы тебе, чем) почему?
> Возможность комбинировать в одном хранилище
> различных классов SSD-накопителейПрям "говорит Одесса" ;-)
Занятная штука, спасибо.
Чем этот двужок может быть полезен обычному пользователю? Будет ли он работать в windows 10 домашняя или нужна более новая винда?
Аноним не читатель ? "Движок выполнен в форме библиотеки для встраивания в другие приложения" - куда встроишь, там и будет работать.
Аноним - тролль. Троль должен сидеть голодным )
Покорми тролля, покорми тролля .ука.
Действительно, А зачем обычный пользователь винды 10 будет писать ключи и значения исключительно в байтовых представлениях в какую-то бд?
Т.е. это что-то вроде NoSQL SQLite, заточенная под SSD? Любые, или только Micron? Что-то можно портануть в другие проекты? Например в SQLite?
А что происходит с кэшированными в ОЗУ данными во время аварийного выключения? Что то мне подсказывает что вся база после такого может побиться.
Что есть аварийное выключение? Такого не существует в природе.
Выключение сервера из розетки. Да представь сервера подключаются в физическую розетку, а не летают в облаках вместе с птицами.
Импосибру, такого не бывает. Абсолютно невероятный кейс.
у нормальных серверов бывает несколько блоков питания, и выключение одного блока питания не приводит к отключению сервера, только всех блоков, а это менее вероятный случай
"в вашем идеальном мире"
А блоки питания по вашему сами энергию вырабатывают? Омг теперь я знаю из-за кого данные в датацентрах теряются.
ну давай назовем как "аварийный останов". Такое в природе существует
Оправданием может служить только попадание тактического ядерного заряда прямиком в датацентр.
оправданием может служить криворукость программиста, который написал программу с ошибками, или тупость работника ЦОДа, который ошибся сервером и вынул из стойки не тот
А как же сам лилукс? Может прийти наёмный убийца ООМ и просто снести все монги к хренам, если не полностью, то по тредам. А дальше уже UB, крэши, зависоны, ресеты...
Да все ясно погремушка из сабжа на такое не рассчитана. Штука для бенчамарков мериться.
Кэширование записи в озу позволяет значительно снизить объем записываемых данных. Непредвиденное выключение приведет только к потере этих закэшированных данных. И это нормально.
Главное чтобы у адинистратора были рычаги, чтобы выставить в зависимости от критичности данных размер этого буфера.
Ну не знаю, некоторые файловые системы от такого разваливаются. А тут база данных и тут возможно варианты.
вариантов в любом случае возможны ровно два: мы сохраняем транзакционную целостность, подтверждая программе факт фиксации изменения на персистентном носителе, или мы на нее плюем. (необратимая порча базы/fs все равно возможна - для этого (надеюсь) у нас был бэкап?)Во втором случае вполне можно сохранить (или восстановить, в конце-концов) _структурную_ целостность базы (или fs) - но нет никакой возможности сказать, какие операции теперь надо переделать или считать не происходившими. Потому что мы это теперь никак не узнаем. Эти данные потеряны, нет их. Нигде нет.
Вот зарплату нашему прохфессору кислых щей к счету приплюсовали, но эта ячейка осталась только в памяти. А из счета его работодателя уже вычли, и эта информация (ну, так получилось) уже попала на носитель. А с базой у нас все в порядке.
Вариант интересней - мы уже начали туда писать, и вдруг питание йок, указатель на блок обновился, но содержимое блока - мусор с диска. Опа, оказывается, прохфессор в этом месяце не только не заработал ничего, но и торчит банку пятнадцать миллиардов. Блок на диске - существует, причин не доверять содержимому нет, прохфессор, пройдите на эстакаду. Вместо адреса блока на диске в указателе лежит -1? Профессора не существует вообще, эктерминационная команда выехала для установления структурной целостности мироздания.Чтобы таких вещей не происходило - используются transaction logs и трехступенчатая запись. И любая база, даже такая которой деньги доверять нельзя - пишет их с O_DIRECT, чтобы быть абсолютно точно уверенной, что если запись вернула OK - данные попали на диск, а не в воздухе повисли.
> Кэширование записи в озу позволяет значительно снизить объем записываемых данных.спасибо, профессор, а можно мы вас опять заморозим? Ваша лекция о модных научных тенденциях 1962го года будет актуальна лет через 150. Сейчас, в начале 21 века, writeback cache признан крайне малоэффективным, если что. Особенно вот на модных нынче persistent ram он "полезен", ага.
> Непредвиденное выключение приведет только к потере этих закэшированных данных. И это нормально.
нет, это ненормально, если эти данные вообще были для чего-то нужны. Если они не были нужны ни для чего - их тем более незачем было кэшировать.
Давайте, для понимания, мы потеряем вашу зарплату - ну а чо такова, сервер непредвиденно выключился, перевод денег вашему работодателю мы подтвердить успели, а вам - вот, дырка от бублика.
> Давайте, для понимания, мы потеряем вашу зарплатуЗдесь утрировать все горазды. То, что у вас хранятся только критически важные данные, не значит, что у всех так. Это ущербное мышление.
так критически неважные - не требуют не только транзакционной целостности, а вообще никакой. Ну паламалася база пейсбука после крэша сервера - подумаешь, попищали хомячки, и заново котиков понафоткали и понапостили (сто раз уже так было).Но конкретно пейсбуку они это не продадут - не их клиент, и ни разу не монга там.
Вы опять смешали всё в кучу. Одно дело когда потеряна какая-та статистика за 5 минут, а совсем другое когда потеряны данные пользователей. Во втором случае кэшировать запись практически бессмыленно. Это ничего не даст.
> за 5 минут, а совсем другое когда потеряны данные пользователей. Воданные пользователей - это не только сами котики, это лайки, репосты и прочая бессмысленная фигня.
Вполне себе кэшируются, и, кстати, представляют основную ценность (в отличие от их фоток).
А фотка котика - запишется куда-то в бездонные закрома чохом, но вот бяда - ее связь с акаунтом юзера патерялася. То есть это не теория, оно так уже бывало, не последний раз - в прошлом году.Патамушта у пейсбука для этой цели - мемкэш, и он накрывается вместе с сервером. Поэтому, после пяти лет страданий, они запилили чудо невиданное - персистентный на ssd мемкэш ;-)
Классический пример данных, которые в принципе нужны, но где потерять кусок не проблема (если это, конечно, не раз в неделю происходит) - это профили пользователей (в смысле - кто куда нажал, что больше лайкает, a/b тестирование и т.д.), статистика посещений и подобное. Пишется там много и надо это делать дёшево. Ещё один вариант - разные логи производительности, статистика использования ресурсов и т.п.Впрочем, думаю, что здесь ресь о кэше на чтение
> Классический пример данных, которые в принципе нужны, но где потерять кусок не проблемаэто да. Мы можем прогадить о них вообще все, они заново наполнят, нельзя терять только (внезапно) сами учетки - и они хранятся нифига не в м@ндедб.
(на самом деле, конечно, нет, не можем - это приведет к снижению ежесекундного дохода от рекламы так, что будут уже не массовые порки, а массовые расстрелы - но там такого и не произойдет, оно шардится и дистрибьютится, прогадим мы только несколько процентов - выпорют, но не убьют)Полагаю, да, где-то так целевая аудитория и выглядит - то есть опять пейсбук (только настоящий не разорится на такие дорогие компоненты, у них memcache, что как бе намекает)
> Впрочем, думаю, что здесь ресь о кэше на чтение
вряд ли - для nvme он уже почти бесполезен, для pram тем более. Наоборот, ими диски кэшируют.
Ты больше на его менеджмент потратишь, чем выиграешь.
А вот запись страничная, с преварительным стиранием, и она - тупит, и быстро изнашивает дорогой накопитель.
Бывают ли в этом мире неважные данные? Допустим пользователь загрузил вам фото со своим котиком и удалил со своего диска. База данные сдохла и котик пропал, будет ли доволен пользователь? Если и делать хранилище в RAM, то только с резервированием на двух разных серверах с раздельными резервными источниками питания.
> загрузил вам фото со своим котиком и удалил со своего дискаЯ был бы рад, если бы такой пользователь сам "пропал". /s
> Бывают ли в этом мире неважные данные?конечно. Большинство данных в этом мире - неважны.
> Допустим пользователь загрузил вам фото со своим котиком и удалил со своего диска.
"Дурак, это я его пользователь".
В смысле, это мы его - пользуем. Времена когда пользователь был чем-то уважаемым и ценным, к сожалению, прошли.> База данные сдохла и котик пропал, будет ли доволен пользователь?
а кого это колышет? Куды ни пойди - везде один и тот же пейсбук. Поэтому пользователь заведет себе нового котика, если старый сдох и перефоткать его уже не получится. И выложит поделиться- "го, я создал!" Куда он денется-то?
А лайкающие - пополнят социальный граф - и вот его-то мы храним ни разу не в мемкыше, поэтому твои лайки с прошлого, сдохшего котика - тоже там осели.
> Если и делать хранилище в RAM, то только с резервированием на двух разных серверах с
ох уж эти васяны-неофиты. "У вас на стройке случаи split-brain были? Нет? - Будут!"
Как оно устроено-то внутри? В чём заключается "оптимизация под SSD"? Нигде упоминаний нет. Код читать что ли?> Высокая скорость работы достигается за счёт гибридной модели хранения - наиболее актуальные данные кэшируются в ОЗУ
Охренеть нововведение
UPD: Кажись какая-то очередная вариация на тему LSM
RocksDB тоже оптимизирована под ssd. И она более популярная. Можешь попробовать погуглить как они это сделали, если найдешь
Кто они? Что сделали?Я погуглил - по поводу микроновского поделия ничего не нашёл. Из исходников мало что понятно. Ждём технического описания.
RocksDB оптимизирована под SSD - это ну такое себе... имеется в виду просто то, что там WriteAmp/ReadAmp/SpaceAmp регулируется параметрами. А в целом LSM деревья всё-таки на HDD больший профит дают, чем на SSD.
Чобля?) Я даже знать не желаю, чо ито за херня, ибо мне казалось, что должен предоставляться СТАНДАРТНЫЙ ОПТИМИЗИРОВАННЫЙ ИНТЕРФЕЙС?
Для нестандартных задач оптимизированный интферфейс тоже нестандартный. Вон, можете на всякие сетевые стеки для высоких нагрузок поглядеть
Да мне даже спорить лень. Для нестандартных задач идет свое специальное железо, с драйверами и прочим. За большие бабки обычно))
если в слове "бОльшие" ударение на букве "о" - то целиком и полностью согласен.А по факту - Optane'ы с ресурсом, в 70+ раз бОльшим, но со стандартным простым интэрфэйсом - стоят очень дорого. Не порядок.
Из новости (собственно из исходного пресс-релиза) выпала существенная техническая деталь: "HSE uses the mpool kernel module to store data. Mpool implements an object storage device interface on SSD volumes."Так вот, этот https://github.com/hse-project/mpool достаточно оптимально реализует несколько фичей принципиально важных для производительности key-value storage, особенно тех что близки к парадигме LSM+WAL.
Соответственно HSE заточен под использование mpool, меньше делает лишнего и из-за этого выигрывает в тестах.
О, вот это интересно, да
Если я правильно понимаю, то ситуация далеко не однозначная.Понятно что LSM-чанки пишутся асинхронно, в том числе параллельно на несколько дисков, причем непосредственно из памяти без лишнего копирования. При этом все компоненты "знают" что важна целостность всего чанка и могут произвольно переупорядочивать запись его отдельных блоков (оптимальный write barrier персонально для каждого чанка).
Далее, с одной стороны, в перспективе mpool должен реализовывать true append write с гранулярностью порядка кеш-линии с однократной очисткой страницы. Т.е. например, место под WAL физически очищается один раз, а потом дозаписывается мелким порциями. Таким образом, страница флеша очищается однократно и немного заранее, а не при фиксации в WAL каждой транзакции.
С другой стороны, сейчас mpool НЕ поддерживает "зональные" SSD (которые явно умеют append-ить) и НЕ поддерживает персистентную память (которая вообще всё меняет и обесценивает многие подходы).
Поэтому можно заподозрить, что Micron довел до минимальной готовности и вытолкнул в opensource проект, который теряет перспективы из-за приближения "эры" персистентной памяти.
Не, чот короче на хрен. Лучше бы сделали прямую работу с диском. mpool дурацкий - позволяет хранить либо дописываемый лог, либо большие неизменяемые блобы. То есть как бы почти ФС, но не совсем ФС, с нестандартным интерфейсом, и вообще.и геморрой лишний, и сравнение нечестное получается - может весь выигрыш за счёт page cache? А может весь выигрыш за счёт просто более оптимального интерфейса к ядру?
> Не, чот короче на хрен. Лучше бы сделали прямую работу с диском.
> mpool дурацкий - позволяет хранить либо дописываемый лог, либо большие неизменяемые
> блобы. То есть как бы почти ФС, но не совсем ФС,
> с нестандартным интерфейсом, и вообще.Да, оно принципиально заточено под LSM+WAL.
Проще говоря, отрезали лишний функционал - получили возможность сделать лучше оставшийся.> и геморрой лишний, и сравнение нечестное получается - может весь выигрыш за
> счёт page cache? А может весь выигрыш за счёт просто более
> оптимального интерфейса к ядру?Сравнение не может быть "честным", ибо как-бы получился новый тип накопителя с "более прямым" интерфейсом, и HSE работает только с ним.
Ну так в том-то и проблема
сначало они делают дрянь, с дохнущими после 10-100 перезаписывания ячейками, а потом открывают всякие програмные костыли, чтобы продлит агонию этого богомерского nand qlc выкидаша.
Если по итогу получается выгоднее, чем долговечныве ячейки стоимостью в крыло Боинга - то почему нет? Потмоу что у вас чувство прекрасного страдает?
Тот факт, что кто-то предлагает вам что-то по цене крыла боинга вовсе не означает, что оно реально столько стоит.. как не означает и то, что, при цене даже копейкой меньше, продавец/производитель уйдут «в минус», продавая дешевле себестоимости.Скорее всего, реальная разница в себестоимости продукции на разных технологиях ощутимо меньше.
Просто одна чуть дешевле и продавать её можно чаще( т.к ломается быстрее ), вот другую и не спешат продавать дешевле, выставляя эдакие заградительные цены «просто потому что».п.с: «выгоднее» вообще ничего не делать, кроме как просто деньги печатать..
> п.с: «выгоднее» вообще ничего не делать, кроме как просто деньги печатать..вы там поаккуратнее с такими идеями. Кеннеди вот - пришлось пристрелить.
О, круто! Очень интересно, спасибо за информацию. Ушёл читать, разбираться.
Ну если верить графикам!то годно! Но опять же где взять память(озу)?
Сейчас вообще ОЗУ прям верх моды. Всякие мемкэши развелись - только в путь.
А в итоге у нас уже с десяток уровней абстракций и продолжают абстрагировать. Кэш внутри ссд, кэш в RAID, кэш в драйвере, кэш в драйвере ФС, кэш в приложении... может, хватит?
Весело когда эти кеши валятся в своп.
Если ты где-то возьмешь столько ОЗУ то прямо в ней и держи всю базу скорости будут ух.
прикол в том, что авторы монги об этом - знают. И держат.
Но пытаются сохранить данные при внезапном падении, поэтому скорость у них хороша только когда чтение попадает в кэш, а с записью и особенно update все гораздо интереснее.А у этой хрени, похоже, вопрос сохранения данных вообще не стоит ;-)
> А у этой хрени, похоже, вопрос сохранения данных вообще не стоит ;-)Ну вот опять "не читал, но осуждаю"...
Эта "хрень" (aka HSE) работает быстрее на 99% из-за mpool (модуль ядра).
В свою очередь, mpool реализует примерно две (нужные для LSM+WAL) вещи, но делает это гораздо оптимальнее чем можно сделать через традиционное API POSIX.Чтение "через mpool" получается быстрее, во многом, из-за непосредственного отображения данных в память (memory mapped I/O). В этом есть схожесть с libmdbx.
Запись "через mpool" тоже выходит быстрее, так как без лишнего копирования и засорения страничного кэша ядра. Отдельная принципиальная фишка в дозаписи WAL "в одну страницу флеша" без её стирания (хотя многое еще не реализовано). К этому добавьте асинхронность и распараллеливание (внутри ядра) между разными носителями, а также автоматические идеальные write barriers.
При этом специфическое API и реализация внутри ядра позволяют дополнительно экономить на системных вызовов и модификациях PTE (со сбросом кеша).
Т.е. фактически Micron предложил специфическое API для хранения LSM+WAL на solid-носителях, и на примере HSE показал его в действии.
"Но" здесь только одно - в моем понимании вся затея сильно обесценивается при выходе на рынок персистентной памяти и Micron можно заподозрить в "выбрасывании в open-source" проекта, который вот-вот потеряет актуальность.
>> А у этой хрени, похоже, вопрос сохранения данных вообще не стоит ;-)
> Ну вот опять "не читал, но осуждаю"...дык, а чего читать-то - данные профайлера? Они у вас разьве есть?
Документации нет, вывален какой-то непойми как работающий код и непойми что тестирующие тесты. (насколько они в чей-то конкретный 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 нет.
> это я не понял, но не читать же чудо-код...Тогда мне с вами не о чем говорить.
>> это я не понял, но не читать же чудо-код...
> Тогда мне с вами не о чем говорить.ну звиняйте - если я не вижу ответов на очевидные вопросы в описании софта - я точно не буду их искать реверс-инжинирингом.
И предпочту обойтись своими предположениями, выбирая худшие - потому что редко, на самом деле, случаются чудеса.
Если кто-то за меня расковыряет - я с интересом его послушаю. Но разбираться сам, откуда там волшебные автоматические барьеры - не буду, тем более.
Я правильно понимаю, что без их модуля ядра mpool движок работать не будет?