Новостной дайджест Postgresso 12 (61)

Вот так читаешь новости про Постгрес и понимаешь какими же гигантскими шагами развивается эта СУБД. Для РФ это СУБД номер 1. Хотя каких-то лет 5 назад всё было по другому...

Распределенный SQL в Picodata (форк Tarantool)
Приятная статья

Аналитиков данных (data scientists) называют "самой сексуальной профессией XXI века". Очевидно тот, кто так выразился, никогда не бывал в пожарной части.
(Грайс Джойл. "Наука о данных с нуля" )

В прод идут не знания экспертов в предметной области, в прод идут предположения разработчиков... (с)
- Альберто Брандолини

Clickhouse не тормозит, а Tarantool не падает

🎓 Вчера собрались составом C++ User Group Moscow послушать доклад бывшего разработчика Tarantool Тимура Сафина про разные подходы к работе с open source.
Сейчас Тимур разрабатывает GaussDB.

☝️ Получился уникальный сплав опыта - знание тонкостей разработки внутри нескольких баз данных. Как со стороны программирования, так и осознания:
"Зачем вообще нужна конкретная база и куда её стоит развивать?"

С таким опытом Тимур проанализировал и внешнюю составляющую разработки - работу с коммьюнити, понимание open source. Как оказалось, представители кликхауза и тарантул имеют разные точки зрения.

Из доклада я уловил, что кликхауз побеждает. И вот по каким причинам:

1️⃣ Чёткое определение своей ниши, привязывание к ней имени
Кликхауз сразу определил свою нишу. И в ней побеждает.
Сейчас говоря об аналитике сразу представляешь себе кликхауз.
Тарантул. Очередная in-memory database? Чем лучше redis?

2️⃣ Наличие roadmap
Кликхауз публикует roadmap. Все могут посмотреть куда движется продукт.
В тарантуле, как я понял, такого нет.

3️⃣ Лёгкая расширяемость за счёт внешних контрибьютеров
Ты можешь расширить функционал кликхауза. Cloudflare нужен был коннектор к кафке.
Они посмотрели в роадмап. Такого не было. Просто привнесли. Им сказали "спасибо" и замерджили.

4️⃣ Дружелюбность к контрибьютерам
У кликхауза твоё авторство сохраняется.

5️⃣ Скорость внедрения
У кликхауза порядка 15 core разработчиков. Какое-то ошеломляющее кол-во коммитов в месяц.
В месяц может быть и несколько крупных коммитов на 1000 строк. Один такой коммит в тарантул занял бы порядка года для мерджа.
В тарантуле требуется 2 лайка на мердж, вместо 1 у кликхауза. "Что драмматически влияет на скорость мерджа".

6️⃣ Наличие тестирования
Кликхауз славится своим подход, который я бы назвал "затестируй меня полностью". Когда переезжали с фактически неограниченной облачной инфраструктуры яндекса в aws пришлось поумерить пыл. Но, всё-же, сохранили своё богатство тестирования.
При тестирование производительности на виртуальных машинах всегда есть разброс. Даже если стартуешь на том же kernel. Есть фактор "буйного соседа".
Вышли из этой ситуации так - на одной и той же машине запускают старый бинарь и новую версию с одинаковыми запросами. Получается, что impact от "буйного соседа" одинаков для обоих)
У тарантула с тестированием, как я понял, не очень.

7️⃣ Код ревью
Условно, в тарантул сильно больше. В кликхауз - "сделал алгоритм? Тесты зеленые? В прод!" 🟢
А потом, если что, для красоты допилить.
Тот же упомянутый Cloudflare благодаря такому дружелюбному подходу сначала внёс коннектор, который написан так себе. А потом переписал его)

8️⃣ Отношение, наличие внешних контрибьютерам
Благодаря такому поощрению к внешним коммитам, расширению функционала даже там, где и не думала core команда, вокруг кликхауза выстраивается сообщество.
Вокруг тарантула нет. Внешних коммитеров, по-моему, zero.

Также пообщались на тему менеджерских решений и выделения внутреннего продукта в open source. Как выяснилось, это не простая задача, успех которой зависит от многих факторов.

