Мультивселенная СУБД
184 subscribers
115 photos
1 video
4 files
257 links
Канал для тех, кто хочет стать супергероем этой мультивселенной
Download Telegram
Недавно вышел свежий номер журнала Database Trends and Applications Magazine за февраль/март 2024 года.

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

Особо ничего существенного для мира СУБД там не сказано, однако поделись некоторыми выдержками из статей, которые меня заинтересовали.

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

- Внедрении ИИ вскрыла гнойник связано с качеством данных. Порой критичные данные располагаются в самых необычных местах. Всё это объединить и очистить - очень трудоемкая задача. Возможно поэтому практики DevOps начинают проникать в мир СУБД (DataOps).

- Nihal Mirashi, principal solutions marketing manager:
Мираши указал на тенденцию в рамках которой автоматизация операций с базами данных приводит к изменению ролей. Эти “data-centric” роли превратили администратора базы данных (DBA) в архитектора данных, аналитика данных - в инженера бизнес-аналитики (BI), а инженера по качеству данных (SRE) - в специалиста по обработке данных (Data scientist).


- Marsha Pierce, global practice lead for databases:
[Data reduction] важно, потому что хранение данных стоит денег. Если мы сможем помочь сократить и смягчить тот экспоненциальный рост объема данных, который наблюдается в наших компаниях, тогда мы действительно будем хорошо распоряжаться деньгами компаний, и лучше использовать нашу инфраструктуру.


Напоследок приведу лишь несколько заголовков статей. Их даже разбирать не стоит и так всё будет понятно о чем будет статья. Если вам вдруг интересно содержание ссылки сохраню:

"Move to the Cloud, AI and Machine Learning, DevOps, and Data Governance:Four Trends That Defined 2023" by Kevin Kline.

"Large Language Models May Have Unacceptable Carbon Footprints" by Guy Harrison
🎦Дарья Колесова. Как выбрать технологии для базы данных?

Посмотрел недавно видео о выборе СУБД от 2022 года. Мне понравился подход, который строится на анализе проблемы и потребности.

Первые 40 минут видео прекрасны😍. (Я даже думаю некоторые фрагменты использовать в своих лекциях). Спикер подходит к выбору продукта, исходя из базовых критериев, и заполняет анкету, отмечая те пункты, которые способны удовлетворить (гипотетические) требования заказчика.

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

Третья часть (50 и далее минут) - секция вопросов-ответов.

Вопрос: "Зачем существует MongoDB, если можно взять PostgreSQL и хранить там документы формата JSON?". Ответ:
📍 Postgres медленный.
📍 У Postgres жесткая схема. Приводится пример с тем, что данные могут быть различные по полям. (Явно спикер потерял мысль - обсуждается именно JSON формат).
📍 SQL - это не про JSON.
Как вы поняли, согласиться можно только с первым пунктом. Все остальные доводы нерелевантны.

Если бы этот вопрос задали мне, то я бы отметил громоздкость такого решения. Postgres - универсальная СУБД, большая и мощная. Следовательно, её тяжело администрировать и сопровождать. С MongoDB все в разы проще, это во-первых.

Во-вторых, MongoDB действительно лучше оптимизирована под хранение, обработку JSON-формата данных. (Хотя это спорное утверждение и нуждается в "пруфах"). Недавно Константин Осипов делал доклад на конференции CodeFest Russia. Оказалась, что MongoDB 4.x и 5.x очень плохо справляется с транзакционной нагрузкой. Сейчас выпущен MongoDB 7.х. Возможно, там что-то оптимизировали.

В-третьих, потребность добавления в архитектуру вашего приложения СУБД MongoDB может быть вызвана необходимостью банально снизить нагрузку на основную СУБД (Postgres). Одним из популярных паттернов проектирования является: "1 задача - 1 СУБД".

Еще один ответ, который меня триггернул:
Вопрос: Хочу стать системным аналитиком/спецом по BigData. С чего начать?
Ответ: пытайтесь устроиться в крупные компании, смотрите видео, читайте книжки и т.п.
🤦‍♂️

Мой ответ: идете на популярный сайт по поиску работы (hh, авито, superjob). Ищете вакансию, которая вам нравится. Ищите список требуемых навыков и выписывайте их.

