Actian Object Database

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 21:10, 17 апреля 2019.
Actian NoSQL Object Database
Logo
Разработчики: Actian
Постоянный выпуск: 9.2 / 13 June 2017 года; 22 months ago (2017-06-13)[Источник 1]
Состояние разработки: Активный
Написана на: Java, C, C#, C++, Smalltalk, Python
Операционная система: Кросс-платформенное программное обеспечение
Лицензия: Коммерческая
Веб-сайт Actian NoSQL Object Database

Actian NoSQL Object Database (устар. Versant Object Database[Источник 2], сокр. AOD, VOD) - программный продукт, представляющий собой объектно-ориентированную базу данных. Изначально разрабатывался компанием Versant Corporation, которая впоследствие стала Actian.

База данных Actian NoSQL Object Database позволяет разработчикам, использующим объектно-ориентированные языки, осуществлять транзакционное хранение своей информации, позволяя соответствующему языку выступать в качестве языка определения данных (DDL, Data Definition Language) для базы данных. Другими словами, модель памяти является моделью схемы базы данных.[Источник 3]

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

Версии базы данных

В настоящее время существует несколько версий Actian NoSQL.

Сравнение версий Actian NoSQL
Actian NoSQL Database Actian NoSQL JPA Actian NoSQL Fast Objects
Поддержка C/C++
Поддержка Java
Поддержка .NET
Масштабируемость
Встраиваемость
Минимальное администрирование
Двойная архитектура кэширования клиент/сервер
Многоуровневая масштабируемость
Требование маппинга кода
Развертывание схемы онлайн

Основные моменты

Главными отличиями рассматриваемой базы данных являются:[Источник 4]

  • Прямая работа с объектами, представленными языками C++, Java и .NET;
  • Поддержка стандартов (например, JDO);
  • Высокая доступность (HA);
  • Динамичная схема БД;
  • Низкая потребность в администрировании;
  • Многопоточность;
  • Поддержка нескольких сессий;
  • Гибкое управление БД;
  • Сквозная архитектура работы с объектами (в памяти БД они представлены также, как в памяти обрабатывающего их языка).[Источник 5]

Система запросов

VOD поддерживает запросы с помощью индексации на стороне сервера и механизма выполнения запросов. Поддержка запросов включает в себя как синтаксис языка запросов, специфичный для Versant, так и стандартизованный. Versant предоставляет эту возможность запроса в нескольких формах в зависимости от выбранной языковой привязки разработчика. Например, в Java VOD предоставляется VQL (язык запросов Versant), JDOQL, EJB QL и OQL. В C++ Versant предоставляет VQL и OQL, для C# - VQL, OQL и LINQ. VOD будет оптимизировать выполнение запросов на основе доступных индексов атрибутов. Versant также поддерживает стандартные SQL-запросы к базе данных Versant с использованием драйверов ODBC/JDBC.

Versant Query Language (VQL)

Собственный язык запросов Versant (VQL) похож на SQL92. Это строковая реализация, которая позволяет осуществлять связывание запросов (binding) в режиме реального времени. Разница заключается в том, что вместо таргетинга на таблицы и столбцы, он предназначен для классов и атрибутов. [Источник 5]

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

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

Индексирование

VOD поддерживает индексацию больших коллекций. Однако нет необходимости создавать коллекцию, чтобы сохранить запрашиваемый объект с рабочим индексом. В отличие от других реализаций OODB, любой объект в базе данных Versant индексируется и доступен через запрос. Индексы могут быть помещены на атрибуты классов, и эти классы могут быть объектом операции запроса. Индексы могут быть хэшем, b-деревом, уникальными, составными или виртуальным и могут быть созданы онлайн либо с помощью утилиты, либо через графический интерфейс пользователя, либо через вызов API.[Источник 5]

Поддержка больших коллекций

