1) Oracle развивается быстрее всех конкурентов, И даже нет надежды что кто то сумеет обогнать ее по функционалу и скорости в своем классе БД?
Смешно. Может я, конечно, и адепт MS SQL Server, а потому не могу судить объективно (как и вы), но имел опыт работы и с Oracle. Вот что сразу в голову пришло:
1) Напрягало отсутствие возможности определить кластеризованный индекс (IOT в оракле) не по первичному ключу. Напрягало, что по умолчанию IOT содержит только сам PK, а не располагает все колонки всех записей в заданном порядке.
2) Напрягало отсутствие возможности определить включенные (INCLUDE) колонки для не IOT-индексов, зачем-то оракл их не может не индексировать, но я-то знаю, что мне это не надо.
3) Не очень удобные планы запроса (субъективно и в сравнении). Нет онлайн-планов запроса, как в MS SQL. Зачем-то внезапно нужно для планов запросов еще и табличку создавать отдельную в БД.
4) COLUMNSTORE INDEX не завезли в Oracle.
Еще сильно бесило, что ораклисты пишут курсоры направо и налево, в частности для соединения двух таблиц(!), имитируя LOOP JOIN, пишут на устаревшем стандарте (FROM table1, table2 WHERE (+)...), но это просто мне такие только попадались.
Если расскажете про плюшки оракла — будет интересно почитать, ибо я уже давненько не углублялся сильно в СУБД, перейдя со скуля на C#. Но говорить что оракл впереди планеты всей — как-то слишком.
А можно подробнее, в чем его испоганили? Я просто пользуюсь временами, не особенно заметил кардинальных изменений от смены владельца, может я что-то упустил. Помню, был радикальный редизайн, но его же вроде откатили давно уже
И тем не менее учить бесполезный язык ради каких-то абстрактных навыков — очень скучная трата времени. Для меня по факту C# был первым языком, не считая макросов в экселе на VBA. Очень легкий в изучении и логичный язык. Учил без книг (только «CLR via C#» через полгода изучения).
А я ничего не напутаю, если скажу, что контекст синхронизации и исполняющий поток — вещи из разных плоскостей? ConfigureAwait определяет необходимость захвата контекста синхронизации, а не использования того или иного потока. Т.е. использование continueOnCapturedContext для того, чтобы оставить код в потоке — концептуально неверное решение.
В корне не согласен с объявлением параметра continueOnCapturedContext в методах библиотечного кода. Это как раз библиотеке решать, нужен ей контекст или нет. Почти всегда — нет, поэтому и рекомендуется использовать .ConfigureAwait(false). Если все же нужен — используем .ConfigureAwait(true), либо вообще его не пишем.
Клиентскому коду абсолютно ни к чему управлять этим поведением. Если клиентскому коду нужен контекст — он может захватывать его на своем уровне. Библиотечный .ConfigureAwait(false) ему в этом никак не мешает.
Кажется, вы не до конца изучили вопрос. Либо же я его до конца не понимаю. Если вы сможете привести хоть один пример, когда клиентскому коду может потребоваться, чтобы библиотечный код захватывал контекст синхронизации внутри себя — я начну сомневаться в своих познаниях в этом вопросе=)
Обычно такими мыслями задаются люди, которые совсем не понимают как устроен мир. Вот я, например, поработал в своё время экономистом-бухгалтером после ВУЗа (никуда больше не брали). Насмотрелся я на действительно ненастоящих работников — которые вечно перекладывают бумажки из стопочки А в стопочку Б, заводят вручную оттуда данные в 1С, печатают документы, ходят с ними к «важным» людям на подпись. И не только насмотрелся, а сам таким был.
Сейчас, по прошествии четырех лет, я переучился в программиста-бэкендера и пишу крупный сервис ЭДО. Дак вот я действительно радуюсь тому, что моя работа приносит много пользы. Потому что она позволяет выгонять таких же работников каким был я. Вместо 10 таких бухгалтеров можно оставить одного-двух, а все остальные вынужденно пойдут заниматься чем-то другим, более значимым. Просто у учителей-врачей-строителей результат всегда перед ними. На лицо, так сказать. Учитель может вам назвать своих учеников, врач видит своих больных, строитель может показать здание, в строительстве которого поучаствовал (заметьте, не сам построил). У программиста результат его работы размыт по тысячам других людей. Каждому из них он принес меньше пользы, чем условный врач, но для общества в целом эта польза может быть выше.
Вот вам наглядный пример из моей практики:
Приложение посылает к базе MS SQL несколько раз запрос, в котором в области WHERE идет фильтрация в каждом отдельном случае по разному значению идентификатора. В запросе накручено много всего (его генерирует ORM). Но, обычно, он выполняется быстро (в зависимости от кол-ва возвращаемых строк — от 0 до двух минут). И тут иногда случаются дикие просадки, запрос висит по часу.
Пошел разбираться — вначале к серверу приходили запросы по идентификатору, по которому одна-две записи. SQL Server генерировал план запроса с использованием Nested Loops для джойнов. И кэшировал этот план. А потом к нему приходил запрос, по которому данных в несколько тысяч раз больше. Но план брался из кэша — не оптимальный.
Это лечится, например, хинтами. Тут два варианта, либо явно указывать алгоритм соединения таблиц в проблемном месте. Либо указывать запросу, чтоб он строил план без учета закэшированного. Так как я работал через ORM то я просто упростил запрос, но в ином случае, возможно, использовал бы хинт.
1) Например, хинты. Насколько я помню, в Postgre их не завозят, в Oracle они в комментах, в MS SQL они часть синтаксиса.
2) В Postgre табличные выражения, насколько помню, указывают планировщику указывают на то, что эту часть нужно материализовать во время выполнения запроса (или как-то так, я с Postgre не работал). А в Oracle и MS SQL они не влияют на план запроса.
3) MySQL вроде как не поддерживает оператор MERGE из стандарта SQL 2008 года. Есть аналоги, но не полностью покрывают функционал.
4) MySQL не поддерживает транзакционность DDL-операций. Из-за этого сложности с накатом миграций.
Это только на ваш взгляд так не бывает. Наверное, вы не работали с планами запросов и не пробовали использовать хинты/менять запрос для изменения этого плана. Или вообще не представляете как работает запрос, что некоторые СУБД кэшируют план и т.д. Самый банальный пример с алгоритмами соединения таблиц, когда планировщик выбирает, например, Nested Loops вместо Hash или Merge Join
Как раз наоборот.
Единственный выигрыш от нескольких переменных, вместо объекта, это экономия памяти на аллокации объекта.
А вы вообще понимаете, что в статье говорится не о мифическом перфомансе и экономии на спичках, а об удобстве работы с кодом? Выигрыш тут в том, что видя названия аргументов (а в идеале, в TS/Flow, еще и их типы), мы сразу можем понять что в функцию нужно пихать. А не какой-нибудь мифический args-объект в котором непонятно что должно содержаться (и не дай бог этот args будет по цепочке передаваться туда-сюда в разные функции, тогда вообще ничего нельзя будет разобрать).
Хоть и был у меня опыт взаимодействия с менеджерами, которые меня совсем не устраивали, но автор производит впечатление программиста, который оккупировал все основные процессы на предприятии в области ИТ и никому отдавать не намерен, поддерживая тем самым собственную незаменимость. Хуже программистов, чем те, которые насиживают одно место годами и которых нельзя при этом заменить — быть не может. Абсолютно непонятны претензии к просьбе оценить время на выполнение задачи. Видимо, автор привык чувствовать, что он «царь и бог» и к нему только на поклон ходить можно, в надежде на его милость.
Ничего странного. В MS SQL ничего подобного нет, там планировщику без разницы где указано условие. В больших запросах разница очень теоретически может возникнуть на этапе построения плана запроса (два немного разных запроса пойдут по немного разному пути и имеют шансы получить разные планы выполнения из-за ограничения времени на построение плана). Но тут никогда нельзя утверждать, что какая-то конструкция языка будет однозначно быстрее аналогичной. Что там в mysql творится — не знаю, говорю за Oracle, MS SQL.
Опишу свою историю, может вас к чему-то подтолкнет.
Я в 24 года, после работы экономистом-бухгалтером, пришел в крупный банк на непонятную позицию (в новом подразделении, то ли аналитик, то ли недоразработчик-писатель макросов на VBA). И так сошлись звезды, что после принятия меня на эту должность, одновременно с начальником (отдел-то новый), он оценил, что я не подхожу под эту должность (не знал SQL) и направил меня на 4 платных майкрософтовских курса по MS SQL и разработке DWH на нем. Через несколько месяцев, сразу после последнего моего курса начальника уволили, взяли другого, но и тот убежал через 3 недели. Я уже тоже готовился писать заявление (было абсолютно не понятно что от нас хотят, но чего-то требовали), но решил остаться и посмотреть что будет дальше.
1. Следующие 7-8 месяцев я на практике изучал и игрался с MS SQL с правами админа. Параллельно работодатель оплачивал мне изучение языка C# на рабочем месте (как и у автора поста, работодатель про это не знал). Сначала писал легкие маленькие скриптики в MS SSIS, затем расширения для MS Excel. Ну и какую-то работу тоже работал.
2. Перешел в не ИТ-компанию даже с небольшим повышением в зп (искал специально, нашел совсем не сразу, отшивали из-за высоких запросов по зп) на стажера-джуна на C#.
3. Отработал там ровно 1 год и ушел в одну из крупнейших ИТ-контор в РФ на позицию middle+
Итого, на то, чтобы мутировать из экономиста, умеющего немного говнокодить на VBA, в middle+ C# разраба, у меня ушло чуть больше полутора лет. Вам, полагаю, стоит приступать сразу к пункту 2.
Попробуйте писать на C# без этого мусора. Я, например, пишу на C# в крупный проект в крупной команде, где не пишут интерфейс, когда есть только одна реализация, где в DI ничего нигде не регистрируется в коде (все автоматически), и все, что DI пробрасывает по умолчанию — Singleton. Я был счастлив найти команду, которая не пишет интерфейс под каждый чих, которая не считает SOLID манной небесной и единственно верным путем.
А вы не задумывались о правильности выбора технологического стека под вашу задачу? Основные проблемы, которые вы описываете, в родственном Java дотнете решаются использованием структур. Там вы можете не ограничиваться примитивами, а писать свои типы, которыми не управляет GC в общем случае.
Для вашей информации, каждый запрос в БКИ — платный. Стоит сейчас не знаю, ну может 10 рублей на клиента.
Поэтому и существует облегченный вариант, о котором я упомянул. Гуглите «триггеры БКИ». По ним можно гонять весь портфель банка, тарифы пакетные вроде, пакеты большие и стоят для банка дешево. Я знаю о чем говорю, т.к. лично участвовал в разработке расчетов «супер выгодных предложений» одного крупного банка, в том числе, на основе этих триггеров. И само их получение и постановку на мониторинг в БКИ тоже делал.
Эта статья скорее о том, что неявная оптимизация может сильно подгадить.
Я не пишу на C#, но например, если в теле цикла меняется размер массива
Ага, «не читал, но осуждаю». В .NET все массивы без исключения фиксированной длины. Она не может измениться, можно только создать новый массив другого размера.
Смешно. Может я, конечно, и адепт MS SQL Server, а потому не могу судить объективно (как и вы), но имел опыт работы и с Oracle. Вот что сразу в голову пришло:
1) Напрягало отсутствие возможности определить кластеризованный индекс (IOT в оракле) не по первичному ключу. Напрягало, что по умолчанию IOT содержит только сам PK, а не располагает все колонки всех записей в заданном порядке.
2) Напрягало отсутствие возможности определить включенные (INCLUDE) колонки для не IOT-индексов, зачем-то оракл их не может не индексировать, но я-то знаю, что мне это не надо.
3) Не очень удобные планы запроса (субъективно и в сравнении). Нет онлайн-планов запроса, как в MS SQL. Зачем-то внезапно нужно для планов запросов еще и табличку создавать отдельную в БД.
4) COLUMNSTORE INDEX не завезли в Oracle.
Еще сильно бесило, что ораклисты пишут курсоры направо и налево, в частности для соединения двух таблиц(!), имитируя LOOP JOIN, пишут на устаревшем стандарте (FROM table1, table2 WHERE (+)...), но это просто мне такие только попадались.
Если расскажете про плюшки оракла — будет интересно почитать, ибо я уже давненько не углублялся сильно в СУБД, перейдя со скуля на C#. Но говорить что оракл впереди планеты всей — как-то слишком.
Клиентскому коду абсолютно ни к чему управлять этим поведением. Если клиентскому коду нужен контекст — он может захватывать его на своем уровне. Библиотечный .ConfigureAwait(false) ему в этом никак не мешает.
Кажется, вы не до конца изучили вопрос. Либо же я его до конца не понимаю. Если вы сможете привести хоть один пример, когда клиентскому коду может потребоваться, чтобы библиотечный код захватывал контекст синхронизации внутри себя — я начну сомневаться в своих познаниях в этом вопросе=)
Сейчас, по прошествии четырех лет, я переучился в программиста-бэкендера и пишу крупный сервис ЭДО. Дак вот я действительно радуюсь тому, что моя работа приносит много пользы. Потому что она позволяет выгонять таких же работников каким был я. Вместо 10 таких бухгалтеров можно оставить одного-двух, а все остальные вынужденно пойдут заниматься чем-то другим, более значимым. Просто у учителей-врачей-строителей результат всегда перед ними. На лицо, так сказать. Учитель может вам назвать своих учеников, врач видит своих больных, строитель может показать здание, в строительстве которого поучаствовал (заметьте, не сам построил). У программиста результат его работы размыт по тысячам других людей. Каждому из них он принес меньше пользы, чем условный врач, но для общества в целом эта польза может быть выше.
Приложение посылает к базе MS SQL несколько раз запрос, в котором в области WHERE идет фильтрация в каждом отдельном случае по разному значению идентификатора. В запросе накручено много всего (его генерирует ORM). Но, обычно, он выполняется быстро (в зависимости от кол-ва возвращаемых строк — от 0 до двух минут). И тут иногда случаются дикие просадки, запрос висит по часу.
Пошел разбираться — вначале к серверу приходили запросы по идентификатору, по которому одна-две записи. SQL Server генерировал план запроса с использованием Nested Loops для джойнов. И кэшировал этот план. А потом к нему приходил запрос, по которому данных в несколько тысяч раз больше. Но план брался из кэша — не оптимальный.
Это лечится, например, хинтами. Тут два варианта, либо явно указывать алгоритм соединения таблиц в проблемном месте. Либо указывать запросу, чтоб он строил план без учета закэшированного. Так как я работал через ORM то я просто упростил запрос, но в ином случае, возможно, использовал бы хинт.
2) В Postgre табличные выражения, насколько помню, указывают планировщику указывают на то, что эту часть нужно материализовать во время выполнения запроса (или как-то так, я с Postgre не работал). А в Oracle и MS SQL они не влияют на план запроса.
3) MySQL вроде как не поддерживает оператор MERGE из стандарта SQL 2008 года. Есть аналоги, но не полностью покрывают функционал.
4) MySQL не поддерживает транзакционность DDL-операций. Из-за этого сложности с накатом миграций.
Продолжать можно до бесконечности
Ммм… Забавно читать такое, когда ты пишешь бэкенд на C# для большой высоконагруженной системы.
А вы вообще понимаете, что в статье говорится не о мифическом перфомансе и экономии на спичках, а об удобстве работы с кодом? Выигрыш тут в том, что видя названия аргументов (а в идеале, в TS/Flow, еще и их типы), мы сразу можем понять что в функцию нужно пихать. А не какой-нибудь мифический args-объект в котором непонятно что должно содержаться (и не дай бог этот args будет по цепочке передаваться туда-сюда в разные функции, тогда вообще ничего нельзя будет разобрать).
Какая-то аргументированная критика C# в сравнении с Java у вас есть?
С вашей стороны весьма глупо называть провальным язык, который уже давно занял неплохую долю в своей нише и очень крупное сообщество.
Я в 24 года, после работы экономистом-бухгалтером, пришел в крупный банк на непонятную позицию (в новом подразделении, то ли аналитик, то ли недоразработчик-писатель макросов на VBA). И так сошлись звезды, что после принятия меня на эту должность, одновременно с начальником (отдел-то новый), он оценил, что я не подхожу под эту должность (не знал SQL) и направил меня на 4 платных майкрософтовских курса по MS SQL и разработке DWH на нем. Через несколько месяцев, сразу после последнего моего курса начальника уволили, взяли другого, но и тот убежал через 3 недели. Я уже тоже готовился писать заявление (было абсолютно не понятно что от нас хотят, но чего-то требовали), но решил остаться и посмотреть что будет дальше.
1. Следующие 7-8 месяцев я на практике изучал и игрался с MS SQL с правами админа. Параллельно работодатель оплачивал мне изучение языка C# на рабочем месте (как и у автора поста, работодатель про это не знал). Сначала писал легкие маленькие скриптики в MS SSIS, затем расширения для MS Excel. Ну и какую-то работу тоже работал.
2. Перешел в не ИТ-компанию даже с небольшим повышением в зп (искал специально, нашел совсем не сразу, отшивали из-за высоких запросов по зп) на стажера-джуна на C#.
3. Отработал там ровно 1 год и ушел в одну из крупнейших ИТ-контор в РФ на позицию middle+
Итого, на то, чтобы мутировать из экономиста, умеющего немного говнокодить на VBA, в middle+ C# разраба, у меня ушло чуть больше полутора лет. Вам, полагаю, стоит приступать сразу к пункту 2.
Поэтому и существует облегченный вариант, о котором я упомянул. Гуглите «триггеры БКИ». По ним можно гонять весь портфель банка, тарифы пакетные вроде, пакеты большие и стоят для банка дешево. Я знаю о чем говорю, т.к. лично участвовал в разработке расчетов «супер выгодных предложений» одного крупного банка, в том числе, на основе этих триггеров. И само их получение и постановку на мониторинг в БКИ тоже делал.
Ага, «не читал, но осуждаю». В .NET все массивы без исключения фиксированной длины. Она не может измениться, можно только создать новый массив другого размера.