А мне про сеньоров и джунов вспомнилось описание ожиданий от уровней разработчиков в одной крупной конторе. Там у сеньоров появлялось требование понимать, когда они не справятся. Джуны там могли браться за что угодно, а вот сеньоры должны иногда говорить - не смогу. Правда там были еще принципалы, которые могли помочь - но так как навыки каждого следующего уровня включали предыдущий, они получается тоже должны были понимать свои ограничения и иногда говорить - не потянем.
Не нужны специальные счетчики. Я предлагаю просто в коде функции которая спускается по дереву в поисках нужного элемента (и входит в бесконечный цикл) завести локальную переменную и считать число итераций.
Там видимо лёгкий ионизатор, для очистки воздуха электростатикой, без сменного фильтра. Появление ионов в воздухе побочный эффект, а не цель. Но как верно выше пишут - это гомеопатия, обычный очиститель воздуха будет на порядки эффективнее.
В соответствие с ГОСТ 12.1.007-76 и 12.1.005-88 озон является веществом первого класса опасности..., требующим автоматического контроля за его содержанием в воздухе, предельно допустимая концентрация (ПДК) озона в воздухе 0,1 мг/м3.
В США норма ещё вдвое меньше, 0,070 частей на миллион.
1 к 10000 это не расчет, а минимальное требование NASA к вероятности нанесения ущерба человеку в случае неконтролируемого спуска, или в случае проблем с контролируемым.
Не так много способов реально что-то поломать - надо уметь либо вызывать произвольный код, либо записывать данные по произвольным адресам. Это VM не даёт, первое проверками типов, второе опять же проверкой типов, плюс проверкой границ массивов. Ну и GC который гарантирует что все указатели остаются валидными, часто за счет замораживания кода на время исполнения.
В результате вы можете писать любой бред, но лишь в пользовательские структуры данных, и лишь если с типами всё в порядке. Программа не падает, но исключения бросает, и в пользовательских структурах может быть что угодно.
На С++ может упасть как угодно: access violation, переписать чужую память, вызвать левый код, отформатировать корневой каталог. На Java гарантируется безопасность на уровне виртуальной машины, ничего перечисленного выше быть не может. Но от ошибок на более высоком уровне структур данных это уже никак не защищает. Создать зацикленные ссылки внутри того что должно быть деревом - с точки зрения VM совершенно нормально, она про структуру деревьев ничего не гарантирует. Это имхо в статье самое интересное, автор разобрался как и что именно происходит.
Есть гораздо более дешёвый способ выкидывать ConcurrentModificationException почти в тех же случаях - просто считать число итераций, и сравнивать с ожидаемой глубиной дерева на основе size. Тоже никаких гарантий, как и с посещенными узлами, но поможет находить ошибку.
А если экономить память - то я бы первым делом избавился от syncarr и использовал Interlocked.CompareExchange чтобы достать элемент arr, и использовал бы уже маленький массив как объект синхронизации.
// печально, но нужны объекты синхронизации. Возможно, тут надо придумать что-то более элегантное.
object[] syncarr = new object[arr.Length];
Для это есть System.Collections.Concurrent, скажем ConcurrentQueue<T>.
Но если есть память, то возможно лучше вообще без синхронизации - каждый поток может вставлять в свою версию arr, а потом при сортировке каждый поток уже работает со своим срезом всех этих массивов. Тогда потоки вообще не конкурируют.
То есть базе данных придется сначала определить, подходит ли распределение данных под этот алгоритм, а потом уже его применять :)
А ещё в базах данных чаще всего данные не подходят. Скажем, сортируете по адресам, а там условно по одному Архангельску и Якутску, и тысяча записей Москва. То есть максимально не похоже на строки стопроцентной хаотичности, используемые здесь для тестов.
Ну и ещё, вам не надо делать заявленный выбор между BigQuery или Iceberg, можно использовать Iceberg таблицы из BigQuery, оно умеет с ними работать напрямую.
Ну ещё немного стоило бы разобраться в деталях того о чем пишете, чтобы не было чуши вроде
применение Z-Order, особенно для колонок с высокой кардинальностью
Z-order применяется для многомерных данных, когда надо отфильтровать либо сразу по нескольким признакам, либо то по одному, то по другому. Что включает упомянутые географические данные, но делает бессмысленным приведенный пример - он будет гарантированно медленнее распределения только по user_id.
Я бы был аккуратнее с терминами, может тогда статью поняли бы больше читателей, и меньше флейма было бы в комментариях. Скажем,
появляется Apache Iceberg — файловый формат
Все его называют табличным форматом, а не файловым. Низкоуровневый файловый формат как раз не изменился, данные лежат в тех же самых Parquet. Вот над этими файлами появился формат таблиц, описывающий метаданные, схему, версии, и так далее.
А мне про сеньоров и джунов вспомнилось описание ожиданий от уровней разработчиков в одной крупной конторе. Там у сеньоров появлялось требование понимать, когда они не справятся. Джуны там могли браться за что угодно, а вот сеньоры должны иногда говорить - не смогу. Правда там были еще принципалы, которые могли помочь - но так как навыки каждого следующего уровня включали предыдущий, они получается тоже должны были понимать свои ограничения и иногда говорить - не потянем.
Не нужны специальные счетчики. Я предлагаю просто в коде функции которая спускается по дереву в поисках нужного элемента (и входит в бесконечный цикл) завести локальную переменную и считать число итераций.
Там видимо лёгкий ионизатор, для очистки воздуха электростатикой, без сменного фильтра. Появление ионов в воздухе побочный эффект, а не цель. Но как верно выше пишут - это гомеопатия, обычный очиститель воздуха будет на порядки эффективнее.
В соответствие с ГОСТ 12.1.007-76 и 12.1.005-88 озон является веществом первого класса опасности..., требующим автоматического контроля за его содержанием в воздухе, предельно допустимая концентрация (ПДК) озона в воздухе 0,1 мг/м3.
В США норма ещё вдвое меньше, 0,070 частей на миллион.
Классный разбор. Только местами микросекунды названы миллисекундами. Скажем
Мне почему-то вспомнилось как лет 15 назад он оптимизировал компьютер для дайвинга, сломал copy / paste в Линуксовом терминале.
Это может сделать пользователь.
А я по то как библиотека может помочь этому пользователю найти проблему и понять что надо синхронизироваться.
Тут перевод немного смешал вероятности.
1 к 10000 это не расчет, а минимальное требование NASA к вероятности нанесения ущерба человеку в случае неконтролируемого спуска, или в случае проблем с контролируемым.
Не так много способов реально что-то поломать - надо уметь либо вызывать произвольный код, либо записывать данные по произвольным адресам. Это VM не даёт, первое проверками типов, второе опять же проверкой типов, плюс проверкой границ массивов. Ну и GC который гарантирует что все указатели остаются валидными, часто за счет замораживания кода на время исполнения.
В результате вы можете писать любой бред, но лишь в пользовательские структуры данных, и лишь если с типами всё в порядке. Программа не падает, но исключения бросает, и в пользовательских структурах может быть что угодно.
На С++ может упасть как угодно: access violation, переписать чужую память, вызвать левый код, отформатировать корневой каталог. На Java гарантируется безопасность на уровне виртуальной машины, ничего перечисленного выше быть не может. Но от ошибок на более высоком уровне структур данных это уже никак не защищает. Создать зацикленные ссылки внутри того что должно быть деревом - с точки зрения VM совершенно нормально, она про структуру деревьев ничего не гарантирует. Это имхо в статье самое интересное, автор разобрался как и что именно происходит.
Так это же намеренно некорректный код показывающий что может случиться при неправильном использовании, на всех языках.
Есть гораздо более дешёвый способ выкидывать ConcurrentModificationException почти в тех же случаях - просто считать число итераций, и сравнивать с ожидаемой глубиной дерева на основе size. Тоже никаких гарантий, как и с посещенными узлами, но поможет находить ошибку.
А если экономить память - то я бы первым делом избавился от syncarr и использовал Interlocked.CompareExchange чтобы достать элемент arr, и использовал бы уже маленький массив как объект синхронизации.
Для это есть System.Collections.Concurrent, скажем ConcurrentQueue<T>.
Но если есть память, то возможно лучше вообще без синхронизации - каждый поток может вставлять в свою версию arr, а потом при сортировке каждый поток уже работает со своим срезом всех этих массивов. Тогда потоки вообще не конкурируют.
То есть базе данных придется сначала определить, подходит ли распределение данных под этот алгоритм, а потом уже его применять :)
А ещё в базах данных чаще всего данные не подходят. Скажем, сортируете по адресам, а там условно по одному Архангельску и Якутску, и тысяча записей Москва. То есть максимально не похоже на строки стопроцентной хаотичности, используемые здесь для тестов.
Это первичный фильтр, но на другое: лояльность новой администрации и лично Маску. Кто первым опишется, тот молодец, а содержание не важно.
15% это в номинальных рублях, без учёта инфляции? LOL
Ну и ещё, вам не надо делать заявленный выбор между BigQuery или Iceberg, можно использовать Iceberg таблицы из BigQuery, оно умеет с ними работать напрямую.
Ну ещё немного стоило бы разобраться в деталях того о чем пишете, чтобы не было чуши вроде
Z-order применяется для многомерных данных, когда надо отфильтровать либо сразу по нескольким признакам, либо то по одному, то по другому. Что включает упомянутые географические данные, но делает бессмысленным приведенный пример - он будет гарантированно медленнее распределения только по user_id.
Я бы был аккуратнее с терминами, может тогда статью поняли бы больше читателей, и меньше флейма было бы в комментариях. Скажем,
Все его называют табличным форматом, а не файловым. Низкоуровневый файловый формат как раз не изменился, данные лежат в тех же самых Parquet. Вот над этими файлами появился формат таблиц, описывающий метаданные, схему, версии, и так далее.