VOD предоставляет поддержку разбиения на страницы для больших коллекций с использованием специальной реализации на узле. Эти коллекции разработаны таким образом, что только узлы, необходимые клиенту, переносятся в память, вместо того, чтобы загружать всю коллекцию.[Источник 5]

Эти большие коллекции создаются и управляются так же, как и другие постоянные классы коллекций. Интерфейс также совместим с соответствующими языковыми конструкциями. Например, стандартная библиотека шаблонов C++, итераторы Java, перечисления C# и т.д.

Коллекции объектов по умолчанию - это всего лишь набор идентификаторов объектов. Таким образом, они могут быть очень большими, но с небольшим объемом памяти. Для итерации коллекции объекты разыменовываются в пространство памяти клиента либо в настраиваемом пакетном режиме, либо по одному за раз. Запрос коллекции можно выполнить с помощью оператора in (или других операторов на основе набора, таких как subset_of, superset_of и т.д.), не загружая коллекцию в пространство памяти клиента.

Репликация данных

Существует несколько механизмов репликации на VOD, которые зависят от мотивации репликации. Это для высокой доступности или для распространения или интеграции.[Источник 5]

Высокая доступность (HA)

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

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

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

Распределенность

Распределенность поддерживается технологией Versant Asynchronous Replication (VAR), в котором может быть выбрана концепция master-slave или peer-to-peer репликации с обнаружением и разрешением конфликтов на основе правил.

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

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

При двунаправленной репликации каналов устанавливается набор правил обнаружения конфликтов, чтобы конфликтующие изменения могли быть разрешены во время выполнения без нарушения активности канала.[Источник 5]

Интеграция

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

Архитектура распределения данных

VOD поддерживает распределенную обработку данных с использованием двухфазного протокола фиксации между многосвязными базами данных. В этом процессе VOD использует внутренний менеджер ресурсов, который обрабатывает распределенные транзакции. Versant также поддерживает протокол HA, позволяющий внешним мониторам транзакций управлять транзакционным контекстом, например, подключаться к серверу приложений CORBA или J2EE.

Versant позволяет объектным отношениям охватывать узлы физического ресурса (базы данных). Общая информация, на которую ссылаются объекты, находящиеся в других базах данных, и разрешение этой информации прозрачно во время выполнения. Например, несколько физических баз данных могут содержать модели пользовательской информации, которые разбиваются по номерам учетных записей, содержащим агрегации, на операции с учетной записью, такие как сделки, а затем располагают еще несколькими базами данных, имеющими фактические торговые модели, и эти пользователи и сделки могут быть связаны. Запрос проодит по всем пользовательским базам данных и возвращает пользователя (или набор пользователей), а затем, когда сообщения отправились пользователям-участникам торгов, торговые модели автоматически будут обновляться через распределенную репликацию данных. После обновления любого из этих объектов в момент фиксации Versant гарантирует, что все изменения вернутся к их соответствующим физическим узлам в процессе полной фиксации ACID 2phase.

Идентификатор объекта гарантированно будет уникальным во всех физических узлах. Объекты могут быть «перемещены» с одного физического узла на другой без каких-либо изменений кода приложения.

Обновление схемы хранилища

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

Существующие объекты в базе данных лениво обновляются до последней версии схемы. На самом деле объект не обновляется, если он не "загрязнен" (не помечен для обновления) и не передан обратно в базу данных. В общем случае это означает, что приложение с новой схемой не вызовет обновления, кроме новых и обновленных объектов.

Есть утилиты, которые могут "сканировать" базу данных, медленно обновляя все существующие объекты до последней версии, захватывая их множество, маркируя их "грязными". Это иногда желательно для встроенных систем или систем реального времени, где производительность и пространство необходимо оптимизировать.

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