У тарантула была возможность выйти на китайский рынок, которой они не воспользовались. После получения известности кликхаузом, он получает от Китая ~50% от всех внешних коммитов.

💰Откуда деньги?
Поняли, что tarantool зарабатывает за счёт внедрения в IT структуры страны. Дело идёт, но рост ограничен сверху.

Не поняли откуда берёт деньги clickhouse. Сейчас они поднимают очередной раунд инвестиций. Как такой true open source может нести инвестором деньги/капитал/value?
Было высказано предположение, что компания стоит дорого лишь до 1ого использования - продажи чего-то/предоставления сервиса - когда её стоимость будет скорректирована.
Вспомнили убер, который до сих по убыточен(в отличие от яндекс такси). Но который вполне себе котируется как актив.

Неужели инвесторы хотят clickhouse только лишь за имя? Ради обладания брендом хорошего open source продукта?
Или дело в рейтинге?

DB-Engines Ranking:
clickhouse - 39
tarantool - 158

https://t.iss.one/cppmoscow/2933

"Софт скиллы важны, но без хардов в них нет смысла". (с)

📻 SQL FM
Третий ежегодный пост по итогам года в мире БД от Andy Pavlo.
Что я бы хотел добавить от себя...
Векторные СУБД - новый тренд. Вроде как он более перспективный, чем блокчейн СУБД. Посмотрим, что произойдет в 2024 году. Интересно смогут ли векторные СУБД стать как документоориентированые, а-ля MongoDB, CouchDB и т.п. или же их функционал интегрируют в себя текущие игроки рынка и на это всё закончится.

Неплохая идея сделать какой-нибудь небольшой курс на 8-10 часов по современным стандартам SQL. Я никогда сильно не интересовался этим трендом, но думаю это было бы востребовано. SQL:2023 - весьма интригующий стандарт

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

Энди приводит статистику инвестиций в мировой рынок СУБД и их размеры поражают. Интересно, а как обстоят дела на рынке СНГ? Хорошо бы сделать такую статистику...

Конечно меня улыбнула история, о том, как сбой пароля в социальной сети обошелся пользователю в миллиард долларов. Советую почитать 🙂🎄

📚Сейчас читаю книгу Хононова Влада "Изучаем DDD – предметно-ориентированное проектирование". Книга очень интересная. Для меня понятно где-то 40%, а запомнил я наверное 20% 🤪.
Таблица как промежуточных итог прочтения 10 глав.
p.s. качество не очень, но уж извините. Сканер такой...

Мне понравилась картинка с публичного интервью на позицию DevOps. Интересный роадмап для карьерного роста.

ClickHouse Overview - Alexey Milovidov interview with CSDN
Вышло видео-интервью СТО Алексея Миловидова и представителя китайской соц.сети CSDN на оф.канале КликХауса.
В ходе интервью была интересная отсылка к книге Кристенса Клейтона М "Дилемма инноватора: Как из-за новых технологий погибают сильные компании". Если компания внедрила одну инновацию, то потребители ждут от компании еще большего.

Тезисы, которые я вынес:
- выход в opensource был отличным решением. Это позволило набрать аудиторию насколько КликХаус как продукт качественный и уникальный.
- команда разработки С++ состоит из 25 человек
- работа, работа, работа.... очень много общения 🤪
- КликХаусу уже 14 лет (если считать время, когда Клик был в недрах Яндекса).
- в КликХаусе меньше 1 млн строк
- много разговоров про тестирование Клика
- поговорили немного по AI. Высказана такая мысль: "Спрос на инженеров низкого качества снизится, но спрос на инженеров высокого качества может возрасти"

🎦Что предстоит делать с данными в 2024 году?
Спикер: Николай Карлов Директор инновационных проектов VK Tech

🤓Не скажу, что сильно интересный доклад, автор рассказывает про концепт высоконагруженной антифрод системы. Как векторный поиск и векторные СУБД в целом могут помочь в этой задаче.

В очередной раз автор грезит об HTAP. Мне кажется, сейчас рынку РФ пока не до этой технологии. Надо еще "привыкнуть" с работой PostgreSQL.

📚Решил почитать книгу «DevOps for Databases» за авторством David Jambor от 2023 года.
Тема показалась мне довольно интригующей 🔎.

