Описание БД ПК ВИКТА презентация

с БД внутри ПК ВИКТА реализована через систему соответствующих классов (API) встроенного СП-языка ПК ВИКТА, поэтому знание SQL не требуется. БД ПК ВИКТА не имеет внешнего интерфейса доступа (API) для использования без графической среды ПК ВИКТА.

ПК ВИКТА может использовать несколько БД (через механизм выбора БД).
Одновременно может использоваться только одна БД*.

Каждая БД может использовать несколько общих справочников ПК ВИКТА.
Пример справочника - список почтовых индексов РФ и т д. Поддерживаемые типы файлов общих справочников: dbf, БД ВИКТА.

Справочники поддерживаемых типов могут быть добавлены прикладным
разработчиком. Для справочников в файлах других типов нужно написание интерфейса взаимодействия системным программистом.
БД поддерживает работу по сети с удаленными узлами. На каждом узле находится полная копия БД**. Целостность данных (в том числе разрешение ситуаций блокировок) поддерживается автоматически.
Архитектура БД поддерживает полный откат состояния БД на соответствующую дату и время, если не проводилась операция сжатия БД.
По архитектуре БД ПК ВИКТА может быть примерно классифицирована как не реляционная БД типа семейство столбцов (колонок)

* - но нет принципиального ограничения на одновременное использование нескольких БД
** - в 2019-2020 гг. предполагается создать модель распределенной БД на базе узлов БД ПК ВИКТА (см. Приложение 4)

Демо-данные*

БД приложения 3

БД приложения N

ПК ВИКТА

Выбор приложения

Выбор БД

Работа в приложении

Список БД

Рис. 1. Цикл работы с БД в ПК ВИКТА

* - в поставку ПК ВИКТА могут входить демонстрационные данные для обучения персонала работе с приложением, прежде чем будет начата работа на реальных данных

файл

Индекс БД — 1 файл

Формат dbf
(возможно использование справочников
в формате БД ВИКТА и других**)

Общие справочники ПК ВИКТА

БД для приложения 1

БД приложения 1.
Демо-данные

БД приложения 3

БД приложения N

Список БД

Конкретная БД

х.dat
< 2 Гб*

x.ind
< 2 Гб*

Рис. 2. Файловый состав БД ПК ВИКТА

* - в 2018 г планируется закончить работы по увеличению емкости БД до уровня нескольких Тб
** - ввод обработки других форматов осуществляется системным программистом среды ПК ВИКТА

записи

Реквизит 1
Значение

Реквизит 3
Значение

Ключ записи

Реквизит 3
Значение

Реквизит 2
Значение

Реквизит 4
Значение

Содержимое записи в БД состоит из значений реквизитов. Реквизит — аналог имени колонки таблицы в реляционной БД. Далее для реквизита будем употреблять как синоним термина — поле
реляционных БД.

Число реквизитов для записи заранее не ограничивается*. Оно может быть изменено в приложении, что не приводит к существенному изменению схемы данных БД. Запись в рамках одной БД имеет уникальный ключ образованный из значений одного или нескольких реквизитов.

Работа с БД осуществляется транзакциями с метками времени, что обеспечивает откат на состояние БД в определенный момент времени. UPDATE записи не происходит. Измененная запись пишется целиком в конец БД. Значение реквизита записи может содержать ключ на другую «таблицу»** или справочник для выбора значения из списка этой таблицы или справочника

Реквизит 6
Значение

Реквизит 7
Значение

Реквизит 8
Значение

Ссылка на другую
«таблицу»* или справочник

* - считается, что потенциально запись может иметь все реквизиты БД, просто неиспользуемые в записи реквизиты - пустые
** - понятие таблицы в БД ПК ВИКТА отличается от принятого для реляционных БД. Это отличие раскрывается на следующем слайде

Рис. 3. Состав записи в БД ПК ВИКТА

ВИКТА задает для записей реквизиты, которые применяются:
- для построения уникальных ключей записи. Такие реквизиты называются основным ключом (см. рис.4.)
- для фильтрации и сортировки записей. Наборы таких реквизитов называются дополнительными ключами (см. рис.4.)

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

«Таблица»

Основной ключ

Дополнительные
ключи

Рис. 4. Часть окна «Список таблиц базы» с демонстрацией ключей
таблицы «Первичные документы»

не связаны жестко с «таблицами» и представлены общим списком для БД (см. рис.5.), в который могут легко добавляться и из которого могут легко распределяться для нужных записей без перестройки схемы БД. Изменения в схеме БД наступают в том случае, когда реквизит назначается, как ключевой. Фактически можно считать,
что каждая запись содержит все реквизиты из списка БД, просто тех, которых нет в записи — пустые и не занимают памяти.

Рис. 5. Часть окна «Список таблиц базы» и окна «Список реквизитов»