Процесс выполняется следующим образом:

  1. обновляются определения классов, т.е. добавляются новые подклассы, добавляются атрибуты, переименовываются атрибуты, удаляются атрибуты и т. д. и перекомпилируются. Когда приложение подключается к базе данных Versant, будет обнаружено несоответствие версии схемы.
  2. несоответствия схемы можно избежать, используя ряд методов:
    1. можно использовать утилиту для описания новой схемы в базе данных. Утилита покажет список несовместимостей и спросит, как вы хотите, чтобы они были разрешены. Ваши действия будут зависеть от того, находитесь ли вы в разработке, QA, производстве и т.д. Независимо от этого, такие действия, как сброс существующего класса, изменение версии схемы и сохранение всех существующих объектов, переименование и повторный тип и т.д., также возможны.
    2. процесс обновления может быть автоматизирован через параметры подключения. Обычно это используется в режиме разработки и позволяет схеме автоматически изменять любые несоответствия при подключении и продолжать сохранять существующие объекты.
    3. специфические API могут использоваться для динамического обновления схемы базы данных. Это расширенная тема, в которой участвуют классы Versant runtime. В принципе, можно создать полностью динамическую структуру схемы для базы данных, чтобы новые классы и атрибуты могли создаваться «на лету».
  3. если клиенты с более старой схемой продолжают работать в базе данных, в файле профиля приложения необходимо установить значение true_schema_mapping в файле профиля приложения.
  4. при желании можно запустить утилиту для обхода базы данных и принудительной миграции версий всех существующих экземпляров.

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

  1. Изменения в середине иерархии наследования. Вставка нового класса в середину иерархии невозможна без потери ваших существующих объектов, если только пользовательский код не написан для выполнения этой операции в несколько этапов.
  2. Несовместимый тип изменяется как Array на String.

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

Жизненный цикл объектов

Жизненный цикл объекта можно контролировать на основе его использования.

По умолчанию объекты загружаются только при отправке сообщения. Это включает поведение по умолчанию для запросов, которые возвращают только набор ссылок на объекты, удовлетворяющие предикату запроса, а не фактические объекты. Когда объект загружен, все его атрибуты без ссылки (примитивы) также загружаются, а оставшиеся ссылочные типы следуют тому же шаблону, что и ссылочный объект.[Источник 5]

Когда сообщение отправляется объекту, VOD просматривает внутренние структуры, чтобы узнать, находится ли объект в клиентской памяти. Если нет, VOS выполняет RPC для загрузки объекта. В то время, когда VOD загружает объект, он также рассмотрит стратегию блокировки соединений, чтобы решить, как бороться с блокировкой объекта при загрузке. VOD поддерживает как глобальные стратегии блокировки, которые могут применяться к соединению, так и чрезвычайно гибкий контроль, чтобы переопределить поведение для конкретного варианта использования.

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

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

Другое событие заключается в том, что кэш клиента начинает заполняться. В этом случае VOD может принять решение об обмене объектами с сервером, чтобы освободить место и выполнить некоторую работу, которая должна быть выполнена при фиксации в любом случае. VOD делает это полностью транзакционным способом, так что даже если измененные объекты будут заменены на сервере, эти изменения все равно будут отменены, если транзакция будет отменена. Кроме того, у вас есть возможность «привязывать» объекты к кэшу клиента, чтобы предотвратить замену важных наборов объектов, что позволяет использовать указатели прямой памяти без учета ошибок памяти.

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

Существует множество способов переопределить поведение по умолчанию. Фактически они обычно используются для настройки производительности на практике. Например, если вы собираетесь перебирать набор из 1000 объектов, вы не хотите делать 1000 запросов. Предоставление коллекции ссылок на вызов groupRead будет использовать один RPC и загрузит все объекты. Аналогично, вы можете сделать вызов getClosure, который будет использовать поведение groupRead для загрузки всех объектов. Кроме того, в запросах есть опции для установки наборов блокировок и загрузки, а не только для ссылок или для использования курсоров. Есть API, чтобы явно загружать объекты в кеш и устанавливать более высокие уровни блокировки, чем настройки по умолчанию и т.д.

