#78 Эволюция баз данных: SQL, NoSQL и доминирование PostgreSQL | Константин Осипов

Сегодня у нас в гостях — Константин Осипов, один из самых известных инженеров в мире баз данных: core-разработчик MySQL, создатель Tarantool, бывший директор разработки в ScyllaDB и сооснователь Picodata. Мы поговорили о том, как на самом деле устроен рынок СУБД сегодня.

Обсудили , как базы данных снова сходятся в одну точку — Postgres как стандарт , и почему новые системы всё чаще просто повторяют его интерфейсы. Погрузились в архитектуру: shared memory vs shared nothing, судьбу распределённых СУБД, влияние SSD и железа на дизайн баз, и почему многие “сложные” решения больше не нужны. Отдельно обсудили ClickHouse, как редкий прорыв и почему такие прорывы случаются крайне редко.

Также поговорили про реальные нагрузки: где на самом деле хайлоад, почему 100k RPS почти никому не нужны, и какие системы действительно упираются в пределы (спойлер: не те, о которых обычно думают). Отдельный блок — про влияние AI на разработку баз данных: как LLM ускоряют R&D, упрощают плагиат идей между проектами и меняют сам процесс создания СУБД.

Полезные ссылки:
https://t.me/rabid_transit
https://github.com/kostja
https://picodata.io - Система управления данными для экспертов по высоким нагрузкам
https://www.youtube.com/watch?v=fykI7uZaGzo - доклад про будущее баз данных
https://www.youtube.com/watch?v=TBAf5l1RmcA&list=PLSE8ODhjZXjbpOIrZheFWxkYG8HD87xW1&index=2 - Towards Sanity in Query Languages (Viktor Leis + Thomas Neumann)


Подписывайтесь на канал «Организованное программирование» в Telegram: https://ttttt.me/orgprog
– Список подкаст-платформ (Apple Podcast, Google Podcast, Spotify, Яндекс.Музыка и другие): https://podcast.ru/1734325321
– Смотреть в ВК Видео: https://vkvideo.ru/video-224967259_456239258

🔹 Telegram-канал Организованного Программирования: https://t.me/orgprog
🔹Хекслет Клуб в Telegram https://t.me/HexletClubBot
🔹 Курсы по искусственному интеллекту: https://ru.hexlet.io/courses_artificial-intelligence
 



#базыданных #sql  #nosql #postgresql  #программирование #разработкаПО #организованноепрограммирование #кириллмокевнин

Эволюция баз данных: SQL, NoSQL и доминирование PostgreSQL | Константин Осипов #78

• (00:00) - - Введение. Легенда баз данных в гостях: что ждёт индустрию дальше?
• (00:28) - - Базы данных: прошлое, настоящее и главный вопрос — что дальше?
• (01:28) - - kostja.github.io — блог Кости: https://kostja.github.io
• (01:31) - - stroppy.io — инструмент для честного бенчмаркинга баз данных: https://stroppy.io
• (01:32) - - jepsen.io — тесты, которые вскрывают реальные проблемы консистентности: https://jepsen.io
• (03:00) - - ScyllaDB: как устроена база для петабайтных нагрузок (пример Discord): https://scylladb.com
• (05:09) - - NoSQL vs SQL: революция, которая не случилась?
• (07:10) - - Доклад про будущее баз данных — что сбылось, а что нет: https://www.youtube.com/watch?v=fykI7uZaGzo
• (09:10) - - Проблемы SQL: почему язык до сих пор критикуют: https://www.youtube.com/playlist?list=PLSE8ODhjZXjbpOIrZheFWxkYG8HD87xW1
• (16:06) - - Почему SQL до сих пор жив
• (17:06) - - Serenedb benchmark game — сравнение поисковых систем и движков: https://serenedb.com/search-benchmark-game
• (18:25) - - Rust против Java: новый тренд в разработке СУБД
• (18:35) - - Volga и Cedrus: переход с Java на Rust и новая волна баз данных:
• (25:20) - - Firebird: живая классика, которая до сих пор используется: https://www.firebirdsql.org/
• (28:00) - - Что осталось от NoSQL: финальная расстановка сил
• (29:15) - - CockroachDB и ClickHouse: два разных подхода к масштабированию
• (33:06) - - SSD убивают старые архитектуры СУБД
• (34:56) - - OrioleDB: попытка радикально улучшить storage в Postgres: https://github.com/orioledb/orioledb
• (43:43) - - InfluxDB и Timescale (TigerData): судьба баз временных рядов
• (45:11) - - MariaDB купила GridGain: как базы «оседают» в экосистемах
• (46:06) - - Графовые базы: будущее или очередной миф?
• (53:20) - - Как обычное добавление поля может «убить» базу
• (01:03:38) - - Будущее аналитики: база сама отвечает на вопросы
• (01:06:30) - - Meteor и Temporal: попытки упростить разработку поверх баз данных:
• (01:11:00) - - SurrealDB: новая волна «универсальных» баз: https://surrealdb.com/
• (01:13:28) - - AI убивает open-source?
• (01:24:57) - - Почему универсальной базы данных не будет
• (01:34:44) - - Заключение. Что нас ждёт в будущем баз данных?

★ Support this podcast ★

Creators and Guests

Guest

Константин Осипов

Co-founder, Picodata

What is Организованное программирование?

Пишем код, за который не стыдно. Разбираем базу, даем рекомендации и встречаемся с умными людьми

Друзья, привет. Это подкаст Организованное программирование. Я его ведущий Кирилл Макевнин. У меня в гостях Константин Осипов. В Кость, привет. Привет.

