Nano Hash - криптовалюты, майнинг, программирование

Проблема с созданием организованной по индексу таблицы

У меня странная проблема с таблицей, организованной по индексу. Я использую стандарт Oracle 11g.

у меня есть таблица src_table

SQL> desc src_table;
 Name            Null?    Type
 --------------- -------- ----------------------------
 ID     NOT NULL   NUMBER(16)
 HASH       NOT NULL   NUMBER(3)
 ........

SQL> select count(*) from src_table;
  COUNT(*)
----------
  21108244

теперь давайте создадим еще одну таблицу и скопируем 2 столбца из src_table

set timing on
SQL> create table dest_table(id number(16), hash number(20), type number(1));
Table created.
Elapsed: 00:00:00.01

SQL> insert /*+ APPEND */ into dest_table (id,hash,type) select id, hash, 1 from src_table;
21108244 rows created.
Elapsed: 00:00:15.25

SQL> ALTER TABLE dest_table ADD ( CONSTRAINT dest_table_pk PRIMARY KEY (HASH, id, TYPE));
Table altered.
Elapsed: 00:01:17.35

Oracle потребовалось ‹ 2 мин.

теперь то же упражнение, но с таблицей IOT

SQL> CREATE TABLE dest_table_iot (
       id     NUMBER(16) NOT NULL,
       hash  NUMBER(20) NOT NULL,
       type  NUMBER(1)  NOT NULL,
       CONSTRAINT dest_table_iot_PK PRIMARY KEY (HASH, id, TYPE)
    ) ORGANIZATION INDEX;

Table created.
Elapsed: 00:00:00.03

SQL> INSERT /*+ APPEND */ INTO dest_table_iot (HASH,id,TYPE)
    SELECT  HASH, id, 1 
    FROM src_table; 

«вставка» в IOT занимает 18 часов !!! Я пробовал это на двух разных экземплярах Oracle, работающих на win и linux, и получил одинаковые результаты.

Что здесь происходит ? Почему так долго?

25.03.2010

Ответы:


1

Подсказка APPEND полезна только для таблицы, организованной в куче.

Когда вы вставляете в IOT, я подозреваю, что каждая строка должна быть вставлена ​​​​в реальную структуру индекса отдельно, что приводит к повторной балансировке индекса.

Когда вы строите индекс в таблице кучи, используется временный сегмент, и я предполагаю, что это позволяет уменьшить накладные расходы на повторную балансировку, которые в противном случае имели бы место.

Я подозреваю, что если бы вы создали пустую таблицу, организованную в куче, с первичным ключом и сделали ту же вставку без подсказки APPEND, это заняло бы больше 18 часов.

Вы можете попробовать поместить ORDER BY в свой SELECT и посмотреть, как это повлияет на производительность вставки в IOT. Ни в коем случае не гарантируется улучшение, но оно может быть.

25.03.2010
  • @ Дэйв. Вы совершенно правы. После добавления предложения order by для оператора select (тот же порядок, что и для первичного ключа таблицы IOT) создание таблицы IOT заняло 2 минуты. Спасибо. 25.03.2010
  • Новые материалы

    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..

    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..

    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..

    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..

    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..

    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..

    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..