Comments 18
Что это было?
Сеньеры разрабы которые не знают про БД и индексы от слова ничего?
Автор, вы сами-то читали что писали?
RavenDB используется для хранения критически важных бизнес‑данных, таких как медицинская информация и финансовые транзакции
Вроде как требования несколько разные: медицинские данные это не OLTP… в отличие от финансовых.
Отдельный вопрос что у вас там за беттинг индустрия, которая вроде как в России запрещена, а в Европах вроде как в районе Гибралтара обитает. И там товарищи вроде как активно на Riak DB сидят, или как там его нынешний клон называется - упокой Господи душе Башо…
Это реальная история касаемо того самого Senior. Не знают как их создать самому в ЯП, самый элементарный пример. Порой интересные кадры встречаются, а так задачи выполняют и работают хорошо. На них жалоб нет, но это забавно со стороны.
Официальная информация, интервью посмотрите с создателем БД, прочитайте документацию прежде писать комментарий.
Беттинг спокойно функционирует и найм происходит через HeadHunter. ЕСТЬ мелкие и крупные компании. В тот же известный всем 1xbet и прочие спокойно устраиваются и работают удаленно.
Вообще без понятия про RiakDb. Никогда о ней не слышал и мои друзья что работают в беттинге тоже, у них MongoDb
в районе Гибралтара обитает
Мальта, Кипр. В основном.
Я помню, как у автора RavenDB знатно пригорело, когда её Афир размазал.
Технически любая СУБД сталкивалась или будет сталкиваться с проблемами - это нормальная часть эволюции сложных систем.
Если вы читали книгу Орена Эйни - libgavran, то знаете, что он подробно разбирает реальные кейсы.
Например, как ALICE выявила серьёзные проблемы в PostgreSQL - и это не делает PostgreSQL «плохой», это делает её активно используемой и тщательно анализируемой.
Когда подобных случаев нет, это обычно означает следующее:
Базу никто не использует
Базу никто не анализирует
База не представляет интереса
Именно активное использование, критика и разбор инцидентов показывают, что продукт живой, востребованный и развивается.
Если уж мерить по критерию «кого размазал Афир», то под этот критерий попадает половина индустрии. Он размазал множество систем - от Cassandra и MongoDB до Etcd, CockroachDB и Redis.
Афир это крутой инженер, для которого подобные разборы = профессиональная деятельность. Его задача как раз в том, чтобы находить слабые места даже в зрелых и популярных системах.
Есть разница между проблемами, найденными в популярных БД, где тесты находят нетривиальные баги, а мейнтейнеры их срочно фиксят, и RavenDB, где Орен просто придумал своё определение ACID и возбух, когда его ткнули носом в то, что в RavenDB нет нормальной поддержки транзакционности.
Вот, нашёл даже правку документации по результатам тестирования, где функциональность RavenDB в области поддержки транзакций заметно скукожилась. https://github.com/ravendb/docs/pull/1766/changes
Никто не придумывает своё определение ACID - эти свойства формализованы и неизменны. Но соблюдение ACID‑гарантий в NoSQL‑БД всегда сопровождается оговорками и условиями.
У любой распределённой базы данных есть контекст, который влияет на транзакционные гарантии. Наличие таких условий само по себе не означает, что транзакции «плохие» или что продукт «не ACID».
В MongoDB, например, итоговые свойства транзакций определяются комбинацией readConcern, writeConcern, топологии кластера, поведения при failover, retry‑сценариев и того, является ли транзакция распределённой.
Документация RavenDB меняется потому, что в процессе эксплуатации и обсуждений возникают новые вопросы, которые требуют уточнений. Появляются баги, которые нужно исправлять, и команда их исправляет. Любая живая система развивается: её поведение уточняется, возможности расширяются, а описание постепенно адаптируется к реальному состоянию продукта.
Вы задаёте сложные и интересные вопросы, и это говорит о глубоком интересе к теме. Но при этом ваша позиция по отношению к RavenDB выглядит предвзятой. Что именно вы хотите доказать - что база данных плохая? Тогда вам придётся убедить в этом Toyota, RakutenKobo и ещё более 12 000 компаний, которые используют RavenDB в продакшене.
Я также вижу в вашем комментарии формулировки вроде «возбух», «пригорело»(не понятно откуда). Это наводит на предвзятость по отношению к Орену и RavenDb.
И, кстати, вам может быть интересна статья Jepsen о PostgreSQL 12.3. У PostgreSQL обнаруживались проблемы с транзакциями и изоляцией, да и такое бывает.
На этом я, пожалуй, закончу обсуждение этой темы. Не хочу продолжать этот диалог. Простите.
соблюдение ACID‑гарантий в NoSQL‑БД всегда сопровождается оговорками и условиями.
Вы не могли бы чуть-чуть развернуть свою мысль? Каким образом модель данных (реляционная, документная, и т. д.) влияет на механизмы соблюдения целостности (ACID)?
Вопрос со звёздочкой: вот в PostgreSQL добавилась поддержка JSON, то есть прямо-таки ровно то, что делает NoSQL СУБД. Какие оговорки и условия, касающиеся ACID, появились в PostgreSQL вследствие добавления этой поддержки?
Я постараюсь ответить кратко, но содержательно.
Реляционная модель - подход нормализации данных т.е разбиения данных по таблицам. Документная модель - обычно подход де-нормализации и хранение корневых агрегатов.
Уже здесь меняется парадигма работы с данными.
Теперь немного о SQL и NoSQL.
SQL-базы появились раньше, в эпоху, когда нагрузка на один узел обычно закрывала основные потребности. Поэтому распределённость исторически не была фундаментальной моделью SQL БД.
Сегодня, например, PostgreSQL предоставляет встроенные механизмы репликации, но полноценная работа отказоустойчивого и распределённого кластера часто строится поверх дополнительной экосистемы: Patroni, Citus и других инструментов.
При этом я бы не делал из этого вывод, что PostgreSQL «плох для распределённых систем». Скорее, разные СУБД изначально делали разные архитектурные акценты.
Более того, PostgreSQL благодаря расширениям способен работать не только с реляционными данными. Например, существует Apache AGE, добавляющий графовую модель и поддержку Cypher-подобных запросов. Я эту вещь лично тестировал. К сожалению - лишь отголосок того приятного, что действительно крутого присутствует в Neo4J.
Просто обратите внимание на этот GitHub и вы поймете насколько сообщество любит и уважает эту БД, но при этом сколько вещей изначально не имеют офф.поддержки.
Более того из-за гибкости настройки PostgreSQL она тоже имеет свои особенности и в том числе с ACID, а точнее Durability. Допустим есть история, как GITHUB терял из-за сбоя при асинхронной репликации данные в 2022 году, там вроде была MySQL. Что то такое было… Однако это не суть. PostgreSQL не скрывает возможные data loss при асинхронной репликации. Везде есть нюансы. Можете почитать на досуге.
JSONB это просто ещё один тип данных вида JSON, только в реляционной модели… Можно обсудить эту вещь, допустим GIN индексы требуют много ресурсов, а так же там медленное обновление. Но… Зачем? Мой комментарий и так уже на целую мини-статью тянет. Это просто полезный тип данных, он не заменяет документные БД.
Поскольку я обсуждаю тут не SQL, а NoSQL, то я сосредоточил внимание именно на этой типологии БД.
Вы ответили длинно и не очень содержательно.
Правильный ответ такой: модель данных и гарантии целостности не связаны примерно никак.
Парадигма работы с данными тут ни при чём вообще: вы можете как в реляционной БД поменять одну строку или несколько строк (в одной таблице или в разных), так и в документной БД поменять один документ или сразу несколько (в одной коллекции или в разных).
Что действительно имеет значение для «нюансов» — это количество хостов, на которых принимается решение о завершении транзакции. В монолитных БД (Oracle, PostgreSQL, Db2...) таких нюансов практически не осталось, в распределённых БД они действительно есть и всегда будут.
Только вот «распределённая» и «документная» — это не синонимы, они описывают разные аспекты СУБД.
Есть монолитные реляционные (это все знают), есть распределённые документные (Mongo, Raven и т. д), есть монолитные нереляционные (BerkeleyDB, например), а есть распределённые реляционные (Cockroach, Fauna, Yugabyte...) И вот в третьей категории нюансов нет, несмотря на реляционность, а в четвёртой — есть.
Да, признаю - я местами смешивал два разных понятия: модель данных и распределённость. Сделано это было намеренно, ради упрощения.
Обратите внимание, что я отдельно писал - тоже с определённым упрощением:
«У любой распределённой базы данных есть контекст, который влияет на транзакционные гарантии».
Дело в том, что исторически NoSQL как направление во многом формировалось вокруг Eventual Consistency и модели BASE - как противовеса ACID. Эти понятия появились и получили распространение параллельно с ростом NoSQL, и именно на этом фоне сложилась ассоциация «документная/NoSQL = мягкие гарантии, реляционная/SQL = строгие».
Что касается формулировок вроде «это все знают» - это уже субъективная оценка и к технической сути отношения не имеет. Кто то незнает и это нормально.
С точки зрения строгой теории - форма хранения и способы достижения консенсуса действительно не связаны, тут спорить не с чем.
Если это было написано именно как академическое уточнение, то вполне здорово. Нечего даже добавить.
Сейчас у меня не так много времени, но, дорогие читатели, я продолжу расширять и дополнять материалы о RavenDB настолько, насколько смогу.
Как я писал в начале статьи, над этим проектом я работаю в одиночку - и это действительно непросто. Но эта работа нужна: иначе такая мощная и продуманная база данных ещё долго оставалась бы в тени.
RavenDB заслуживает внимания, изучения и практического применения, и я постараюсь внести свой вклад в то, чтобы она получила заслуженное место в профессиональном сообществе.
Когда работа над статьёй будет завершена? Тогда, когда вступление перестанет содержать фразу о «живом документе» и превратится в полноценное, завершённое введение.
Пока же статья развивается, дополняется и остаётся открытой для новых материалов.
И да, некоторые вещи мне сложно внести сразу по разным причинам, поэтому в качестве черновика здесь периодически будет появляться что-то подобное
неужели на такой мощной платформе, как C# и .NET, нет собственной базы данных?
Есть Garnet - альтернатива Redis от Microsoft. Он тоже на .net написан
Нууу такое, ведь одно только использование memory mapped files под базой данных это уже огромные риски отказоустойчивости, надёжности и предсказуемости. Кто знает тот знает, если будет минутка - приведу релевантный тред в недавней статье про очередную убер БД.
Upd: https://habr.com/ru/articles/1007060/comments/#comment_29624772
Сразу ответить на ваше сообщение не смог, с 27 августа был занят вплоть до сегодняшнего момента. Я ознакомился, спасибо за комментарий, это действительно интересно.
Разбирать полностью движки хранения и сравнивать их я не собираюсь, но привести конкретику, почему конкретно у Voron это не “огромный риск отказоустойчивости” - могу.
Voron основан на memory-mapped files, т.е. маппит файлы в память, но в первую очередь - для эффективного доступа к страницам без необходимости явно копировать их между kernel space и user space, как это происходит при read() с копированием данных в пользовательский буфер. Voron is based on memory mapped files.
Voron никогда не модифицирует страницу дерева “на месте” внутри активной транзакции - изменения пишутся в новые страницы через copy-on-write, а старые остаются валидными до момента коммита. Это защищает от ситуации “процесс упал посреди записи страницы, и теперь структура дерева повреждена наполовину”. Модифицированные данные работают через scratch space, где изменения выполняются над копией, а не над основной версией страницы, доступной другим транзакциям. Data modified by a transaction is copied into the scratch space - modifications are made on a copy of the data.
Записи в журнале и заголовки транзакций снабжены checksum’ами. При восстановлении Voron проверяет их и обрезает журнал на последней валидной, полностью записанной транзакции - это защита от torn writes/частично записанных блоков при сбое питания. [Voron] Fixed checksum validation being skipped for the last 64 pages of the data file when the allocated page count was an exact multiple of 64
WAL-механизм - стандарт для ACID, конкретно для Durability - реализован через append-only журнал. Voron is a fully transactional storage engine that ensures atomicity and durability using a Write-Ahead Journal (WAJ).
Отдельно, поскольку тема явно отсылает к статье Crotty/Leis/Pavlo “Are You Sure You Want to Use MMAP in Your Database Management System?” (CIDR 2022). Voron все выше не отменяет - он их осознанно принимает в обмен на то, что ОС берёт на себя чтение с диска, кеширование, вытеснение страниц и работу с другими процессами в системе. Автор Voron (Ayende, основатель RavenDB) разбирал эту статью пункт за пунктом здесь
Развёрнутый разбор той же статьи есть и у автора LMDB
Резонанс статья получила серьёзный: до сих пор всплывают в обсуждениях спустя годы после публикации, включая рассылку разработчиков PostgreSQL, где её приносил Брюс Момджан, а Александр Коротков указал, что это просто ещё одна ниша решения. То есть тема действительно спорная даже среди core-разработчиков БД, а не однозначно решённая в пользу “mmap = риск”.
Вообще механизмы mmap вы встретите во множестве систем - проблема не в mmap как таковом, а в модели persistence вокруг него:
Kafka использует mmap для индексов сегментов.
MongoDB - WiredTiger применяет mmap частично, хотя основная буферизация у него уже своя, поверх ОС
Так что если резюмировать: сам факт использования mmap - не индикатор надёжности или её отсутствия, важно, как конкретный движок обходит его слабые места, а у Voron это описано и задокументировано, а не является слепым пятном.
Как пишут базы данных на C#: RavenDb