Живучесть

Для пользователей C++ Versant требует, чтобы самый верхний класс в иерархии наследования наследовался от базового класса «PObject», который обрабатывает действия базы данных.

Затем есть настройка файла, schema.imp, которая объявляет, какие классы в модели должны быть постоянными, и этот файл используется на этапе предварительной компиляции, где их обрабатывает Versant. Наконец, полученный файл schema.cxx скомпилирован и связан с приложением.

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

При использовании Java или .NET эта же процедура, описанная выше с C++, выполняется с помощью улучшения кода после обработки. Один настраиваемый файл, который объявляет, какие классы должны быть постоянными, а затем использует утилиту или API или интеграцию IDE для улучшения классов перед запуском или отладкой.

Versant предоставляет другие Java API на основе стандартов JDO и JPA. В этих версиях API система придерживается стандартов, определенных для объявления сохранения, будь то какой-то XML или аннотация. Затем расширение выполняется с помощью утилиты (аналогично .NET) или, чаще всего, с подключаемым модулем Eclipse или Visual Studio во время процесса сборки.

Интеграция с реляционными базами данных

Большой процент клиентов Versant делает некоторую интеграцию с реляционными таблицами. Это можно выполнить несколькими способами в зависимости от требований, таких как: online/offline, пакетный, транзакционный и т.д.

XA

Versant поддерживает протокол XA для распределенных транзакций. Это позволяет участвовать в онлайн-распределенных транзакциях с реляционными базами данных. Взаимодействие с реляционными таблицами может принимать различные формы от пользовательского кода до ORM-решений, серверов приложений J2EE (моделирование отношений сущностей), передачи сообщений в ORB и т.д. XA API позволяет базе данных Versant действовать как ресурс, контролируемый внешней транзакцией, отслеживать координацию изменений как в версиях, так и в реляционных базах данных в одном и том же транзакционном контексте.[Источник 5]

ORM

Versant может взаимодействовать с реляционными базами данных с использованием технологии Java ORM, такой как JDO (объекты данных Java) и Hibernate JPA. Эти реализации на основе стандартов имеют возможность отделять объекты от их транзакционного контекста, а затем присоединяют их к другому соединению. Существуют ограничения в том, что Versant требует, чтобы приложение использовало концепцию, известную как идентификатор базы данных, чтобы репликация не работала с отношениями. Versant не поддерживает форму идентификации ORM в чем-либо, кроме несвязанной формы данных.

XML

Versant имеет инструменты, которые позволяют импортировать и экспортировать данные XML. Например, пакетная репликация данных может быть выполнена путем экспорта объектов из базы данных Versant в формате XML, при необходимости с применением преобразования XSLT и последующего импорта в реляционные таблицы. Также возможно противоположное направление. С помощью Java наиболее распространенным подходом с использованием XML является динамическая репликация информации с использованием JAXB, среда выполнения которой преобразует объекты в XML-форму и из нее. Используя JAXB, база данных Versant должна работать только с объектами, а не импортировать XML-форму. По сути, XML, поступающий из реляционных баз данных, преобразуется в объекты во время выполнения с использованием JAXB, и эти объекты затем сохраняются в базе данных Versant.[Источник 5]

Пользовательский код

Пользователям C++ особенно сложно интегрироваться с реляционными базами данных. Versant предоставляет консультации, помогающие этим клиентам решать свои задачи интеграции.

Транзакции

Versant по умолчанию всегда подразумевает транзакции при подключении к базе данных. Кроме того, VOD поддерживает протокол XA и применяет это к определенному стандарту API, например JDO и JPA, которые требуют явного объявления транзакций. Существует неявная форма транзакции, в которой должно быть объявлено начало/конец транзакции.

Чтобы отказаться от объектов памяти, которые были изменены в текущей транзакции, можно сделать это глобально для текущей транзакции, выпустив откат, который также неявно запускает другую транзакцию, или можно сделать это изолированно или глобально, используя определенные вызовы в одной и той же транзакции.

