Хабр Курсы для админов
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Администрирование доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 37
Круто, интересно, пойду изучать
А вот эта БД-шка redb - она тоже на memory mapped files, как и lmdb? Судя по беглому поиску - да. Похоже, в текущей архитектуре это слабое звено и потенциально станет точкой отказа. Хороший материал по теме: Are You Sure You Want to Use MMAP in Your Database Management System? Еще в документации SQLite тоже есть по теме, для удобства процитирую:
But there are also disadvantages:
An I/O error on a memory-mapped file cannot be caught and dealt with by SQLite. Instead, the I/O error causes a signal which, if not caught by the application, results in a program crash.
The operating system must have a unified buffer cache in order for the memory-mapped I/O extension to work correctly, especially in situations where two processes are accessing the same database file and one process is using memory-mapped I/O while the other is not. Not all operating systems have a unified buffer cache. In some operating systems that claim to have a unified buffer cache, the implementation is buggy and can lead to corrupt databases.
Performance does not always increase with memory-mapped I/O. In fact, it is possible to construct test cases where performance is reduced by the use of memory-mapped I/O.
Windows is unable to truncate a memory-mapped file. Hence, on Windows, if an operation such as VACUUM or auto_vacuum tries to reduce the size of a memory-mapped database file, the size reduction attempt will silently fail, leaving unused space at the end of the database file. No data is lost due to this problem, and the unused space will be reused again the next time the database grows. However if a version of SQLite prior to 3.7.0 runs PRAGMA integrity_check on such a database, it will (incorrectly) report database corruption due to the unused space at the end. Or if a version of SQLite prior to 3.7.0 writes to the database while it still has unused space at the end, it may make that unused space inaccessible and unavailable for reuse until after the next VACUUM.
Because of the potential disadvantages, memory-mapped I/O is disabled by default
Похоже в redb похожим вопросом уже задавались.
Привет! Спасибо за развернутый комментарий
В контексте архитектуры S4 с redb и mmap выбор осознанный, и оно не станет точкой отказа. Главная проблема mmap это падение процесса при I/O ошибке диска, в S4 это норм, redb тут используется как индекс метаданных, а сами данные лежат в append-only логах. В случае жесткого краша (или потери файла БД) срабатывает механизм Crash Recovery: S4 сканирует заголовки томов и с нуля перестраивает индекс
Далее, описанные в SQLite баги с унифицированным кэшем на Windows остаются проблемой windows)) S4 core делал с прицелом на серверный Linux
I/O. Запись/чтение самих объектов не проходит через mmap, большие блобы пишутся и читаются через tokio fs прямо в append-only тома , redb держит только крошечные < 4KB
Отказ от mmap требует реализации собственного buffer pool manager, ну или альтернативы к примеру rocksdb, что невероятно усложняет код и повышает вероятность багов, на что не подписывался пока)
В целом, на днях будет новая альфа релиз, загоню синтетические тесты на краш, отпишусь тут
LMDB Garage на NFS разваливается, тут похоже будет тоже самое.
Зачем такое делать на NFS? Какой-то антипаттерн
S4 core это сверхбыстрая single-нода, которая изначально проектировалась для работы исключительно на локальных дисках. У S4Core есть crash recovery, ну а для для серьезных кластеров с петабайт данных выбирайте Ceph или Ozon, они из коробки по архитектуре созданы для таких вариантов
А вы не сравнивали redb c fjall? Я так понимаю, сейчас это основные key-value либы на расте, наряду со sled, который уже не поддерживается.
Привет, нет. Посмотрел сейчас, это отличия lsm дерево vs b дерево, немного не моя архитектура - у меня B)
разница в скорости чтения и записи, по факту примерно одинаково, только в первом случае скорость чтения будет ниже, а во втором быстрее, ну и другие подводные камни тоже. Попробую изучить на выходных
redb тут используется как индекс метаданных, а сами данные лежат в append-only логах.
Но в статье вы гордитесь тем, что все файлы меньше 4кб помещаются прямо в мету. Как быть?
Изначально архитектура на этом и основывалась, что все что меньше 4кб это в основном метаданные (теги, acl и тд). Возможно, все таки стоит добавить флаг strick_wal, при котором абсолютно все файлы (даже < 4KB) будут дублироваться в append-only , но тут есть подводный камень - падение IOPS, ну и перерасход места, компактор(мусоросборщик) ахренеет от таких мелких файлов, чтение упадет. Но как вариант можно такое сделать как альтернативу если ваши данные настолько мелкозернистые
@x4team_only поддержу комментарий - основная мысль статьи считывается как "у меня все очень надежно". При этом как минимум в одном компоненте есть признанный индустрией коварный антипаттерн. Коварный потому, что в основном работает, но ломается в граничных случаях из-за отсутствия контроля. Такое очень трудно отлаживать и чинить в час X.
И уже на уровне мнения - я, например, попросту игнорирую все статьи по типу "наша новая замечательная БД не обладает недостатками всех существующих баз данных и не содержит tradeoff'ов", когда вижу под капотом memory mapped files. Сразу можно сделать выводы о том, какая боль в конечном счете ждет пользователей. Сама по себе это отличная технология, но кейсы ее применения в БД eventually неудачные.
Очень круто!
Круто! Добавил в закладки.
Вы указываете про миллиарды объектов в тысяче файлов на хранилище.
Это будет приводить к фрагментации фнутреннего хранилища и деградации производительности.
Вы сами проверяли работу вашего кластера на 1-5-50 миллиардах объектах?
Буду рад найти единомышленников в развитии проекта, а также в тестировании 🤝
Привет, интересный проект. Если хочешь найти потенциальных контрибьютеров или пользователей в проект то тебе бы в сообщество опенсорс разрабов: https://t.me/OpenSource_Chat
Там можно поделится своим проектом, задачами из него, они будут опубликованы на https://opensourcehub.tech
Удачи с проектом, выглядит перспективно!
Добрый день. Тут надо уточнить - minio уже форкнули и даже выкатили заплатку. Развивать не планируют, но закрывать дырки да. https://github.com/pgsty/minio. Да и в интерфейсе вернули всё убранное.
А так да, заинересовал ваш проект, желаю удачи и побольше сил и желания всё реализовать. Подписался на github. LDAP в community версии оставьте... :-)
Привет. Жаль что " Развивать не планируют ". К сожалению, когда нет хозяина у проекта, это превращается в забвение, ентерпрайзом конечно оно останется жить, наверное на это и целились. Мне больше всего близка политика Gitlab и их лицензирование. Даже если я поставлю EE версию, то без лицензии оно останется CE. Большинство небольших компаний ограничиваются CE, а для крупняков у них спец условия)
Считаю это достойно поддержки звездой )
Классный проект! Приятно видеть, что на Rust.Всё собирается, всё работает. Как написали выше: "Считаю это достойно поддержки звездой ) ".
Интересный проект. Насколько сложно будет добавить альтернативый сторадж на базе обычной файловой системы?
MinIO удобно заводится поверх любой существующей директори. Триллионы файлов и наносекунды производительности не критичны. Ценна возможность встроить в существующую архитектуру.
Вот это по нашему, взял и запилил.
Я был заинтересован в растфс, даже контрибьютил немного.
Но в итоге разочаровался в проекте
- Ты создаешь PR, в следуещей версии его ломают
- Не факт что новая версия вообще заработает
- Растфс просто разваливался после рестарта подов в кубе (это починили, но не скоро)
- Перманентная альфа, чтото рефакторят (ломают) каждый час и конца этому не видно
После такого смотреть на RustFS как-то неохота https://habr.com/ru/news/982688/
Все равно навайбкожено и здесь и там, может у автора получится лучше.
Согласен, все хотят простым путем пойти) "Я подрублю тыщу агентов и завтра с утра у меня будет супер проект, я сам не буду ничего писать, буду пить пина коладу и вайбкодить!". Но так не работает, когда начинаешь писать с нуля, появляются слишком много сложных вопросов по архитектуре и не только, которые ИИ не сможет нормально найти и обьяснить, разгрести все и принять решение. У меня только неделя минимум ушла на исследование по Минио и aws s3 sdk с signature v2 и signature v4, куча документации пришлось лопатить, я не вылазил до 2 ночи из компа, и к концу недели уже почти пропало желание чтото создавать с нуля, понимая фронт работы 😁 А еще куча других вопросов и сотни тестов по каждому чиху) Если где-то поправил, главное чтобы это не отразилось на другом функционале, просто это не реально для одного человека.
Сейчас вот только в 20:00 я подготовил новую альфу более стабильную, которая прошла все тысячу тестов, включая mint от minio на s3 full compatibility, и уже готовлю к публикации)
Спасибо за интересный и нужный проект.
Так понял, что сейчас это single node server? И как раз для масштабирования планируется добавление raft и тп., а почему не смотрите в сторону распределенных БД чтобы там хранить мету (распространенная практика) или смотрели, но сознательно решили не идти туда?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как я искал замену MinIO S3 и написал свой S4 на Rust