Я далеко не с первого раза понял начальные абзацы, мне кажется, что не хватает пояснений.
В первом абзаце есть вот такое:
Внутристраничная очистка (HOT cleanup) – это оптимизация, благодаря которой старые версии строк могут эффективно удаляться из блоков таблиц. Освобождённое место используется под размещение новой версии строки. Освобождается только место, занимаемое версиями строк, вышедшими за горизонт базы данных (xmin horizon)
Я так понимаю, что это чисто техническая активность по освобождению места в странице, не выполняемая в рамках каких-то транзакций. Причём удаляемые старые версии могли стать таковыми любым способом, например UPDATE создал новую версию строки.
А потом во втором абзаце уже идёт вот такое:
Алгоритм быстрой очистки табличной страницы реализован в файле pruneheap.c (heap page pruning and HOT-chain management code) исходного кода PostgreSQL. При удалении строки в блоке (странице) таблицы удаляющая транзакция проставляет свой номер в заголовок строки в поле xmax и пытается найти место под новую версию строки в том же самом блоке, при этом признак фиксации не проставляется.
Здесь уже, как я понял, речь совсем про другое: удаление строки из таблицы через DELETE в рамках пользовательской транзакции. Как это связано с "быстрой очисткой страницы" - непонятно и не объяснено.
Когда вы говорите, что бит LP_DEAD выставляется, когда index scan обнаружил, что "строка удалена", вы что имеете в виду? Какая-то транзакция могла пометить версию строки как "удалённая", но для параллельно выполняющихся repeatable read транзакций нужно возвращать эту строку, поэтому что-то сомнительно. А если имеется в виду запись, помеченная как "очищенная", тогда понятно.
Неудачная структура статьи: главная часть - это очень базовое объяснение транзакций, которое знакомо мало-мальски работающему с базами данных человеку. Потом перепрыгнули на JOOQ непонятно зачем, про его связь с транзакциями не сказано ничего. И дальше про сохранялку из Kafka. Меня вышибает термин "JDBC коннектор Kafka", я не могу воспринимать это иначе чем нечто, что реализует JDBC-интерфейс для данных, хранящихся в логах Kafka. Оказалось, имелся в виду Kafka Connect, который сливает в базу данные из топиков. Мне кажется, вы в объяснении где-то напутали, и хотели сказать, что read repeatable вам не подошёл, а подошёл read commited. Ну логично, там же только сохранение данных. В конце вы сами пишете, что read commited - уровень по-умолчанию, значит даже у человека, не понимающего в транзакциях, всё бы сработало.
Люди добрые, помогите, пожалуйста? Читал году примерно в 2000-2001 в электронном виде фэнтези-произведение российского автора, забыл и автора и название. Сюжет таков: какого-то принца колдуны отправляют искать "дракона", забрав невесту в заложницы. После множества мощных приключений он попадает в пустыню, "дракон" оказывается летательным аппаратом, герой возвращается и мстит колдунам. По градации автора этой статьи это очень глупое чтение, не попаданство, но абсолютно безыдейное sword and sorcery, без worldbuilding-а, без характеров и без истории. Очень хочется перечитать.
Какие-то советы для начинающих индусов из года примерно 2010. Блог компании OTUS, наш девиз "похер на качество контента, мы берём количеством".
Проблема со склеиванием строк не в том, что память потребляется, память-то выделить очень быстро. Проблема в том, что из старого объекта копируются символы в новый объект, много раз. StringBuilder делает то же самое внутри, когда не хватает буфера. Правильная оптимизация - это прикинуть окончательный размер строки, и передать его в StringBuilder.
Не нужно size() выносить в переменную, компилятор это оптимизирует сам.
Там про смысл написано вполне чётко: кластеризация располагает строки таблицы не в порядке добавления, а в порядке какого-либо индекса, обычно первичного ключа. Очень часто значения первичного ключа формируются самой базой из возрастающей последовательности, поэтому индекс по первичному ключу соответствует порядку добавления. Но Posgres при обновлении строк создаёт их новые версии, поэтому со временем порядок строк на диске будет сильно отличаться от порядка по первичному ключу.
Автор-питонист хотел поджечь Java-жопы, и ему это удалось. При этом пытался немножко выглядеть объективными и профессиональным, но наличие мемасов в статье выдавало Штирлица. А потом в комментах начали поджигать жопу автору. Нравится!
Теперь совсем про другое: про реализацию quicksort на Java, которую автор привёл. Там в partition() два индекса, и для некоторого количества элементов в начале оба индекса будут совпадать, пока эти начальные элементы меньше pivot-а. Представленный алгоритм будет менять элемент самого с собой. В худшем случае, если исходный массив уже отсортирован, будет много лишней работы. Можно добавить if, но он будет напрасно исполняться на том этапе, когда i уже гарантированно меньше j, тоже неприятно.
private static int partition(int[] arr, int low, int high) {
int pivot = arr[high];
int i = low ;
for (int j = low; j < high; j++) {
if (arr[j] <= pivot) {
if (i < j) {
int temp = arr[i];
arr[i] = arr[j];
arr[j] = temp;
}
i++;
}
}
Скажите, Дмитрий, вот я открыл текст статьи на вашей wiki, начинаю скроллить мышкой вниз по полосе прокрутки, и через какое-то время начинается очень неприятное явление: ползунок перестаёт сдвигаться вниз, возвращается назад, из-за чего скроллить очень неудобно. Я догадываюсь, что это какая-то "оптимизация" рендера, но мне, как пользователю, очень не нравится. Браузер Chrome.
Мне кажется, что есть ещё третья ошибка, возникающая при программировании конечных автоматов, от которой спасают акторы. Я называю её "object reentrancy". Суть вот в чём: функция или метод, принимающая событие, должна сделать две вещи: поменять состояние, и выполнить всякие side effect-ы. Представим, что она это делает в таком порядке: сначала выполняет сайд-эффекты, а потом меняет состояние. Если side effect - это синхронный вызов, то в его процессе может породиться новое событие, и в том же потоке выполнения снова вызовется метод, принимающий событие. Но состояние-то осталось старым! Потом эта цепочка начнёт раскручиваться, и состояния начнут обновляться задом наперёд. Mutex-ы не спасут, они обычно позволяют себя повторно захватить потоку, который ими и так уже владеет.
В ООП есть понятие "class invariant". Это нормально, что внутри метода этот инвариант временно ломается, пока это не наблюдаемо извне. Но если метод временно передаёт управление, например в какой-нибудь callback, пока инвариант сломан, то возможна неожиданная жопа. Я с таким сталкивался, когда у меня несколько стейт-машин общались друг с другом.
Поэтому для конечных автоматов есть два варианта: или дисциплина "сначала меняем состояние, потом выполняем остальные действия", или все события только через очередь. Мне больше нравится первый вариант, очень люблю сквозную отладку.
Нормальная история человека, чьё самолюбие настолько велико, что он решил стать самым умным, чтобы все его любили и уважали, после чего он, наконец, смог бы полюбить себя сам. Читать интересно. Главным образом затем, чтобы понимать, как не надо делать. Кошку жалко. Статью плюсанул.
Хотел предложить распространять LookAndFeel отдельно, глянул в исходники, чтобы поглядеть, какие шрифты используются, и понял, что это покрашенный Metal. Ну тоже норм. А можно убрать установку цветов Foreground/Background/Caret/Selection для JTextArea в UIManager?
Ещё посмотрел, как сделана подсветка синтаксиса, увидел regexp-ы. Имеет смысл вынести компиляцию Patter-нов куда-нибудь в конструктор или инициализацию, они же не меняются. И я не увидел паттерн для чисел, а на скриншотах они подсвечены, как это сделано?
Статья очень хорошая. Но у меня есть пара вопросов.
В первом листинге я сначала удивился, зачем вы загружаете значение из AddedThreadCounter сначала в BL, а оттуда в AL, можно же было сразу. Только потом я увидел, что BL используется как параметр в GetSavedSPOffset, сильно ниже по листингу. Неочевидно. И ещё по этому листингу получается, что самый первый элемент в области ThreadStacks не используется, теоретически он под main зарезервирован?
Я далеко не с первого раза понял начальные абзацы, мне кажется, что не хватает пояснений.
В первом абзаце есть вот такое:
Я так понимаю, что это чисто техническая активность по освобождению места в странице, не выполняемая в рамках каких-то транзакций. Причём удаляемые старые версии могли стать таковыми любым способом, например UPDATE создал новую версию строки.
А потом во втором абзаце уже идёт вот такое:
Здесь уже, как я понял, речь совсем про другое: удаление строки из таблицы через DELETE в рамках пользовательской транзакции. Как это связано с "быстрой очисткой страницы" - непонятно и не объяснено.
Когда вы говорите, что бит LP_DEAD выставляется, когда index scan обнаружил, что "строка удалена", вы что имеете в виду? Какая-то транзакция могла пометить версию строки как "удалённая", но для параллельно выполняющихся repeatable read транзакций нужно возвращать эту строку, поэтому что-то сомнительно. А если имеется в виду запись, помеченная как "очищенная", тогда понятно.
Мусорная статья, написанная нейросетью.
А ну хотя чего я удивляюсь, часть про транзакции и заключение писала LLM, а от автора тут только часть про JOOQ и сохранялку из Kafka. Фу так писать.
Занятный троллинг
Неудачная структура статьи: главная часть - это очень базовое объяснение транзакций, которое знакомо мало-мальски работающему с базами данных человеку. Потом перепрыгнули на JOOQ непонятно зачем, про его связь с транзакциями не сказано ничего. И дальше про сохранялку из Kafka. Меня вышибает термин "JDBC коннектор Kafka", я не могу воспринимать это иначе чем нечто, что реализует JDBC-интерфейс для данных, хранящихся в логах Kafka. Оказалось, имелся в виду Kafka Connect, который сливает в базу данные из топиков. Мне кажется, вы в объяснении где-то напутали, и хотели сказать, что read repeatable вам не подошёл, а подошёл read commited. Ну логично, там же только сохранение данных. В конце вы сами пишете, что read commited - уровень по-умолчанию, значит даже у человека, не понимающего в транзакциях, всё бы сработало.
Увидел в названии "философия", заинтересовался, прочитал. Мда, и правда "философия".
Люди добрые, помогите, пожалуйста? Читал году примерно в 2000-2001 в электронном виде фэнтези-произведение российского автора, забыл и автора и название. Сюжет таков: какого-то принца колдуны отправляют искать "дракона", забрав невесту в заложницы. После множества мощных приключений он попадает в пустыню, "дракон" оказывается летательным аппаратом, герой возвращается и мстит колдунам. По градации автора этой статьи это очень глупое чтение, не попаданство, но абсолютно безыдейное sword and sorcery, без worldbuilding-а, без характеров и без истории. Очень хочется перечитать.
Какие-то советы для начинающих индусов из года примерно 2010. Блог компании OTUS, наш девиз "похер на качество контента, мы берём количеством".
Проблема со склеиванием строк не в том, что память потребляется, память-то выделить очень быстро. Проблема в том, что из старого объекта копируются символы в новый объект, много раз. StringBuilder делает то же самое внутри, когда не хватает буфера. Правильная оптимизация - это прикинуть окончательный размер строки, и передать его в StringBuilder.
Не нужно size() выносить в переменную, компилятор это оптимизирует сам.
Там про смысл написано вполне чётко: кластеризация располагает строки таблицы не в порядке добавления, а в порядке какого-либо индекса, обычно первичного ключа. Очень часто значения первичного ключа формируются самой базой из возрастающей последовательности, поэтому индекс по первичному ключу соответствует порядку добавления. Но Posgres при обновлении строк создаёт их новые версии, поэтому со временем порядок строк на диске будет сильно отличаться от порядка по первичному ключу.
Автор-питонист хотел поджечь Java-жопы, и ему это удалось. При этом пытался немножко выглядеть объективными и профессиональным, но наличие мемасов в статье выдавало Штирлица. А потом в комментах начали поджигать жопу автору. Нравится!
Теперь совсем про другое: про реализацию quicksort на Java, которую автор привёл. Там в partition() два индекса, и для некоторого количества элементов в начале оба индекса будут совпадать, пока эти начальные элементы меньше pivot-а. Представленный алгоритм будет менять элемент самого с собой. В худшем случае, если исходный массив уже отсортирован, будет много лишней работы. Можно добавить if, но он будет напрасно исполняться на том этапе, когда i уже гарантированно меньше j, тоже неприятно.
Прямо даже не знаю, хоть два цикла делай.
Ужасно. Один из абзацев присутствует в двух местах. Ничего толкового про кодировки не написано.
Скажите, Дмитрий, вот я открыл текст статьи на вашей wiki, начинаю скроллить мышкой вниз по полосе прокрутки, и через какое-то время начинается очень неприятное явление: ползунок перестаёт сдвигаться вниз, возвращается назад, из-за чего скроллить очень неудобно. Я догадываюсь, что это какая-то "оптимизация" рендера, но мне, как пользователю, очень не нравится. Браузер Chrome.
Мне кажется, что есть ещё третья ошибка, возникающая при программировании конечных автоматов, от которой спасают акторы. Я называю её "object reentrancy". Суть вот в чём: функция или метод, принимающая событие, должна сделать две вещи: поменять состояние, и выполнить всякие side effect-ы. Представим, что она это делает в таком порядке: сначала выполняет сайд-эффекты, а потом меняет состояние. Если side effect - это синхронный вызов, то в его процессе может породиться новое событие, и в том же потоке выполнения снова вызовется метод, принимающий событие. Но состояние-то осталось старым! Потом эта цепочка начнёт раскручиваться, и состояния начнут обновляться задом наперёд. Mutex-ы не спасут, они обычно позволяют себя повторно захватить потоку, который ими и так уже владеет.
В ООП есть понятие "class invariant". Это нормально, что внутри метода этот инвариант временно ломается, пока это не наблюдаемо извне. Но если метод временно передаёт управление, например в какой-нибудь callback, пока инвариант сломан, то возможна неожиданная жопа. Я с таким сталкивался, когда у меня несколько стейт-машин общались друг с другом.
Поэтому для конечных автоматов есть два варианта: или дисциплина "сначала меняем состояние, потом выполняем остальные действия", или все события только через очередь. Мне больше нравится первый вариант, очень люблю сквозную отладку.
Господа, каламбурчик:
Извините
Нормальная история человека, чьё самолюбие настолько велико, что он решил стать самым умным, чтобы все его любили и уважали, после чего он, наконец, смог бы полюбить себя сам. Читать интересно. Главным образом затем, чтобы понимать, как не надо делать. Кошку жалко. Статью плюсанул.
Очень неплохо!
Хотел предложить распространять LookAndFeel отдельно, глянул в исходники, чтобы поглядеть, какие шрифты используются, и понял, что это покрашенный Metal. Ну тоже норм. А можно убрать установку цветов Foreground/Background/Caret/Selection для JTextArea в UIManager?
Ещё посмотрел, как сделана подсветка синтаксиса, увидел regexp-ы. Имеет смысл вынести компиляцию Patter-нов куда-нибудь в конструктор или инициализацию, они же не меняются. И я не увидел паттерн для чисел, а на скриншотах они подсвечены, как это сделано?
Спасибо за наводку, неплохая игра. Скачал демку, прошёл. На первом уровне все секреты нашёл, на втором два не смог расковырять. Зато вот что нашёл:
Совет 0: не вставлять свою фотографию как картинку к статье, аудитория заподозрит, что технического содержимого нет, только самореклама.
Как жаль, что статья не соответствует этим критериям.
С чего бы?
Статья очень хорошая. Но у меня есть пара вопросов.
В первом листинге я сначала удивился, зачем вы загружаете значение из AddedThreadCounter сначала в BL, а оттуда в AL, можно же было сразу. Только потом я увидел, что BL используется как параметр в GetSavedSPOffset, сильно ниже по листингу. Неочевидно. И ещё по этому листингу получается, что самый первый элемент в области ThreadStacks не используется, теоретически он под main зарезервирован?