Да, признаю - я местами смешивал два разных понятия: модель данных и распределённость. Сделано это было намеренно, ради упрощения.
Обратите внимание, что я отдельно писал - тоже с определённым упрощением:
«У любой распределённой базы данных есть контекст, который влияет на транзакционные гарантии».
Дело в том, что исторически NoSQL как направление во многом формировалось вокруг Eventual Consistency и модели BASE - как противовеса ACID. Эти понятия появились и получили распространение параллельно с ростом NoSQL, и именно на этом фоне сложилась ассоциация «документная/NoSQL = мягкие гарантии, реляционная/SQL = строгие».
Что касается формулировок вроде «это все знают» - это уже субъективная оценка и к технической сути отношения не имеет. Кто то незнает и это нормально.
С точки зрения строгой теории - форма хранения и способы достижения консенсуса действительно не связаны, тут спорить не с чем.
Если это было написано именно как академическое уточнение, то вполне здорово. Нечего даже добавить.
Реляционная модель - подход нормализации данных т.е разбиения данных по таблицам. Документная модель - обычно подход де-нормализации и хранение корневых агрегатов.
Уже здесь меняется парадигма работы с данными.
Теперь немного о 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, то я сосредоточил внимание именно на этой типологии БД.
Никто не придумывает своё определение ACID - эти свойства формализованы и неизменны. Но соблюдение ACID‑гарантий в NoSQL‑БД всегда сопровождается оговорками и условиями.
У любой распределённой базы данных есть контекст, который влияет на транзакционные гарантии. Наличие таких условий само по себе не означает, что транзакции «плохие» или что продукт «не ACID».
В MongoDB, например, итоговые свойства транзакций определяются комбинацией readConcern, writeConcern, топологии кластера, поведения при failover, retry‑сценариев и того, является ли транзакция распределённой.
Документация RavenDB меняется потому, что в процессе эксплуатации и обсуждений возникают новые вопросы, которые требуют уточнений. Появляются баги, которые нужно исправлять, и команда их исправляет. Любая живая система развивается: её поведение уточняется, возможности расширяются, а описание постепенно адаптируется к реальному состоянию продукта.
Вы задаёте сложные и интересные вопросы, и это говорит о глубоком интересе к теме. Но при этом ваша позиция по отношению к RavenDB выглядит предвзятой. Что именно вы хотите доказать - что база данных плохая? Тогда вам придётся убедить в этом Toyota, RakutenKobo и ещё более 12 000 компаний, которые используют RavenDB в продакшене.
Я также вижу в вашем комментарии формулировки вроде «возбух», «пригорело»(не понятно откуда). Это наводит на предвзятость по отношению к Орену и RavenDb.
И, кстати, вам может быть интересна статья Jepsen о PostgreSQL 12.3. У PostgreSQL обнаруживались проблемы с транзакциями и изоляцией, да и такое бывает.
На этом я, пожалуй, закончу обсуждение этой темы. Не хочу продолжать этот диалог. Простите.
И сама история довольно забавная. Есть человек в моём окружении, который следит за новостями одной известной персоны и та известная персона регулярно ездит на конференции.
Мой знакомый, кстати, подписан здесь, на Хабре, на него вроде как. Но этот человек сам толком ничего не публикует. А если что-то и появляется, то, как говорится, кот наплакал. Да и информация там в основном довольно очевидная - всё это легко гуглится, и особо разбирать там нечего.
Да, такое действительно бывает.
Часть действий здесь вложено в Networking, а другая просто не понятно во что. Никогда не понимал этого.
Если у человека действительно стоящий материал - это одно дело. А если по сути там ничего нет - совсем другое.
Спасибо за ссылку, я почитаю. Но в целом к маленьким статьям у меня отношение скорее как к обрывочной информации - они могут дать какую-то отдельную мысль или факт, но целостного понимания темы после них обычно не появляется. Ну и опять же зависит от статьи. Некоторые вещи не требуют освещения на 30 минут.
Они либо забросили это, либо разобрали то, что им было нужно, но дальше информация до моих друзей так и не дошла. В итоге знания вроде бы есть, тема интересная, но фактически всё остаётся в вакууме. Не потому, что информации нет, а потому что у людей зачастую просто нет времени или сил настолько глубоко в это погружаться.
А если учитывать, что аудитория на Хабре непредсказуемая, то, как рассуждали мои знакомые, можно запросто «упасть лицом в грязь» и после этого вообще больше не захотеть писать.
У меня тогда был тот самый энтузиазм, который позволил сдвинуть это с мёртвой точки. Сейчас, оглядываясь назад, понимаю, что я действительно это сделал.
Дальше написание статьи о моём опыте было уже скорее Just For Fun. Я экспериментировал и проверял собственную теорию: «А если я напишу вот это - зайдёт ли людям? А вот это?»
И тут я сам попал в какое-то странное состояние. Статья, которую я сам воспринимал скорее как лёгкий материал про собственный опыт, по сути чуть ли не как халтуру, оказалась успешнее статьи, в которую я вложил огромное количество времени и сил, разбирая архитектуру MassTransit.
Третья статья - уже закрепление всего этого опыта. Мне действительно была интересна RavenDB, но оставлять информацию снова в вакууме я не хотел. При этом делать очередную поверхностную «халтуру» тоже не хотелось.
Это уже был мой осознанный выбор: я понял, что реакция аудитории для меня до конца непредсказуема, но при этом передо мной целая БД, которая, на мой взгляд, освещена недостаточно подробно.
Поэтому я решил просто сделать максимально содержательный материал и посмотреть, что из этого получится.
На данный момент у моих публикаций есть ещё одна личная цель, о которой я не хочу рассказывать публично. Тем более комментарии на Хабре потом не удалить.
Хабр для меня - это не просто способ поделиться знаниями, но и площадка для накопления опыта и экспериментов. В конце концов, к написанию технических статей я отношусь достаточно ответственно.
Вы правы в том, что со стороны я действительно могу звучать как ребёнок. Сейчас, уже на холодную голову, я сам это понимаю. С другой стороны мы все в душе дети я считаю.
Перейдем к точке интереса и тут дьявол, как говорится, кроется в деталях.
Я просто не смогу спокойно публиковать дальше, если будет минусовая карма. И казалось бы - за что?
Я потратил огромное количество времени, чтобы собрать целое пособие и подробнейшим образом рассказать об этой БД. Это не статья, написанная за вечер, - за ней стоят исследования даже ни 1ого месяца.
Я просто наблюдаю за тем, как пишут другие. И это ни в коем случае не камень в их огород, но иногда действительно больно смотреть.
Наверное, моё ожидание какой-то справедливой оценки действительно выглядит по-детски. Жизнь не сахарная вата, да и я не медовый пряник, чтобы всем нравиться.
Но если не любят меня - пусть так. Но сам материал-то хороший.
Видно же, что он как минимум содержательный и структурированный. Минусовать комментарии - одно дело. Но когда из-за этого фактически убивают целый аккаунт - это уже совсем другое.
Люди, как вижу, даже незнают, что они могут убить чужой аккаунт. Так, например, здесь уже убили аккаунт моего друга. А он человек с действительно ценным, местами уникальным опытом, которым мог бы поделиться.
И вот этого я как раз не понимаю. Я своим постом как раз хотел вызвать людей на диалог и выслушать других. Благо уже представление некое есть об о всем.
По возможности тут отвечу:
Спасибо всем тем, кто отписался тут и обсудил со мной эту ситуацию.
Двойное спасибо тем, кто поддержал. Для меня это действительно ценно. Я, если честно, даже не ожидал такой реакции и просто вне себя от счастья)
Просто чувствую, что мотивация постепенно пропадает, силы угасают, и каждый следующий шаг будто делаешь через болото. Да и времени на это далеко не всегда хватает.
Мысли на тот момент, когда статья ещё не была опубликована, были примерно такие:
«Материала пока нет. Но его нужно выпустить, иначе всё это можно просто забросить. Пусть он выйдет не совсем в том виде, в котором я изначально его представлял, - главное сделать этот шаг.»
А дальше уже можно постепенно дополнять и улучшать. Подобное я уже проворачивал с «Архитектура MassTransit: как устроена библиотека под капотом», - там у меня ушёл примерно месяц или даже два на дебаг, исследование и сбор всей необходимой информации.
Иначе есть риск просто пропасть в бесконечных самокопаниях, пытаясь довести всё до какого-то идеала.
Просто вот в чём дело. Я когда-то работал в одном аутсорсе, и там стоял вопрос: использовать Neo4j или другие графовые БД вроде TigerGraph.
И главная проблема была не в том, как писать запросы, а в том, что нормально структурированной информации о самих БД практически нет. Хотелось понять: как она масштабируется, какие у неё возможности, ограничения, сильные и слабые стороны. А вместо этого приходилось собирать информацию по десяткам документов и самому всё анализировать.
Мне это тогда настолько надоело, что я сейчас решил сделать похожий материал про RavenDB. Допустим, человек хочет уйти с MongoDB или CouchDB и рассматривает RavenDB. А где ему быстро понять, что это вообще за БД, как она устроена и на что способна? Изучать документацию 100 лет? Ну глупость же, особенно в сжатые сроки, где выжимают соки. Быстрые стресс тесты, которые вообще ни о чем не говорят.
Из-за этого хорошие БД просто остаются незамеченными.
Поэтому я и не хочу сильно дробить статью. Да, отдельные части читать легче, но чтобы получить целостную картину, придётся постоянно прыгать между десятками документов.
В итоге я захотел сделать не просто набор статей, а некий учебник-пособие - краткий экскурс по всему, что касается RavenDB.
Вот пример из моего Notion - обратите внимание на даты: работа велась долго и тщательно.
И именно поэтому так сложно принять ситуацию, когда серьёзный труд встречают не просто равнодушием, даже негативом.
И это не единый источник, так же вносил часть информации в .txt файлы
Я увидел дизлайк за “сгенерировано ИИ”. Ну ладно, допустим(просто представим человек так подумал), но карму понижать, чтоб я вообще ничего не мог делать здесь…
Публикации с откровенной ерундой набирают популярность, собирают лайки и внимание. А я сижу с материалом, над которым работал месяцами, и не могу поверить, что результат встречают не просто холодно, а негативом.
Вы понимаете, какой это материал: чтобы его написать, я действительно потратил месяц или два работы. Интервью смотрел создателя БД. На хабре нет подобной статьи.
Я изучил биографию создателя базы данных, указал источники, сделал всё, чтобы текст был максимально объективным.
Я прочитал его книгу, статьи, документацию - и вы просто не представляете, сколько сил вложено в этот процесс. Это не поверхностный пересказ, а глубокая работа, требующая времени, внимания и концентрации.
И именно поэтому так демотивирует, когда результат встречают негативом.
Сейчас у меня не так много времени, но, дорогие читатели, я продолжу расширять и дополнять материалы о RavenDB настолько, насколько смогу.
Как я писал в начале статьи, над этим проектом я работаю в одиночку - и это действительно непросто. Но эта работа нужна: иначе такая мощная и продуманная база данных ещё долго оставалась бы в тени.
RavenDB заслуживает внимания, изучения и практического применения, и я постараюсь внести свой вклад в то, чтобы она получила заслуженное место в профессиональном сообществе.
Когда работа над статьёй будет завершена? Тогда, когда вступление перестанет содержать фразу о «живом документе» и превратится в полноценное, завершённое введение.
Пока же статья развивается, дополняется и остаётся открытой для новых материалов.
Если уж мерить по критерию «кого размазал Афир», то под этот критерий попадает половина индустрии. Он размазал множество систем - от Cassandra и MongoDB до Etcd, CockroachDB и Redis.
Афир это крутой инженер, для которого подобные разборы = профессиональная деятельность. Его задача как раз в том, чтобы находить слабые места даже в зрелых и популярных системах.
Технически любая СУБД сталкивалась или будет сталкиваться с проблемами - это нормальная часть эволюции сложных систем.
Если вы читали книгу Орена Эйни - libgavran, то знаете, что он подробно разбирает реальные кейсы.
Например, как ALICE выявила серьёзные проблемы в PostgreSQL - и это не делает PostgreSQL «плохой», это делает её активно используемой и тщательно анализируемой.
Когда подобных случаев нет, это обычно означает следующее:
Базу никто не использует
Базу никто не анализирует
База не представляет интереса
Именно активное использование, критика и разбор инцидентов показывают, что продукт живой, востребованный и развивается.
Это реальная история касаемо того самого Senior. Не знают как их создать самому в ЯП, самый элементарный пример. Порой интересные кадры встречаются, а так задачи выполняют и работают хорошо. На них жалоб нет, но это забавно со стороны.
Официальная информация, интервью посмотрите с создателем БД, прочитайте документацию прежде писать комментарий.
Беттинг спокойно функционирует и найм происходит через HeadHunter. ЕСТЬ мелкие и крупные компании. В тот же известный всем 1xbet и прочие спокойно устраиваются и работают удаленно.
Вообще без понятия про RiakDb. Никогда о ней не слышал и мои друзья что работают в беттинге тоже, у них MongoDb
Хочется делать упор именно на такие материалы - с разбором того, что происходит “под капотом”. Базовые вещи сегодня легко найти в документации, существующих статьях или с помощью нейросетей, а вот глубокие технические разборы встречаются гораздо реже.
Сейчас как раз готовлю новый материал. Тема непростая, поэтому на подготовку потребуется время…
Да, признаю - я местами смешивал два разных понятия: модель данных и распределённость. Сделано это было намеренно, ради упрощения.
Обратите внимание, что я отдельно писал - тоже с определённым упрощением:
«У любой распределённой базы данных есть контекст, который влияет на транзакционные гарантии».
Дело в том, что исторически NoSQL как направление во многом формировалось вокруг Eventual Consistency и модели BASE - как противовеса ACID. Эти понятия появились и получили распространение параллельно с ростом NoSQL, и именно на этом фоне сложилась ассоциация «документная/NoSQL = мягкие гарантии, реляционная/SQL = строгие».
Что касается формулировок вроде «это все знают» - это уже субъективная оценка и к технической сути отношения не имеет. Кто то незнает и это нормально.
С точки зрения строгой теории - форма хранения и способы достижения консенсуса действительно не связаны, тут спорить не с чем.
Если это было написано именно как академическое уточнение, то вполне здорово. Нечего даже добавить.
Я постараюсь ответить кратко, но содержательно.
Реляционная модель - подход нормализации данных т.е разбиения данных по таблицам. Документная модель - обычно подход де-нормализации и хранение корневых агрегатов.
Уже здесь меняется парадигма работы с данными.
Теперь немного о 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, то я сосредоточил внимание именно на этой типологии БД.
Никто не придумывает своё определение ACID - эти свойства формализованы и неизменны. Но соблюдение ACID‑гарантий в NoSQL‑БД всегда сопровождается оговорками и условиями.
У любой распределённой базы данных есть контекст, который влияет на транзакционные гарантии. Наличие таких условий само по себе не означает, что транзакции «плохие» или что продукт «не ACID».
В MongoDB, например, итоговые свойства транзакций определяются комбинацией readConcern, writeConcern, топологии кластера, поведения при failover, retry‑сценариев и того, является ли транзакция распределённой.
Документация RavenDB меняется потому, что в процессе эксплуатации и обсуждений возникают новые вопросы, которые требуют уточнений. Появляются баги, которые нужно исправлять, и команда их исправляет. Любая живая система развивается: её поведение уточняется, возможности расширяются, а описание постепенно адаптируется к реальному состоянию продукта.
Вы задаёте сложные и интересные вопросы, и это говорит о глубоком интересе к теме. Но при этом ваша позиция по отношению к RavenDB выглядит предвзятой. Что именно вы хотите доказать - что база данных плохая? Тогда вам придётся убедить в этом Toyota, RakutenKobo и ещё более 12 000 компаний, которые используют RavenDB в продакшене.
Я также вижу в вашем комментарии формулировки вроде «возбух», «пригорело»(не понятно откуда). Это наводит на предвзятость по отношению к Орену и RavenDb.
И, кстати, вам может быть интересна статья Jepsen о PostgreSQL 12.3. У PostgreSQL обнаруживались проблемы с транзакциями и изоляцией, да и такое бывает.
На этом я, пожалуй, закончу обсуждение этой темы. Не хочу продолжать этот диалог. Простите.
И да, некоторые вещи мне сложно внести сразу по разным причинам, поэтому в качестве черновика здесь периодически будет появляться что-то подобное
Знаю эту ситуацию.
И сама история довольно забавная. Есть человек в моём окружении, который следит за новостями одной известной персоны и та известная персона регулярно ездит на конференции.
Мой знакомый, кстати, подписан здесь, на Хабре, на него вроде как. Но этот человек сам толком ничего не публикует. А если что-то и появляется, то, как говорится, кот наплакал. Да и информация там в основном довольно очевидная - всё это легко гуглится, и особо разбирать там нечего.
Да, такое действительно бывает.
Часть действий здесь вложено в Networking, а другая просто не понятно во что. Никогда не понимал этого.
Если у человека действительно стоящий материал - это одно дело. А если по сути там ничего нет - совсем другое.
Спасибо за ссылку, я почитаю. Но в целом к маленьким статьям у меня отношение скорее как к обрывочной информации - они могут дать какую-то отдельную мысль или факт, но целостного понимания темы после них обычно не появляется. Ну и опять же зависит от статьи. Некоторые вещи не требуют освещения на 30 минут.
Моё движение на Хабре началось просто с интереса. Опыта написания статей у меня до этого не было.
Потом мне захотелось разобраться и осветить одну конкретную тему - «Архитектура MassTransit: как устроена библиотека под капотом. В процессе оказалось, что не только меня интересовал этот вопрос - похожие проблемы были и у коллег моих друзей.
Они либо забросили это, либо разобрали то, что им было нужно, но дальше информация до моих друзей так и не дошла. В итоге знания вроде бы есть, тема интересная, но фактически всё остаётся в вакууме. Не потому, что информации нет, а потому что у людей зачастую просто нет времени или сил настолько глубоко в это погружаться.
А если учитывать, что аудитория на Хабре непредсказуемая, то, как рассуждали мои знакомые, можно запросто «упасть лицом в грязь» и после этого вообще больше не захотеть писать.
У меня тогда был тот самый энтузиазм, который позволил сдвинуть это с мёртвой точки. Сейчас, оглядываясь назад, понимаю, что я действительно это сделал.
Дальше написание статьи о моём опыте было уже скорее Just For Fun. Я экспериментировал и проверял собственную теорию: «А если я напишу вот это - зайдёт ли людям? А вот это?»
И тут я сам попал в какое-то странное состояние. Статья, которую я сам воспринимал скорее как лёгкий материал про собственный опыт, по сути чуть ли не как халтуру, оказалась успешнее статьи, в которую я вложил огромное количество времени и сил, разбирая архитектуру MassTransit.
Третья статья - уже закрепление всего этого опыта. Мне действительно была интересна RavenDB, но оставлять информацию снова в вакууме я не хотел. При этом делать очередную поверхностную «халтуру» тоже не хотелось.
Это уже был мой осознанный выбор: я понял, что реакция аудитории для меня до конца непредсказуема, но при этом передо мной целая БД, которая, на мой взгляд, освещена недостаточно подробно.
Поэтому я решил просто сделать максимально содержательный материал и посмотреть, что из этого получится.
На данный момент у моих публикаций есть ещё одна личная цель, о которой я не хочу рассказывать публично. Тем более комментарии на Хабре потом не удалить.
Хабр для меня - это не просто способ поделиться знаниями, но и площадка для накопления опыта и экспериментов. В конце концов, к написанию технических статей я отношусь достаточно ответственно.
Вы правы в том, что со стороны я действительно могу звучать как ребёнок. Сейчас, уже на холодную голову, я сам это понимаю. С другой стороны мы все в душе дети я считаю.
Перейдем к точке интереса и тут дьявол, как говорится, кроется в деталях.
Я просто не смогу спокойно публиковать дальше, если будет минусовая карма. И казалось бы - за что?
Я потратил огромное количество времени, чтобы собрать целое пособие и подробнейшим образом рассказать об этой БД. Это не статья, написанная за вечер, - за ней стоят исследования даже ни 1ого месяца.
Я просто наблюдаю за тем, как пишут другие. И это ни в коем случае не камень в их огород, но иногда действительно больно смотреть.
Наверное, моё ожидание какой-то справедливой оценки действительно выглядит по-детски. Жизнь не сахарная вата, да и я не медовый пряник, чтобы всем нравиться.
Но если не любят меня - пусть так. Но сам материал-то хороший.
Видно же, что он как минимум содержательный и структурированный. Минусовать комментарии - одно дело. Но когда из-за этого фактически убивают целый аккаунт - это уже совсем другое.
Люди, как вижу, даже незнают, что они могут убить чужой аккаунт. Так, например, здесь уже убили аккаунт моего друга. А он человек с действительно ценным, местами уникальным опытом, которым мог бы поделиться.
И вот этого я как раз не понимаю. Я своим постом как раз хотел вызвать людей на диалог и выслушать других. Благо уже представление некое есть об о всем.
По возможности тут отвечу:
Спасибо всем тем, кто отписался тут и обсудил со мной эту ситуацию.
Двойное спасибо тем, кто поддержал. Для меня это действительно ценно. Я, если честно, даже не ожидал такой реакции и просто вне себя от счастья)
Так что продолжу писать статьи здесь.
Ну, я это понял и так сделал.
Просто чувствую, что мотивация постепенно пропадает, силы угасают, и каждый следующий шаг будто делаешь через болото. Да и времени на это далеко не всегда хватает.
Мысли на тот момент, когда статья ещё не была опубликована, были примерно такие:
«Материала пока нет. Но его нужно выпустить, иначе всё это можно просто забросить. Пусть он выйдет не совсем в том виде, в котором я изначально его представлял, - главное сделать этот шаг.»
А дальше уже можно постепенно дополнять и улучшать. Подобное я уже проворачивал с «Архитектура MassTransit: как устроена библиотека под капотом», - там у меня ушёл примерно месяц или даже два на дебаг, исследование и сбор всей необходимой информации.
Иначе есть риск просто пропасть в бесконечных самокопаниях, пытаясь довести всё до какого-то идеала.
Просто вот в чём дело. Я когда-то работал в одном аутсорсе, и там стоял вопрос: использовать Neo4j или другие графовые БД вроде TigerGraph.
И главная проблема была не в том, как писать запросы, а в том, что нормально структурированной информации о самих БД практически нет. Хотелось понять: как она масштабируется, какие у неё возможности, ограничения, сильные и слабые стороны. А вместо этого приходилось собирать информацию по десяткам документов и самому всё анализировать.
Мне это тогда настолько надоело, что я сейчас решил сделать похожий материал про RavenDB. Допустим, человек хочет уйти с MongoDB или CouchDB и рассматривает RavenDB. А где ему быстро понять, что это вообще за БД, как она устроена и на что способна? Изучать документацию 100 лет? Ну глупость же, особенно в сжатые сроки, где выжимают соки. Быстрые стресс тесты, которые вообще ни о чем не говорят.
Из-за этого хорошие БД просто остаются незамеченными.
Поэтому я и не хочу сильно дробить статью. Да, отдельные части читать легче, но чтобы получить целостную картину, придётся постоянно прыгать между десятками документов.
В итоге я захотел сделать не просто набор статей, а некий учебник-пособие - краткий экскурс по всему, что касается RavenDB.
Вот здесь все описано
Я вас понимаю, но тяжело оставаться равнодушным.
Вот пример из моего Notion - обратите внимание на даты: работа велась долго и тщательно.
И именно поэтому так сложно принять ситуацию, когда серьёзный труд встречают не просто равнодушием, даже негативом.
И это не единый источник, так же вносил часть информации в .txt файлы
Я увидел дизлайк за “сгенерировано ИИ”. Ну ладно, допустим(просто представим человек так подумал), но карму понижать, чтоб я вообще ничего не мог делать здесь…
Я всё больше прихожу к выводу, что делиться материалами не имеет смысла, как сделал мой друг однажды.
Гораздо спокойнее изучать тему для себя: углубляться, разбираться, накапливать знания - и максимум делиться ими только с друзьями.
Такой принцип, похоже, работает везде: меньше разочарований, больше пользы для себя и близкого круга.
Не делаешь добра - и не получаешь зла.
Ситуация сейчас такая: я просто в шоке.
Публикации с откровенной ерундой набирают популярность, собирают лайки и внимание. А я сижу с материалом, над которым работал месяцами, и не могу поверить, что результат встречают не просто холодно, а негативом.
Вы понимаете, какой это материал: чтобы его написать, я действительно потратил месяц или два работы. Интервью смотрел создателя БД. На хабре нет подобной статьи.
Я изучил биографию создателя базы данных, указал источники, сделал всё, чтобы текст был максимально объективным.
Я прочитал его книгу, статьи, документацию - и вы просто не представляете, сколько сил вложено в этот процесс. Это не поверхностный пересказ, а глубокая работа, требующая времени, внимания и концентрации.
И именно поэтому так демотивирует, когда результат встречают негативом.
Сейчас у меня не так много времени, но, дорогие читатели, я продолжу расширять и дополнять материалы о RavenDB настолько, насколько смогу.
Как я писал в начале статьи, над этим проектом я работаю в одиночку - и это действительно непросто. Но эта работа нужна: иначе такая мощная и продуманная база данных ещё долго оставалась бы в тени.
RavenDB заслуживает внимания, изучения и практического применения, и я постараюсь внести свой вклад в то, чтобы она получила заслуженное место в профессиональном сообществе.
Когда работа над статьёй будет завершена? Тогда, когда вступление перестанет содержать фразу о «живом документе» и превратится в полноценное, завершённое введение.
Пока же статья развивается, дополняется и остаётся открытой для новых материалов.
Если уж мерить по критерию «кого размазал Афир», то под этот критерий попадает половина индустрии. Он размазал множество систем - от Cassandra и MongoDB до Etcd, CockroachDB и Redis.
Афир это крутой инженер, для которого подобные разборы = профессиональная деятельность. Его задача как раз в том, чтобы находить слабые места даже в зрелых и популярных системах.
Технически любая СУБД сталкивалась или будет сталкиваться с проблемами - это нормальная часть эволюции сложных систем.
Если вы читали книгу Орена Эйни - libgavran, то знаете, что он подробно разбирает реальные кейсы.
Например, как ALICE выявила серьёзные проблемы в PostgreSQL - и это не делает PostgreSQL «плохой», это делает её активно используемой и тщательно анализируемой.
Когда подобных случаев нет, это обычно означает следующее:
Базу никто не использует
Базу никто не анализирует
База не представляет интереса
Именно активное использование, критика и разбор инцидентов показывают, что продукт живой, востребованный и развивается.
Допустим в 1xbet, как пример, нанимают не напрямую, а через Аутстафф(компания прокладка). Там вы можете проживать где угодно и спокойно работать.
Это реальная история касаемо того самого Senior. Не знают как их создать самому в ЯП, самый элементарный пример. Порой интересные кадры встречаются, а так задачи выполняют и работают хорошо. На них жалоб нет, но это забавно со стороны.
Официальная информация, интервью посмотрите с создателем БД, прочитайте документацию прежде писать комментарий.
Беттинг спокойно функционирует и найм происходит через HeadHunter. ЕСТЬ мелкие и крупные компании. В тот же известный всем 1xbet и прочие спокойно устраиваются и работают удаленно.
Вообще без понятия про RiakDb. Никогда о ней не слышал и мои друзья что работают в беттинге тоже, у них MongoDb
Спасибо за фидбек :)
Хочется делать упор именно на такие материалы - с разбором того, что происходит “под капотом”. Базовые вещи сегодня легко найти в документации, существующих статьях или с помощью нейросетей, а вот глубокие технические разборы встречаются гораздо реже.
Сейчас как раз готовлю новый материал. Тема непростая, поэтому на подготовку потребуется время…