🤓 Книга оказалась больше теоретической, чем практической, хотя в ней довольно много примеров на YAML, Python и прочих языках. Автор делает упор на основные постулаты DevOps, в которые интегрирована еще и тема СУБД. Книга отнюдь не для начинающих - необходимо для начала ознакомиться с идеологией DevOps.

➕Плюсы:
- Много интересных идей о роли DevOps в современных организациях.
- Книга хорошо структурирована. Каждая последующая глава дополнят предыдущую.
- Мне лично очень зашла глава 13. Мне очень нравится идеология про самовосстановление в мире программного обеспечения🔝.

❗️Особенности:
- Отдельная глава про опыт работы автора 📑. По сути целая глава выделена как одно большое резюме. Хорошо это или плохо каждый решит сам.
- Много воды 💦. Пусть это и свойственно любым книгам, но почему-то здесь это особенно бросилось в глаза.
- Некоторые главы проходные (10, 11, 12).

Далее я сделаю несколько постов с цитатами из книги📝.

#DevOpsDataBases #book

📍Эволюция моделей баз данных. Иерархические модели

✍️В этой модели данные организованы в записи, которые хранятся в иерархии отношений "родитель-потомок". Эта структура похожа на дерево, с корневым узлом наверху и дочерними узлами, отходящими от него.

➕Плюсы:
1) Скорость и эффективность
2) Простота

➖Минусы:
1) Неадаптивность
2) Отсутствие поддержки сложных взаимосвязей между данными
3) Избыточность данных
4) Ограниченная масштабируемость

🟰Итого:
Несмотря на эти ограничения, иерархические базы данных продолжают использоваться во многих отраслях промышленности. Они могут быть полезны для небольших приложений, где простота является приоритетом, а взаимосвязи данных относительно просты.
Однако иерархические системы всё-таки являются "вымирающим видом". Они выживают только там, где принцип "Работает - не трогай" является базовым 🗿.

#DevOpsDataBases #book

📍Эволюция моделей баз данных. Сетевые модели.

✍️Сетевая модель базы данных основана на концепции, согласно которой данные организованы в ряд взаимосвязанных узлов или записей, образующих сеть данных.

➕Плюсы:
1) Гибкость. Допускаются сложные взаимосвязи между объектами.
2) Обработка сложных структур данных и взаимосвязей.
3) Обработка больших объемов данных.
4) Поддержка несколько путей доступа к данным.
5) Повышенная производительность в некоторых типах аналитических запросов.

➖Минусы:
1) Трудно поддерживать согласованность и целостность при наличии множества взаимосвязей между объектами.
2) Трудность освоения и понимания всех взаимосвязей.

🟰Итого:
Сетевая модель представляет собой иерархическую СУБД, которая допускает сложные взаимосвязи между сущностями. Несмотря на эти преимущества, модель сетевой базы данных в значительной степени была вытеснена моделью реляционной базы данных, которая на сегодняшний день является доминирующей моделью.

#DevOpsDataBases #book

📍Эволюция моделей баз данных. Реляционные модели.

✍️Модель реляционной базы данных является широко используемым методом организации данных и управления ими в компьютерных системах. Впервые она была представлена Эдгаром Ф. Коддом в 1970 году и с тех пор стала основой для многих современных СУБД.

➕Плюсы:
1. Согласованность и целостность данных.
2. Масштабируемость.
3. Гибкость.
4. Безопасность данных.

➖Ограничения:
1. Производительность.
2. Сложность.
3. Недостаточная гибкость.
4. Дублирование данных.
5. Ограниченная поддержка неструктурированных данных.

🟰Итого:
На текущий момент РСУБД представляют собой доминирующий класс СУБД. По сути, все современные задачи можно решить с помощью реляционной модели данных. Да, возможно в ущерб скорости и простоты, но тем не менее. Однако со временем мириться с ограничениями реляционной модели становится всё сложнее, поэтому новые noSQL решения начинают открыто заполнять рынок (2009 год)

#DevOpsDataBases #book

ACIDRain: concurrency-related attacks on database backed web applications

🤓Статья далеко не новая, однако очень интересная👍.
Когда заходит тема про атаки 🎯на СУБД, все как один говорят об SQL-инъекциях, и более ни о чем. Мол, других атак нет🤦. На самом деле это далеко не так☝️.