Далее смотрите на свой бюджет:
Денежки нет: в YouTube ищем обучающие видео и занимаемся по ним. Тот же совет по книгам.
Денежка есть: Ищете обучающие курсы по выбранной вакансии и сравнивайте программу курса со списком требуемых навыков. Если совпадение есть более чем на 80%, то это успех! Покупайте курс и учитесь.
Денежка есть и мотивации много: ищем ментора. Этот человек максимально быстро погрузит вас в выбранную профессию. Мне кажется, в РФ это не сильно распространено, но эффективность крайне высокая.

Я бы рекомендовал сайт по менторингу от своего коллеги.
👍2🔥1👀1
📻NoSQL FM
Казалось бы, только недавно мы привыкли считать, что современные СУБД - это не просто база данных, а еще и сервер приложений со своими уникальными фишками. Но никто не думал, что можно двигаться в противоположную сторону - в сторону операционной системы.

Статья, в которой разбирается концепция СУБД/ОС как единого механизма.

Концептуально - идея ТОП. Осталось только собрать народ и протестировать новую архитектуру на соответствие современным стандартам рабочих нагрузок.
"Немного юмора в чат" (с)

#mems
🔥9
Не смог пройти мимо и не прочесть статью на любимом Хабре от товарищей из YDB: Когда одного Postgres'a мало: сравнение производительности PostgreSQL и распределенных СУБД

Всегда интересно, когда народ сравнивает производительности распределенных систем. Мне очень симпатичен CockroachDB, хотя я с ним никогда не работал. Почему-то доклады по этой СУБД вызывают у меня бурный интерес. Аналогичные чувства у меня и к ScyllaDB.

Несмотря на то, что статья классифицируется хабром как "сложная", написана она довольно понятным языком. Вообще, автор молодец. Я прочел статью практически на одном дыхании. Хотя мне не хватило каких-то более глубоких выводов. Как-то поверхностно получилось: "Постгрес - отличное решение, пока не требуется горизонтальное масштабирование. CockroachDB и YDB - хороши во всем".
😱3
🗓8-9 апреля проходит конференция PGConf.Russia 2024.
Организатор - компания
Postgres Professional. По счастливому совпадению, место проведения конференции - Бизнес-центр «Рэдиссон Славянская». Да-да, то же место, где проходят конференции ВБА и IFIN, на которых я бываю каждый год.

День 1.

Из плюсов:

Еда 🍱 - безусловный плюс. Всего много, и качество отличное. Обед был очень неплох 👌. Фуршет под конец первого дня был просто волшебным! Много горячего, бургеры, шашлычки, роллы, салаты, пироженки, муссы и многое другое🥂. И вишенкой на торте - живая музыка. Очень круто!

Стенд СУБД Pangolin. Один из самых крутых стендов. Мерча было немного, но кое-что удалось урвать. Главным для меня было познакомиться и пообщаться с разработчиками - думаю включить эту СУБД в мой курс по базам данных в следующем году. Ах да, там же был розыгрыш умной колонки Сбера. Угадайте, кто выиграл? Да, это был я ) чистое совпадение )) никакой подставы )))

Заполучил книжку Мониторинг PostgreSQL с автографом автора Алексея Лесовского.

Из минусов:
Тьма народу, которым было явно тесно на конференции. Хотя после 17 часов народ рассосался, но всё равно. Например, на доклады, которые стартовали ровно в 15 часов, не было мест! Все залы были забиты людьми. Народ сидел на лестницах.

Мало времени было уделено секции Q&A. Чаще всего её просто пропускали. То ли докладчики не помещались в тайминг, то ли организаторы напутали с расписанием.

Я посетил следующие доклады:

PostgreSQL 17 - спикер Павел Вениаминович Лузанов.

В целом, ничего особо интересного. Доработали тут, доработали там. Ничего важного мне не запомнилось. Сложилось впечатление, что доработали то, что было внедрено еще в 16 версии. "Довели до ума".

Про-Shardman - спикер Алексей Евгеньевич Борщев

Рассказ о Shardman, какой он классный и что умеет. Тоже какой-то проходной доклад. Проще было задать вопросы у стенда Shardman и получить ответы.

Консистентность в распределенных системах на базе PostgreSQL - спикер Никита Сергеевич Печёнкин.
Этот доклад более интересный - про виды консистентности и изолированности. В открытом доступе единственным инструментом тестирования распределенных систем является Jepsen. Товарищи из Shardman адаптировали тесты под свою СУБД и нашли ряд проблем, сейчас активно их решают.