записи) со справочниками и другими таблицами в случае, когда требуется выбор значения из списка данного справочника или таблицы может быть осуществлено статическим и динамическим связыванием.


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

Динамическое связывание позволяет добавить к виду таблицы колонку с выбором из справочника в коде обработчика фрейма*. Внешне вызовы обоих типов не различаются и открывают справочник одинаково (см. рис. 6.)

Рис. 6. Пример раскрытия таблицы, связанный с полем записи

* - в ПК ВИКТА фреймом называется окно интерфейса. Например, на рис. 6. фрейм это окно «Классификация материальных ресурсов»

всегда добавляется в конец файла БД.

2. Соответственно приложение в работе выбирает записи только с последними по порядку записями в БД

3. Это позволяет не искать запись в теле файла при выполнении операций UPDATE, что заметно поднимает производительность

4. При этом, однако, растет размер файла БД за счет того, что в БД остаются устаревшие записи.

5. Устаревшие записи позволяют мгновенно откатить состояние базы на то время за которое есть устаревшие записи. Метка времени хранится в истории транзакций.

6. Для предотвращения чрезмерного увеличения файла БД существует операция сжатия, которая удаляет из базы устаревшие записи, оставляя только последние экземпляры.


Вывод. Особенности работы с записями в БД ВИКТА позволяют достичь наибольшего эффекта по критерию «скорость работы/размер БД» на задачах в которых операций чтения готовых данных для локальной обработки гораздо больше, чем операций записи или модификации данных.

к не реляционным базам типа «Семейство колонок», примерами которых являются: HBase, Apache Cassandra, Apache Accumulo, Hypertable, SimpleDB. Все эти БД применяются для работы с Большими Данными
в крупных проектах для хранения взаимосвязанных данных (документов) т.е. имеющих
полные или частичные общие данные. Например: события, записи и комментарии блогов.

Особенностью модели хранения данных «Семейство колонок» является с одной стороны отсутствие жесткой схемы данных реляционной модели (а значит повышенных расходов на изменение этой схемы при изменении приложения), а с другой стороны возможность работы с данными бОльшим числом запросов, нежели в не реляционных базах с моделями «ключ-значение» (Riak, Redis) и документоориентированными (MongoDB, CouchDB) в которых затруднительно, а то и невозможно делать выборки с условиями по содержанию записей (но не ключей). Более подробно модель «семейство колонок» рассмотрена в Приложении 1.

* - ведутся работы по увеличению объема файла БД. Планируемая дата окончания — середина 2018 г.
** - ведутся работы по созданию внешнего интерфейса (API) к БД ПК ВИКТА. Планируемая дата окончания — середина 2018 г.
*** - эксперименты могут быть проведены после выполнения работ по * и **

Таблица 1. Сравнение БД ПК ВИКТА с аналогами типа «Семейство колонок»

ВИКТА находится полная копия БД. Это позволяет обеспечить высокую надежность т.к. каждый узел может стать сервером (если узел, назначенный сервером изначально станет недоступен) и каждый узел имеет полную копию БД. Однако это-же ограничивает общий размер БД емкостью дисков только одного компьютера*.

Решение с полными копиями БД на клиентских машинах позволяет обеспечивать режим отсутствия блокировок средствами самой БД при чтении данных. Блокировка возникает при попытке записать измененные данные. В этом случае предлагается либо отказаться от записи, либо взять свежие данные и отредактировать их. Более подробно этот процесс описан в Приложении 3.

Весь процесс синхронизации данных между узлами осуществляется в БД ПК ВИКТА автоматическом режиме.

* - в Приложении 4 предлагается решение для преодоления этого ограничения.

Встроенные инструменты работы с БД ПК ВИКТА

1. Инструменты управления: базами, справочниками таблицами, реквизитами, связями реквизитов и таблиц, реквизитов и справочников, таблиц и справочников.

2. Инструменты контроля транзакций и откатов

3. Инструменты сжатия и бэкапирования БД

