Автоматическое увеличение составного ключа Oracle (Уменьшение !?)

Question

У меня есть относительно большая таблица (~ 100 м записей), которая в основном является хранилищем XML. Может быть несколько документов XML с разными временными метками (с логикой, что последняя метка времени = самая последняя версия). Мы ожидаем ежемесячные пакеты обновленных данных, возможно, с новыми версиями ~ 70% данных.

Мы планируем хранить в магазине только самые последние 2-3 версии, поэтому я предполагаю, что наш текущий индекс b-дерева (идентификатор записи, отметка времени) не обязательно самый быстрый? Простой запрос "select * from table, где timestamp> = yyyy-mm-dd по идентификатору записи, timestamp" завершился вчера вечером - довольно высокотехнологичный комплект, и я не думаю, что кто-то другой использовал БД в самый раз.

(что касается самого запроса, в идеале я хочу выбрать только самый последний документ с отметкой времени> = гггг-мм-дд, но это пока не проблема).

Можно ли как-нибудь создать столбец авто- декремента следующим образом:

Record ID   Timestamp    Version   XML
1           2011-10-18   1         <...>
1           2011-10-11   2         <...>
1           2011-10-04   3         <...>
2           2011-10-18   1         <...>
2           2011-10-11   2         <...>

и т. Д., Т. Е. По мере появления новой версии, самая последняя отметка времени = версия 1, а все старые записи получают версию = версия + 1. Таким образом, мои служебные сценарии могут быть простыми: «Удалить, где версия> 3 "(или что мы решили оставить), и у меня может быть индекс b-дерева для идентификатора записи и двоичный индекс для версии?

Надеюсь, я не лаю совсем не на то дерево - все утро "творчески гуглюл", и это теория, которую я выдвинул ...

Answer 1

Пакетная работа определенно отличается от типичного подхода вставки / обновления (особенно если задействованы триггеры или много индексов).Даже с приличными дисками / оборудованием вы обнаружите, что традиционный подход DML очень медленен с этим томом.Для таблиц 100 мм +, где вы обновляете пакет 70 мм каждый месяц, я бы посоветовал рассмотреть подход, подобный следующему:

1. Загрузить новый пакетный файл (70 мм) в отдельную таблицу (NEW_XML)в том же формате, что и существующая таблица (EXISTING_XML).Используйте nologging, чтобы избежать отмены.

2. Добавление (nologging) записей из EXISTING_XML, которых нет в NEW_XML (30-миллиметровые записи, в зависимости от того, какие ключи вы уже используете).

3. Переименуйте EXISTING_XML в HISTORY_XML и NEW_XML в EXISTING_XML.Здесь вам понадобится некоторое время простоя, возможно, в нерабочее время на выходных.Это не займет много времени, но вам понадобится время для следующего шага (и из-за недействительности объекта).Если у вас уже есть HISTORY_XML за предыдущий месяц, обрежьте и сначала отбросьте его (сохраните данные за 1 месяц).

4. Постройте индексы, статистику, ограничения и т. Д. Для EXISTING_XML (который теперь содержитновые данные, а также).Перекомпилируйте любые недействительные объекты, используйте ведение журнала и т. Д.

Итак, в двух словах, у вас будет таблица (EXISTING_XML), которая не только содержит новые данные, но и была построена относительно быстро (во много раз быстрее, чем DML / триггерный подход).Кроме того, вы можете попробовать использовать параллель для шага 2, если это необходимо.

Надеюсь, это поможет.

Answer 2

Я не уверен, что уменьшение версии было бы хорошей идеей. Единственный способ сделать это - с помощью триггеров искать совпадающие идентификаторы записей и обновлять их соответствующим образом. Это не было бы здорово для производительности ..

Это то, как я делаю что-то похожее в нашей среде баз данных (которая имеет такой же размер). Надеюсь, это полезно:

Создайте отдельную архивную таблицу, в которой будут храниться все версии ваших записей. Это будет заполнено триггером при вставке в вашу основную таблицу. Триггер будет insert текущей версией записи в вашем архиве и update записью в основной таблице, увеличивая номер версии и обновляя отметку времени и данные.

Затем, когда вам нужно только выбрать последнюю версию всех записей, вы просто делаете:

SELECT * FROM TABLE;

Если вам нужна возможность просматривать «снимки» того, как данные выглядели в данный момент времени, вам также понадобятся столбцы valid_from и valid_to в таблице для записи времени, в которое каждая версия записи были последние версии. Вы можете заполнить их с помощью триггеров при записи в таблицу архива ..

Valid_to в последней версии записи может быть установлена ​​максимальная доступная дата. Когда вставляется более новая версия записи, вы должны обновить valid_to предыдущей версии, чтобы она была незадолго до valid_from новой записи (это не то же самое, чтобы избежать ошибок).

Затем, когда вы хотите увидеть, как ваши данные выглядели в данный момент времени, вы запрашиваете архивную таблицу, используя SQL, например:

SELECT *
FROM ARCHIVE_TABLE a
WHERE <time you're interested in> BETWEEN a.valid_from AND a.valid_to