Мы с Косей знакомы, как ни странно, довольно давно, но видимся крайне редко. И вот у нас последний раз мы встречались, это 2000 примерно двадцатый год, когда мы делали подкаст для Хекслета. И, соответственно, тема была на самом деле очень похожая. Мы разговаривали про базу данных, и сегодня мы тоже будем говорить про баз данных, про их будущее. Немножко копнём в историю. У нас, знаешь, Кость, не обходится ни один выпуск без Диды бухтят, потому что есть что сказать о прошлом, да, в том числе. И для тех, кто не знает, Костя вообще легендарная личность. Это для меня один из самых крутых вообще разработчиков в этом мире. Человек, который стоял у истоков Майоскиэля, был кордевелопером, внёс туда гигантский вклад. После этого, я думаю, уже многие слышали про Тарантул, да, которым ты много лет занимался, собственно, его создал, был архитектором и так далее. И я сегодня задам тебе вопросы тоже по нему, потому что для меня эта немножко тема ушла, да? А интересно, как бы сам концепт насколько живой ещё. И я так понимаю, что очень живой. И последнее время вот Костя по сути, как и все, наверное, глыбы того времени, основал свою собственную компанию. Есть у тебя там название пика пика пика дата, да. Ну, то есть мы мы там думали, как назвать, решили постебаться. Теродата есть, экзодата есть. Мы решили взять пика. Угу. Да. А и это то, чем ты сейчас занимаешься. При этом понятно, что в мире ты признаны эксперт по базам данных. Ну и, соответственно, естественно, ты очень хорошо знаешь, что вообще происходит. Все эти базданные, кто умер, кто появился, куда всё это движется и где мы окажемся через какое-то количество лет. Вот правильно ли я всё сказал? Слушай, спасибо. Я думаю, что стоило упомянуть то, что я 6 лет проработал в Сыле. А вот Алла - это директором по разработке. Ссыл- это открытая до каких-то пор. Ну то есть это реализация Касандры на плюсах и на архитектуре более более эффективной, чем изначально Касандре. Вот. То есть такая история. Если кто-то пользуется, то может быть интересно. Кстати, как ни странно, я почему-то, знаешь, у меня не щёлкает, я не пересекался вообще. Это история про опять же крупный enterpriseй, большие нагрузки и так далее. Да, какая-то специфика. Слушай, Discord, вот, чтобы понять, что такое ссыла слово Discord. Discord хранит все свои чат-сообщения в сыле. Все сообщения всех чатов, всех чатрумов, всех серверов ранятся в Сыле. Это распределённая система, это не одна. Вот. То есть это огромная резиновая база для NoQL база для для вот такого для, ну, NoQL, короче, слабо структурированная информация, да. А для красоты можешь цифру назвать какую-нибудь? Ну, питабайтные деплои есть. То есть я когда работал, там только сыловский cloud, собственно, был несколько метабайт. То есть это то, что ссыла менеджела для своих клиентов. Вот. Но сколько сейчас сложно сказать, смысл основной в том, что есть как бы такой сегмент, когда у тебя самое важное - это стоимость хранения на байт и стоимость административных издержек на байт. То есть тебе нужны базы. Вот вот, допустим, постгрес там ему обычно дают вот вот в такой парадигме, типа, чтобы было понятно, сколько ты у тебя оперативной памяти, сколько у тебя диска. Вот в LTP базах классических у тебя всё-таки оперативной памяти, ну, так нормально. Может, у тебя все данные не влезают, но может быть оди 10, там 1 ктрицати. А, а в таких кейсах, которых ссыла используются, у тебя там 1 к 100. То есть у тебя там вот стольчко оперативной памяти и вот такой вот дисковый массив. Но тем не менее это не файлуха, понимаешь? Это не файловая система, это не какой-то blobстоore. Вот это именно база данных. Она тебе покивелю достаточно эффективно с этим диском работает. И вторая тема - это именно администрирование. Потому что когда у тебя появляется, у меня был, блин, клиент, а вот я работал, а сидел на саппорте, у меня был клиент, у него было 22 ноды в кластере, и на каждой ноде был там под сотню теров. Вот. То есть представь себе это просто там администрировать вот этот вот хрень. То есть получается любую ноду рестартуешь, она там поднимается по часу, понимаешь? Вот. Или, ну, любая проблема, там, у тебя нода сгорела, диски сгорели, то есть как бы ты хочешь, чтобы у тебя, ну, бизнес не остановился. Вот такого рода кластера это сцила. Угу. Я так понимаю, что акценты именно на не просто на том, как мы храним, что мы умеем реплицироваться, но там именно административных инструментов внутри много. Это не специаль, то есть специальные люди плюс большое количество инструментариев. Она просто живучая. Она она живучая. То есть, э, там много компромиссов сделано в архитектуре, чтобы даже если ты потерял часть данных, часть узлов, то у тебя управляемость не потерялась, понимаешь? То есть вот ну там в Позгросе представить себе, что ты там закараптил данные и поехал дальше работать там, ну это как зашквар, да? А здесь ты можешь даже потерять часть часть нот и ты поедешь дальше данно. Вот как пример. Ну мы с тобой об этом поговорим, да. Ну, кстати, классно, что начали с Noуcale, потому что, собственно, мой первый вопрос, он именно про это. А был момент, когда появился NesquL, Монго, потом потеряли все данные, если ты помнишь, For Square. Много весёлых было историй. И было вот это соревнование даже какое-то. А потом мы все наблюдали, как с одной стороны Москиль базы начинали расщепляться и очень сильно расщепились, да, плюс часть из них э пыталась быть похожей на реляционный баз данных, а реляционные в свою очередь постоянно мимикировали под no scale, по крайней мере, часть из них документы ориентированные базы данных. И вот оно как-то бурлило, бурлило, бурлило. Потом немножко из моего фокуса ушло. И вот расскажи, пожалуйста, куда оно пришло. Как вот на SQL и SQL, как они между собой? Бака в следующем, короче. В восемнадцатом году 8 лет назад мне, ну, там меня позвали там на конфе выступить в Новосибирск, типа, ну, забились на тему. И в какой-то момент, значит, организаторы пишут, говорят, что типа, слушай, мы вот с чуваками, ну, я не знаю, корректно упоминать или нет Олега Борнова, но, в общем, мы с Олегом Бартуновым забились на то, что он расскажет всем про будущее Базданнов, но он заболел. Ты можешь вместо него? Я такой за неделю, короче, ладно, сейчас меняем тему, подготавим слайды. И до сих пор на Ютбе лежит мой докладик с Новосибо, называется, так называется, про будущее базданных. Я просто к чему это говорю, там половина прогнозов вообще как бы все левые оказались. Вот просто вот ты разговариваешь с людьми, да, но вот эта тема с СQэлем, я её предсказал. То есть у меня один из прогнозов был то, что типа, ну, SQL умирает и SQL вообще там типа возвращается в тех или иных ипостасиях и рано или поздно все там добавят SQL. Сейчас из тех, кто не добавил SQL, остались только Монга и Редис. Да. И ну вот я прости, ты имеешь в SQL в смысле как язык внутрь или на каком-то другом? Как язык, с которым, которым не у все добавляют стандартные SQL, но как бы если ты посмотришь всё, что новое появляется, там везде SQL. И у старых там, допустим, на момент вот восемнадцатого года у какого-нибудь каучбейса там не было подобного языка, у Аэроспайка не было там особо сколь подобного языка. То есть было куча баз, которые чисто не чуваки, мы не про SQL. Недавно я же подписан на рассылку АЧ Касандра и АЧ Касандра и там как бы сидели люди в своё время. То есть, если ты как бы немножко знаешь синтаксис сикуэля, а пач кассандра, то ты просто и ты эсQэльный чувак, типа как я, то тебя будет просто разрывать, потому что там синтаксис, ну, то есть в тех местах, где можно было просто сделать так же, как в SQL, сделано не так же, как в SQL. И когда ты им об этом писал, они говорили: "Ну, мы же Но SQL база, мы не как бы нам не нужно, мы не хотим вводить как бы людей в заблуждение". Типа заблуждение, понятно. Это байдизайн, короче, было сделано, да? Это это байдизайн, короче. А сейчас они добавили, короче, транзакции, и у них прямо на полном серьёзе они обсуждают добавление полностью ансинтаксиса в Кассандру. Вот я думаю, что через 2-3 года и в Кассандре появится там Ансинтаксис, потому что А почему нет? То есть они там обсуждают и оптимизатор запросов, и джоины уже в списке рассылки. То есть вот когда ты за всем этим наблюдаешь и видишь, какие там упоротые, но сQэльщики уже начинают думать про SQL, ты понимаешь, что всё, как всё прошло. То есть эта революция, она уже просто позади. Уточняющий вопрос. А это же в первую очередь связано просто с тем, что они борются за массы людей, которые знают Искель, они хотят их таким образом привлечь, правильно я понимаю? Потому что технически же нет никаких проблем. Их языки и их подходы. Ты знаешь, во-первых, технически есть, потому что они все начали, они все очень много совершили ошибок, которые в СQэле так или иначе уже тоже совершены. Ну, то есть они их совершили по сое. То есть было бы прикольно. Ведь в своё время в как бы в среде эсэльщиков было очень много критики СQэля там. И, значит, ээ и Стоунбрейкер критиковал и, значит, там была там был третий манифест, критика третьего манифеста, там было прямо целый ряд. И были прото про прототипные языки, а значит, которые критикуют сиквелы и там предлагают более, ну, такую лаконичную, самое главное лаконичную. То есть больше вот есть реализация, допустим, Кэли, она больше похожа типа на пролог или на лисп. Вот, ну, она реально более вкусная, потому что ты, а, она экспрессивная и она более как Ну, это структура ведь, да? Ну да. То есть там как бы ты оперируешь с, ну, множествами более явно. Вот. Угу. А, а, и даже недавно там вот была очередная история, что не так со скуэлем. А, я сейчас не вспомню, кто выступал. По-моему, есть церди, чуваки. Це cederb - это такой европейский, значит, стартап. Там прямо э вот они занимаются аналитическими базами. Они там, по-моему, эти же ребята в своё время колоночное хранение предложили, если я не ошибаюсь. Ну, я могу ошибаться, не суть важно. Короче, то есть критика СQэля постоянно идёт, но ничего не меняется. И поэтому как бы, то есть в сQэле как бы жизнь, а вот нойскульщики они вместо того, чтобы учесть этот опыт, предложить что-то лучшее, вот весь noйQL, который есть, он наступает на те же грабли, что ранее SQL, то есть отсутствие стандартов, отсутствие экспрессивности, вендерские какие-то, значит, замороты. И, значит, для чего придумывался? Для того, чтобы отделить уровень представления от уровня реализации, от уровня хранения. Вот это вот, что на уровень представления постоянно просачивается абстракция уровня хранения, понимаешь? То есть ты, грубо говоря, в языке там. А приведи пример. Не знаю, монгу будем сегодня мучить с тобой. Кого мы как пример возьмём? Ну давай мучить монгу. Тогда тебе надо дать мне погуглить. Я тебе примеры живые приведу. Просто как бы о'кей. О'кей. Я просто думал, если у тебя в голове загружено, было бы интересно, где просачивается, потому что я опять же с этим мало работал вот глубоко. Ну в монге. Ну смотри, в монге где просачивается? В первую очередь в том, что ты фактически у тебя индекс - это часть как бы коллекции там, да? Ну вот смотри, то есть вот сейчас я тебе найду секс mongb search by index. Угу. То есть то есть основная фишка SQэля уже SQL- это в том, что ты не знаешь, есть у тебя индекс или нет. То есть админ может при Ну да, да. Это решение бэкэндовое, да, и добавить индекс в любой момент. А когда у тебя индекс становится часть языка, всё, приехали. И не только индекс, когда у тебя репликация, например, то есть ты, а, начинаешь на уровне языка языка говорить какие-то вещи, которые связаны, ну, с консистентностью данных или с тем, как они физически реплицированы, типа куда сходить. Сходи в такую реплику, да? Да, сходи в такую реплику, например. Вот. То есть это уже тоже типа считается зашквар. Угу. Какие ещё? Так, конкретно в Кассандре это вся тема с инсертом, который не является инсертом. То есть в консентре и инсртм, апдейт не является апдейтом. Вот это всё одна и та же операция. Это по сути мутация. То есть и это всё скрыто за неким синтаксисом SQL похожим. То есть смотри, ты можешь в Касандре сделать апдейт, а у тебя данные вставятся, даже если их не было. Ты можешь сделать delete, а, но данные удалятся не полностью или как бы вообще не удаляться, если данных не было. То есть вот она же это append only storage. И когда когда ты специфицируешь, что ты, ну пишешь insert, update delete, всё, что она делает, это она записывает влог, что ты это сделал. Она даже не проверяет, были данные или не было данных. Она тебе как бы говорит: "О'кей, я записала это и всё". То есть duplicate ke не существует как бы такого понятия, что ну да. То есть даже если вот сама само понятие уникальности первичного ключа, оно такое там уже более слабое, потому что ты не можешь ээ им воспользоваться, потому что ты сделал инсрт, а у тебя ирт всё равно прошёл. Он просто, если не было таких данных, он вставит новые, а если были, он обновит. А работает это потом на каких-то внутренних указателях или просто при выборке он порядок учитывает? Он при выборке тебе, э, берёт всю историю изменений по ключу и из неё собирают, ээ, как бы наиболее актуальную. консист, там коммуникативные типы данных и вот это вот всё. Угу. Вот. Хотя тоже Афир в своё время писал в статье, что коммуникативные типы данных Кассандры на самом деле не являются таковыми. Ну, много там много историй. Основная история такая, что никто этого не понимает. Это всё для гиков. И людям нужно нужен как бы э нормальная модель изоляции транзакций, нормальная консистентность. И по большей части вот это ещё выигрывает. То есть нормальные синтаксис, к которому все привыкли, консистентность данных, с которой все привыкли. У меня был недавно вообще пример вообще на обратный. У меня клиент переезжал с Постгреса, и у него на Постгресе, а значит, э транзакции конкурентные. Они обновляют данные и, э, ну, несколько транзакций обновляют данные и взрысе по дефолту read committed. Эти транзакции не конфликтуют друг с другом, потому что в read committed как бы они, ну, transaction manеджер очень лояльный конкурентности, а у нас по умолчанию seralizable в нашем дисковом движке максимум, короче, вы взяли. Вот, да, и у него просто не работает. Он говорит: "Слушайте, ребята, ну как бы, ну, у меня запросы не работают. можете как бы вот не не грузите меня вот этим всем. То есть вплоть до того, что люди настолько привыкли к даже к тем аномалиям, что есть в СQэле, что они не хотят как-то менять свой приклад. А то есть им не интересно вот это всё. Ну типа, ребята, а у вас там потенциально скрытая ошибка в коде, и вы никогда об этом не узнаете. То есть у вас могут быть данные, то там же были же такие ещё исследования, что типа дефолтный уровень изоляции, то есть SQL славится тем, что это консистентный язык программирования, там Strong consistency, но на самом деле дефолтный уровень изоляции во всех базах максимум snapsot Isolation. И большинство приложений, они просто используют дефолтный уровень изоляции, они не задумываются о том, что это типа небезопасно, и всех всё устраивает, как бы это статус кво. Вот. Так что как бы сам такой, что да, но Эсколь как бы умер,эль есть куда стремиться, но пока что прогресс не особо движется. Ну когда ты про это говоришь, это действительно речь идёт скорее про языково восприятие происходящего. То есть всем действительно хочется вот привычного, понятного и стабильного, а не 55 новых способов что-то делать с протеканием, как ты говоришь. А если всё-таки говорить непосредственно про базы с точки зрения решения проблем, то есть, о'кей, даже, допустим, SK или позгрес, но мы же упрёмся в какую-нибудь фигню, а, например, аналитические запросы, realта какой-нибудь и так далее. И в этом отношении же всё равно получается, ты же сам сказал, вот Кассандра, там тарантула, его разновидности, в том числе твоя, они появля они становятся нужны. Вот что из этого живое? Какие направления, грубо говоря, науске живы вот в этом смысле, которые в посресе не решить легко? Самое живое - это поиск. Поиск. Угу. Я не знаю, захочет упомянуть или нет, но сегодня вышел анонс а сеirн DB. А, ребята переписали, сделали поисковую библиотеку. Они до этого, это бывшая оранга, команда из оранга. Вот. Они сделали фактически более быстрый ластик. Вот, значит, как бы поиск - это прямо актуальная тема, потому что поиск есть у всех. И векторной базы тоже вот как пример, да, то есть раг все все сейчас абсолютно все добавляют поддержку векторов и SQL нено SQL просто отдельно векторные базы. Что у них там будет с бизнесом, непонятно у векторных баз, потому что а тоже там все сделали open source-версии и непонятно, как монетизировать. Вот вообще отдельная тема монетизации СБУД, но как бы поэтому, ну да, вот искусственный интеллект опять, потому что нужны вектора. А мы дойдём, да? Да. А, кстати, давай тогда вот прямо разложим. То есть получается поиск первое, понятно, есть большие ребята, которые вообще всё как-то там на каком-то гибриде максимальном делают, но стандартное решение - это LINEA всегда была и Elлаastic search, я так понимаю, что Elлаastic плюс они ещё и написаны там на Jруuби и Джаве, по-моему, да? Соответственно, я так понимаю, переписывают сейчас всё на раз весело и бодро или что там сейчас вообще? Да, всё переписывают на раз, это правда. Ну и ну конкретно сирин он, по-моему, на плюсах. Но но да. Ну, по крайней мере, по производительности там, наверное, очень похожие показатели будут. Да. Дада. Да. Нет, раз вообще здесь это отдельный тренд, что-то опять же Волга. Волга сегодня ты всё тоже вышел анонс, что Волга. Кто-то слышал про Волга ДБ или Волга? Волгар, по-моему, они называются. Я жил на Волге. на Волгастор не слышал. А погугли. Вот они тоже они, ребят, всё переписали на Раст. Церди были на Джаве, переписали всё на раз. Это тоже тренд вообще мощнейший. Ну Java, кстати, да, для баз данных, честно говоря, сейчас думаешь какой-то немножко безумный выбор, а, наверное. Но при этом я тебя парирую. Короче, я тут ковырял пятую Кассандру. А я когда работал с Или мы, у нас постоянный был продажный пич то, что у нас sharper architecture, значит у нас очень быстрые безблокировочная СУBD, Direct io, то есть у нас если надо iю мы используем, то есть все модные фишки и мы за счёт этого быстрее Касандры. Я тут взял Джаву старую добрую, да, Кассандру пятёрку, погонял Бенчи, она очень бодренькая. То есть ребята сократили гэп очень сильно. И опять же, если смотреть, понимаешь, почему там та же Касандра на Джаве была изначально там тормозной, они ориентировались на сатаски. И вообще ЦПУ никого не волновал, потому что СУБД она просто упиралась в диск. Вот огромные дисковые массивы в диски. Понял. Угу. А сейчас, когда диски сэсдшные дают тебе огромное количество опсов, всё становится снова CPU баound. Но опять же, знаешь, вот тренд такой, реально РПС они никому не нужны. То есть вот RPS у приложения больше там 5 тире 10.000. Это, ну, огромное исключение. А 5 10.000 ты можешь сделать на любой базе. То есть тебе, да, нужны объёмы, тебе, да, нужны сказать, всякие интересные запросы типа поиска, типа векторов, типа аналитики. Вот. Но тебе не так нужен RPS сегодня уже, как раньше. То есть все раньше гоняли за, ну, выжить там 100.000 RPS, 200.000 RPS. То есть, ну, это в том числе, потому что может решаться горизонтальным масштабированием, правильно я понимаю? Там шардирование или нет? Не в этом дело. Нет, нет, просто не нужно никому. Просто вот даже в горизонтальном или без вот как бы ну ну нету у людей там типа запроса больше 50.000. Я сейчас уже давно как бы уже бизнесом занимаюсь, и я просто ещё знаю вообще весь крупный бизнес в России. И вот Россия не маленькая страна всё-таки, да. Ну, наверное, там в Китае и в США там больше есть мегабизнесов, которые высокий РПС, но глобально в России там, ну, нет таких задач. Там у какого-нибудь крупнейшего российского банка будет в час пик, в новогоднюю распродажу там до 5.000 транзакций в секунду вот этих вот на, ну, на на ключевых базах. Маленький офтопщик. Просто интересно, а какой вообще бизнес по типу имеет самые большие нагрузки в целом? Вот е опять же вот Россию берём. Мне вот интересно, это банки, это мобильная связь, это поиск Яндекса, это может что-то ещё? Нефть какая-ниуд, и мы вообще ничего об этом не знаем. Где самые вообще? По цене на транзакцию надо считать. Вот самая низкая цена на транзакцию в дижитале. То есть условно а в дижиле высокие нагрузки, их много и они на дешёвом железе. Где ещё высокие нагрузки? Высокие нагрузки, очень высокие нагрузки у нас сейчас во всяких госсистемах. какая-нибудь СМФ, шина данных, значит, вот она и сделана масштабируемым образом, потому что это центральная система на всю страну, она заведома, ну, большая. А так, опять же, там бывают разные, ну, трейдинг никто же не вспоминает, понимаешь, в этот момент. А в трейдинге постоянно там следят за рынком, то есть там отставание там в микросекунды считается уже всё, провал от того, от биржевых значений. То есть а резидентные, например, СБД и там вот высокие нагрузки, они могут быть в трейдинге, в крипте, как не странно. То есть highфency трейдинг. Вот. А так я не знаю, там всё в памяти, правильно я понимаю? То есть там всё в памяти, там другое немножко, да. Вот. А если говорить про опять же про какие нагрузки, ну в России это сормы, понимаешь? У нас же всё слушают. Сорм, как расшифровывается системы средства обеспечения какого-то мониторинга. Ну, короче, это Ну, я я понял, короче, всё, что анализирует трафик, всё, что анализирует вот это вот добро. Угу. Ну, кстати, да, у тебя все звонят одновременно. Всё это системы технических средств для функции оперативно-розыскных мероприятий. Забавно получается, что самая самая серьёзная нагрузка и компетенция должна быть именно в государственных штуках, потому что там иначе ты не сможешь вообще существовать. подходят ребята алгоритмисты, поротые алгоритмисты, а которые вот, ну, вот слушали мои выступления и у которых абсолютно закрытая тема. Вот вот если говорить, кто ко мне приходит там на том же там хайлоуде, периодически подходит, задают вопрос, то такие ребята приходят, да. Угу. Я тебя понял. У военных ничего нет, как ни странно, потому что у военных всё должно быть автономно. А всё опять же там есть военная тайна и, ну, в смысле нагрузок, там как бы база данных-то есть, а вот таких хайлоудов нет, потому что там хайлоу подразумевает централизацию и а военная тайна подразумевает, что ты не можешь просто никого не пустить, пока он тебе показал физически не предъявил, понимаешь? Поэтому там нет нагл, как эта база называется, которая на абрамсах-то вся история. Firebase. Firebird. Firebase она на Ай, Firebird, точно. Фаербр, я помню, что что-то вот похожее. Да, ты же помнишь эту историю, да? А я был в Пензи буквально в этом году, но в прошлом, 2025. И, собственно, меня ребята из Firebр приглашали. Я выступал в Пензи, там регулярно проходит ещё по-прежнему Сикон. Сикон попрему, да. Вот. Ну, кстати, тоже, знаешь, что такое очень интересно? Вот я был на Сиконе много раз, как меняется народ. Совсем другая тема, короче, демография. Вот сейчас студенты - это те, кто родились 20 лет назад. А 20 лет назад была какая-то адская дыра в демографии. Вот. И вообще вот это чувствуется, чувствуется. Прикольно. Я приехал на Сикон, и чувствуется, что студентов реально меньше. Все такие же, всем всё интересно, но меньше. Ну, мы, кстати, за этим следили, потому что у нас колледж вот, в котором я участвовал, и мы как раз знали, что там через какое-то время, вот мы его стартовали, через 5 лет будет деграфическая, ну, демографическая яма. Поэтому мы тоже за этими моментами немножко следили. И сейчас действительно мы вот в ней входим даже, скорее всего. А, а знаешь, где фабр используется? В кассах. А, в кассах ещё используется. Я просто помню, тогда ребята рассказывали очень классную историю про танки Абрамса, что у него после выстрела происходило настолько сильная это была штука с точки зрения систем, которые там работают, то, что у него происходила фактически полная перезагрузка. И во время этой перезагрузки только фаербр выживал, все остальные базы карабтились, которые были. И, соответственно, это дало им когда-то возможность собственно туда попасть. И, ну и, соответственно, вот, как ты и говоришь, автономная, надёжная, специфическая база данных, про которую никто в нормальной жизни не знает сейчас, потому что раньше она хоть как-то звучала, но она вот ну опять же это уже, наверное, в байку превратилось. Я не знаю актуальность, то есть насколько сейчас это всё так. Ну, возможно так. Не, ну как бы баз базы данных остались, никуда не деваются. Более того, даже развиваются, я бы так сказал, потому что сейчас там вот у Фаербрда конкретно там сейчас глянул внушительный список чеeлок изменений, то есть они продолжают фичи добавлять. Знаешь, что в России е насколько тебе это интересно с твоим слушателем, но в России вот есть отдельная тема импортозамеса с во всяких промышленных историях. Вот. Да, я бы ожидал, что такие базы там, как Fireабр, допустим, они, э, как бы в мега выстрелят, потому что очень много где в железках всё это используется, но реально этого не происходит, потому что мм железки меняются ликом, и железки продолжают делать не в России. Вот, то есть как бы вот у нас не выстраиваются вот эти вот цепочки производственные, которые бы позволили как-то, то есть баз данных - это слишком низкого уровня продукт. То есть мы как айтишники как бы все это знаем, все это понимаем, зачем это надо. Но в реальной промке там даже не только в промке, ни в промке, ни в банках, ни в телекомах за за небольшим количеством исключений базы данных как таковые не выбирают, не покупают, не используют. Покупают продукты, которые на над ними находятся постеку. Я понял. Да, это как часть инфраструктуры идёт допом к ним. Хорошо, если вернуться немножко вот в структуру, да, то есть мы говорим есть поиск и есть там эластик и так далее. Причём, кстати, получается, что вот когда мы говорим про эластик, я правильно понимаю, он немножко структуру свою скрывает. То есть это не база данных в классическом смысле, да? То есть у тебя там нет табличек, да? У тебя просто оно как-то там внутри само разложило, и ты как-то с этим взаимодействуешь внешним каким-то интерфейсом, очень слабо понимаю, как оно устроено. Не, ну ну нас же бы как к эластику пришли. Мы говорили про то, что в НосQэльмире ещё жив. Но, дада, вот и вот Иластик, да, вот жив, а Кивелью как бы мёртв. Э, Джейсон есть в Постгресе. Ну, Кивель концептуально мёртв, понимаешь? То есть он как А вот давай сейчас дойдём, да? То есть я вот прямо хочу тебя, э, как бы с тобой разложить, чтобы вот эта картинка сложилась. Так, поиск. Понятно. Дальше у нас есть раги векторный баз данных. Но я правильно понимаю, что общая тенденция в том, что, ну, например, посрес там говорит: "У нас тоже это есть". И как бы пропадает смысл в отдельных базах глобально или нет? Ну, случаи разные бывают. Вот поэтому я бы не сказал, что, ну, ты прав. Короче, если если коротко, то ты прав. Знаешь, вот это такая же история, как была в своё время с Джейсоном, потому что считали, что Джейсон баз данных - это какие-то отдельные базданных. Потом все баз данных добавили поддержку Джейсона, и ты уже этим не выпендришься. Там была такая базаби, они говорили: "Мы база данных для докера". Вот как тебе такой пич? Да то есть, понимаешь, а вот и все приедут в Докер рано или поздно, понимаешь? То есть поэтому ну с векторами также будет вопрос времени. Заеду. Давай дальше. Хорошо. У нас есть колоночные базы. Я так понимаю, что вот они как минимум выжили, и более того, у тебя кликхаус, наверное, там впереди планеты всей и они забрали на себя аналитику. Да, но я бы не назвал колоночной базы Нойскуэлем, понимаешь. Вот у Кликхауса, кстати, очень вредит то, что они Кликхауса, ну, клиck или, как он там называется, вот Click House Query Language, он не очень совместимый с S сQэлем. То есть мне не раз говорили и в России, и на Западе о том, что, блин, Клихаус вообще бомбическая вещь, но у нас просто нет людей, которые бы знали язык. И это прямо был в своё время барьер. Сейчас, наверное, уже меньше. Слушай, ведь я что-то действительно тупанул. Это же ни фига неуль просто, знаешь, как-то в голове вот типа либо у тебя SQэльная совсем база, либо всё остальное уale, но это не так. Колоночные базы - это тоже реаляционные базы данных. Вопрос в том, как они хранят. Да. Да. Ну ты, ну вот как RoHDB интересная в этом смысле и база, потому что как бы вот вообще главный вопрос на самом деле, который ну мне лично интересен, если говорить там про будущее, это вообще распределённые базы особо выживут или нет? Понимаешь, что что происходит? Вот где засада. Неважно, SQL - это или SQL. Непонятно, нужны ли распределённые СУБД, потому что сейчас, э, диски увеличиваются в размерах. Вот ядер становится на одной тачке больше и практически, ну, то есть вот все говорят, что там стало больше сильно данных, но но на самом деле нет. То есть в определённых бизнес сценариях, в которых баз данных всегда были вот прямо ключевым агентом, это телекомы, банки, вот, и ритейл, там в целом не сильно растёт количество данных. Там есть отдельные сейчас CTO офисы и склады данных, которых, ээ, идёт аналитика тяжёлая. Там реально весь архив за всё, но операционные данные не растут так сильно. То есть тебе для того, чтобы там проводить транзакции, тебе нужно что? Банковский счёт, тебе нужен банковский баланс, там какой-то набор продуктов, тарифов, правил, да, для того, чтобы всё это делать. И вот это это не так много. Короче, поэтому самый большой вопрос про будущее - это вот в классическом секторе в своё время NoQL и распределённые база, они как бы заходили как следующая, как волна, которая смоет ээ там постгрес. И вообще этого может не случиться. Прямо конкретный пример, да, это когда, ну вот ты относишь к этому репликацию или нет, когда Монга пришла и говорит: "Ребята, у нас всё само, смотрите, как классно". Или ты дальше имеешь в виду ещё более отношу. Не относишь? не отношу, потому что репликация - это про readalн и про всё равно у тебя Ну смотри, вот классификация какая должна быть. Есть база данных типа Shared Storage, да, Shared Memory и Shared Nothing. Вот в своё время, ещё до всяких там noQэлей были такие классификации СУBD. Shared storage - это когда у тебя куча компьютеров, но у них внешний накопитель, и они через внешний накопитель как-то взаимодействуют. И это за счёт этого поддерживается общие общая как бы объём, ну, общая СУBD. Shareded Memory - это твой классический MySQL или Postgress, где у тебя, короче, кэш общий, диск общий, но есть куча бэкэндов. Каждый консорах обслуживает своё приложение. Аed nothing - это когда у тебя каждый бэкэнд он владеет своим фрагментом диска памяти и коммуницируется с остальными по сети. Вот эта классификация, она никуда не делась, понимаешь? Поэтому вот позгро - это shared memory subd, и от того, что ты добавил ему реплику, он не перестал быть shared memory subd. Соответственно, что сейчас происходит? Вот так как памяти становится всё больше, дисков становится всё больше, Shared Memoriesd, как таковая, как архитектурный, у них есть свои преимущества. У каждого вот этого подхода есть свои преимущества, да, и их как бы они фундаментальны, их нельзя никак ээ нулья, ну, знаешь, нельзя просто перекрыть как алгоритмами или чем-то ещё, потому что под это под всё пишет, то всё от начала до конца дизайнится. И вот преимущество Shard Memory SubD, они как бы возвращаются постепенно, потому что SSD диски очень быстрые, тебе фактически не нужно много памяти. То есть, смотри, у тебя сейчас миллионы иопсов могут быть локально доступны. Вот для shard Memories BD миллионы опсов. Мы даже сейчас в своих дисковых инсталляциях отключаем кэш данных вообще, потому что кэш только тормозит. Всё SSD справляется, понимаешь, реально. Ну, перформанс выше. У, ничего себе. Удивительно. Вот. Да. То есть поэтому вот это интересно. И, э, ну, репликация будет всё лучше работать. То есть у Постгреса до сих пор ты должен там поставить синхру, потом отдельно поставить патроны, отдельно поставить ещё кучу приседаний, да, но вот тоже того же ПГП, там у них есть свои как бы пропритарные расширения, они всё это собирают вот так у них работает, э, там кластер значит высокодоступный. То есть и почему они не это не контрибьют в комммьюнити, это отдельный вопрос. Вот. Но к чему я это всё рассказываю? Потому что основное, что тормозит реально Shard Memory SubD того, чтобы захватить мир. То есть Позг, почему Позгрос не захватил ещё весь мир ещё больше? Вообще, если бы он мог, он бы захватил и всех бы убил вообще просто-напросто. Это там э то, что у Постгреса до сих пор дико древний сторедж. Вот. То есть вот этот хипсторадж там в своё время была буча тридцатиубитные кды, которые переполняются и не подходят для реальных нагрузок. высоких нагрузок. Это на самом деле не совсем так. Вот. И если там, кстати, говорить то, чем я занимаюсь в Аренодате, я занимаюсь по сгрессовым стореджем. Есть Саша Кородков, ты с ним общался? Нет. Слушай, знакомая фамилия, мне кажется, пересекались где-то. Саша Кородков работал в ПГПО раньше очень давно, но он уже довольно давно в супайзе, и он делает сторедж для постгреса orби. А про OriB не слышал? Ну, какие-то слова знакомые, но я не копал. Да, для меня это мы тоже сейчас этим занимаемся. Смотрим. Вот если там, допустим, тот же Постгрес ускорят в несколько раз на больших СУБД, потому что у Позго на больших размерах данных реально начинает тормозить сборка мусора. Это прямо вот чума, из-за которой там подгроз не отжирает ещё больше нишу. У, то есть, смотри, SSD диски становятся быстрее, позви становится быстрее, ему ничего делать не надо. А здесь проблема вот с этим с этим мусором, она ограничивает именно размер базы данных. Вот если эту проблему решить, то ну тебе там пользовась на 10, а 10б хватит всем. Угу. Интересно, как Oracle на всё это смотрит. Да никак. Они, понимаешь, они сейчас ээ как бы трансформируются в cloud. И это вторая тема, которая тоже может убить горизонтально масштабируемы СБD. То есть смотри, что получается. С одной стороны, у тебя есть постгрес, который забирает и забирает всё больше кейсов, а с другой стороны, у тебя есть cloud, где реально огромные СУBD, то есть вот там Dynamo DB там она там сотни петабайт менеджет. Вот это это там это даже не база данных, это физический такой монстр, который там отдельно под неё выстроенные дата-центры, отдельно выстроенные каналы связи, понимаешь? То есть это второй второй второй как бы край. То есть вот эти вот горизонтально масштабируемые СУБД, они вот уходят вот туда, а, в облака. А с этой стороны, то есть вот это openсорсные СУBD такие, что для комьюнити они, ну, их ниша размывается с двух сторон. Прикольно. Хорошо. И чтобы вот закрыть эту тему, потому что всё-таки мы с тобой основные какие-то моменты проговорили, закончили Клихаусом, но ты периодически Кассандра упоминаешь. И вот можешь, а как-то Кассандра - это всё-таки набор, это пример какой-то класса, э, баз под определённые задачи или Кассандра сама по себе уникальная и вот она как-то вот используется только где-то. Вот. Можешь чуть раскрыть эту историю? Потому что я с Кассандрой вообще никак ну никак. Ну Кассандра - это история тоже про объёмы. То есть это та самая, что история про что из Сыла. Я вот тебе с этого начал рассказывать, да? То есть, когда у тебя куча носикольного, по сути, хлама, слабо структурированного, допустим, клиентские какие-то вот, а, все телекомы российские, по крайней мере, ну, и западные тоже, кстати говоря. Я же, ну, я же всё это знаю, я что-то забыл, кого я саппортил. Значит, они все хранят. Есть такое понятие calls. То есть когда ты как бы разговариваешь по телефону, телефон каждые 15 секунд и базовая станция каждые 15 секунд оставляет след цифровой об этом для того, чтобы тебя, если что, можно было проторифицировать, инциденты, ну, вообще всё. Ну, короче, журнал они не пишут сам сам разговор, но они пишут, где ты был в этом находил, на какой сот разговаривал, да, по какому тарифу, да, какое текущее время, вот такие вот истории. И вот этих колдата рекордов они только прибывают. Вот они все хранятся либо в Сыле, либо в Касандре. Вот пример. И по ним уже, допустим, строится тебе личный кабинет. Например, заходишь, там тебе биллинг, тебе показывают, с кем ты разговаривал, сколько тебя проталифицировали. Вот такая история. Это идёт не в кликахаусе. Кликахаус. А масштаб какой? В смысле масштабируется? Это тоже за счёт машин. Это горизонтальное масштабирование, да? То есть тоже добавляешь ноды. Кстати, знаешь, я ещё что подумал? А вот ты сказал каждые 15 секунд, а я вспомнил, что многие российские операторы когда-то позже говорили: "У нас посекундная тарификация". Обманывали ведь? Да. Слушай, может и было, может они и делали эти CDры, ээ, не знаю, настолько не знаю. Но вообще стандарт 15 секунд. Угу. У них же есть там этот самый консорциум свой, который всё это очень сильно как бы расписывает. Каноническая архитектура, как это всё должно быть устроено. тоже вот когда начинаешь погружаться, оказывается, что там, например, в медицине или в телекомах никто не приходит и особо не проектирует всё с нуля. Есть более-менее канонические паттерны, по которым ты проектируешь, допустим, медицинские системы, лимссистемы там и так далее. Всё это там, ну, кстати, про телекома я знаю. Я просто немножко консалтил и помогал ребятам, которые делали биллинг для Мегафона с разными командами там работал. Я просто помню, что там есть просто у него готовые спецификации, которые вообще полностью их домен раскладывают на то, как он должен существовать от и до. Да. Причём сейчас вот, знаешь, когда я это делал, это был там семнадцатый год, я сейчас думаю: "Вот если бы сейчас это делать, да, ты вгружаешь это в чат GPT и, пожалуйста, любой ответ получаешь моментально, вместо того, чтобы сидеть и изучать это там годами, как оно всё устроено, что довольно сложно". Это это вообще, слушай, я вот думаю, что, знаешь, недооценённая история. Мы сейчас все с ума сходим по этой истории, потому как она может заменить человека и условно говоть, да? А мне вот очень интересно как с помощью неё научиться учиться. То есть я вот думаю, может ли она выступать в роли наставника? Вот как правильно вот, допустим, изучать язык или изучать какой-то навык? Очень херово. Очень херово. Это не совсем тема. Слушай, я могу, потому что просто это моя как бы прямая история, да. Вот у тебя база данных, у меня обучение людей. Я такой чуть-чуть оф-топ просто сделаю. Проблема, знаешь, всегда в чём? Почему вот люди же задают вопрос, почему вообще приходят, покупают курсы? Казалось бы, вот у тебя всё есть, потому что у тебя всегда нужна верификация того, задаёшь ли ты вообще правильный вопрос. Проблема в том, что если для тебя есть же как бы изучение, вот ты знаешь одну базу данных, ты изучаешь вторую, тебе реально никто не нужен, потому что это как прочитать справку, только в более лучшем виде, потому что не ты спрашиваешь: "А что ты можешь и как вообще, а ты знаешь, что ты хочешь". И ты говоришь: "А вот там это делается так, как это у тебя делается". А теперь представь, а простейший пример. Какой-нибудь вот дяденька, который вчера водил такси, и сегодня он хочет, значит, программирование изучать, и у него тема объектноориентированное программирование. Какой он вопрос должен задать чат GPT? чтобы начать изучать эту тему правильно. Ноль шансов, ноль, какой бы она умная ни была, просто вообще никаких шансов. Поэтому я в этом плане, с одной стороны расстраиваюсь, что это невозможно, а с другой стороны оно, скорее, знаешь, как оно элементиками вставляется. То есть вот из этого можно части пазла закрыть, но ты весь пайплайн не сделаешь. Да, да, да, да, да, да. Вот. Но на самом деле то же самое и во всех остальных. Ты знаешь, у меня какая история. Э, когда, ну, я же не сразу там клодом тем же стал пользоваться или кодексом. У меня было отношение изначально, ну, такое вайп-кодинг и вайб-кодинг. Все про него слышали, да? Угу. А вот а потом я за один вечер сделал э прототип словарной компрессии для винила, ну вот для нашего диского движка. За один вечер просто вот сел и там к утру оно было готово. Короче, значит, я пришёл на дейлик просто охреневший. То есть я как бы, ребята, а а что можно было? Вот. И они мне: "Да ты вообще просто не понимаешь, как это всё это плохо работает. Ты ещё просто все минусы не видел". И потом началось начались вот эти вот итерации, да, как этим, кто как этим пользуется, как этим правильно пользоваться. И я выяснил для себя лично, что все очень по-разному взаимодействуют с этой системой. Вот. То есть для меня это реально такой Google на стероидах, который просто ускоряет всё, что я, ну, всю рутину, которую раньше я вынужден был делать сам вот этими ручками. А для кого-то это попытка, ну, как бы заменить мозг, да, но и так не работает, да. Ну, скажем так, есть вещи, в которые действительно не хочется погружаться, и можно это делать. Ну, это может касаться не напрямую там вообще твоей работы, всякое бывает, да. Ну, это вообще тема, которая настолько сейчас всех цепляет, что никто отпустить её не может. Она просто из каждого разговора лезет. Это абсолютная правда, да. Так что это прикольно, но мы с тобой про это поговорим, а, вот, в применении базданных, потому что это довольно интересно. Хорошо, смотри, вот про ноу skill базы более-менее поговорили. Есть ещё, наверное, один тип баз данных, про которых я точно хотел у тебя спросить. Это временные ряды. А помнишь influxс db, сбор метрик и так далее. А вот эта область, она вообще что из себя сейчас представляет? Слушай, мне кажется, это слишком узко. Вот, если честно, слишком. Да, да. То есть, ну, ну там дельта, дельта кодирование ты можешь выбрать для той же кликхаус таблички как способ, да? То есть какие-то агрегаты можешь выбрать. Ээ агрегаты клик классно делает тоже, да? То есть я просто общался с, понимаешь, в чём фигня? И как это вообще этот хайп был? Там вот когда мы с тобой как раз тогда общались в двадцатом году, все орали про индустрию 4.0. То есть была такая мысль на тот момент, что если мы оцифруем вообще все промышленные данные, а всё покроем датчиками, то мы достигнем другой эффективности производства. То есть выйдет производство, но то есть вот как, знаешь, как с паровозом там вот с этим с двигателем внутрем сгорания, вот это вот всё, да? Значит, и а что происходило? Очень многие хайпанули. Очень многие на этом поехали. IBM, в том числе там САС, все стали какие-то искать истории, как можно из промышленных данных извлекать ценность. А самое там обслуживание по предиктивное обслуживание, да, а вот значит э использование машинного обучения для того, чтобы понять состояние оборудования. То есть множество этих историй, короче, появилось. И основная фишка в том, что они не оказались, они они частным образом работают, но они не порождают вот этот индустриальный переход. И вот с Influx DB, с таймлом, у них неплохо идут дела, я даже не сомневаюсь, да? То есть они как бы у них достаточно защищённая ниша там, где они её уже взяли. Но а я думаю, что ты слышал, там Мария DB купила Гритгей, например, вот попросу. Угу. То есть ты где ты видел кладбище базданых? Куда уходят базданы, когда они умирают? Я то про тебя тоже хотел спросить тоже, потому что этих названий каучби, такой DB, такой DB, кошмар. Их там миллиарды просто. Да. Вот поэтому, ну, они не умирают, базы данных не умирают. Базы данных просто остаются маленькими навсегда. Я думаю, что просто не, ну, не вы, не вывезет это на отдельный прямо класс. Люди хотят, чтобы было просто. Ну что так сложно? Ну можно проще. Ну прикольно. То есть кликхаус получается и вообще колоночные базы покрывают эту тему. И в принципе, если надо, в общем-то, не надо выделять под это отдельный тип базданных. Ну чтоб чтобы меня не поняли превратно, они покрывают её для 90% кейсов, понимаешь? И это и это, к сожалению, убивают вот эти 10%. Она оставляет она не даёт им как бы вылезти из своего угла. И, в общем, никто про них не вспоминает. Хорошо, тогда теперь уже я не знаю. примеров современных таких баз данданых. Но про это иногда говорят, знаешь, вот любители объектноориентированного программирования, там вот разных всяких сложных схем, графы там и так далее, и говорят: "Вот смотрите, классно, графовые базы данных - это будущее или объектные ориентированные базы - это будущее". Был такой, помнишь, концепт? А, да, мне кажется, даже ещё в девяностые было. Что происходит с этим всё? Ну, графы для меня там же находятся, в принципе, где вектора. То есть они у меня где-то рядом. Я просто поясню, почему. То есть вот есть же MCP сервера. Угу. И в целом, э, основная фишка графа - это хорошее снятие антологии. Она никуда не девается. Вот, э, поэтому я думаю, что с графами всё будет нормально. Вот это как раз ниша интересная. Просто опять же здесь у них такая же тема. Как только они вылезут немножечко из своей ниши, Постгрес просто добавит синтаксис для графов и всё. То есть там под капотом такой же сторедж, такая же репликация, понимаешь? И, короче, нет там никакого особенного, да, структу, да, там нет. Основное, основная фишка графовой модели именно в её самой концептуальной модели. То есть это удобная модель для целого ряда, ну, как бы проблем. Вот. Угу. Угу. Но когда ты начинаешь копать то, как она сделана под капотом, всё равно тебе нужен какой-то индекс, какой-то, значит, там работа с мусором, какой-то какие-то транзакции. Вот. И самое интересное в графах СБД - это, на самом деле, запросы, язык запросов. Вот там интересные могут появляться оптимизационные возможности, которых нет в реаляционных СБД. То есть как быстро там найти кучу связей в графах. Это прямо отдельная там проблематика, отдельные методы, да. Вот. Но всё равно ничего не мешает это реализовать просто сбоку в одном продукте. То есть база данных - это ещё не только технология, это просто канал доставки кода прикладному программисту. Это просто, я не знаю, ну вот пятёрочка для как бы таких вот системных фич и всё, понимаешь? А правильно понимаю, что если ты графовую эту историю, допустим, заводишь в погрез, ты скюлем не обойдёшься, потому что тебе придётся вводить дополнительный синтаксис под это добро. Да. Да, конечно. Тебе те, ну, у тебя появится си специальные операторы. Ну, для Джейсона же добавили, там для кмля в своё время добавили расширение. Добавили, да, появится оператор там. Они, кстати, переезжают потом в стандарт. XML въехал. Джейсон, по-моему, тоже уехал. Мм. Мне кажется, кстати, это сейчас быстро стало всё происходить. То есть как-то быстро всё происходит. Добавили там через каких-то лет уже в стандартах появляется. Не скажу я. Раньше медленнее было. Нет, не знаю. Мне кажется, нет. Знаешь, а я немножкоровался в самом подходе к стандартизации. То есть, понимаешь, это была очень такая актуальная история лет 20 назад. Это вот всё связано с глобализмом, вот с этим вот, понимаешь? То есть, а я, ну, то есть мир меняется очень сильно и не очень понятно, как это в целом, то есть, ну, взять раст хотя бы, да? Вот ну, по-моему, там нет никакого ансико комитета по расту. Вот. И слава богу. А есть Анси комитет по C++. И то, что они рожают, ну, мне лично очень не нравится. То есть как бы вот поэтому я немножко остыл про вообще не слежу за стандартами. Как-то я как пример, знаешь, вот опять же поговорим про базы данных. Ты знаешь, что сейчас большинство новых вендеров ориентируется на синтаксис Постгриса, а не на синтаксис Анси. Я прекрасно в это верю. Да, мне кажется, всегда так было. Всегда выбирали кого-то, на кого надо смотреть, кто является топом. Просто когда-то был Маскиэль, потом собственногрес. Да. Ну вот как как пример, то есть вплоть до даже каких-то идей синкрозий этого синтаксиса люди выбирают. Мы недавно у себя зарубились, индексы должны быть глобальные или локальные. Вот когда ты создаёшь индекс на таблицу, имя индекса оно вот в Москоле ты имя индекса, это имя таблицы, имя индекса, а в постгресе имя индекса глобальное. Это такой геморрой, потому что если ты переименовываешь таблицу, тебе нужно не забыть переименовать все индексы, иначе у тебя клэш будет, понимаешь? Угу. Вот. Но все в Позгресса экосистеме к этому привыкли. Они там доказывают, что это супер правильно. И все, кто повторяет, вот повторяют вот эту тему из Позгриса. В сQэле сделано, как в MySQэле, как бы много где сделано, ну, более удобно, но нет, как бы, потому что ты хочешь показать бенчмарк ПГЧ, а PГНЧ не заработает, если ты как бы не повторяешь синтаксис Постгресса. Угу. Ну, при этом, конечно же, тебе скажу, что о каком переименовании таблички вы вообще говорите, когда у вас база наполнена питабайтами данных. Ну, наверное, да, в таком случае вряд ли. Это я помню, ребята из Букинга рассказывали всякие приколы о том, что за десятилетие там существования проекта у них огромное количество таблиц, э, там именуется абсолютно там неадекватно. И внутри, собственно, есть специальные, короче, справочники, по которым они понимают, что вообще происходит. А ещё я не могу про это не сказать. Я слышал такой прикол про какой-то порносервис. В общем, на какой-то конференции выступали разработчики порносервиса, который изначально был для геев. И у них табличка так называлась в базе не юзеры, а ну или может быть дополнительная табличка. Кстати, сразу скажу, прошу прощения, может быть, это байка на самом деле, но я это слышал от чуваков, которые типа были на этой конференции. И он говорит, что в какой-то момент оно расширилось ещё и до девушек. И поскольку табличку не переименовать, они туда ещё пол внедрили внутрь этой таблички, и получился такой вот забавный микс. Да. Вот. Но переименовывать, видишь, уже, мягко говоря, нельзя в большинстве случаев. Слушай, вот тоже из нерешённых проблем прямо ты сейчас затронул проблемы эволюции схемы. Тоже ведь как бы мы говорим там что-то там эволюция базы данных, чтобы всё было супер круто, там нужен или не нужен. Вот есть простая тема. как правильно добавлять поля в таблички. И эта простая тема, она до сих пор болит у кучи бас и у кучи приклада. Вот. То есть и и про неё нужно рассказывать на курсах. То есть вместо того, чтобы ты мог как-то это вот, ну, сделать просто по инструкции и не думать, чтобы не включать голову, но нет, да? То есть вот Green Blue dey допустим, вот мы там проповедуем Green Blue dey Bluegreen, я не знаю, как правильно. Вот BL, по-моему, да. То есть я тебе к чему это хочу сказать, что базам данных вообще есть куда развиваться. Это, кстати, удивительная вещь. Я вообще у меня вообще отдельно заготовлен был про этот вопрос, но раз ты начал, скажи, пожалуйста, решена ли в посгресе эта проблема или нет? Я уверен, многие про неё не знают. Когда ты добавляешь просто поле и ты не указываешь ничего, кроме того, что, ну, а какого оно типа, то, по-моему, там меняются только методанные, а само изменение таблички там в процессе как-то начинается. Ну, мы до конца не знаем. Но если ты добавляешь дефолт, значение какое-то, ему нужно перелопатить всю структуру, и тогда у тебя блочится табличка, пока он этого не сделает. Мы точно на это напарывались. То есть там есть прямо такие типа, ну, справочники, как делать. Ни в коем случае при добавлении поля не ставьте дефолт. И с Налом тоже какая-то такая приколюха была. Я не скажу, поправили это или нет. Не не скажу настолько, как в Позгресе это работает, но ты прав в том, что и это абсолютно древняя тема. который нет уже в куче. Я тебе могу рассказать, почему так, если тебе интересно. Ну, расскажи. Это интересно, да. Вот это вот штука, она Я же уверен, что современные разработчики даже не очень в курсе про это. Это DBA скорее там секут. Это очень интересно, когда ты начинаешь смотреть на лейаут, то есть на то, как данные лежат на диске. И все старые базы, а вот там, я не знаю, кто слышал про Fax Pro, то есть просто, чтобы понимали, как это работает. Вот был экран на нём был выведен заголовок, короче, и ты и поля такие, и ты вводил в поля данные. То есть изначально эти базы данных они заменяли уже картотеки, а у картотек вся структура карточек фиксированная. Поэтому у базы данных у всех, и у Погреса, и у МайсQэля, и у Оракла, да, в самой строке нет вообще никакой информации о фрейме, о том, как, э, грубо вот фрейм, чтобы ты представил, это о трафарете, условно говоря, как это туда-то встать, то есть без трафарета ты это не прочитаешь. Вот, соответственно, когда ты меняешь трафарет, ты должен под этот трафарет перелопатить все данные, чтобы они подходили по, потому что там должны быть данные на нужных позициях, иначе на нуж позициях, да, смещения идут по сути по Да. Вот. А если бы посмотреть на там тот же формат Jсоon, то, ну, там же нет этой проблемы. Пожалуйста, если у тебя данные хранятся в Jсоon или в Pyhon, почему Монга это делает? Потому что у неё в каждой строке есть её фактически вот этот трафарет, её схема. Вот. Но что увеличивает объёмы там, что увеличивает объёмы, но есть же компромисс, понимаешь, вот то то, как мы там делали и делаем, есть возможность хранить версию просто. То есть ты хранишь там несколько байт, условно, которые обозначают, какая версия трафарета у тебя используется в каждой строке. Вот поэтому вот вот так это работает, так это ну реализовано. А вот ещё интересная тема, знаешь, как раз про Кассандру. Я я пока не стал заниматься касрой. Я я об этом не задумывался. А что будет у тебя в eventually consistant базе данных, если ты меняешь схему? То есть ты можешь произойти следующее. То есть неважно это синхронно или асинхронно, но у тебя могут прилететь данные в старой схеме уже после того, как ты уже решил, что ты вообще полностью везде схему поменял. То есть в event у тебя это не запрещено. У тебя может просто там usер прислать и как бы, ну, не отказать же ему, понимаешь, потому что транзакций нет. Откажешь, данные потеряются. Поэтому вот, например, в Кассандре запрещены какие-то операции с данными вообще. То есть типа дропнуть колонку ты нормально не можешь, понимаешь? Appendли получается, да? То есть оно append only по схеме. И когда ты, допустим, а дропаешь колонку, то реально она не дропается, а м просто помечается, что этот эта колонка мёртвая. У каждой колонки свой уникальный идентификатор, и если ты такую же колонку с новым именем создаёшь, то просто она рядом находится. То есть это будет новая колонка, и она будет всё равно в строке жить, но рядом. Да. Да. Не, ну тут понятная, кстати, штука. Я так понимаю, всё-таки это не влияет на объём. Ну то есть, грубо говоря, когда ты добавляешь новые записи, у тебя нет там скрытого, украденного пространства, правильно ведь? То есть у тебя это не влияет вот этот предыдущий груз на новые записи, потому что они просто не будут заполнять эти промежутки. Не, ну у тебя есть оверхд на метаданные и у тебя есть оверхad на главное на чтение. То есть опять же, откуда берётся вот эта тема с трафаретами, с этими фреймами в старых базах? Они все были на сата диски сделаны, на не очень большие диски и на не очень быстрые процессоры. И все экономили инструкции просто потому, чтобы получить доступ к нужному полю. То есть никто не вычитывал там строку целиком в оперативную память, потому что не было, ну, такого бенду, если понимаешь, то есть вот не память не такая была бы быстрая, то есть старались вычитывать по минимуму, а сейчас ээ как бы ну на это подзабивают, то есть читают всю строку и строки потом просто выбирают всё, что нужно технологически, да, вот на уровне там реализации. Но если ты посмотришь на всякие как раз колоночные базы, то они Почему колоночные базы рулят? Почему они такие быстрые? Потому что они хранят одну колонку рядом и работают с ней там какими-то векторными инструкциями процессора, опять же, клик, там куча оптимизации, чтобы можно было колонку прямо через векторную математику пропустить процессорную и получить сразу результат там ту же сумму, понимаешь? Вот. И ты это теряешь, если ты хочешь эволюцию. Ну то есть вот вот как это сделать нормально с эволюцией схемы, это вопрос. Это можно, наверное, сделать, но вот как бы вот когда ты начинаешь вот это всё учитывать, уже у тебя получается такой Франкенштейн. Знаешь, вот когда ты про всё это рассказываешь и давно в это не погружался, может сложиться впечатление, ну я имею виду разговор с тобой о том, что мы как бы прошли некий вот этот рубикон, когда порешали все проблемы, сейчас появляются новые базы и мы решаем какие-то новые проблемы. А то, что ты рассказываешь, по сути, получается, что мы вот копаемся и варимся в том же самом примерно, чуть может быть на другом уровне, но в целом нету какого-то прорыва, да, вот что прям ух кардинально решили, где-то legси тянин, где-то совместимость, что-то отмирает. Мне кажется, сейчас прорывы прямо попрут, если честно. Попрут, да. Да. Ну я считаю, что кликхаус - это прорыв. Вот честно, давай вот про это поговорим, да. Про прорыв просто по тому, как люди стали работать с аналитическими данными. Ну то есть такого не было. 5 лет назад, понимаешь, 5-7 лет назад представить себе, что ты можешь там несколько гигабайт просканировать за несколько секунд и получить любой ответ про эти несколько гигабайт, это было невозможно себе представить. Но аналитика - это, да, это особая тема, где самые большие объёмы, самые тяжёлые вычисления, самые сложные запросы. Правильно, ведь? Да. То есть нет, были пропритарные базы, короче, была там Вертика, быладата, но чтобы в Open source сообществе ты мог сделать такое, нет. Вот поэтому, мне кажется, в OLTP тоже может быть такой прорыв. Просто там поляна более такая забитая, там гораздо больше вендеров. Вот. И, ну, LTP он вообще очень такой сложный вот в аналитике всё-таки, но сейчас в аналитике тоже стало сложно, потому что там есть кликхаус. То есть, если ты хочешь прийти на эту поляну и сделать базу данных, да, базу, которая была бы в разы быстрее кликхауса, тебе реально нужно очень сильно постараться. Ну, концептуальная победа в чём? в том, что в первую очередь они выбрали колоночную структуру, а дальше это позволило дать кучу оптимизаций. Ну и плюс компромиссы, связанные со схемами и другим. Не, я думаю, что победа в первую очередь в том, что Миловидов изначально писал это под параллельное выполнение и под сканы и выбирал, ну, колонночную структуру. Это уже следствие того, чтобы сделать это максимально быстро для сканов. Вот. И причём таких параллельных сканов параллельные, да? То есть, чтобы много на много ядер можно было всё это запустить, я думаю, как бы вот, потому что если ты даже посмотришь на постгреш, то постгреш как сделан? Есть эээнд, и эээнд обрабатывает запрос. ты можешь в запросе, если там какая-нибудь там сортировка или ещё что-то в плане, ты можешь подключать ещё больше там процессов на это дело, но в целом это такая отдельная тема, которая как бы сбоку как бы это самое вот. Ээ поэтому ну ты имееш, что планировщик всё равно последовательно выполняет свои задачи, там этот просортировал, это фильтранул, да. То есть планировщик по сути работает с данными как с таким вот там вулкан, да? То есть, по сути, высасываешь данные из самого нижнего уровня, фильтруешь их, сортируешь и так далее. Строка за строкой. Ну и как бы, понимаешь, когда ты уже подключаешь, я говорю, векторные инструкции, когда ты подключаешь э всякие Memory Optimized леayауты, интересную компрессию специализированную, то всё это в комплексе даёт эту историю. При всём при этом возможно ли распространение клихауса за рамки аналитических данных, чтобы мы сказали: "Слушайте, а зачем нам посгрез? Давайте сразу там делать". Я думаю, нет. Техническое како или какое ограничение? Там просто никто не будет этого делать, потому что как только ты как бы, ну, то есть вот ты вошёл в какую-то нишу, ты уже у тебя инерция есть, определённое движение. То есть вот у них нет там в голове задачи сделать универсальную СУБД. У них есть в главе задача стать лидером своей в своём сегменте. Ну вот если бы я там был, я бы, наверное, так рассуждал. Вместо того, чтобы сделать какую-то СУБД, которая потенциально там заменит все, давайте лучше сделаем лучшие СУБД в сегменте аналитики. Вот. А ещё тем более сейчас вот этот переход в облака, а Кликhус - это сейчас коммерческая компания. Соответственно, скорее всего, у них будет основной фокус это не на то, чтобы это что-то релизить в Open Source, это Яндекс делал это для openсорса, понимаешь? И то там не просто далось это решение зарелизить. Это, я думаю, что это просто целая череда обстоятельств удачно сложившихся конкретных людей, принявших конкретные решения. А как бы сейчас коммерция, сейчас скорее всего Кликаус будет ориентироваться там на S3 хранение, на облачные сервисы, вот такие вещи. Маленькая ремарка. Вот мы буквально завершили перевод всей нашей аналитики в кликхаус и как раз вот в том числе по причинам торможения, то есть даже если у тебя немного данных, запросы, которые пишут аналитики, 500 вложенных с джойнами совсем, приводят к тому, что это невозможно. Особенно сейчас, когда очень много начинает генериться ишко и там никто уже особо не разбирается, что этот запрос делает. Как бы результат-то есть, есть. Надо ли там его красиво делать? Не надо. И в итоге это с удовольствием. Расскажи, какую задачу решают аналитики. Продуктовая маркетинговая аналитика, сеошная аналитика. То есть у нас там метрика выгружается, у нас выгружается Амка. Ну то есть я думаю, что это классическая история про любой САС, про любой бизнес онлайновый, где тебе, где тебе надо вот работать со всем этим добром. А сквозная аналитика. Поэтому данных при том, что у нас-то проект-то микроскопический по меркам, ну, крупняка, но когда у тебя миллионы, много-много миллионов миллионов десятки миллионов строк пошли и ты с этим начинаешь что-то делать, сам понимаешь, там на там либо витрины постоянно надо хитрые готовить, короче, там очень много подготовительной работы нужно делать для того, чтобы оно было хоть как-то приемлемо быстро. А мы хотим, чтобы вот в сыром виде плюс-минус их загрузил, да, там система событий есть, там есть какие-то таблички, вот там вмки в метрике, и ты прямо напрямую говоришь: "Дай мне, что я хочу, чтобы ничего делать не надо было". И вот кликхаус это позволяет. А вот представь себе, вот ты говоришь запросы генерации яишкой, а я думаю, что ну не очень далеко то время, когда ты просто будешь приходить к иишке, говорить: "Вот мой массив данных, приготовь его и начни мне отвечать на вопрос". Вот ещё что интересно. То есть как бы ты не будешь вообще как бы там думать о базе данных, потому что база данных будет, ну, и сама там выберет что-то для себя, она просто будет отвечать на твои вопросы. Мы очень к этому близки, насколько я понимаю. Вот Антропик уже выпустил решение похожее, когда у тебя ты видел, они там экстеншены делают, у них очень много запускается такого, когда ты берёшь экшн, например, он конкретно в Google табличках, например, там у тебя работает и делает всё, что тебе надо. То же самое, я уверен, на самом деле, когда мы говорим конкретно про Яндекс, поскольку мы в его облаке, я просто жду, я вижу, что они уже запустили яишку внутри облака, где ты её открываешь, и ты можешь уже и говорить: "Создай ресурсы, сделай то, сделай сё". Поэтому, когда мы со своими ребятами говорим, я я им всегда говорю: "Подождите ещё полгодика, вот чуть-чуть, и всё это будет уже встроено". То есть это даже не снаружи будет. Поэтому мы, а, в общем-то, тоже к этому готовы. И переход на клик нам в этом плане очень помогает. Ну, облачный, я имею в виду, мы их юзаем в Яндекс-облаке. Пока мы, кстати, давай так. Вот мы сейчас перешли к этой теме. Это уже как раз следующая часть, это облака. Значит, я хотел тебя вот что спросить. Во-первых, в принципе, вот эту облачность, насколько она является как бы тоже таким трендом тенденций? И во-вторых, я в принципе стал последнее время слышать про какое-то огромное количество слов, связанных с облачными базами данных. Какие-то неоны, посгрес в облаки. Ты, наверное, тоже все эти вещи слышал, да? Там у тебя появляются ОРМ, которые пишут: "Мы облако ориентированный ОРМ". Я даже до конца не очень понимаю, что это значит. У тебя как чуть ли не Cloudфра уже какие-то там вещи даёт делать и список там из 10ти-пнаца продуктов онлайновых, которые там и посгрес онлайновый, и это и это. И это как будто выглядит уже шире, чем просто РДС в Амазоне, да. Вот расскажи немножко, что это вообще такое всё происходит. Я тоже не очень знаю. То есть вот вот честно, то есть я знаю, во-первых, ребята из Силы бывшие, там Пек и Глаубер, их зовут, они сделали такую базу Турса называется. Они взяли Сикулай, переписали его на Расти и размещают его в облаки и хостят. И считаю, почему-то как бы всех прёт от того, что они в облаке могут, значит, иметь sequлай. Я искренне не доумеваю, как бы, что это за кейсы. То есть это, видимо, какие-то то ли маленькие веб-сайты, то ли какие-то агентики. Мне не очень понятно, что что такое чему как бы нужен вот такой вот BC Light. Вот при этом они как бы вот фишка в том, что для секулай обеспечить highability gbed база, а ты хочешь, чтобы она как бы у тебя не теряла данные, если у тебя инстанс вышел из строя. Вот это это тоже челлендж, это надо сделать и так далее. Но, короче, я видел это в своё время был Метеор, по-моему, такой проект. Вот есть ещё Temporal, там много было агентских проектов, и я скептически отношусь как UX уже человек в мире базданных. Я, конечно, не знаю, как опять же, как всё это поменяет мир агентов, да, а, но, э, для человека, то есть, вот почему это очень рядом сидит с тем, с историей про таранту. Ты помнишь, меня в начале разговора спросил: "А где вообще сейчас тарантулы?" Я тебе уже частично ответил: "Там база данных не умираются, они просто всегда остаются маленькими". Тарантул не умер, он прекрасно живёт, развивается. Просто он, ну, вот небольшой, да. Мы, когда делали тарантл, мы думали, что люди будут писать на Луа какие-то скрипты внутри базы, и это мегаклёво. Вот. И с каки в каком-то смысле это клёво, но в общем-то как бы вот эта инерция, знаешь, вот что что самое важное, что вот и почему сиквел там победил, и почему и там подход, вот был же подход in memory dataged, когда ты там на джаве писал внутри базы данных, просто у тебя было персистентное приложение, ты не думал о том, что у тебя есть отдельно СУБД, отдельно приклад, ты просто писал персистентное приложение. Вот прямо мегаприкольно. Вот. Но причина, по которой это не полетело, на мой взгляд, и не полетит, потому это в том, что стек ты хочешь выбирать независимо. Вот ты хочешь сменить себе там свой фреймворк фронтэнда ээ и как бы не думать о том, что у тебя при этом произойдёт с данными. Ты хочешь переехать с Goa на Раст и так далее, и ты хочешь переехать с Маскуэли на Постгриз. То есть вот вот люди хотят не хотят этого каплинга, понимаешь, совсем не хотят. Угу. Вот поэтому мне кажется, что там очень странная история будет. Вот мне поэтому не нравятся всякие облачные темы типа РДСА или даже Dynна DB в Амазоне, потому что, ну, dynam DB сейчас просто стал стандартным. Ты много где можешь получить dynam DB интерфейс. Угу. Вот. Но вот этот каплинг, который у тебя появляется с конкретным вендером, он на самом деле, то есть самые крупные, те, кто там типа типа Амазона, они как бы создадут статус кво как S3. Вот S3 формат IP. он много кем поддерживается, и это более-менее будет распространено. И тут всё понятно. Но когда ты создаёшь какую-то там хитрую базу данных с хитром AP и там и всякими такими штуками, я думаю, эта тема, ну, она в какой-то момент взлетает, потом остаётся нишевой. При этом сейчас, по-моему, бум какой-то идёт со всем этим добром. Мне самому интересно, знаешь, иногда я когда просто смотрю на всё это, у меня иногда такое проскакивает, может, я что-то не понимаю и что-то упускаю, раз все туда рванули. Но как будто это просто инвесторы по какой-то причине решили вкладываться. Я просто знаю, что даже Петя инвестирует в такие базы. У меня за последний год было много гостей из этих миров, которые прямо непосредственно сейчас занимаются разработкой таких вот надстроек каких-то облачных часто, да, которые решают какие-то доппроблемы. Вот интересный такой. Не, ну вопрос инвестиции вообще отдельный, потому что часто ты инвестируешь, например, в какую-то тему, потому что ты понимаешь, что ты её выгодно продашь там какому-нибудь крупняку потом. Не потому, что ты хочешь захватить мир и захватить умы вселенной, понимаешь? Вот. Ну я не знаю, спроси своих ребят, они готовы там бросить всё и начать кокодировать под какого-то конкретного. Ну то есть кака какой должен быть value? Просто вот перформанс никого уже не парит. Ну, объективно для больших данных понятно, тебе нужен перформанс, но для там, когда ты пишешь свой веб-сайт, ну, блин, я не знаю, кого должен парить перформанс. Может быть, хостеров и он парит, но людей не особо. Знаешь, какие там кейсы были точно? Ну, помимо облачности был кейс, связанный как раз с масштабированием. А второй, наверное, основной. У меня просто был в гостях разработчик, один из скоро разработчиков Pйthна, который Анwayй там реализовал. Очень крутой дядя, кстати, один из лучших выпусков. И он разрабатывает сейчас базу данных, который она по сути надстройка над посгресом, в которой язык более такой выразительный, который позволяет проще выражать те вещи, которые в сукели надо превращать там в сложные джойны и так далее, когда ты на уровне ближе к бизнесу, да, думаешь, да, это немножко, когда ты делаешь настройку на под на подгресом. Я я это Да, это вот тут тоже не надо путать. Смотри, я всё время общался с Ричардом Хиппом, который мне достал график. Ричархи Хип - это автор Сиклайта. Он сказал: "Все проекты, которые имбелят Sequite, как бы выстреливают". Вот смотри, Nokia встроила свой телефон Sequalite. Смотри, как пошли продажи Nokia. Apple, значит, начала пользоваться сикволайтом. Хорошая связь, да? Смотри, что произошло с Appleм. Вот поэтому, если ты что-то делаешь поверх Позгри, тебе заведомо, ну вот помнишь, про Пятёрочку я тебе говорил, что ты ты заведомо уже заходишь в такой маркетплейс, в котором всё супер как бы ну ты можешь донести ценность до много кого. Угу. Просто они все DB называют себя. То есть не просто там мы надстройка, а мы что-то DB, что-то DB. То есть вот у всех так. Ну это отдельный тренд тоже, да? То есть сейчас народ, допустим, берёт уже готовую СУБД типа IDB, а поверх неё делает настройку для векторов, для агентов и называет это, я уж не помню как, ну, короче, супер новая база данных, а под капотом там сидит другой open source проект. Ну, точно так же, как Elластик всё своё время стартанул, помнишь? Они с что там взяли? Люсин начали переделывать. Да. Ну, наверное, да. то, что он был, поэтому как бы это это отдельная тема, да? Ясно. Ну, понятно, они ещё слишком все маленькие и незаметные, чтобы хоть кто-то из них на что-то повлиял. В любом случае фундаментальные проблемы, они плюс-минус остаются. Смотри, мы дошли с тобой буквально у нас парочку ещё моментов осталось разобрать. Мы про И на протяжении всего вот подкаста сейчас говорили, но есть ли какое-то прямо видимое влияние, которое ты видишь иишки, которое может поменять что-то фундаментальное в базах данных, подходы, ещё что-то? Я думаю, да. Я думаю, да. Расскажи. Кроме того, что ты как кодер, ну, лучше делаешь какие-то вещи. Я тебе просто как кодер расскажу. Смотри, что происходит сейчас. Это не только в базе данных будет меняться. Угу. Что было раньше? А раньше я у меня есть какая-то супер клёвая идея. Вот ты говоришь, там, допустим, тот чувак, который для постгреса делает настройку, которая, ну, для питанистов, да, бывший петанист. А, и тебе для того, чтобы эту идею реализовать, нужно пройти огромный путь доставки ценностей. То есть ты должен там, вот у тебя есть идея супер клёвого оптимизатор запросов, но ты не можешь сделать оптимизатор запросов как продукт. Ты должен сделать стож, должен сделать новую базу данных с нуля, с репликацией, с какими-то юзерами, с правами, с аудитом-нибудь журналом, понимаешь, с авторизацией там и со всякой такой фигнёй. Вот. И как бы это сложно, это долго, и это много денег. Поэтому то, что мы сейчас можем вполне себе увидеть, это то, что соло как бы, ну вот всё, что говорят про солофаундерами, фаундеров, вот соло разработчики смогут делать продукты end to end, которые, ну, гораздо быстрее выходят на вот этот вот уровень пригодности для там проверки идеи. Это первая тема, которая, мне кажется, 100% будет. Вторая тема, это о которой вообще никто не думает. Смотри, Иишка, вот клоды и всякие, да, они уничтожают Open source. В каком смысле? Они его, естественно, не уничтожают как явление, но всё, что выложено в Open Source, оно всё в большой языковой модели. Вот я прихожу к ней и начинаю говорить: "Слушай, я хочу перепроектировать свою подсистему хранения. Я хочу, чтобы она стала быстрее. Что ты мне посоветуешь сделать?" И она мне говорит: "А, ну вот, ребята в как HDB придумали вот это, ребята, значит, ээ там где-то ещё придумали вот это. Ты что выберешь? Давай я тебе запилю, как бы". Ну ты просто скажи, что тебе больше нравится. Все создатели баз данных, они плагиаторы на самом деле. То есть у них есть несколько своих собственных уникальных идей. Вопрос о выборе, какая база данных самая клёвая. На самом деле в каждой базе данных есть какие-то красивые, уникальные идеи, а остальное э как бы всё равно один человек не может вот реализовать всё идеально. Вот вот сейчас вот всё, что вот весь плагиат, он становится очень простым, понимаешь? То есть, как только кто-то где-то реализует супер-дупер оптимизаторы, это будет open source базы данных. Через какое-то время модель обучится, и все разработчики базданных по всему миру смогут сказать модели: "Слушай, а ты можешь реализовать эту оптимизацию у меня на моей кодовой базе?" И за счёт этого прогресс будет, в принципе, идти быстрее. Вот это только такоя вот базовая такая история, которая совершенно точно будет происходить. Третья история, которая будет происходить - это в целом ты можешь модельке сказать: "Слушай, вот этот йпер вышел, прочитай, разберись и давай попробуем его запротопировать". Раньше ты должен был сам лично садиться на полгода и сидеть и читать йпер, разбираться, что автор имел в виду, покрывать это тестами и как-то пытаться это всё, понимаешь? Сейчас она может это сделать. И вот это всё в этот паратапинг тоже очень сильно влияет. Ты попробовал идею, ты замерил перформанс, да, базово. Тебе не нужно промерить всех, сделать её prodдаction ready. Ты просто навайп-кодил и пошёл, значит, проверять performance. Performance не катит. Ты посмотрел по коду, посмотрел по профайлеру, почему он не катит. Ты понял, разобрался, это ты где-то сложал или это иишка где-то сложала или это в целом идея непригодная, поехал дальше, выкинул, понимаешь? То есть вот этот цикл сокращается. Вот поэтому и я мне ещё интересно, что будет с там ты не читал там Дональд Кнут написал статью, на которой ему там Клод доказал такие какие-то гамилтоновых графах, какой-то способ что-то нашёл. Посмотри, кнут, короче, зарядил. Ну, заголовок я точно видел, да. Короче, вот если её правильно зарядить, она просто сокращает тебе огромное количество ручной работы, за счёт чего ты можешь ну вот у тебя есть задача проверить какую-то гипотезу, вот именно ручную работу, то есть она не будет за тебя думать, доказывать тебя теоремы, но тебе гораздо меньше надо упарываться, чтобы как бы вот, ну, ты превращаешься в такой мыслителя гораздо большей мере. Ну, знаешь, что ещё интересно? А только с Иишкой, мне кажется, мы лучше стали понимать, а что является реальной рутиной в нашей профессии. Согласись, ведь, то есть до этого ты какие-то вещи думал, делал, и ты считал, что, ну, это и есть работа программиста, потому что это должен делать, а кто ещё и как. А тут внезапно выясняется, что большое количество задач, которые раньше казались интеллектуальными, оказываются, в общем-то, ну, мартышкиным трудом. И и вот эта вот граница, она сильно выросла. Слушай, я не соглашусь здесь до конца. Я до Я я понимаю твоей мысли. Я с ней согласен. Я с не знаешь почему до конца. Не, ну не до конца, естественно. Да, у меня точно это подвинулось. У меня точно как бы эта граница изменилась. Я понял. Мне знаешь, что в этом интерес интересно, да? Вот сейчас, когда ты хочешь сделать какой-то веб-сайт, да, просто, ну, любой веб-сайт или прикладное по любое сделать, ты можешь просто диктовать промты. Ты вообще оказался в этой точке, потому что огромное количество людей в своё время, они набили себе шишки, они как бы чуть ли не поубивали друг друга, делать ОРМ или не делать. И вообще, какой подход правильный, сделали 100, 500 фреймворков. И сейчас ты уже как бы вот с этой точкой прогресса. И вот как только, ну, с тебя эту рутину сняли, да, ты перестал о ней задумываться, прогресс здесь, мне кажется, это может вообще остановиться. Вот кто те люди, которые как бы придумали всё то, чем она пользуется как бы каждый день, там лс, там, понимаешь, я не знаю, Греп, понимаешь? Вот никто никто не задумывался, что когда ты там работаешь, то она просто мега неэнеэффективна. Она пользуется командлайном и шелом, а для того, чтобы что-то делать, понимаешь? Вот, то есть она эмулирует работу как бы программиста, понимаешь, такую вот деби Ну ведь это же машина. Зачем она это делает, понимаешь? Вот тебе хотел про это сказать. Я знаю, я читал про это тоже, мне этот вопрос был интересен, и там сказали на, по крайней мере, на тот момент, когда всё это внедрялось, оно реально работало эффективней. Просто тупой вот этот греп, чем попытка использовать какие-то движки, как-то это раскладывать внутри. Но вроде как бы сейчас движение есть. Просто, видишь, нужно, видимо, несколько итераций, чтобы они, а, меняли подходы и что-то там улучшали. Поэтому, ну, возможно, сменится, да. По крайней мере, лспишки точно начали подрубать. Вот я в Openкоде смотрю, он уже там, знаешь, lsp начал использовать для каких-то задач, но по-прежнему грепает много. Это правда. Кстати, вот к вопросу о том, что раньше все такие: "Ну, вроде именование важно, но вроде можно и забить, а теперь нельзя, потому что иначе у тебя яишка нормально работать не сможет". Вот такие вот есть довольно забавные эффекты. Это тоже интересно, потому что, да, ты, как бы, они канализировали нечто, что никогда не являлось, ээ консенсусом, понимаешь? То есть вот ээ и это ну тоже ограничивает свободы очень сильно. О, кстати, а вот как ты думаешь, представь? А я уже видел для Редиса такое, когда а чувак просто написал аля скилы, ну он там больше, чем скилы, там ещё такое описание для Ишки, в том числе, где со всеми паттернами, со всеми вот кейсами, типа как использовать эффективно. Я, конечно, смотрю на это сейчас уже во все фреймворки это добавляю, да. А вот сейчас постгрес, это тоже 100%, я уверен, добавит. И Позгспрос, скорее всего, уже у себя это сделал. Насколько это улучшит ну структуры у конкретных людей их базданных? То запрос, который они делают, если ещё этой штуке дать возможность посмотреть, что там реально происходит, как будто можно такую аналитику вытаскивать оттуда, да, и и предлагать улучшение можно, но мы увидим. Я не думал, что BГдил. Вот это всё, ну, как бы это скорее уже такой переход в мейнстрим, то есть ну топовые люди они умели и до того, как это всё, то есть понимаешь, это канонизирует опять же такое топовое знание, как этим пользоваться. Вот. И я там Питер Тиль что ли опубликовал там своих агентов или кто-то кто-то из изкомбинатора. Вот. То есть это, ну, се, ну, мне это не очень как раз интересно лично. Вот. Ну, поня просто такое базовая вещь сейчас станет, да? Да. То есть я не очень смотрю, кто как что делает, потому что у меня уникальная моя работа, она, ну, то есть мне мне вряд ли кто-то поможет со скилами. Это правда. Это правда. Хорошо. У меня буквально есть последний блок, который я тебе хотел задать. Он как раз связан с тарантулом. Мы уже частично про это говорили. Ну, может быть, сейчас немножко повторимся. Расскажи, пожалуйста, для каких конкретно проблем появился Тарантул, почему в итоге он не взлетел и почему спустя вот н времени, довольно много лет, ты фактически стал делать, я так понимаю, его аналог и, видимо, в это веришь очень сильно. Нет, я не делаю аналог. Давай напомню, на таранту была есть такая история, что мы делали резидентный компьютер, персистентный резидентный компьютер. То есть мы, э, слоган был такой: bring your code close to data, то есть типа принеси код к данным, да, enjoy the performance. Как бы это было нужно для того, чтобы в первую очередь заменить огромное количество кода, которое нужно было написать там на C++, который кэшировал состояние какого-то мойля или постгреса и делал с ним что-то сложное. И Редис здесь, э, ну, забрал себе часть кейсов, но вообще не все, потому что дис всё равно это большая тупая банка. А если тебе нужно быстро с данными что-то делать, прямо вот, ну вот, не вынимая их из базы, то тебе не подойдёт, ну, никакая СБ, да. И, собственно, и сейчас это никак не поменялось. И такие кейсы есть. Просто этих количество этих кейсов не увеличивается со временем. А как решают эту проблему люди? Да ну, по-прежнему тем же тарантулом решают. То есть либо тарантулом, либо что-то своё, либо сбд какая-то, да. Вот. То есть тарантул родился в дижитале, он родился там, где ещё нужно горизонтальное масштабирование. Например, есть резидентная СУБД, как inмеory аналитика, да, резидентная. Поэтому вот такая проблема была, но есть куча кейсов, где это работает. Мы только сейчас внедряем там двухтарабайтный кластер, понимаешь? То есть как бы Но это нейстрим, это не My SQL, не Постгрес и даже не Redis, потому что дис всё равно он это очень простая штука, да, то есть это некий шаг вперёд по там после мкэша, да? То есть у тебя есть база, у тебя есть кэш, это нормальные, понятные паттерны, как с этим работать. Ты можешь одно от другого, оно всё деплд, у тебя есть приклад, код приклада, то есть у тебя всё всё разнесено. Ну сказать, что это совсем не полетела, я не могу. То есть вот ну какая-нибудь московская биржа, она там по-прежнему или Санкт-Петербургская биржа, она по-прежнему есть что-то такое нужно, да? То есть каким-нибудь, э, всяким, я говорю, криптонам им по-прежнему нужны такие такие паттерны проектирования ПВО, они никуда не делись вообще. То, что мы делаем в пикадате - это скорее вопрос не этого, да? То есть тарантул вот помимо вот этого вот этой идеи базовой, да, что на луашке пишешь рядом с с данными, он э ещё был прототипом один из одним из пионеров вот этого подхода Shared Nothing, когда у тебя Sharпер percore. То есть раньше Shared Nothingd они были такие, одна машина, одна один экземпляр, да, и кластер составлялся из экземпляров на одной машине. А сейчас, если ты посмотришь там на Tokio Runime, на Go Runime, на там вот все стары, это в CLDB, а, то есть очень много даже, ну, как бы рантаймов, которые тебе фактически шардируют твоё твоё приложение. Вот. И вот этот фреймворк, который мы в Тарантуле сделали для того, чтобы эффективно делать sharper cor, то есть один процесс, один одно ядро, один сегмент данных. Этот фреймворк фактически лёг в основу пикадаты. То есть мы просто взяли вот эту часть, взяли storage в пикадате и стали делать СУБД. То есть это СБУД изначально в памяти, да, то есть резидентная СУБД. Мы вот я говорил много про постгрес убрали вообще все притарные протоколы. К нам можно ходить обычным постгрисовым протоколом, по сгрессовыми драйверами. Взяли постгрисовый синтаксис. Вот. А для Ну и всё мы это делаем на расте, да? То есть, если тебе нужен шардированный резидентный постгрес, в нём пока не так много фич, но те фичи, что есть, они работают по оперативной памяти, они реально работают быстро, то вот такую штуку мы делаем. Я не особо про это рассказываю, потому что, как бы, понимаешь, я по опыту тарантула понимаю, что когда ты выходишь и людям что-то начинаешь рассказывать, особенно там прикладным программистам, у тебя уже должен быть toн продукт, который прямо вот, ну, типа они убирают постгрес, они ставят тебя, у них всё становится быстро. А этот подход, он до сих пор так не работает. То есть у тебя есть куча приклада. Вот. Ну вот, например, мы сейчас делаем аналитический кейс в среднем там по 20 джоинов с оконными функциями и со всем таким. Это не аналитика в смысле кликхауса, потому что кликхаус он быстро сканирует данные. А это аналитика в смысле OLTP, потому что это база, которая использует эффективно вторичные ключи для того, чтобы в оперативной понять, для того, чтобы быстро найти нужные данные. То есть она реально это поис такой структурированный поиск, высокоэффективный структурированный поиск в оперативной памяти. Вот. И там у тебя получается то, что раньше там на понимаешь какая беда у всех аналитических СУБД. У них низкая конкурентность по количеству сессий. То есть если у тебя там сессий 10 или 20, это о'кей. Клиентов одновременно подключённых. Если у тебя клиентов одновременно подключённых тысячи и они все начинают делать сложные запросы, то любая аналитическая СУБД со своими сканами, со своими колонками, она всё равно ложится. Поэтому есть такая ниша, мы её делаем. Если говорить про то, как мы бабки зарабатываем в России, так вообще элементарно мы, у нас есть, например, коммерческая версия, которая делает свой российский стексерфицированный дисластер на этой технологии. То есть там вообще она ходит под капот, минуя SQL, прямо вот как на внутреннея IP, но sнуе и а ну это импортозамес, да? То есть кому-то нужен стексертифицированный дис, пожалуйста, мы его делаем. Мы сейчас стали очень сильно доработали винил, то есть дисковый сторедж аля Кассандры и стали делать импортозамещённую тоже Касандру сцилу, то есть SQL тоже, то есть много у кого есть. Вот. Но основная идея такая, что вот есть шарперкоore архитектура, в которой мы делаем базу. То самое тоже такое занятное, мы не бросили историю с inmemory компьютером, то есть мы поддержали всё это, но мы перевели всё это слово на раз целиком. То есть у нас можно писать расширение для базы, но они пишутся строго на расте. Опять же преимущество раста я не буду расписывать. То есть ты делаешь плагин, ставишь его в кластер и получаешь высокопроизводительное какое-то вычисление прямо рядом с данными в кластере. То есть такое тоже осталось, такая фишка осталась. Но это маленькая сегмент относительно всего того сегмента, кому нужны вообще СУБД и зачем, понимаешь? То есть вот мы как бы я лично в первую очередь, когда ушёл из ВК, я себе задал этот вопрос: что я делаю, зачем? А, и что я хочу делать? И вот получилась такая штука. Угу. Единственное, знаешь, про редис хотел уточнить. Редис или всё-таки уже сейчас люди волки воспринимают? Как они смотрят на происходящее? Нет, смотри, волки - это реализация Редиса. Вот у нас своя же реализация, понимаешь? То есть мы, ну, там внутри, там будет наша персистентная там нет ни строчки кода op, ну, такой вот внешней. Это всё наш код. Поэтому это не редис, не волкито, это просто, грубо говоря, если редис спецификация, вот её мы её реализуем. А, я тебя понял. Короче, у вас получа А это я единственное, наверное, может не уловил или прослушал. Это всё-таки в итоге одна как бы база данных с фичами или это прямо просто независимые продукты, которые вот сами по себе сетапятся и делаются? Это плагины. То есть вот мы сделали плагины на Расте, сделали фреймворки для реализации плагинов. ставишь базовую платформу, она вся кластерная, там добавление узлов, удаление узлов. А у меня на костебо есть статьи. Вот. И, короче, ставишь плагин через SQL, заходишь в SQL-консоль, делаешь, значит, create плагин, указываешь ему путь, подгружаешь, получаешь дис. Он открывает порт и получаешь дис. Но потом по сгрисовой консоли можешь там шариться, смотреть, что у тебя происходит, админить. MCPшки ещё не сделали. Ты имеешь в виду для того, чтобы этим всём можно было через клод пользоваться? Не, он клод это всё заводит. Ээ то есть если ты придёшь клод и скажешь: "Хочу попробовать поиграться", он всё это заводит. Но просто мы сейчас ну тот же Редис мы коммерчески лицензируем, то есть мы его не размещаем. Ну я понял. Да. Да. Вот эта история про Open source, она чуть-чуть поменялась. Сейчас вендеры, они больше защищаются от облаков, от плагиата. Поэтому я даже как бы с одной стороны вот вся пикадата, она open онрourсная, но с другой стороны я не Ну вот раньше была такая история, что все там фаундеры они, ну вот этот евангелизм был очень комнити адвокат. Вот это всё, кстати, вот профессия комьюнити адвокат, она осталась вообще? Ну в каком-то виде существует. По ику давай. Деврелы точно существуют, мне кажется уже так. Ну сейчас уж точно вот последнее время там несколько крупных компаний делают, но это не комьюнити, наверное, адвокаты. Слушай, сложно сказать. Я, наверное сильно погружён просто в это. Ну вот я к чему это говорю, тоже очень интересно, что раньше была такая лихорадка, что все делали ос продукты, пытались захватить максимум сообщества и через это как-то потом монетизироваться, стать единорогами и так далее. Сейчас этого нет. Э, вот и этого массового нет. Это печально, конечно, но, э, и деньги ушли инвесторов, и сам подход ушёл. Ну, может, мы ещё выросли и немножко максимализма, идеализма ушло тоже, потому что это всё-таки как-то, знаешь, вот я тоже помню, это и с идеалами было связано, и про это говорили, и ты как бы тебя пёрло от того, что ты влияешь на мир, как-то там что-то такое делаешь. Вот сейчас чуть более прагматично стало. Ну и плюс понятно, экономика и вообще мир поменялся. Конечно, те года были золотым веком, теперь мы это точно знаем. Там начало двухтысячных, когда просто всё пёрло, всё росло и все всё было как бы на позитиве в этом смысле. Знаешь, какой последний вопрос, наверное, хотел тебе задать. Он немножко в сторону, но просто для понимания. Вот мы с тобой много-много раз про монгу говорили. Вот с точки зрения реального смысла монди вообще как база сейчас нужна или нет? Не с точки зрения legгаacy, там у кого-то проекты, они какую-то нишу занимают, у них какой-то маркетинг, а вот прямо реально как проект, который вот решает какую-то задачу, которую другие не решают. Ну, я не очень разбирался, какую они задачу решают раньше, понимаешь? То есть, ну, правда, искренне. Я же из Майскуэля сразу перешёл в SQL такой вот более современный. То есть я монго как бы пропустил. Я монго застал, когда они приезжали ещё мон DB 1.0, они приехали на мой SC конференс и раздавали там кружки. У меня даже были кружки Mongo DB. Вот. И вот как кружки я их заценил. А потом они хайпанули, вышли на IPO. Я я до сих пор не очень понимаю, как это работает. Вот, честно. Я знаю, что там есть сейчас очень крутые спецы. То есть там команда несколько раз поменялась, и там прямо реально крутые чуваки. Но у них такой груз legси, что там тоже вот мы свору лет назад тестировали, есть ещё один проект, знаешь, про который хотел рассказать. Стропи. Значит, мы сделали инструмент для бенчмаркинга разный по СБD as a strropi. Если хочешь, я тебе пришлю потом ссылку. Значит, и мы тестировали монгу, транзакции в монге. Это было 3 года назад, по-моему, или четыре. Ну, может быть, они там починили. Но прикол в том, что транзакции в монге, они становятся медленнее, когда ты добавляешь узлы в кластер. Только ленивый не пнёт монгу. Но вот син какой-то там где-то на Но вот факт, да. То есть с одной стороны горизонтально масштабируем СБД, но с другой стороны она становится как бы медленнее. Ну то есть сейчас, когда меня спрашивают вообще люди приходят, говорят: "А какую мне базу взять?" Я говорю: "Бери постгрез". Если ты не знаешь, какую у тебя базу, бери постгрес. Кстати, ещё вот интересный факт. Недавно Афир это Кайл Кинсбури, это там Джепсон, слышал такой фреймворк по тестированию баз тоже. А он свомел, он чувак занимается консистентностью с УБД, но видишь, у нас мир, мир такой маленький, но нас всех знают. Вот он, у него, кстати, отличные статьи про СБД. Я советую зайти просто почитать его исследование. Вот он недавно выпустил как бы отчёт по галерея кластере в Мариби. Отчёт просто, ну, такой очень негативный, что консистентности нет, что данные теряет. Э вот и, ну, и репутационно - это очень тяжёлый отчёт. Я уверен, что они всё исправят. А вот, но я к чему говорю? К тому, что сегодня вот этот фокус внимания, он очень важен в сообщества. И если ты начинающий, то, ну, тебе точно нужна не монго. И понятно, что сейчас Постгрец - это главный пажёр, поэтому Удивительно, да, и для него главное всё готово, понимаешь? То есть всё есть. То есть минимальное количество шансов, что ты где-то ложань, потому что даже когда ты берёшь продукт и он не мейнстримный, ты можешь ложануть. Удивляется позгресом ситуация, потому что обычно продукты проходят такую цикл, который известен всем, когда у тебя проходит тренд. И в целом дальше идёт только на спад, он занимает какую-то нишу, и в целом о нём не возни не вспоминают. Как посгрес второй раз взобрался на этот, э как бы пик, я не очень понимаю, потому что это очень удивительно. вещь. Он же уже был, когда, помнишь, переход, когда Москель посгрез, мой скель подгрес, а потом упал и снова фантастика. Да, я знаешь что жду? Жду, что как там ребятки в Турс переписали Sequлай на Расте, кто-то наконец напишет на Расте полностью Постгрес, и вот тогда начнётся очень весело, потому что одна из самых больших проблем постгреса, как бы вот этот велосити, который есть в постгрисовой экосистеме. Потому что с одной стороны там всё очень быстро происходит, а реально много пачей принимается. С другой стороны, там как настолько, ну, как бы какие-то legси. Я недавно смотрел в Позгресе там доклад, чувак рассказывал, чего стоит добавить Иоюринг, а это новый вот вывод линуксовый, высокоэффективный в Постгрес, и там просто какие-то нереальные усилия, понимаешь? То есть нужно перевести постгрес на фреды или что-то похожее сделать. То есть вот прямо ну очень непросто извлечь выгоду из новых AP линуксовых возгресей. Вот. И каждый, ты смотришь каждый релиз, там огромное количество всего меняется, но такие базовые вещи, они меняются очень медленно. Если это смогут порешать, вот будет веселуха. Ну да. То есть получается, что они доходят до той точки, что в какой-то момент просто переписать будет дешевле, чем пытаться поддерживать. Я думаю, да, интересно. Ну главное, если совместимость внешнюю оставят, мы с радостью перепрыгнем. такие уж мы пользователи онсорсных продуктов, да? Куда туда, куда ветер дует, туда мы и прыгаем. Вот на этой позитивной ноте. Кость, большое спасибо, что ты пришёл ко мне и поговорил про базы данных. Я надеюсь, тебе понравилось и надеюсь, что нашим слушателям это очень сильно понравится, потому что ты много чего интересного рассказал и понятно, что ты оченьочень круто разбираешься в этой теме. Спасибо тебе. Спасибо. Ну, если было там что-то грузил очень сильно, ну, не всё всё прекрасно. Да, ребят, обязательно, да, ставьте лайки, подписывайтесь, пишите свои комментарии, будем читать, будем смотреть. Кость, тебе удачи в твоей компании. Нам удачи в просмотрах. Спасибо. Всем спасибо. Пока.