«Аймэн» (http://www.aimen.ru), являющееся Microsoft Gold Certified Partner,
проводило сравнительное тестирование приложений типа «Заработная плата», разработанных на платформе Microsoft и на платформе ПК ВИКТА. Тестирование показало почти 30-кратное превосходство в скорости решения на базе ПК ВИКТА: 30–40 секунд у ПК ВИКТА против 15–16 минут у Microsoft для задачи расчета заработной платы.


Второй эксперимент проводился в январе 2016 г. для сравнения быстродействия БД ВИКТА и реляционной БД MySQL. Для эксперимента было составлено два справочника. Первый содержал 100 тыс. записей списка сотрудников, второй – 300 тыс. записей мест работы сотрудников. Каждый сотрудник мог иметь до 3-х мест работы. В эксперименте выбирались 1000 сотрудников с местом работы, совпадавшим в контексте с некоторым шаблоном. Задача состояла в том, что место работы неоднозначно. Нужно выбрать всех, кто работал, например, в МГУ ВМиК. Может быть, все 3 места сотрудника отвечают заданному требованию, может быть, – одно. Например, МГУ ВМиК нужно искать в контексте Поле «аааа бббб МГУ ВМиК оооо» и в «МГУ ВМиК ннн»; оба отвечают поставленному требованию. Эксперимент на этом тесте показал преимущество в скорости БД ПК ВИКТА в 17,5 раза: 35 секунд у MySQL и 2 секунды у ПК ВИКТА.

иметь более компактную БД, которая занимает столько памяти, сколько реально есть данных.

2. Использование обязательных реквизитов (полей) в «таблицах» только уникальных ключей и ключей фильтрации/сортировки позволяет гораздо быстрее адаптировать приложение к изменениям за счет отсутствия жесткой схемы данных, присущей классической реляционной архитектуре

3. Запись обновленных данных в конец файла БД позволяет заметно повысить скорость работы с БД на операциях чтения и обновления, а также дает возможность получения полностью консистентного состояния базы на любой заданный момент времени (до выполнения операции сжатия). Однако обратной стороной является сравнительно низкая скорость записи новых данных.

4. Компактность БД позволяет реализовать высоконадежную работу распределенной сети БД ПК ВИКТА за счет наличия 100% копии данных на каждом узле, каждый из которых может принять на себя роль сервера при отказе узла, первоначально назначенного сервером. Однако обратной стороной данной возможности является ограничение максимальной емкости БД — емкостью дисков одного компьютера.

5. Специфика организации распределенной работы текущей БД ПК ВИКТА дает заметное преимущество для решения задач, где нагрузка на сеть происходит, в основном, за счет запросов на получение данных из базы, а сама база изменяется при этом сравнительно мало. К такому классу задач можно отнести управленческие и экономические задачи в производстве, задачи бухгалтерского учета на мелких, средних и даже относительно крупных предприятиях

6. Наличие встроенного СП-языка с развитым API доступа к БД позволяет выполнять сложные выборки с использованием всей мощи объектно-ориентированного подхода. Однако отсутствие внешнего интерфейса этого API не позволяет сейчас использовать БД ПК ВИКТА как опорную БД для других приложений.

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

8. Устройство БД (п.1-3) позволяет отнести ее к не реляционным базам типа «Семейство колонок», примерами которых являются: HBase, Apache Cassandra, Apache Accumulo, Hypertable, SimpleDB (Amazon.com), используемых для работы с Большими Данными. Однако данный потенциал БД ПК ВИКТА нуждается в исследовании и сравнительном тестировании*.

*
На сегодняшний момент ведутся работы для преодоления ограничений БД ПК ВИКТА:
- ограничения в 2Гб на файл БД
- ограничение отсутствия внешнего API к БД ПК ВИКТА
Ожидаемый срок завершения этих работ — середина 2018 г.

По завершении этих работ можно будет провести экспериментальные исследования того, насколько БД ПК ВИКТА может решать задачи, которые сейчас решают «импортные» колоночные БД.

1
Значение
Метка времени

Есть ограничения
на структуру документов

Ключ столбца 2
Значение
Метка времени

Ключ строки

Ключ столбца 1
Значение
Метка времени

Ключ столбца 3
Значение
Метка времени

Ключ строки

Ключ столбца 4

Значение = массив столбцов





Метка времени

Ключ столбца 4.1
Значение
Метка времени

Ключ столбца 4.2
Значение
Метка времени

Семейство столбцов

Не заполнено

Не заполнено

Не заполнено

Не заполнено

Не заполнено

Не заполнено

Не заполнено

из которых имеет ключ и значение

Значение столбца может быть простым или ассоциативным массивом столбцов СУБД может работать со значением.

Поэтому, кроме операций допустимых с моделью ключ-значение допустимые дополнительные операции со значением: выборки по ключам столбцов

СУБД может работать с ключами также как и в модели ключ-значение

Преимущества:

Приемлемая скорость
Хорошая масштабируемость
Работа со значениями
Более гибкая модификация структуры (add colum)

Недостатки:

Ограничения на структуру значений
Избыточное извлечение данных
Трудности изменения шаблонов
запросов (при изменении семейства
колонок)

Представители: Cassandra, HBase

Применение: хранения взаимосвязанных данных (документов) т.е. имеющих
полные или частичные общие данные. Например: события, записи и комментарии блогов.

Приложение 1. Описание модели БД «семейство столбцов»

данных сервера и клиентских приложений.

На рисунке 7 изображен процесс синхронизации баз данных на сервере и всех клиентских приложениях. Чтение и обработка данных происходит на каждом клиентском месте, не загружая каналы связи. Каждое клиентское приложение имеет собственный идентификатор. При возникновении изменения в информации клиентское приложение (1.1) формирует транзакцию (4), помечает ее своим идентификатором и передает ее серверу. Сервер присваивает транзакции сквозной номер (i), записывает транзакцию в собственную базу данных и передает ее всем клиентам в режиме вещания, не заботясь о факте ее приема конкретной станцией. Передающая станция (1.1) узнает о приеме своей транзакции сервером в случае ее получения в режиме вещания. Если клиентское приложение (1.n) по каким-либо причинам не соединено с сервером, транзакция ему в этот момент не поступает.

клиентским приложением пропущенной транзакции.

Рисунок 8 показывает описание запроса клиентским приложением (1.n) пропущенной транзакции (4.i). Станция обращается к серверу о запросе пропущенных транзакций в момент включения либо при получении транзакции, номер которой отличается от существующей в базе данных станции больше, чем на 1. Тогда у сервера запрашиваются транзакции с конкретными номерами, и взаимодействие происходит в режиме диалога между сервером и станцией.

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

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










На рисунке 9 указано, что сервер и все три станции работают с некоторым состоянием базы на момент времени равный T1. На этот момент времени последней транзакцией в базе является транзакция с номером 7. Обе операционистки формируют данные для новой транзакции (у нее пока еще нет номера, но мы будем считать, что данные формируются для восьмой транзакции).

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









Здесь все станции получили обновленное состояние базы, но при этом операционистка второй станции продолжает работать с состоянием базы, которым оно было на момент времени T1, поскольку данные, которые она видит на своем экране, были прочитаны раньше момента совершения обновления, - то есть она продолжает работать с состоянием, актуальным на момент завершения седьмой транзакции и продолжает формировать данные для следующей. Если она в этот момент завершит свою работу и изменившиеся данные пойдут на сервер, он не сможет записать ее данные и сообщит на станцию об ошибке (вспомним, что они редактировали один и тот же документ). Если бы операционистка второй станции работала с другим документом, конфликта бы не возникло, и данные успешно были бы записаны в базу (в этом случае операция второй операционистки просто записалась бы под номером 9). В данном случае это не так, и операционистке будет предложено либо отменить свою операцию, либо просмотреть и откорректировать данные, измененные другой операционисткой (сделать изменения в базе на основании состояния, имеющегося в момент времени T2).

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

Рис. 9.

Рис. 10.

они есть)*