NoSQL and NewSQL: Tradeoffs Between Scalable Performance & Consistency

Обзорный доклад по системам DistibutedSQL (CockroachDB) и NoSQL (ScyllaDB).

В очередной раз Scylla похвасталась своей производительностью, которая на голову выше почти любой РСУБД 📈.

Автор доклада кратко проходится по истории СУБД, терминологии ACID, CAP/PACELC 📑.

🤓Самое интересное - это вторая часть доклада, посвященная различию подходов NewSQL и NoSQL.

Далее автор рассказывает про то, как повлияло на производительность СУБД развитие аппаратной части. Упоминается Закон Амдала, что дает автору доп.очки лично от меня 🏅.
В самом конце автор подводит итоги сравнения подходов NewSQL и NoSQL.

Compute/Storage separation в Greenplum
Презентация
Автор: Андрей Бородин (Yandex Cloud)
*️⃣Yezzey — открытое расширение GreenplumDB, которое позволяет перенести таблицу в S3, но при этом сохранить нативный формат данных. При таком подходе производительность многих запросов оказывается сходной с производительностью запросов к таблицам на локальных SSD-дисках.

🤓Рассказ о том, что Яндекс с командой из Екатеринбурга участвуют в opensource проекте Greenplum (GP). Главный инсайт для меня лично: GP плохо работает с SSD локальными дисками и отлично работает с S3 хранилищем. Получается "некая магия" - производительность на SSD лишь чуть-чуть 🤏 уступает облачному S3. По сути, хранить файлы с данными можно в S3 практически без снижения скорости доступа. Это можно назвать революцией в хранении данных в облаке 👏🏻.

#HighLoad2023

🎦Когда нужно делать свою базу данных
Презентация

Когда нужно делать свою базу данных? И нужно ли вообще? 🤔

Разработчик Александр Бирюков в своём докладе прольёт свет 💡на сложности выбора между использованием готовых решений и созданием собственного.

🤓Очень интересный доклад! Особенно мне понравилась секция с анализом текущих решений. 📊Вопрос разбирается с учетом актуальной ситуации на мировом рынке, где уже присутствует множество конкурентов, особое внимание уделяется компаниям, продолжающим работать в России🇷🇺.
🟰По сути, решиться на разработку своего продукта очень сложно. Особенно на рынке СУБД, где схожих по функционалу продуктов очень много. Тем не менее, команда разработчиков с Александром во главе приступила к разработке SageBD для компании Тинькофф 🧑‍💻. Автор смог убедить руководство в необходимости собственной базы данных🗂️.

Немного удивляет, что команда разработки у SageDB весьма скромная (около 4-х человек), но слушая автора, я понимаю, что все они настоящие профессионалы своего дела 🔝.

📍Ждем! Возможно, SageDB от Тиннькофф выйдет в open source.

#HighLoad2023

🎦Математический хайлоад: большие, очень большие и немыслимо большие числа
Автор: Александр Кирсанов (VK)
Презентация

🤓Если автор или организаторы конференции Highload++ когда-нибудь выложат это выступление в открытый доступ, всем советую его посмотреть!
40 минут увлекательного путешествия в мир сверхбольших чисел и даже дальше! ♾️
Поделюсь с вами главными мыслями доклада.

✍️История изучения больших чисел на всем ее протяжении связана с тупиками✖️: как записать сверхбольшие числа, не потратив на это сверхбольшое количество времени? Форма записи стала настолько сложной, что превратилась в рутину. Числа четвертого и более высоких порядков 📈 нуждались в сокращении формы записи. Так образовались разные ситемы символов: гипероператоры, стрелочная нотация Кнута, числа Грема и тд, которые выполняют одну задачу - фиксируют в качествке математического текста сверхбольшие числа. (Не удивительно, что человечество придумывает всевозможные способы, чтобы избавится от рутины. 😏 И всегда находятся те, кто смог прорвать этот барьер и заглянуть в будущее).

💪Если вы когда-нибудь упретесь в стену, то переживать не стоит. Вскоре она точно вам поддастся. 🤞

#HighLoad2023 #сверхбольшиечисла #математика