Поиск VSAM VS Поиск/цикл COBOL

У меня есть файл, который может содержать около 3 миллионов записей. Некоторые записи в этом файле необходимо обновлять несколько раз во время выполнения программы. Если мне нужно извлечь определенные записи из этого файла, что из следующего более эффективно:

  1. Индексированный поиск VSAM
  2. Индексированный плоский файл с поиском COBOL по всем
  3. Буферизация всех данных в рабочее хранилище и написание цикла для обработки поиска

person SaggingRufus    schedule 24.06.2016    source источник
comment
У вас уже есть несколько хороших советов в двух ответах. Однако какой-либо конкретный ответ на ваш вопрос неясен, так как недостаточно подробностей. Необычно обновлять одну и ту же запись KSDS более одного раза из одной и той же пакетной программы. Вам не хватает совпадения двух файлов, когда у вас есть оба набора данных в одном и том же ключевом порядке, и вы читаете их пошагово. При довольно низком уровне обращений в KSDS (даже без обновлений) это может быть выходом. Но... знайте, что ваши данные незаменимы. Плохой код/плохая идея — обычная проблема с производительностью.   -  person Bill Woodger    schedule 25.06.2016


Ответы (2)


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

Но будьте очень осторожны при рассмотрении «скрытого дискового ввода-вывода», вызванного подсистемой подкачки виртуальной памяти! Если запрошенные данные "в памяти" на самом деле не находятся "в памяти", произойдет ошибка страницы, и ваш процесс остановится до тех пор, пока страница не будет получена. (А если происходит «кража страницы», то у вас проблемы. Ваша стратегия «в памяти» только что превратилась в, возможно, очень неэффективную (!) стратегию на основе диска. Если ключи распределяются случайным образом, значит, ваш процесс гигантский рабочий набор, к которому он обращается случайно. Если вся эта память на самом деле не находится в памяти, и останется там , у вас проблемы.

Если вы обновляете большой файл, рассмотрите возможность сортировки дельта-файла обновлений перед его обработкой, чтобы все вхождения одного и того же ключа были рядом. Теперь вы можете написать свою программу на языке COBOL, чтобы воспользоваться этим преимуществом (и, конечно же, abend, если когда-либо будет обнаружена запись с нарушением последовательности!). Если ключ в "этой" записи идентичен ключу "предыдущего", то запись перечитывать не нужно. (И на самом деле вам не нужно записывать старую запись, пока ключ не изменится.) Поскольку метод доступа к индексированному файлу представлен последовательностью ключей, каждый ключ, скорее всего, будет " близко к запрошенной ранее, так что некоторые из необходимых страниц индексного дерева уже будут в памяти. Очевидно, вам нужно будет сравнить это, но количество времени, затраченное на сортировку файла, может быть намного меньше, чем количество времени, затраченное на поиск по индексу. (Что на самом деле может быть значительным.)

person Mike Robinson    schedule 24.06.2016
comment
Просто для информации: в z/OS (ОС, используемая OP) есть системная служба, которая позволяет исправлять страницы. Очевидно, что это нужно использовать только разумно (в ключевом порядке, логически или физически). Это простой ВЫЗОВ из программы COBOL. Это теория. Практика такова, что не делайте этого, не сообщив об этом техническим специалистам. Но возможно. - person Bill Woodger; 25.06.2016

В ответе Майка есть важный вопрос о «скрытом вводе-выводе» (зависит от машины, конфигурации, объема данных)...

Если вам, скорее всего, нужно обновить много записей, вариант, предложенный Майком, является наиболее полезным.

Если вам, скорее всего, нужно обновить не так много записей (я думаю, вы, вероятно, ниже 2%), другой подход может быть намного быстрее (нужен тест!):

  • прочитать каждый ключ через индексированный поиск VSAM
  • сохранить измененную запись в памяти (большая таблица событий), если вы измените только некоторые значения, а запись довольно большая, сохраните только все возможные измененные значения + ключ в таблице без фактического REWRITE
  • перед выполнением поиска VSAM: посмотрите в таблице событий, если вы уже прочитали ключ, возьмите значения либо оттуда, либо получите новый
  • ...
  • в конце программы: просмотрите ваши события и REQRITE все записи (если у вас есть полная запись, достаточно REWRITE, иначе вам понадобится READ, чтобы получить полную запись)

Производительность часто такова: «узнайте свои данные и возможный поток программы, затем попробуйте лучший 2-3 подхода, оцените и решите».

person Simon Sobisch    schedule 24.06.2016