Безопасность баз данных - Владимир Иванович Комаров, СберТех (разработчик СУБД Pangolin).
Один из лучших докладов! Очень четко и по полочкам разложил все функции по обеспечению безопасности, которые внедрены в Pangolin. У меня прям вопросов не осталось. Очень круто.

Оптимизация OLTP-нагрузки - Сергей Новиков.
Второй по значимости доклад. Безумного интересно, как в компаниях DBA занимаются оптимизаций на уровне СУБД. Можно почерпнуть кучу лайфхаков для себя. Как только выложат видео докладов, сделаю отдельный пост.

Мониторинг и алертинг большой инфраструктуры - Алексей Сергеевич Светличный от Тинькофф.
Казалось бы, тоже должен быть интересный доклад, и поначалу так оно и было, но... в итоге можно сделать такой вывод: Тинькофф с помощью разных команд разработчиков создали несколько доп.систем, которые в совокупности решают задачи мониторинга и аллертинга. Единственное, что полезного я вынес: все метрики и способы сбора метрик у них вполне стандартные. Ничего сверхнового или необычного нет.

Очень жду 2-ого дня конференции. Фотки выложу чуть позже отдельным постом.
🎉1
🗓 8-9 апреля проходит конференция PGConf.Russia 2024.
PGConf.Russia – международная техническая конференция по открытой СУБД PostgreSQL

День 2.

День для меня начался беседой с коллективом стенда Pangolin. Говорили про обучение специалистов и студентов в разных ВУЗах. К разговору подключился Владимир Комаров, автор книги "Путеводитель по базам данных". Оказывается, он тоже хочет разработать актуальный курс по СУБД для студентов ВУЗов. Я пригласил его поучаствовать в своей разработке нового курса. Надеюсь, наше сотрудничество будет плодотворным.

Пообщался с Михаилом Жилиным из Postgres Professional. Пригласил его провести в следующем году 1-2 лекции про распределенную СУБД Shardman. Причем, формат лекции будет необычным. Мы еще согласовываем детали, но должно быть интересно. Лекция, скорей всего, (на 90%) будет офлайн. Прямо на территории СберТеха.

Встретил коллегу-преподавателя из МПГУ. Он привел на конференцию своих студентов. В целом, студентов было не много. Я видел 1-2 человека из НИЯУ МИФИ, УКИТ им.Разумовского и МИРЭА. У меня сложилось впечатление, что народ пришел просто так. Посмотреть, как и что тут люди делают. Хотя я слышал много хороших слов в адрес докладчиков от них. Кстати, компания PostgresPro проводит бесплатные стажировки. Можно, учась параллельно в ВУЗе, обучаться предполагаемой профессии. Возможно, для студентов МФТИ и нашей кафедры БИТ это не очень актуально, но для студентов колледжей, ВУЗов ниже первой десятки, такой вариант очень привлекателен. Я даже думаю пройти их "лагерь". Авось, что-то интересно почерпну.

По традиции, немного про доклады:
JSONB и будущее реляционных СУБД - взгляд разработчика - Василий Пучков
Доклад больше всего интересен тем, что автор подробно расписывает процесс разработки схемы базы данных на примере нефтебазы. Для чего каждая сущность нужна? Почему именно такие связи и т.д. В конце он говорит, как именно большинство бизнес-запросов с 3-6 операциями join можно упростить с внедрением JSON. К сожалению, автор не привел примера упрощённой схемы базы данных после добавления этого поля ☹️ Но это не умаляет ценность доклада.

Слон и Моська. Проблема фенсинга в кластерах PostgreSQL - Павел Конотопов.
Очень интересный кейс как разломать кластер Постгрес привел автор доклада. Сценарий:
1. Есть кластер Постгрес, допустим, с тремя нодами: мастер, реплика, реплика.
2. ВМ, на который крутится мастер, по какой-то причине зависает. Состояние мастера неопределенное.
3. Однако кластер считает, что мастер недоступен, и происходит выбор нового мастера.
4. Проходит условно 60 секунд, и ВМ с бывшим мастером оживает.
5. Кластер Постгрес видит, что старый мастер жив, и отправляет команду на новый мастер: погасись. Превратись обратно в реплику.
6. После чего кластер восстановлен в своей первоначальной архитектуре, однако часть данных потеряна.

