В классических проектах на 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.
Тогда все становится на место. И выглядят логично и ваши неуместные доказательства того, что не все одинаковые значения блокируются (чего никто и не утверждал). И дока оказывается правильной.
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.
Именно key entry, а не bitmap piece и не index entry. Так что не такая она и общая, ваша терминология)
Предложите лучше перевод — я не против.
Погодите товарищ, шашкой махать, похоже вы просто не внимательно прочитали. Я говорю о том же, обратите внимание на разницу — «заблокируютя все строки содержащиеся в этом ключе индекса» (т.е. в данном случае битмап ключе, а не значении поля) и «заблокируются все строки с этим же значением столбца». У меня ощущение что вы опровергаете как раз второе. Вот простой и понятный пример у Кайта, как блокировки относятся с бимап ключом: Bitmap indexes and locking
НИЗКИЙ DML таблицы — использование вставки/обновления/удаления должно быть низком. На обновление bitmap-индексов требуется много ресурсов, поэтому они лучше подходят для таблиц, доступных только для чтения, и таблиц, пакетно обновляемых каждую ночь;
вы уж договаривайте до конца. Требуется много ресурсов — это, мягко говоря, не точно сказано. При изменении строки, накладывается блокировка на изменение всех(!) строк таблицы, содержащихся в этом ключе битмап индекса. И никак с количеством ресурсов это связано.
Автор, иди ка ты в… гугл, и почитай про этот термин):
Термин «токсичные сотрудники» впервые появляется в статье Майкла Хаусмана и Дилана Майнара, опубликованной в 2015 году в Harvard Business Review. Авторы описывают новый термин, основываясь на более ранних исследованиях психологических типов работников: от «звезд», приносящих организации множество бонусов, до тех, кто вредит своим поведением рабочему процессу. Главной особенностью в трактовке нового термина является тот факт, что токсичные сотрудники не просто вредят рабочему процессу, но и демотивируют весь коллектив, заражая его негативными эмоциями.
Токсичность не определяется грубостью или наоборот излишней вежливостью и обходительностью. И то и то может быть токсичным, если вредит рабочей атмосфере.
+1, да и то не всегда. Перегрузить проект на начальных этапах лишним менеджментом, может дать обратный эффект. Никаких ПМов за плечами Цукерберга, Гейтса, Лари Эллисона не стояло, когда они начинали пилить свои решения «в гаражах») И ничего справились.
Роль ПМ в данном случае, состоит в четкой организации процесса выполнения проекта. От написания ТЗ, которое не будет изменено более чем на 10% от момента старта разработки,
Что? Что за метрика такая 10%? Да здравствует ватерфолл? Типичный пример бессмысленной метрики «эффективного» менеджера.
Ээмм… да как-бы плюс-минус все.
Реляционная алгебра — без комментариев.
Многие nosql не поддерживают ACID(или поддерживает частично), какие уж тут redo(aka wal), да undo.
B-tree тоже скорей исключение для мира nosql, тут скорей актуальней hash table
У разных БД разные литературные «классики») Например, каждый Ораклист знает кто такие Том Кайт и Джонатан Льюис) Думаю, правильней сразу искать литературу по нужной субд, общие аспекты там тоже рассмотрены, а дьявол он как обычно в деталях. Может вы вообще Nosql хотите)
Кстати, название у статьи слишком общее — как минимум, не хватает слово реляционным, а иначе будут немного другие советы.
Уже была статья про Delphix — habr.com/company/croc/blog/316908
Delhix, по сути, обвязка над снапшотами. А минусы снапшотов мы все знаем: растущая дельта при росте изменений, как следствие невозможность хранить его продолжительное время; размазанная нагрузка — т.к. одни и те же блоки на диске могут использоваться разными снапами. Идеального решения не существует. Имхо, самый гибкий и правильный путь — использование и сабсеттинга и снапшотов (и полных клонов), и комбинации их — снапшотов с сабсеттнинг клонов.
Тоже решал задачу мониторинга PG. Остановился на pgwatch2 github.com/cybertec-postgresql/pgwatch2. Очень советую, особенно если много серверов. Собирает централизованно в свою БД (InfluxDB), готовые модули для Grafana, удобно и красиво.
Вендоры хотят кушать и хотят кушать всегда. Вдруг компания будет сидеть n лет на 1них серверах, и не захочет i7 менять на новый i7+, старое ПО на новое ПО+, где они затратились на новые свистелки. На облаках вы то денюжки им постоянно несете.
Облака иногда полезны, но надо уметь считать, и считать хорошо, чтобы понять, где вам будет выгоднее переезд на другие железки у дяди, которые делает тоже самое что и вы, но еще свою маржу будет с вас иметь.
Иии… что там должно чем отличатся?
Вы правда про запрос по одной row спрашиваете (я напомню кортеж (с1, с2) уникален).
Мм, в случае уникальности (с1, с2) пожалуй, скорей всего, вы правы. Тогда это не совсем понял ваш пример. Почему индекс по (с1, с2, c3, c4) в вашем примере не уникальный, если кортеж c1, c2 уникален?
Эх ребята, все не так, все не так ребята (с)
Вообще в классическом понимании 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, строго по определению.
Тогда все становится на место. И выглядят логично и ваши неуместные доказательства того, что не все одинаковые значения блокируются (чего никто и не утверждал). И дока оказывается правильной.
Конечно Julian Duke авторитетный автор, но предлагаю все таки заглянуть в документацию:
docs.oracle.com/cd/E11882_01/server.112/e40540/indexiot.htm#CNCPT1182
Именно key entry, а не bitmap piece и не index entry. Так что не такая она и общая, ваша терминология)
Предложите лучше перевод — я не против.
вы уж договаривайте до конца. Требуется много ресурсов — это, мягко говоря, не точно сказано. При изменении строки, накладывается блокировка на изменение всех(!) строк таблицы, содержащихся в этом ключе битмап индекса. И никак с количеством ресурсов это связано.
Токсичность не определяется грубостью или наоборот излишней вежливостью и обходительностью. И то и то может быть токсичным, если вредит рабочей атмосфере.
Что? Что за метрика такая 10%? Да здравствует ватерфолл? Типичный пример бессмысленной метрики «эффективного» менеджера.
Реляционная алгебра — без комментариев.
Многие nosql не поддерживают ACID(или поддерживает частично), какие уж тут redo(aka wal), да undo.
B-tree тоже скорей исключение для мира nosql, тут скорей актуальней hash table
Кстати, название у статьи слишком общее — как минимум, не хватает слово реляционным, а иначе будут немного другие советы.
Delhix, по сути, обвязка над снапшотами. А минусы снапшотов мы все знаем: растущая дельта при росте изменений, как следствие невозможность хранить его продолжительное время; размазанная нагрузка — т.к. одни и те же блоки на диске могут использоваться разными снапами. Идеального решения не существует. Имхо, самый гибкий и правильный путь — использование и сабсеттинга и снапшотов (и полных клонов), и комбинации их — снапшотов с сабсеттнинг клонов.
Тут, судя по запятым, как и я — это сотрудница банка, а не как я — это решившая переехать в Канаду.
Облака иногда полезны, но надо уметь считать, и считать хорошо, чтобы понять, где вам будет выгоднее переезд на другие железки у дяди, которые делает тоже самое что и вы, но еще свою маржу будет с вас иметь.
Мм, в случае уникальности (с1, с2) пожалуй, скорей всего, вы правы. Тогда это не совсем понял ваш пример. Почему индекс по (с1, с2, c3, c4) в вашем примере не уникальный, если кортеж c1, c2 уникален?
Подумайте как запрос вида
Будет вести себя с
и с