The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Micron открыл код движка хранения HSE, оптимизированного для SSD

28.04.2020 10:17

Компания Micron Technology, специализирующаяся на производстве DRAM и флеш-памяти, представила новый движок хранения HSE (Heterogeneous-memory Storage Engine), разработанный с учётом специфики использования на SSD-накопителях, основанных на NAND flash (X100, TLC, QLC 3D NAND) или постоянной памяти (NVDIMM). Движок выполнен в форме библиотеки для встраивания в другие приложения и поддерживает обработку данных в формате ключ-значение. Код HSE написан на языке Си и распространяется под лицензией Apache 2.0.

Из областей применения движка упоминается применение для низкоуровневого хранения данных в NoSQL СУБД, программных хранилищах (SDS, Software-Defined Storage) типа Ceph и Scality RING, платформах для обработки больших объёмов данных (Big Data), системах высокопроизводительных вычислений (HPC), устройствах интернета вещей (IoT) и решениях для систем машинного обучения.

HSE оптимизирован не только для достижения максимальной производительности, но и для обеспечения долговечности работы различных классов SSD-накопителей. Высокая скорость работы достигается за счёт гибридной модели хранения - наиболее актуальные данные кэшируются в ОЗУ, что снижает число обращений к накопителю. В качестве примера интеграции нового движка в сторонние проекты подготовлен вариант документно-ориентированной СУБД MongoDB, переведённый на использование HSE.

Технологически HSE опирается на дополнительный модуль ядра mpool, который реализует специализированный интерфейс хранения объектов для твердотельных дисков с учётом их возможностей и особенностей, что позволяет получить принципиально другие характеристики быстродействия и долговечности. Mpool также является разработкой Micron Technology открытой одновременно с HSE, но выделен в самостоятельный инфраструктурный проект. Mpool предполагает использование персистентной памяти и зональных хранилищ, но в настоящее время реализована поддержка только традиционных SSD.

Тестирование производительности при помощи пакета YCSB (Yahoo Cloud Serving Benchmark) показало существенный прирост производительности при использовании хранилища размером 2 ТБ с обработкой блоков данных размером 1КБ. Особенно значительный прирост производительности наблюдается в тесте с равномерным распределением операций чтении и записи (тест "A" на графике).

Например, MongoDB с движком HSE оказался быстрее варианта со штатным движком WiredTiger примерно в 8 раз, а СУБД RocksDB движок HSE обогнал более чем в 6 раз. Отличные показатели также видны в тестах, в которых фигурируют 95% операций чтения и 5% изменения или добавления (тесты "B" и "D" на графиках). В тесте "С", подразумевающем только операции чтения, демонстрируется выигрыш примерно на 40%. Увеличение живучести накопителей SSD при операциях записи по сравнению с решением на базе RocksDB оценивается в 7 раз.