Во время зависания ВМ, старый мастер продолжал принимать запросы, и, после синхронизации кластера, данные на старом мастере были удалены. Такой интересный кейс. Это признали багом и вроде в новой версии PGBouncer ее поправили. Расходимся.

Историко-статистический взгляд на сообщество PostgreSQL - Павел Толмачев.
Тут со мной сыграли злую шутку мои обманутые ожидания. Я думал, что доклад будет о том, как Постгрес захватывает мир! Однако автор просто рассказал, как росло комьюнити постгрес с точки зрения разработчиков/контребьютеров. Когда проходят коммит-фесты, сколько патчей было подано на рассмотрение, сколько было принято, и так за последние 20 лет. Вроде интересно, но чувство неудовлетворенности осталось.

На этом 2-ой и последний день конференции подошел к концу. Было безумно интересно! Если кто-то хочет посмотреть доклады с прошлой конференции 2023 года, то их уже выложили в открытый доступ.
3 апреля 2023
4 апреля 2023
Добыча с конференции PGConf.Russia 2024.

Поговорил с Владимиром Комаровым. Договорились совместно сделать новый курс по СУБД для кафедры БИТ. Может быть, на следующий год или через год.
🔥8
📚Предлагаю разобрать секцию Q&A: Cockroach Labs’ Spencer Kimball on Distributing SQL от журналиста Joab Jackson.

Спенсер Кимбалл - генеральный директор Cockroach Labs. Работал в компании Google. Участвовал в развитии Bigtable и продукта Spanner.

С чего началась Cockroach Labs.
Работая на Google, Спенсер решал вопросы, связанные с хранением и обработкой данных. В то время компания Google строила ЦОДы. Текущий объем данных уже выходил за рамки возможностей Oracle и традиционных РСУБД. Продукту AdWords требовались масштабируемые СУБД. Это подтолкнуло Google к ряду инноваций.
Начались эксперименты с MySQL, т.к. нужны были транзакции. Решить проблему масштабирования в Google пытались использованием шардинга. В конечном счете количество шард достигало 1000.
Этот эксперимент длился 10 лет и в итоге провалился.

Началась разработка принципиально новой СУБД - BigTable. Однако для сервиса AdWords она не подошла, т.к. Бизнес требовал транзакции, которые в BigTable не поддерживались. Поэтому Google сделали форк и назвали его Megastore. Под капотом Megastore был Paxos. Это было большим нововведением в те времена.

Именно тогда, участвуя в постоянных сражениях со сбоями инфраструктуры, Спенсер понял, что за распределенными СУБД будущее, и, пока ниша была свободной, решил ее занять. Спенсер вместе с коллегой Беном ушли из Google и создали свой продукт - CockroachDB.

Принципы работы CockroachDB максимально близки Postgres. CockroachDB славится своей выживаемостью и масштабированием. Разработчики не пытаются решать эти проблемы. Это работа архитекторов.

Весь маркетинг по продвижению новой СУБД был направлен на системных архитекторов. За 2022 год компания Cockroach Labs заработала 30 млн.долларов. Рост прибыли за год - 200%. Данных за 2023 год еще нет, т.к. финансовый год еще не закончен. Однако ожидаются цифры около 60 млн.долларов.

Заключительный вопрос был про тенденции в области СУБД. Спенсер считает, что в поддержке ИИ СУБД будет играть одну из самых важных ролей, т.к. все данные ИИ нужно где-то хранить.

Полное интервью можно прочитать на сайте
🎦 СУБД Ред База Данных - это? - вебинар с Романом Симаковым CPO Ред СОФТ.

Обычно я разбираю подобные видео по тезисам и делаю некий пересказ особо запоминающихся моментов. Однако в этом видео для себя я ничего не приметил. Всё видео для меня прозвучало на волне: "У нас крутая СУБД. Нас используют в 100500 местах. Конец". Много каких-то пустых фраз, и не понятно как на самом деле обстоят дела. Представители Ред базы данных (РБД) за последние 3 года не засветились ни на одном техническом митапе, конференции или дринкинпати. У меня нет понимания, что они делают.

