Но ни в одном новом проекте я не буду использовать PG (как и на Oracle, MySQL и всех прочих монстров 90-ых). Я не хочу становиться экспертом в БД, я хочу комфортно решать прикладную задачу.
Простите конечно, но нету ни одной такой системы которая удовлетворила бы вас.
И все мои возмущения по сути, сугубо на сравнении с более модными штуками типа mongo — с его веб-панелью, типа cassandra, которая всё сама, типа elasticsearch, который тоже практически всё сам, и так далее — приведите свои примеры.
Если вы про это, то поверьте это не решает и 10% проблем таких систем. С той же Mongo под нагрузкой не меньше проблем чем с Postgres (на самом деле куда больше!!!). Или вон недавно сами монговци признались, что если хотите быстрый Mongo то используйте её поверх Postgres. :)
А честные транзакции? А уровни изоляции? Если вам это стало нужно, а у вас Mongo то у вас скорее всего проблема.
MongoDB и многие из этой волны, больше маркетинг чем реально что то ещё. Причём уже очень многие на этом обожглись.
к БД — никакое, к продукту СУБД — полное.
В этом контексте это синонимы. Если вы думаете что под Системой Управлением БД понимается GUI и веб морда для настроек то вы ошибаетесь.
У меня на календаре 2016 год, уже который год вовсю шагает докер
Ещё раз: какое отношение эта утилита имеет к БД? Она реально больше к докеру имеет отношение чем к БД.
Если у БД надо узнать какие то параметры или статистику, то она всегда пожалуйста её дать может.
Опять же, если такая система (а не просто утилитка), так нужна то можете написать сами.
PG, остальные пробуют с «дефлотными настройками»
PG тут можно заменить на MySQL, Oracle, IBM DB2 и т.д.
по этому я не понимаю, у вас претензия к отрасли или конкретно к Postgres?
Я где-то сказал о пера кликов и ракете на Марс?
Вы написали про то, что слишком мало супер пупер специалистов во всех тонкостях БД. Я ответил в том ключе, что это неизбежно т.к. сложность текущих БД очень и очень высока.
«чувак, у тебя в системе 8G памяти, а под PG отдано 1G, давай добавим?»
А если у вас там ещё веб сервер крутится? Этого не может и не должна знать БД. Вы ей приписываете совершенно не свойственные ей фичи. Этим всем и занимается админ вместе с DBA (или кто то один).
с кучей тонкостей и нюансов, и нужен человек с опытом, который хорошо понимает что вообще происходит и какие рукоятки из миллиона возможных крутить.
Так блин системы сложные! Ну нельзя в пару кликов мышкой собрать ракету для полёта на Марс.
2. судя по этому пункту про UPSERT, у нас разные понимания термина «продукт».
Я вас не понимаю. Фичу то давно хотели, и давно пытались только пока не получалось сделать. Сейчас вот всё срослось. Какие тут противоречия со словом продукт?
по крайней мере вокруг меня разработка сдвигается в сторону от реляционных баз. Данные из реальной жизни становятся сложнее структурно, запихивание их в таблицы занимает всё больше труда. При этом альтернативные решения, всякие такие фишки уже дают.
Именно по этому в Postgres есть JSON/JOSNB и в 9.5 появился json_set.
Какие есть причины, не выпускать фичу, которая хорошо работает на малых объемах?
Не очень понимаю ваш вопрос. Тут отчасти как с UPSERT т.е. партицирования в Postgres нету, оно эмулируется через наследование таблиц. т.е. это достаточно сложный вопрос. Кроме того спрос (от крупных фирм готовых платить) есть именно на партицирование тысяч таблиц.
Нет не поменялось. У BTree есть проблемы когда записей ооочень много то добавление нового элемента становится очень затратным.
Если у вас огромная таблица и вам иногда хочется по ней искать быстрее чем SeqScan то BRIN хороший выбор.
ЗЫ была надежда, что COLA отчасти решит это… но увы. Сейчас правда идут подвижки к улучшению самого BTree, возможно которые приведут к ненужности GIN.
меня даже более простой интересует — партиционирование таблиц
Вот прям сейчас это пилится, уже есть хорошие результаты, надеюсь в 9.6 будет. Хотя главная там задача избавится от оверхеда и сделать работу с 10000 партициями без проседания производительности (сейчас в postgres уже на 100 есть траблы).
К сожалению люди которые пилят БД как правило делают именно БД
Зря вы так думаете. Просто есть:
1. Не такой большой спрос на эти фичи.
2. Не все фичи легко реализовать исходя из текущей архитектуры. К примеру для UPSERT пришлось вводить новый тип блокировки (Postgres очень строгий MVCC).
Старый тупл никогда не обновляется, создаётся всегда новый с новым TID, xmin, xmax. Другое дело, что оно может упасть в ту же страницу памяти.
Ну и не забываем, что при работе с индексами там немного иначе может всё отработать (т.е. логика этого процесса для индекса и хипа отделена).
1. Задержка особо не уменьшается, а CDN не всегда получается использовать.
2. Не надо забывать, что это 3-4 сотни килобайт ещё надо распарсить браузером… возьмём мобильный веб к примеру. :) (у меня там от jQuery были проблемы то)
И я правильно вас понял: вы предлагаете даже для приложений уровня ToDoMVC всегда использовать фреймворки?
В той теме я то же отписался… мне кажется вы во мне разбудили бунтаря.
Интересны были бы рекомендации при каком размере приложения имеет смысл связываться с каким либо фреймворком? А то для меня всё это выглядит как огромный блоатваре почти на пол мегабайта одного кода!!!
т.е. все эти фреймворки явно излишни для ToDoMVC примера (хотя я видел и гораздо проще примеры куда вкорчивали Angular).
Надеюсь понятно моё недоумение…
ЗЫ Dart конечно по приятнее чем JS но вся эта возня с трансляцией конечно отпугивает так же как и от TypeScript.
Жду когда появится гений и создаст фреймворк где без лишних абстракций получится писать чистый и ясный код, решающий задачу, а не очередную проблему совместимости библиотеки А с языком B…
MVC — чисто GUI архитектура, которую изначально придумали как решение проблем десктопных приложений.
Я вам даже больше скажу, это всё было сделано для StateFull систем, а современный веб как правило StateLess. От сюда и неприменимость многих архитектурных плюсов MVC.
делаем API для мобильных приложений — начинается веселье
Веселье в любом случае начинается, так как вам приходится старое и новое API разводить либо в модели либо в контроллере (как правило это затрагивает все слои).
А вообще есть мысль, что под словом MVC сейчас все понимают разные вещи и его применяют часто не к месту. (Pyramid вообще себя RV фреймворком называет)
Короче надо смотреть конкретные реализации и их минусы, всё крайне сложно. :(
если только каждый экшн не выносить в отдельные файлы, что тоже гемор
Так всегда работаешь с минимальным количеством кода, пусть и файлов плодиться куча.
А не те самые это яйца только в профиль?
Мне в целом нравится как это сделано в Pylons когда контроллер это некий класс который содержит экшены т.е. их можно группировать функционально и создавать внутреннюю логику для избежания копипаста (такие контролеры можно наследовать друг от друга). Ну и конечно если постоянно много однотипных работ с данными то тут надо модель мучить.
Дело в том, что разработчики самого Yii2, слишком дословно трактовали MVC при разработке инструмента. В результате модель получается таким божественным классом, который делает все.
Я вообще считаю, что для веба куда практичнее делать жирные контроллы и тонкие модели (в меру конечно). Многие товарищи вообще говорят, что MVC для веба (не бизнес приложений) плохая идея (разработчики Pyramid).
Простите конечно, но нету ни одной такой системы которая удовлетворила бы вас.
Если вы про это, то поверьте это не решает и 10% проблем таких систем. С той же Mongo под нагрузкой не меньше проблем чем с Postgres (на самом деле куда больше!!!). Или вон недавно сами монговци признались, что если хотите быстрый Mongo то используйте её поверх Postgres. :)
А честные транзакции? А уровни изоляции? Если вам это стало нужно, а у вас Mongo то у вас скорее всего проблема.
MongoDB и многие из этой волны, больше маркетинг чем реально что то ещё. Причём уже очень многие на этом обожглись.
В этом контексте это синонимы. Если вы думаете что под Системой Управлением БД понимается GUI и веб морда для настроек то вы ошибаетесь.
К слову на счёт веб морд: www.heroku.com/postgres такое вас устроит? :)
Ещё раз: какое отношение эта утилита имеет к БД? Она реально больше к докеру имеет отношение чем к БД.
Если у БД надо узнать какие то параметры или статистику, то она всегда пожалуйста её дать может.
Опять же, если такая система (а не просто утилитка), так нужна то можете написать сами.
PG тут можно заменить на MySQL, Oracle, IBM DB2 и т.д.
по этому я не понимаю, у вас претензия к отрасли или конкретно к Postgres?
Вы написали про то, что слишком мало супер пупер специалистов во всех тонкостях БД. Я ответил в том ключе, что это неизбежно т.к. сложность текущих БД очень и очень высока.
А если у вас там ещё веб сервер крутится? Этого не может и не должна знать БД. Вы ей приписываете совершенно не свойственные ей фичи. Этим всем и занимается админ вместе с DBA (или кто то один).
Так блин системы сложные! Ну нельзя в пару кликов мышкой собрать ракету для полёта на Марс.
Я вас не понимаю. Фичу то давно хотели, и давно пытались только пока не получалось сделать. Сейчас вот всё срослось. Какие тут противоречия со словом продукт?
Именно по этому в Postgres есть JSON/JOSNB и в 9.5 появился json_set.
Не очень понимаю ваш вопрос. Тут отчасти как с UPSERT т.е. партицирования в Postgres нету, оно эмулируется через наследование таблиц. т.е. это достаточно сложный вопрос. Кроме того спрос (от крупных фирм готовых платить) есть именно на партицирование тысяч таблиц.
Если у вас огромная таблица и вам иногда хочется по ней искать быстрее чем SeqScan то BRIN хороший выбор.
ЗЫ была надежда, что COLA отчасти решит это… но увы. Сейчас правда идут подвижки к улучшению самого BTree, возможно которые приведут к ненужности GIN.
Вот прям сейчас это пилится, уже есть хорошие результаты, надеюсь в 9.6 будет. Хотя главная там задача избавится от оверхеда и сделать работу с 10000 партициями без проседания производительности (сейчас в postgres уже на 100 есть траблы).
Зря вы так думаете. Просто есть:
1. Не такой большой спрос на эти фичи.
2. Не все фичи легко реализовать исходя из текущей архитектуры. К примеру для UPSERT пришлось вводить новый тип блокировки (Postgres очень строгий MVCC).
Ну и не забываем, что при работе с индексами там немного иначе может всё отработать (т.е. логика этого процесса для индекса и хипа отделена).
Во многом гораздо стабильнее нвидевских блобов.
На github можете правки глянуть.
1. Задержка особо не уменьшается, а CDN не всегда получается использовать.
2. Не надо забывать, что это 3-4 сотни килобайт ещё надо распарсить браузером… возьмём мобильный веб к примеру. :) (у меня там от jQuery были проблемы то)
И я правильно вас понял: вы предлагаете даже для приложений уровня ToDoMVC всегда использовать фреймворки?
А ещё больше признаны недостатки этого подхода, из-за чего нету и не предвидится его доминирование.
Интересны были бы рекомендации при каком размере приложения имеет смысл связываться с каким либо фреймворком? А то для меня всё это выглядит как огромный блоатваре почти на пол мегабайта одного кода!!!
т.е. все эти фреймворки явно излишни для ToDoMVC примера (хотя я видел и гораздо проще примеры куда вкорчивали Angular).
Надеюсь понятно моё недоумение…
ЗЫ Dart конечно по приятнее чем JS но вся эта возня с трансляцией конечно отпугивает так же как и от TypeScript.
Почему все забывают старые добрые Сишные функции?
Я вам даже больше скажу, это всё было сделано для StateFull систем, а современный веб как правило StateLess. От сюда и неприменимость многих архитектурных плюсов MVC.
Веселье в любом случае начинается, так как вам приходится старое и новое API разводить либо в модели либо в контроллере (как правило это затрагивает все слои).
А вообще есть мысль, что под словом MVC сейчас все понимают разные вещи и его применяют часто не к месту. (Pyramid вообще себя RV фреймворком называет)
Короче надо смотреть конкретные реализации и их минусы, всё крайне сложно. :(
А не те самые это яйца только в профиль?
Мне в целом нравится как это сделано в Pylons когда контроллер это некий класс который содержит экшены т.е. их можно группировать функционально и создавать внутреннюю логику для избежания копипаста (такие контролеры можно наследовать друг от друга). Ну и конечно если постоянно много однотипных работ с данными то тут надо модель мучить.
Я вообще считаю, что для веба куда практичнее делать жирные контроллы и тонкие модели (в меру конечно). Многие товарищи вообще говорят, что MVC для веба (не бизнес приложений) плохая идея (разработчики Pyramid).