NumPy для массивов как Pandas для табличек в Питоне, все ужасно, но уже поздно что-то делать. Гвидо не обратил внимания на эти пороли боабобов вовремя и вот результат
На сайте есть и ссылки на статьи и имплементация в DuckDB
Поддерживать прямые ссылки приходится используя технику pointer swizzling и на больших объемах и при больших вставлениях это все ужасно работает, поэтому и не используется.
Объектные базы данных были интересны в 90-ых, что-то они очень удобно и хорошо делали, сам пользовался O2 в свое время. Графовые СУБД сейчас что-то интересное показывают, но только на узких сценариях. С графовыми я сам плотно работал, разрабатывая оптимизатор запросов в TigerGraph
Возьмите те же самые аналитические бенчмарки TPCH и TPCDS и попробуйте конкурировать с реляционными базами, а работе DuckPGQ сравнение на графовом бенчмарке
Практика показывает, что 99.9% пользователей не готовы и не умеют оптимизировать свои сложные запросы, да и сама задумка SQL - это декларативность, вы пишите что вы хотите от СУБД, а она сама находил лучший план как это обеспечить. Для меняющейся статистики и такого рода страхов есть инструменты, как прикопать конкретный план, который понравился - пока в YDB не реализовано, но скоро сделаем, на подобие как сделано в TiDB.
Если ну очень хочется все самому - можно полностью захинтовать запрос
В графовых базах есть как односторонние так и двусторонние ребра, но не суть.
Такие вот легковесные ссылки во первых только на лукапах дают большое преимущество, а у нас полно запросов со значительным сканированием в аналитике. Потом поддерживать такие ссылки на больших объемах данных очень непростое дело и вредит производительности больше чем помогает.
Вот статья о том, как на DuckDB реализовали PGQ и побили Neo4j 10x: https://duckpgq.org/
Вы описали обычную графовую базу, которая умеет только лукавы. В графовых СУБД оптимизация запросов ничем не проще, чем реляционный и можете почитать работу DuckPGQ где на реляционной базе 10х перебивается Neo4j. При этом есть кейсы где графы действительно полезны, когда например по одному большому графу мы ходим в глубину. Поэтому мы внимательно следим за этой темой и какой-то графовой функционал в формате PGW будем реализовывать в будущем
YDB гибридная реляционная СУБД, что означает, что она поддерживает высокие OLTP нагрузки одновременно с тяжелыми OLAP запросами. Авторы YDB в свое время и XML СУБД разрабатывали, и как показывает многолетняя практика, реляционные СУБД отлично справляются со всеми современными вызовами. Предлагаю в комментариях обсуждать статью, а не модели данных для СУБД
Изначально хороших запросов в аналитике (когда сложный план, много джоинов и возможны разные варианты доступа к данным) нет. Тот SQL который вы напишете недоопределен - там порядок джоинов фиксирован, но не выбраны алгоритмы и access paths (способы доступа к данным). Поэтому все аналитические СУБД используют стоимостные оптимизаторы.
Конечно, оптимизатор может ошибаться и оптимальность не гарантирована. Если производительность не устраивает после оптимизации и есть подозрение, что можно улучшить план, который сделал оптимизатор, можно посмотреть на EXPLAIN ANALYZE и попробовать подсказать какие-то детали оптимизатору в местах, где видно, что он ошибся. Это делается с помощью хинтов запросов
На бенчмарках у нас есть запросы с 17 и 19 джоинами, у некоторых заказчиков видели запросы 20+ джоинов. Есть команды аналитики, которые используют схемы данных Vault и Anchor, у них встречаются запросы с 60+ джоинами
Исторически Clickhouse был заточен на аналитику сверху одной таблицы, по сравнению со многими другими СУБД он это делал мгновенно. Сейчас они на более широкий пласт переходят и там точно потребуется стоимостный оптимизатор.
В современном мире аналитики запросы с 20+ джоинов не редкость например
Эйджизм мировой тренд, и к нам именно таким образом и докатился. Турбо Паскаль это конечно здорово, но если хочется остаться разработчиком за 47 (самому сейчас 47) надо метить в гуру и лучше уже отрастить крутые компетенции в более узкой области, поздно быть jack of all trades. Матчасть тоже должна помочь, молодежь с горящими глазами и готова 24/7 фигачить, но может например заняться решением нерешаемых задач. Рекомендую свою статейку на хабре про образование (местами там ошибся, например со Scala, но в общем актуально)
Майкл до сих пор очень активно занимается СУБД и его более поздние проекты еще более интереснее ранних. Система интеграции данных Tamr решает самую больную проблему интеграции данных, без которой Большие Данные - просто большая помойка. DBOS - еще более амбициозный проект - переосмысление принципов операционной системы Unix/Linux и создание новой кластерной ОС.
Также пропущены другие детища Майкла. Да, они не такие успешные, но отражают его уровень энергии: StreamBase, Cohera, SciDB, VoltDB, и другие.
История с коммерциализацией Postgres через Illustra, ее продажа Informix и война с Oracle тоже вроде не раскрыта.
В YQL неплохо решена проблема SQL с NULLs, которая всех уже замучила порядочно. Кстати, решение похоже на то, как предлагал исправить стандарт SQL С.Д. Кузнецов в своей статье
Без Achor и Vault часто приносят 20+ джоинов, а недавно вот 60 принесли. Жизнь меняется.,.
NumPy для массивов как Pandas для табличек в Питоне, все ужасно, но уже поздно что-то делать. Гвидо не обратил внимания на эти пороли боабобов вовремя и вот результат
Вот теперь на 100TB бенче прогоните и покажите что у вас получится
Это и аналитики, которые и отчеты сложные пишут, и ad-hoc запросы. И разные BI инструменты.
На сайте есть и ссылки на статьи и имплементация в DuckDB
Поддерживать прямые ссылки приходится используя технику pointer swizzling и на больших объемах и при больших вставлениях это все ужасно работает, поэтому и не используется.
Объектные базы данных были интересны в 90-ых, что-то они очень удобно и хорошо делали, сам пользовался O2 в свое время. Графовые СУБД сейчас что-то интересное показывают, но только на узких сценариях. С графовыми я сам плотно работал, разрабатывая оптимизатор запросов в TigerGraph
Возьмите те же самые аналитические бенчмарки TPCH и TPCDS и попробуйте конкурировать с реляционными базами, а работе DuckPGQ сравнение на графовом бенчмарке
Практика показывает, что 99.9% пользователей не готовы и не умеют оптимизировать свои сложные запросы, да и сама задумка SQL - это декларативность, вы пишите что вы хотите от СУБД, а она сама находил лучший план как это обеспечить. Для меняющейся статистики и такого рода страхов есть инструменты, как прикопать конкретный план, который понравился - пока в YDB не реализовано, но скоро сделаем, на подобие как сделано в TiDB.
Если ну очень хочется все самому - можно полностью захинтовать запрос
В графовых базах есть как односторонние так и двусторонние ребра, но не суть.
Такие вот легковесные ссылки во первых только на лукапах дают большое преимущество, а у нас полно запросов со значительным сканированием в аналитике. Потом поддерживать такие ссылки на больших объемах данных очень непростое дело и вредит производительности больше чем помогает.
Вот статья о том, как на DuckDB реализовали PGQ и побили Neo4j 10x: https://duckpgq.org/
Вы описали обычную графовую базу, которая умеет только лукавы. В графовых СУБД оптимизация запросов ничем не проще, чем реляционный и можете почитать работу DuckPGQ где на реляционной базе 10х перебивается Neo4j. При этом есть кейсы где графы действительно полезны, когда например по одному большому графу мы ходим в глубину. Поэтому мы внимательно следим за этой темой и какой-то графовой функционал в формате PGW будем реализовывать в будущем
YDB гибридная реляционная СУБД, что означает, что она поддерживает высокие OLTP нагрузки одновременно с тяжелыми OLAP запросами. Авторы YDB в свое время и XML СУБД разрабатывали, и как показывает многолетняя практика, реляционные СУБД отлично справляются со всеми современными вызовами. Предлагаю в комментариях обсуждать статью, а не модели данных для СУБД
Статья про оптимизатор запросов в реляционной СУБД
Изначально хороших запросов в аналитике (когда сложный план, много джоинов и возможны разные варианты доступа к данным) нет. Тот SQL который вы напишете недоопределен - там порядок джоинов фиксирован, но не выбраны алгоритмы и access paths (способы доступа к данным). Поэтому все аналитические СУБД используют стоимостные оптимизаторы.
Конечно, оптимизатор может ошибаться и оптимальность не гарантирована. Если производительность не устраивает после оптимизации и есть подозрение, что можно улучшить план, который сделал оптимизатор, можно посмотреть на EXPLAIN ANALYZE и попробовать подсказать какие-то детали оптимизатору в местах, где видно, что он ошибся. Это делается с помощью хинтов запросов
На бенчмарках у нас есть запросы с 17 и 19 джоинами, у некоторых заказчиков видели запросы 20+ джоинов. Есть команды аналитики, которые используют схемы данных Vault и Anchor, у них встречаются запросы с 60+ джоинами
Исторически Clickhouse был заточен на аналитику сверху одной таблицы, по сравнению со многими другими СУБД он это делал мгновенно. Сейчас они на более широкий пласт переходят и там точно потребуется стоимостный оптимизатор.
В современном мире аналитики запросы с 20+ джоинов не редкость например
Нет, у нас сбор статистики идет на компакшене, то есть совсем немного запаздывает от вставки.
Ну не так важно как так случилось, но вот рекомендации я привел
Эйджизм мировой тренд, и к нам именно таким образом и докатился. Турбо Паскаль это конечно здорово, но если хочется остаться разработчиком за 47 (самому сейчас 47) надо метить в гуру и лучше уже отрастить крутые компетенции в более узкой области, поздно быть jack of all trades. Матчасть тоже должна помочь, молодежь с горящими глазами и готова 24/7 фигачить, но может например заняться решением нерешаемых задач. Рекомендую свою статейку на хабре про образование (местами там ошибся, например со Scala, но в общем актуально)
Майкл до сих пор очень активно занимается СУБД и его более поздние проекты еще более интереснее ранних. Система интеграции данных Tamr решает самую больную проблему интеграции данных, без которой Большие Данные - просто большая помойка. DBOS - еще более амбициозный проект - переосмысление принципов операционной системы Unix/Linux и создание новой кластерной ОС.
Также пропущены другие детища Майкла. Да, они не такие успешные, но отражают его уровень энергии: StreamBase, Cohera, SciDB, VoltDB, и другие.
История с коммерциализацией Postgres через Illustra, ее продажа Informix и война с Oracle тоже вроде не раскрыта.
ИМО следует написать версию 2.0
В YQL неплохо решена проблема SQL с NULLs, которая всех уже замучила порядочно. Кстати, решение похоже на то, как предлагал исправить стандарт SQL С.Д. Кузнецов в своей статье
А что побудило переводить статью о TigerGraph? Вы пользуетесь этой СУБД, или собираетесь ее ставить?