Стратегии блокировки и кэширования

Versant по умолчанию использует пессимистическую стратегию блокировки для обеспечения того, чтобы объекты на сервере базы данных синхронизировались с доступом клиента по пути ACID. Это делается с помощью комбинации блокировок как с объектами схемы, так и с экземплярами.

Процесс сервера базы данных поддерживает очереди блокировки запросов на уровне объекта для управления параллелизмом доступа к одному и тому же объекту. Запрос на обновление установит очередь, если есть какие-либо существующие читатели объекта. Запрос проходит, когда все текущие читатели снимают свои блокировки. Блокироваки обычно освобождаются на границах транзакций. Когда очередь выполняет запрос на обновление, все остальные последующие запросы попадают в очередь после запроса на обновление. После того, как запрос на обновление был заполнен, все запросы на чтение в очереди получают блокировку на чтение, читают объект, а если нет других обновлений, очередь исчезает. В этой архитектуре блокировки выполняются на уровне объекта, поэтому ложные ожидания и ложные взаимоблокировки не возникают.[Источник 5]

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

Масштабирование

Хранилище

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

Клиенты

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

Эффективность

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

Дополнительные модули

Versant предоставляет дополнительные модули для развертывания или доступа к своей базе данных объектов.

  • V/Management Center: V/MC обеспечивает просмотр данных производительности и аналитических данных о базе данных Versant в режиме реального времени. Например, он предупреждает администраторов о возможных проблемах до того, как будет затронута доступность базы данных. Он разработан как клиент RCP на основе Eclipse.
  • Versant Compact: онлайн-обслуживание базы данных.
  • Versant FTS: сервер базы данных высокой доступности.
  • Versant Async Server: репликация производственной базы данных.
  • Резервное копирование Versant HA: решение для резервного копирования с высокой доступностью.
  • Versant SQL: SQL Access & Reporting.

Применение

Обычно лучшим спобобом для использования базы данных Versant являются приложения, требующие конкретной базы данных для обработки транзакций онлайн. Существуют определенные характеристики приложений, в которых технология Versant обеспечивает лучшую производительность и масштабируемость, чем традиционные реляционные технологии: сложные модели, большой объем данных, большое количество одновременных пользователей. VOD использовалась такими приложениями, как глобальные торговые платформы для крупных фондовых бирж, управление сетью для крупных поставщиков телекоммуникационных услуг, аналитика разведки для оборонных агентств, системы резервирования для крупных авиакомпаний/гостиничных компаний, аналитика управления рисками для банковских и транспортных организаций, многопользовательские онлайн-игры, системы безопасности сети и обнаружения мошенничества и т.д.

Источники

  1. Actian Launches Actian NoSQL // URL: https://www.actian.com/company/news-and-events/press-releases/actian-launches-actian-nosql-first-object-oriented-database-designed-deliver-enterprise-class-performance-data-driven-organizations/ (дата обращения: 30.11.2018 г.).
  2. Actian NoSQL Object Database - главная страница продукта // URL: https://www.actian.com/data-management/nosql-object-database/ (дата обращения: 23.09.2018 г.)
  3. Статья про Versant на английской Wikipedia // URL: https://en.wikipedia.org/wiki/Versant_Object_Database (дата обращения: 23.09.2018 г.)
  4. Краткое описание Actian NoSQL Object Database // URL: https://www.actian.com/wp-content/uploads/2017/03/DS19-ActianNoSQL-Database_02.pdf (дата обращения: 23.09.2018 г.)
  5. 5,0 5,1 5,2 5,3 5,4 5,5 5,6 5,7 5,8 5,9 Документация по Versant // URL: http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=71EF02AC196AF6F89D89313AE5E97BD7?doi=10.1.1.114.5088&rep=rep1&type=pdf (дата обращения: 23.09.2018 г.)