Has the same effect as PLSQL_OPTIMIZE_LEVEL=1—instructs the PL/SQL compiler to generate and store the code for use by the PL/SQL debugger. Oracle recommends using PLSQL_OPTIMIZE_LEVEL=1 instead of DEBUG.
Отечественные СУБД отлично зарекомендовали себя ...
Ну да конечно. Обычно, то что на 99% состоит из open source кода называется форк. ИМХО надо гнать в шею таких "импортозамещателей", наследнички bolgenOS и дела Попова) Ну разве что, PostgresPro еще можно понять, так как они контрибьютор основной ветки.
Ну не знаю.. Продавать такое как продукт... Фио перемашать , ака Третьев Первый Вторвович. Емейлы, телефоны - ну тут понятно простейший генератор. Адреса - есть кладр, или можно также перемешать (города, улицы, дома), если физическое существование не важно. Сохранить в отдельные таблицы, дергать по мере надобности, в нужном кол-ве, при раскатке тест баз, чтоб каждый раз не генерировать.
Плюсую. Известно, же как раз что в крупных компаниях наоборот много уровней иерархии инженеров, и высшие имеют большие полномочия в принятии решений, сравнимые в топ менеджерами. Взять тот же МС, иерархия выглядет примерно так Junior Software Engineer Intermediate Software Engineer Senior Software Engineer Staff Software Engineer Senior Staff Software Engineer Principal Software Engineer Distinguished Software Engineer Fellow Senior Fellow ... Я думаю, общий посыл статьи правильный, просто диавол как всегда в деталях..
О многом ни слова. Да тема такая огромная, что одной статьей не обойтись. Но все же, имхо, автор, зря вы с хинтов начинаете. Начинают разрабы пихать их не к месту после таких статей. Все таки с основ cost based оптимизации лучше. Дальше, что есть estimated планы ( о которых речь в общем то тут и идет), и реальные. А как про реальные планы, так тут и статистика , child cursors, hard/soft parse и plan stability( вот тут о хинтах уже можно, наряду с outlines).
Кто то еще использует Oracle SE ? Давно работаю с Oracle, не помню когда встречал его последний раз, точно лет 10 прошло. С момента появления enterprise фич в opensorce бд (типа partitioning, HA, incremental backup) уже как то не особо нужен. Кажется этот рынок Oracle давно проиграл.
Спасибо за статью, но осталось несолько вопросов. Аналитику пернесли, а остальное осталось в PG ? Или это изначально чисто аналитическая БД была ? Если чисто аналитическая, то почему выбрали PG изначально ? Как загружаете данные в Clickhouse ?
Достаточная сложность, при серьезных ограничениях. Почему не захотели пойти классическим путем : RAC + ASM ? И дискгруппы можно собрать (с необходимым redundancy) с неcкольких СХД и проблем с их resize нет на лету, и под vmware работает. По деньгам не готов утверждать что это не дороже, но знаю, что VCS тоже сильно не дешевый.
Решение проблемы split brain — обязательная составляющая кластерного решения. Без этого вообще нет смысла в кластере. И защита от этого есть — различные voting алгоритмы.
В классических проектах на Java роли тестировщика, разработчика и DevOps четко разграничены, а serverless-системы – принципиально другие.
Эх ребята, все не так, все не так ребята (с)
Вообще в классическом понимании DevOps нет такой роли, есть набор практик, технологий и методологий.
DevOps должны заниматься и админы и разработка и тестирование. Если вы кого-то конкретного (админа, разработчика или тестировщика) в девопс назначаете, такой девопс у вас и получится — однобокий. Что собственно противоречит его сути.
но спорить о существовании этого мифа довольно глупо.
не надо мне приписывать, то чего я не делал.
Я давно написал и выделил, что речь именно о key entry.
Давайте теперь еще раз логике:
a index entry==entry==index key entry==key entry?
Речь вроде шла о общей терминологии. Это вы сейчас задним числом исправились, дописали key entry. Раньше вроде было bitmap, bitmap piece, index entry и это в сообщении о общей терминологии. Разве не так? А оказалось key entry — именно это общепринятая терминология( а не bitmap, bitmap piece и не index entry
Заголовок спойлера
index entry, чтоа? — где вы вообще в таком сочетании это встретили? В том смысле который вы вкладываете именно такое сочетание не используется. Это не бурлесоновщина, случаем ?)
Если и у меня плохо с английским, то у вас с логикой тоже как-то не сложилось.
Ну с английским у меня то хоть есть еще шансы)
Что index key != index key entry, как то опять обратное никто и не доказывает. Как раз я о втором. А вы мне все рассказываете про первое.
Еще раз, выше я уточнил что речь идет именно о key entry и выделил жирным (то определение доки, которое вы сочли не правильным ):
If the indexed column in a single row is updated, then the database locks the index key entry (for example, M or F) and not the individual bit mapped to the updated row. Because a key points to many rows, DML on indexed data typically locks all of these rows.
Вот Кайт, использует те же определения:
There is a locking implication by design in bitmap indexes, the keys point to hundreds of rows and if I lock a single key entry in a bitmap index, I've locked the key entry for hundreds of other rows.
В общем я не вижу смысла тут дальше спорить. Там более в таком тоне.
Если вам так будет спать спокойней, могу признать — в моем изначальным посте «содержашихся в этом ключе индекса» было не совсем точным. Пусть будет «содержашихся в этой записи ключа индекса», т.е. locked the index key entry, строго по определению.
Гм… А мне кажется вы все таки путаете index key для b-tree, как значения полей таблицы индекса и index key для bitmap, что несколько иное. Смотрите там же:
In a conventional B-tree index, one index entry points to a single row. In a bitmap index, each index key stores pointers to multiple rows.
Тогда все становится на место. И выглядят логично и ваши неуместные доказательства того, что не все одинаковые значения блокируются (чего никто и не утверждал). И дока оказывается правильной.
Можно добавить, что compile с debug mode отрицательно влияет на производительность psql кода,
ну и в доку заглянуть всегда не мешает (19с) :
Hidden text
https://docs.oracle.com/en/database/oracle/oracle-database/19/lnpls/COMPILE-clause.html#GUID-FB890581-9F65-474B-9D86-6E318110AD5F
DEBUG
Has the same effect as PLSQL_OPTIMIZE_LEVEL=1—instructs the PL/SQL compiler to generate and store the code for use by the PL/SQL debugger. Oracle recommends using PLSQL_OPTIMIZE_LEVEL=1 instead of DEBUG.
Ну да конечно. Обычно, то что на 99% состоит из open source кода называется форк. ИМХО надо гнать в шею таких "импортозамещателей", наследнички bolgenOS и дела Попова)
Ну разве что, PostgresPro еще можно понять, так как они контрибьютор основной ветки.
Обычно ответ - ACID, если ACID требования нет, транзакционность не нужна, тогда да хранить и обрабатывать json в pg - дорого и неэффективно.
Ну не знаю.. Продавать такое как продукт...
Фио перемашать , ака Третьев Первый Вторвович.
Емейлы, телефоны - ну тут понятно простейший генератор. Адреса - есть кладр, или можно также перемешать (города, улицы, дома), если физическое существование не важно. Сохранить в отдельные таблицы, дергать по мере надобности, в нужном кол-ве, при раскатке тест баз, чтоб каждый раз не генерировать.
Статья-то неплохая, спасибо, что делитесь опытом, блок-схемы интересные, но согласен название - муть.
Плюсую. Известно, же как раз что в крупных компаниях наоборот много уровней иерархии инженеров, и высшие имеют большие полномочия в принятии решений, сравнимые в топ менеджерами.
Взять тот же МС, иерархия выглядет примерно так
Junior Software Engineer
Intermediate Software Engineer
Senior Software Engineer
Staff Software Engineer
Senior Staff Software Engineer
Principal Software Engineer
Distinguished Software Engineer
Fellow
Senior Fellow ...
Я думаю, общий посыл статьи правильный, просто диавол как всегда в деталях..
О многом ни слова. Да тема такая огромная, что одной статьей не обойтись.
Но все же, имхо, автор, зря вы с хинтов начинаете.
Начинают разрабы пихать их не к месту после таких статей.
Все таки с основ cost based оптимизации лучше. Дальше, что есть estimated планы ( о которых речь в общем то тут и идет), и реальные.
А как про реальные планы, так тут и статистика , child cursors, hard/soft parse и plan stability( вот тут о хинтах уже можно, наряду с outlines).
Задачу получения консистентного бэкапа всех шардов как решили ?
Кто то еще использует Oracle SE ? Давно работаю с Oracle, не помню когда встречал его последний раз, точно лет 10 прошло. С момента появления enterprise фич в opensorce бд (типа partitioning, HA, incremental backup) уже как то не особо нужен. Кажется этот рынок Oracle давно проиграл.
Спасибо за статью, но осталось несолько вопросов.
Аналитику пернесли, а остальное осталось в PG ? Или это изначально чисто аналитическая БД была ? Если чисто аналитическая, то почему выбрали PG изначально ?
Как загружаете данные в Clickhouse ?
Достаточная сложность, при серьезных ограничениях. Почему не захотели пойти классическим путем : RAC + ASM ? И дискгруппы можно собрать (с необходимым redundancy) с неcкольких СХД и проблем с их resize нет на лету, и под vmware работает. По деньгам не готов утверждать что это не дороже, но знаю, что VCS тоже сильно не дешевый.
Для нагруженных БД перевыбор мастера (slaves в RO, когда один из них выбирается новым мастером, происходит рестарт БД) очень даже заметен.
Эх ребята, все не так, все не так ребята (с)
Вообще в классическом понимании DevOps нет такой роли, есть набор практик, технологий и методологий.
DevOps должны заниматься и админы и разработка и тестирование. Если вы кого-то конкретного (админа, разработчика или тестировщика) в девопс назначаете, такой девопс у вас и получится — однобокий. Что собственно противоречит его сути.
Я давно написал и выделил, что речь именно о key entry.
Давайте теперь еще раз логике:
Речь вроде шла о общей терминологии. Это вы сейчас задним числом исправились, дописали key entry. Раньше вроде было bitmap, bitmap piece, index entry и это в сообщении о общей терминологии. Разве не так? А оказалось key entry — именно это общепринятая терминология( а не bitmap, bitmap piece и не index entry
Как же так:
А получилось что именно key entry? И ошиблись именно вы, со своим никак не key, а не дока и Кайт, как раз которые используют key entry.
Каша у вас с определениями. У самого то получится разобраться ?))
Ну с английским у меня то хоть есть еще шансы)
Что index key != index key entry, как то опять обратное никто и не доказывает. Как раз я о втором. А вы мне все рассказываете про первое.
Еще раз, выше я уточнил что речь идет именно о key entry и выделил жирным (то определение доки, которое вы сочли не правильным ):
Вот Кайт, использует те же определения:
В общем я не вижу смысла тут дальше спорить. Там более в таком тоне.
Если вам так будет спать спокойней, могу признать — в моем изначальным посте «содержашихся в этом ключе индекса» было не совсем точным. Пусть будет «содержашихся в этой записи ключа индекса», т.е. locked the index key entry, строго по определению.
Тогда все становится на место. И выглядят логично и ваши неуместные доказательства того, что не все одинаковые значения блокируются (чего никто и не утверждал). И дока оказывается правильной.