Например, у компаний-интеграторов обмен решениями между командами, работающих на разных заказчиков, практически исключен, потому что юридические риски превышают затраты на разработку с нуля.
Такое только при 100% in-house разработки возможно
Там кластеризация данных не принудительная, как в Redshift, но де-факто это дефолтный метод хранения (особенно для таблиц TB+). Для этого даже механизм автоматической кластеризации существует.
А, ну я просто не увидел в тексте, что больше транзакционная нагрузка рассматриваются
Тогда Citus можно выделить, он как раз больше под OLTP заточен - его и on-premise можно развернуть из open-source, и Microsoft его в Azure педалирует активно У Амазона есть Aurora PostgreSQL - облачный распределённый OLTP (в двух вариантах исполнения - на мускуле и PG)
Хотя Аврору иногда к NewSQL относят, но критерии тут вообще очень размытые. В Авроре, по сути, под капотом форки классических БД, оптимизированные под бессерверные вычисления.
Не совсем понял, почему "олдскул SQL" получил оценку "нет" по критерию "Распределённые"
На рынке куча MPP RDBMS с полноценным ACID и SQL - от опенсорсных (Greenplum, Citus) до проприетарных (Teradata, Exasol, Vertica, Redshift, Snowflake...). Я уж не говорю, что даже обычный PG или Oracle можно вполне себе сделать распределённым без особых ухищрений.
Точно такая же проблема у Яндекса с поиском любой узкоспециализированной информации. Когда учился в универе/аспирантуре в середине 10-х регулярно искал англоязычные материалы по лазерной физике, выдача Яндекса, Mail.ru и Bing по теме была просто никакой. Можно было пользоваться только Google.
Подозреваю, что у них какой-то принципиально другой подход, и тысячами асессоров и закостыленных нейронок тут не отделаться
Однажды в проекте по разделению двух схем в Oracle мы столкнулись с тем, что пакеты одной схемы вызывают пакеты из другой схемы, которые в свою очередь снова вызывают пакеты из первой, и так по кругу. И всё это делалось через уже упомянутые синонимы. Мы построили дерево зависимостей и оцепенели от ужаса… Его высота составила 42 уровня!
От таких архитекторов никакая миграция не спасёт, увы
>>Нашла странный UX: при удалении пространства требуется дословно повторить его название
Это стандартное решение из систем контроля версий (Git и т. п.). Меньше вероятность, что пользователь случайно безвозвратно удалит важный репозиторий/доску, т.к. ему придётся сначала перечитать название удаляемого объекта.
И тут вспомнился коммерческий Neo4j, который тупо (и вполне успешно) хранит всю информацию о рёбрах и вершинах с произвольным количеством тегов и атрибутов тупо в JSON
Например, у компаний-интеграторов обмен решениями между командами, работающих на разных заказчиков, практически исключен, потому что юридические риски превышают затраты на разработку с нуля.
Такое только при 100% in-house разработки возможно
Глобально - нет. Все рекомендации для стандартных сборок PostgreSQL применимы и там.
В сборках от PostgresPro есть модуль online_analyze, который частично подменяет функционал автоматического сбора статистики - его можно настроить отдельно:
https://postgrespro.ru/docs/postgrespro/15/online-analyze
Там кластеризация данных не принудительная, как в Redshift, но де-факто это дефолтный метод хранения (особенно для таблиц TB+). Для этого даже механизм автоматической кластеризации существует.
А, ну я просто не увидел в тексте, что больше транзакционная нагрузка рассматриваются
Тогда Citus можно выделить, он как раз больше под OLTP заточен - его и on-premise можно развернуть из open-source, и Microsoft его в Azure педалирует активно
У Амазона есть Aurora PostgreSQL - облачный распределённый OLTP (в двух вариантах исполнения - на мускуле и PG)
Хотя Аврору иногда к NewSQL относят, но критерии тут вообще очень размытые. В Авроре, по сути, под капотом форки классических БД, оптимизированные под бессерверные вычисления.
Не совсем понял, почему "олдскул SQL" получил оценку "нет" по критерию "Распределённые"
На рынке куча MPP RDBMS с полноценным ACID и SQL - от опенсорсных (Greenplum, Citus) до проприетарных (Teradata, Exasol, Vertica, Redshift, Snowflake...). Я уж не говорю, что даже обычный PG или Oracle можно вполне себе сделать распределённым без особых ухищрений.
Точно такая же проблема у Яндекса с поиском любой узкоспециализированной информации.
Когда учился в универе/аспирантуре в середине 10-х регулярно искал англоязычные материалы по лазерной физике, выдача Яндекса, Mail.ru и Bing по теме была просто никакой. Можно было пользоваться только Google.
Подозреваю, что у них какой-то принципиально другой подход, и тысячами асессоров и закостыленных нейронок тут не отделаться
Есть статья на тему роли FK при планировании join, но PG там не в лидерах
https://blog.jooq.org/join-elimination-an-essential-optimiser-feature-for-advanced-sql-usage/
Хотя FK не для этого нужны, конечно
От таких архитекторов никакая миграция не спасёт, увы
>>Нашла странный UX: при удалении пространства требуется дословно повторить его название
Это стандартное решение из систем контроля версий (Git и т. п.). Меньше вероятность, что пользователь случайно безвозвратно удалит важный репозиторий/доску, т.к. ему придётся сначала перечитать название удаляемого объекта.
И тут вспомнился коммерческий Neo4j, который тупо (и вполне успешно) хранит всю информацию о рёбрах и вершинах с произвольным количеством тегов и атрибутов тупо в JSON