* - например, в простейшем случае, запрос Delete требует в качестве данных — ID (ключ) удаляемой записи
** - например, ограничения реестра для Hadoop оценивается в 4 тыс. узлов. см. - https://ru.wikipedia.org/wiki/Hadoop

БД ПК
ВИКТА

БД ПК
ВИКТА

БД ПК
ВИКТА

БД ПК
ВИКТА

БД ПК
ВИКТА

БД ПК
ВИКТА

БД ПК
ВИКТА

БД ПК
ВИКТА

Слой
«рецепторов»

Слой узлов
( нейронов )

Из трех текущих неудобств БД ВИКТА: ограничение файла данных/индекса в 2Гб, отсутствие внешнего интерфейса к БД и сравнительно низкая скорость записи в БД только последнее является принципиальным архитектурным ограничением, которое, однако, может быть преодолено в решении в котором сам узел с БД ПК ВИКТА инициирует обращение к слою, содержащему запросы по мере того, как у него освобождаются для этого вычислительные ресурсы.

В распределенной БД, построенной на узлах с БД ПК ВИКТА, сами узлы обращаются к слою задач/запросов, считывают запросы, исполняют и возвращают результат. При этом, общий вывод (принятие решения) может быть сделан на основе возврата данных не от всех узлов. Т.е. в данной системе (даже при применении механизма приоритетов запросов) возможна ситуация, когда за заданное на выполнение запроса время на него ответили не все узлы, а только определенный % узлов. В этом случае, либо выделяется большее время, либо решение принимается с пониманием вероятности ошибки.

Возможен также вариант, когда для выполнения задачи/запроса не хватает данных. В этом случае может быть инициирован процесс сбора дополнительных данных, после чего запрос выполняется повторно

Отдельный узел БД ПК ВИКТА «несет самостоятельную ответственность» за сохранность данных. В случае обнаружения при самотестировании наличия угрозы данным (битые сектора на диске) узел самостоятельно связывается с ближайшими узлами и организует процесс миграции данных

Слой задач не хранит информации о том, какие данные на каком узле были записаны. Это снимает ограничения на количество узлов в сети БД, упирающиеся в мощность центрального реестра**.

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

Робот-бот для сбора
данных из внешней среды

Интернет,
датчики,
другие БД

Человек
или другое
приложение