Да, у них есть своя конференция, которая пройдет 6 июня в Москве. Да, у них есть бесплатное обучение по администрированию РБД (кстати, я записался на обучение с 15 апреля). Но всё это почему-то не вызывает у меня доверия и уверенности в продукте РБД. Возможно, после обучения и конференции моё мнение изменится. Подождем.

Справедливости ради отмечу, что РБД и в целом компания РедСофт бывали на конференциях Ifin и ВБА. Но там ничего полезного про РБД я не узнал. 2 года назад было выступление от маркетолога РБД на IFIN, но там очередная маркетинговая информация. На технические вопросы аудитории ответа не было.

Как итог, подождем 6 июня, и надеюсь, на многие вопросы я получу ответ. Участие в Firebird Conf 2024 для студентов бесплатное, поэтому жду всех желающих "затусить" с коллегами из мира СУБД.
Бородатый мем, но всё еще актуальный

#mems
🔥5👍1
Статья-перевод "В погоне за заменой Redis"
Недавно я писал, как Redis inc поменяла свою лицензию для будущих продуктов с Apache 2.0 на SSPL.
Это стало настоящим шоком для ИТ-сообщества, и теперь народ пытается найти альтернативу. Сейчас их потенциально всего 2:

1. Форк Redis - KeyDB. Нюанс проекта в том, что он ближе к Redis 6 версии, а значит, множества фишек 7-ой версии там нет. Вдобавок, проект не сильно развивающийся.
Возможно, часть котребьютеров из сообщества Redis перейдёт в этот проект, что вдохнет в него новую жизнь.

2. Форк Redis - Valkey от Linux Foundation. Это прямой форк последней версии Redis 7.2.4. Авторы проекта захотели перетянуть всех котребьютеров Redis к себе. Казалось бы, это довольно утопичная идея, однако ряд крупных компаний поддержали проект: Amazon Web Services (AWS), Google Cloud, Oracle, Ericsson и Snap.

Пока рано говорить, что в итоге случится с Redis и ее форками. Какая СУБД из этих трёх добьется наибольшего успеха. Будем следить за новостями.
👍2
Минутка интеллектуального юмора...С пятницей!

#mems
😱5
🎦 Database Internals Meetup #2: зачем нам DBOS, и новый тип гистограмм в openGauss

Состоялся второй митап от компании Яндекс, посвященный СУБД, он представлял собой два доклада:

📍 OpenGauss. Новый метод для оценки кардинальностей. Спикер, Егор Саттаров, контребьютер в OpenGauss.

📍Что такое DBOS? Позиционирование проекта. Спикер Александр Поляков. Разработчик из DBOS.

👆Традиционно первый доклад очень хардкорный. Много сказано про "внуренности" проекта OpenGauss. Дать свою оценку материалу мне сложно, но думаю, для людей "в теме" будет весьма полезно.

🤔Меня недавно мучил вопрос, а можно ли написать кандидатскую диссертацию на тему СУБД? Если ты разработчик, то, если постараться, это сделать не проблема. Количество тем для исследования поражает воображение. Другое дело, если ты НЕ разработчик. Вот тут возникают нюансы 🙂
Как сказала моя жена, если не знаешь про что писать, пиши ретроспективу.

👆В продолжение научной темы - второй доклад про новый стартап DBOS (произносится как ДиБОС). Я уже делал несколько постов об этом (1 и 2), тема весьма интересная.

Несколько тезисов:
Проект DBOS вышел из академической среды.

Продукт DBOS Transact - opensource typescript framework. Под лицензией MIT. Под капотом PostgreSQL. Однако в будущем возможна миграция на другие СУБД - VoltDB или FoudationDB.

DBOS Cloud - облачная среда, где разработчики могут запускать свои DBOS Transact приложения. Под капотом облака PostgreSQL в AWS.

Самая интересная функция DBOS Cloud - Time Travel Debugging. Этот функционал позволяет продебажить ход выполнения транзакции на выбранную дату. Фактически можно очень точно смоделировать, что происходило в приложении в момент выполнения выбранной транзакции.

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

✍️Всем советую ознакомится с этими докладами. Если они вам понравятся и захочется что-то еще добавить к моим словам, то присоединяйтесь в комментариях.

Для себя отметил, что Discord становится мировой площадкой для чатинга с разработчиками, вендорами.
Однако в РФ любят Telegram.
👀1