Существует ли корреляция между индексом INLINE_SIZE и данными столбца индекса (тип строки) в Apache Ignite?
Существует ли корреляция между индексом INLINE_SIZE и данными столбца индекса (тип строки) в Apache Ignite?
В следующей ситуации, когда я вставляю данные, возникает исключение, связанное с отсортированным индексом, появляется сообщение о блокировке/разблокировке, и узел отключается.
Чистая память
PK_INLINE_SIZE=2000,AFFINITY_INLINE_SIZE=200 (с использованием SQL With)
Создано 3 столбца типа varchar в качестве первичного ключа.
Apache Ignite 2.16.0 (H2 DB Engine, я тестировал Calcite DB Engine, та же проблема)
Таблица имеет 20 столбцов (все типы varchar)
Исключение произошло в
Когда я наблюдал соответствующие переменные с помощью отладчика, значение p.rootlvl продолжало увеличиваться (исключение возникает при p.btmlvl=129, p.rootlvl=129).
Когда для PK_INLINE_SIZE было установлено значение 200, значение p.rootlvl не увеличивалось так сильно, как раньше.
Что происходит с созданием индексного b+дерева, которое вызывает блокировку страниц и приводит к отключению узла?
С другими наборами данных этого не происходит. Но я могу воспроизвести ту же ситуацию для конкретного набора данных (совместное использование набора данных невозможно...)
Я пытаюсь понять код, но может ли кто-нибудь помочь...?
протестировано с использованием разных наборов данных
набор данных, вызывающий проблему, содержит специальные символы, поэтому я попытался удалить их.
изменил размер столбца PK на фиксированный (archer -> varchar(2000)
сделал ПК колонки 3 на 2 но. такой же....
Мне трудно поделиться тем, что вы сказали, потому что я не на месте, поэтому я надеюсь, что вы понимаете.
Ответы 1
Причина в том, что встроенный размер вашего индекса слишком велик. В настоящее время Ignite слишком либерален и допускает неправильную настройку. В случае такой конфигурации возможно, что b+tree разложится на слишком много слоев и столкнется с внутренними проверками, с которыми вы столкнулись (внутренний предел глубины равен 128). Есть билет для улучшения проверки и регистрации.
Проблема в том, что страница может содержать только один большой элемент. Все встроенные элементы имеют одинаковый размер и помещаются на одной странице каждый. Для некоторых наборов данных это приводит к очень быстрому сбою — например, при попытке вставить лексикографически отсортированные (или даже «почти» отсортированные) строки. Это также зависит от нескольких факторов, влияющих на макет страницы, например. ТДЭ. Это не ваш случай, у вас чистый In-Memory.
Вам нужно уменьшить размер встроенного индекса , чтобы сделать его более разумным. Если вам действительно нужно, чтобы это было так, подумайте об увеличении размера страницы.
Поделитесь полной трассировкой стека исключений, схемой таблицы и фрагментом кода, который вставляет данные. В идеале добавить репродуктор.