Ключевые особенности HSE:

  • Поддержка типовых и расширенных операторов для обработки данных в формате ключ/значение;
  • Полная поддержка транзакций и с возможностью изоляции срезов хранилища через создание снапшотов (снапшоты также могут применяться для поддержания независимых коллекций в одном хранилище);
  • Возможность использования курсоров для обхода данных в представлениях на основе снапшота;
  • Модель данных, оптимизированная для смешанных типов нагрузки в одном хранилище;
  • Гибкие механизмы управления надёжностью хранения;
  • Настраиваемые схемы оркестровки данных (распределения по разным типам памяти, присутствующим в хранилище);
  • Библиотека с C API, которая может динамически связываться с любыми приложениями;
  • Возможность масштабирования до терабайтов данных и сотен миллиардов ключей в хранилище;
  • Эффективная обработка тысяч параллельных операций;
  • Значительное увеличение пропускной способности, снижение задержек и усиление записи/чтения для различных видов нагрузки по сравнению с типовыми альтернативными решениями;
  • Возможность использовать в одном хранилище SSD-накопители разных классов для оптимизации производительности и долговечности.


  1. Главная ссылка к новости (https://www.micron.com/about/b...)
  2. OpenNews: Используемая проектом MongoDB лицензия SSPL признана недопустимой в Fedora Linux
  3. OpenNews: Релиз документо-ориентированной СУБД MongoDB 4.0
  4. OpenNews: Релиз Memcached 1.5.4 с поддержкой кэша на SSD-накопителях
  5. OpenNews: Уязвимость, предоставляющая доступ к данным на самошифруемых SSD-накопителях
  6. OpenNews: Новая проблема в SSD-накопителях HPE, приводящая к потере данных через 40000 часов
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/52827-hse
Ключевые слова: hse, micron, nosql, mongo, ssd, memory
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (62) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, нах. (?), 11:52, 28/04/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    хмм, а ничего что монга - ни разу не про "ключ-значение", кэширование данных в оперативке делает сама и вряд ли тут что-то можно улучшить без радикальной переделки?

    В результате - неясно ни что и на чем они тестировали (ок, wired tiger, загадочный яхин тест на не менее загадочном maven - хз как ложится в чью-то реальную задачу, допустим) - а дальше-то что, может вы там lvm+xfs ненастроенные тестировали?

    Ну и дайте угадаю - если ты не сотрудник micron - хрен тебе это удастся настроить, потому что опять нужны сокровенные знания о внутреннем устройстве ssd/nvme "диска", которые тщательно прячутся.

     
     
  • 2.30, kai3341 (ok), 16:21, 28/04/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > хмм, а ничего что монга - ни разу не про "ключ-значение"

    В рамках каждого документа очень даже ключ-значение. Просто сперва надо понять, что значение может быть ссылкой на другой документ

    > Ну и дайте угадаю - если ты не сотрудник micron - хрен тебе это удастся настроить, потому что опять нужны сокровенные знания о внутреннем устройстве ssd/nvme "диска", которые тщательно прячутся.

    Шок! От нас скрывают внутреннее устройство nvme! И драйверов тоже нет! Уже скоро джва года как нет

     
     
  • 3.33, нах. (?), 16:45, 28/04/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Шок! От нас скрывают внутреннее устройство nvme!

    знаешь, ты, кажется, зря включал компьютер. Тебя тут шокирует не только и не столько это...

    > И драйверов тоже нет!

    драйвер nvme ничего не знает о внутреннем устройстве, в том и дело.
    У ssd вообще нет никакого специального драйвера. И у "advanced format hdd" тоже. А знать почему-то надо, как ты думаешь (впрочем, было бы тебе, чем) почему?

     

  • 1.3, Michael Shigorin (ok), 11:58, 28/04/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    > Возможность комбинировать в одном хранилище
    > различных классов SSD-накопителей

    Прям "говорит Одесса" ;-)

    Занятная штука, спасибо.

     
  • 1.4, Аноним (4), 12:13, 28/04/2020 Скрыто модератором [﹢﹢﹢] [ · · · ]
  • –2 +/
     
     
  • 2.5, 1 (??), 12:20, 28/04/2020 Скрыто модератором
  • +2 +/
     
     
  • 3.7, gogo (?), 12:36, 28/04/2020 Скрыто модератором
  • +4 +/
     
     
  • 4.8, Аноним (8), 12:46, 28/04/2020 Скрыто модератором
  • +3 +/
     
  • 2.25, Нонон (?), 15:32, 28/04/2020 Скрыто модератором
  • +/
     

     ....ответы скрыты модератором (4)

  • 1.6, Аноним (6), 12:23, 28/04/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Т.е. это что-то вроде NoSQL SQLite, заточенная под SSD? Любые, или только Micron? Что-то можно портануть в другие проекты? Например в SQLite?
     
  • 1.9, Аноним (8), 12:48, 28/04/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А что происходит с кэшированными в ОЗУ данными во время аварийного выключения? Что то мне подсказывает что вся база после такого может побиться.
     
     
  • 2.10, Аноним (10), 12:54, 28/04/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Что есть аварийное выключение? Такого не существует в природе.
     
     
  • 3.12, Аноним (8), 13:07, 28/04/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Выключение сервера из розетки. Да представь сервера подключаются в физическую розетку, а не летают в облаках вместе с птицами.
     
     
  • 4.15, Аноним (10), 13:17, 28/04/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Импосибру, такого не бывает. Абсолютно невероятный кейс.
     
  • 4.44, aaa (??), 21:25, 28/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    у нормальных серверов бывает несколько блоков питания, и выключение одного блока питания не приводит к отключению сервера, только всех блоков, а это менее вероятный случай
     
     
  • 5.51, InuYasha (?), 12:16, 29/04/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    "в вашем идеальном мире"
     
  • 5.54, Аноним (54), 13:43, 29/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А блоки питания по вашему сами энергию вырабатывают? Омг теперь я знаю из-за кого  данные в датацентрах теряются.
     
  • 3.13, Аноним (13), 13:07, 28/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    ну давай назовем как "аварийный останов". Такое в природе существует
     
     
  • 4.16, Аноним (10), 13:18, 28/04/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Оправданием может служить только попадание тактического ядерного заряда прямиком в датацентр.
     
     
  • 5.24, Аноним (13), 15:15, 28/04/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    оправданием может служить криворукость программиста, который написал программу с ошибками, или тупость работника ЦОДа, который ошибся сервером и вынул из стойки не тот
     
     
  • 6.52, InuYasha (?), 12:18, 29/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А как же сам лилукс? Может прийти наёмный убийца ООМ и просто снести все монги к хренам, если не полностью, то по тредам. А дальше уже UB, крэши, зависоны, ресеты...
     
     
  • 7.55, Аноним (54), 13:45, 29/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Да все ясно погремушка из сабжа на такое не рассчитана. Штука для бенчамарков мериться.
     
  • 2.11, Аноним (6), 13:06, 28/04/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Кэширование записи в озу позволяет значительно снизить объем записываемых данных. Непредвиденное выключение приведет только к потере этих закэшированных данных. И это нормально.
    Главное чтобы у адинистратора были рычаги, чтобы выставить в зависимости от критичности данных размер этого буфера.
     
     
  • 3.14, Аноним (8), 13:11, 28/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну не знаю, некоторые файловые системы от такого разваливаются. А тут база данных и тут возможно варианты.
     
     
  • 4.19, нах. (?), 14:15, 28/04/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    вариантов в любом случае возможны ровно два: мы сохраняем транзакционную целостность, подтверждая программе факт фиксации изменения на персистентном носителе, или мы на нее плюем. (необратимая порча базы/fs все равно возможна - для этого (надеюсь) у нас был бэкап?)

    Во втором случае вполне можно сохранить (или восстановить, в конце-концов) _структурную_ целостность базы (или fs) - но нет никакой возможности сказать, какие операции теперь надо переделать или считать не происходившими. Потому что мы это теперь никак не узнаем. Эти данные потеряны, нет их. Нигде нет.

    Вот зарплату нашему прохфессору кислых щей к счету приплюсовали, но эта ячейка осталась только в памяти. А из счета его работодателя уже вычли, и эта информация (ну, так получилось) уже попала на носитель. А с базой у нас все в порядке.
    Вариант интересней - мы уже начали туда писать, и вдруг питание йок, указатель на блок обновился, но содержимое блока - мусор с диска. Опа, оказывается, прохфессор в этом месяце не только не заработал ничего, но и торчит банку пятнадцать миллиардов. Блок на диске - существует, причин не доверять содержимому нет, прохфессор, пройдите на эстакаду. Вместо адреса блока на диске в указателе лежит -1? Профессора не существует вообще, эктерминационная команда выехала для установления структурной целостности мироздания.

    Чтобы таких вещей не происходило - используются transaction logs и трехступенчатая запись. И любая база, даже такая которой деньги доверять нельзя - пишет их с O_DIRECT, чтобы быть абсолютно точно уверенной, что если запись вернула OK - данные попали на диск, а не в воздухе повисли.

     
  • 3.17, нах. (?), 13:52, 28/04/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Кэширование записи в озу позволяет значительно снизить объем записываемых данных.

    спасибо, профессор, а можно мы вас опять заморозим? Ваша лекция о модных научных тенденциях 1962го года будет актуальна лет через 150. Сейчас, в начале 21 века, writeback cache признан крайне малоэффективным, если что. Особенно вот на модных нынче persistent ram он "полезен", ага.

    > Непредвиденное выключение приведет только к потере этих закэшированных данных. И это нормально.

    нет, это ненормально, если эти данные вообще были для чего-то нужны. Если они не были нужны ни для чего - их тем более незачем было кэшировать.

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

     
     
  • 4.21, Аноним (6), 14:44, 28/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Давайте, для понимания, мы потеряем вашу зарплату

    Здесь утрировать все горазды. То, что у вас хранятся только критически важные данные, не значит, что у всех так. Это ущербное мышление.

     
     
  • 5.32, нах. (?), 16:40, 28/04/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    так критически неважные - не требуют не только транзакционной целостности, а вообще никакой. Ну паламалася база пейсбука после крэша сервера - подумаешь, попищали хомячки, и заново котиков понафоткали и понапостили (сто раз уже так было).

    Но конкретно пейсбуку они это не продадут - не их клиент, и ни разу не монга там.

     
     
  • 6.39, Аноним (6), 18:23, 28/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Вы опять смешали всё в кучу. Одно дело когда потеряна какая-та статистика за 5 минут, а совсем другое когда потеряны данные пользователей. Во втором случае кэшировать запись практически бессмыленно. Это ничего не даст.
     
     
  • 7.41, нах. (?), 19:48, 28/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > за 5 минут, а совсем другое когда потеряны данные пользователей. Во

    данные пользователей - это не только сами котики, это лайки, репосты и прочая бессмысленная фигня.
    Вполне себе кэшируются, и, кстати, представляют основную ценность (в отличие от их фоток).
    А фотка котика - запишется куда-то в бездонные закрома чохом, но вот бяда - ее связь с акаунтом юзера патерялася. То есть это не теория, оно так уже бывало, не последний раз - в прошлом году.

    Патамушта у пейсбука для этой цели - мемкэш, и он накрывается вместе с сервером. Поэтому, после пяти лет страданий, они запилили чудо невиданное - персистентный на ssd мемкэш ;-)

     
  • 4.27, Crazy Alex (ok), 16:06, 28/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Классический пример данных, которые в принципе нужны, но где потерять кусок не проблема (если это, конечно, не раз в неделю происходит) - это профили пользователей (в смысле - кто куда нажал, что больше лайкает, a/b тестирование и т.д.), статистика посещений и подобное. Пишется там много и надо это делать дёшево. Ещё один вариант - разные логи производительности, статистика использования ресурсов и т.п.

    Впрочем, думаю, что здесь ресь о кэше на чтение

     
     
  • 5.31, нах. (?), 16:30, 28/04/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Классический пример данных, которые в принципе нужны, но где потерять кусок не проблема

    это да. Мы можем прогадить о них вообще все, они заново наполнят, нельзя терять только (внезапно) сами учетки - и они хранятся нифига не в м@ндедб.
    (на самом деле, конечно, нет, не можем - это приведет к снижению ежесекундного дохода от рекламы так, что будут уже не массовые порки, а массовые расстрелы - но там такого и не произойдет, оно шардится и дистрибьютится, прогадим мы только несколько процентов - выпорют, но не убьют)

    Полагаю, да, где-то так целевая аудитория и выглядит - то есть опять пейсбук (только настоящий не разорится на такие дорогие компоненты, у них memcache, что как бе намекает)

    > Впрочем, думаю, что здесь ресь о кэше на чтение

    вряд ли - для nvme он уже почти бесполезен, для pram тем более. Наоборот, ими диски кэшируют.
    Ты больше на его менеджмент потратишь, чем выиграешь.
    А вот запись страничная, с преварительным стиранием, и она - тупит, и быстро изнашивает дорогой накопитель.

     
  • 3.42, Аноним (42), 20:13, 28/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Бывают ли в этом мире неважные данные? Допустим пользователь загрузил вам фото со своим котиком и удалил со своего диска. База данные сдохла и котик пропал, будет ли доволен пользователь? Если и делать хранилище в RAM, то только с резервированием на двух разных серверах с раздельными резервными источниками питания.
     
     
  • 4.48, Аноним (-), 23:55, 28/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > загрузил вам фото со своим котиком и удалил со своего диска

    Я был бы рад, если бы такой пользователь сам "пропал". /s

     
  • 4.61, нах. (?), 00:30, 30/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Бывают ли в этом мире неважные данные?

    конечно. Большинство данных в этом мире - неважны.

    > Допустим пользователь загрузил вам фото со своим котиком и удалил со своего диска.

    "Дурак, это я его пользователь".
    В смысле, это мы его - пользуем. Времена когда пользователь был чем-то уважаемым и ценным, к сожалению, прошли.

    > База данные сдохла и котик пропал, будет ли доволен пользователь?

    а кого это колышет? Куды ни пойди - везде один и тот же пейсбук. Поэтому пользователь заведет себе нового котика, если старый сдох и перефоткать его уже не получится. И выложит поделиться- "го, я создал!" Куда он денется-то?

    А лайкающие - пополнят социальный граф - и вот его-то мы храним ни разу не в мемкыше, поэтому твои лайки с прошлого, сдохшего котика - тоже там осели.

    > Если и делать хранилище в RAM, то только с резервированием на двух разных серверах с

    ох уж эти васяны-неофиты. "У вас на стройке случаи split-brain были? Нет? - Будут!"

     

  • 1.18, vitalif (ok), 13:58, 28/04/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Как оно устроено-то внутри? В чём заключается "оптимизация под SSD"? Нигде упоминаний нет. Код читать что ли?

    > Высокая скорость работы достигается за счёт гибридной модели хранения - наиболее актуальные данные кэшируются в ОЗУ

    Охренеть нововведение

    UPD: Кажись какая-то очередная вариация на тему LSM

     
     
  • 2.26, Нонон (?), 15:36, 28/04/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    RocksDB тоже оптимизирована под ssd. И она более популярная. Можешь попробовать погуглить как они это сделали, если найдешь
     
     
  • 3.34, vitalif (ok), 17:20, 28/04/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Кто они? Что сделали?

    Я погуглил - по поводу микроновского поделия ничего не нашёл. Из исходников мало что понятно. Ждём технического описания.

    RocksDB оптимизирована под SSD - это ну такое себе... имеется в виду просто то, что там WriteAmp/ReadAmp/SpaceAmp регулируется параметрами. А в целом LSM деревья всё-таки на HDD больший профит дают, чем на SSD.

     

  • 1.20, user90 (?), 14:31, 28/04/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Чобля?) Я даже знать не желаю, чо ито за херня, ибо мне казалось, что должен предоставляться СТАНДАРТНЫЙ ОПТИМИЗИРОВАННЫЙ ИНТЕРФЕЙС?
     
     
  • 2.28, Crazy Alex (ok), 16:08, 28/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Для нестандартных задач оптимизированный интферфейс тоже нестандартный. Вон, можете на всякие сетевые стеки для высоких нагрузок поглядеть
     
     
  • 3.40, user90 (?), 19:26, 28/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Да мне даже спорить лень. Для нестандартных задач идет свое специальное железо, с драйверами и прочим. За большие бабки обычно))
     
     
  • 4.58, Аноним (58), 14:53, 29/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    если в слове "бОльшие" ударение на букве "о" - то целиком и полностью согласен.

    А по факту - Optane'ы с ресурсом, в 70+ раз бОльшим, но со стандартным простым интэрфэйсом - стоят очень дорого. Не порядок.

     

  • 1.22, erthink (ok), 14:57, 28/04/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Из новости (собственно из исходного пресс-релиза) выпала существенная техническая деталь: "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, меньше делает лишнего и из-за этого выигрывает в тестах.

     
     
  • 2.35, vitalif (ok), 17:22, 28/04/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    О, вот это интересно, да
     
  • 2.36, erthink (ok), 18:00, 28/04/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Если я правильно понимаю, то ситуация далеко не однозначная.

    Понятно что LSM-чанки пишутся асинхронно, в том числе параллельно на несколько дисков, причем непосредственно из памяти без лишнего копирования. При этом все компоненты "знают" что важна целостность всего чанка и могут произвольно переупорядочивать запись его отдельных блоков (оптимальный write barrier персонально для каждого чанка).

    Далее, с одной стороны, в перспективе mpool должен реализовывать true append write с гранулярностью порядка кеш-линии с однократной очисткой страницы. Т.е. например, место под WAL физически очищается один раз, а потом дозаписывается мелким порциями. Таким образом, страница флеша очищается однократно и немного заранее, а не при фиксации в WAL каждой транзакции.

    С другой стороны, сейчас mpool НЕ поддерживает "зональные" SSD (которые явно умеют append-ить) и НЕ поддерживает персистентную память (которая вообще всё меняет и обесценивает многие подходы).

    Поэтому можно заподозрить, что Micron довел до минимальной готовности и вытолкнул в opensource проект, который теряет перспективы из-за приближения "эры" персистентной памяти.

     
  • 2.37, vitalif (ok), 18:00, 28/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Не, чот короче на хрен. Лучше бы сделали прямую работу с диском. mpool дурацкий - позволяет хранить либо дописываемый лог, либо большие неизменяемые блобы. То есть как бы почти ФС, но не совсем ФС, с нестандартным интерфейсом, и вообще.

    и геморрой лишний, и сравнение нечестное получается - может весь выигрыш за счёт page cache? А может весь выигрыш за счёт просто более оптимального интерфейса к ядру?

     
     
  • 3.38, erthink (ok), 18:14, 28/04/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Не, чот короче на хрен. Лучше бы сделали прямую работу с диском.
    > mpool дурацкий - позволяет хранить либо дописываемый лог, либо большие неизменяемые
    > блобы. То есть как бы почти ФС, но не совсем ФС,
    > с нестандартным интерфейсом, и вообще.

    Да, оно принципиально заточено под LSM+WAL.
    Проще говоря, отрезали лишний функционал - получили возможность сделать лучше оставшийся.

    > и геморрой лишний, и сравнение нечестное получается - может весь выигрыш за
    > счёт page cache? А может весь выигрыш за счёт просто более
    > оптимального интерфейса к ядру?

    Сравнение не может быть "честным", ибо как-бы получился новый тип накопителя с "более прямым" интерфейсом, и HSE работает только с ним.

     
     
  • 4.43, vitalif (ok), 20:14, 28/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так в том-то и проблема
     

  • 1.23, Аноним (23), 15:13, 28/04/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    сначало они делают дрянь, с дохнущими после 10-100 перезаписывания ячейками, а потом открывают всякие програмные костыли, чтобы продлит агонию этого богомерского nand qlc выкидаша.
     
     
  • 2.29, Crazy Alex (ok), 16:09, 28/04/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Если по итогу получается выгоднее, чем долговечныве ячейки стоимостью в крыло Боинга - то почему нет? Потмоу что у вас чувство прекрасного страдает?
     
     
  • 3.49, Lex (??), 00:04, 29/04/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Тот факт, что кто-то предлагает вам что-то по цене крыла боинга вовсе не означает, что оно реально столько стоит.. как не означает и то, что, при цене даже копейкой меньше, продавец/производитель уйдут «в минус», продавая дешевле себестоимости.

    Скорее всего, реальная разница в себестоимости продукции на разных технологиях ощутимо меньше.
    Просто одна чуть дешевле и продавать её можно чаще( т.к ломается быстрее ), вот другую и не спешат продавать дешевле, выставляя эдакие заградительные цены «просто потому что».

    п.с: «выгоднее» вообще ничего не делать, кроме как просто деньги печатать..

     
     
  • 4.65, FRS (?), 10:26, 30/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > п.с: «выгоднее» вообще ничего не делать, кроме как просто деньги печатать..

    вы там поаккуратнее с такими идеями. Кеннеди вот - пришлось пристрелить.

     

  • 1.45, Иваня (?), 22:07, 28/04/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    О, круто! Очень интересно, спасибо за информацию. Ушёл читать, разбираться.
     
  • 1.50, srgazh (?), 00:46, 29/04/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Ну если верить графикам!то годно! Но опять же где взять память(озу)?
     
     
  • 2.53, InuYasha (?), 12:40, 29/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Сейчас вообще ОЗУ прям верх моды. Всякие мемкэши развелись - только в путь.
    А в итоге у нас уже с десяток уровней абстракций и продолжают абстрагировать. Кэш внутри ссд, кэш в RAID, кэш в драйвере, кэш в драйвере ФС, кэш в приложении... может, хватит?
     
     
  • 3.57, Аноним (54), 13:48, 29/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Весело когда эти кеши валятся в своп.
     
  • 2.56, Аноним (54), 13:48, 29/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Если ты где-то возьмешь столько ОЗУ то прямо в ней и держи всю базу скорости будут ух.
     
     
  • 3.59, нах. (?), 22:07, 29/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    прикол в том, что авторы монги об этом - знают. И держат.
    Но пытаются сохранить данные при внезапном падении, поэтому скорость у них хороша только когда чтение попадает в кэш, а с записью и особенно update все гораздо интереснее.

    А у этой хрени, похоже, вопрос сохранения данных вообще не стоит ;-)

     
     
  • 4.60, erthink (ok), 22:53, 29/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > А у этой хрени, похоже, вопрос сохранения данных вообще не стоит ;-)

    Ну вот опять "не читал, но осуждаю"...

    Эта "хрень" (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" проекта, который вот-вот потеряет актуальность.

     
     
  • 5.62, нах. (?), 01:03, 30/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    дык, а чего читать-то - данные профайлера Они у вас разьве есть Документации ... большой текст свёрнут, показать
     
     
  • 6.63, erthink (ok), 01:12, 30/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > это я не понял, но не читать же чудо-код...

    Тогда мне с вами не о чем говорить.

     
     
  • 7.64, нах. (?), 09:38, 30/04/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >> это я не понял, но не читать же чудо-код...
    > Тогда мне с вами не о чем говорить.

    ну звиняйте - если я не вижу ответов на очевидные вопросы в описании софта - я точно не буду их искать реверс-инжинирингом.

    И предпочту обойтись своими предположениями, выбирая худшие - потому что редко, на самом деле, случаются чудеса.

    Если кто-то за меня расковыряет - я с интересом его послушаю. Но разбираться сам, откуда там волшебные автоматические барьеры - не буду, тем более.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру