Технологии Raima
База данных в памяти
IN-MEMORY DATABASE
Что такое система управления базами данных в оперативной памяти?
База данных в памяти (IMDB; также система базы данных в основной памяти или MMDB) хранится в основной памяти компьютера ( RAM ) и управляется системой управления базой данных в памяти. Традиционные базы данных хранятся на дисках.
Традиционные дисковые базы данных форматируются с учетом блочно-ориентированного устройства, на котором данные читаются и записываются. Когда одна часть базы данных ссылается на другую часть, может потребоваться чтение с диска другого блока. Это не проблема с базами данных в памяти, и взаимосвязями между частями базы данных можно управлять с помощью прямых указателей. Данные в памяти всегда присутствуют, поэтому нет задержки для чтения. Запись данных на диск должна выполняться «атомарно», когда все записи регистрируются или ни одна из них не регистрируется. Это часто требует ведения журнала или двойной записи. База данных в памяти не имеет таких требований, поэтому изменения в памяти происходят практически мгновенно.
Оглавление
- Что такое система баз данных в памяти?
- Дисковая база данных против Базы данных в памяти
- Как осуществляется доступ к данным и их изменение в системе управлеия базами данных в памяти?
- Как данные в памяти распределяются между несколькими задачами?
- Можно ли использовать базу данных на диске в памяти?
- Каковы преимущества и недостатки баз данных в памяти?
- В чем разница между базой данных в памяти и простым хранением данных в сегментах разделяемой памяти?
- База данных в оперативной памяти может потерять данные, если что-то перестает работать: как вы с этим справляетесь?
- Все ли встроенные базы данных также являются базами данных в памяти?
Дисковые базы данных VS Базы данных в памяти
Дисковые базы данных
- Все данные хранятся на диске, дисковый ввод-вывод необходим для перемещения данных в основную память, когда это необходимо.
- Данные всегда сохраняются на диске.
- Традиционные структуры данных, такие как B-Tree, предназначены для эффективного хранения таблиц и индексов на диске.
- Поддержка очень широкого набора рабочих нагрузок, например OLTP, хранилищ данных, смешанных рабочих нагрузок и т. Д.
Базы данных в памяти
- Все данные хранятся в основной памяти, нет необходимости выполнять дисковый ввод-вывод для запроса или обновления данных.
- Данные являются постоянными или изменчивыми в зависимости от продукта базы данных в памяти.
- Специализированные структуры данных и структуры индексов предполагают, что данные всегда находятся в основной памяти.
- Оптимизирован для высокой производительности.
Как осуществляется доступ к данным и их изменение в системе управления базами данных в оперативной памяти?
Данные в базе данных RDM в памяти «готовы к работе». Если данные в блоке диска могут быть сжаты, зашифрованы, уплощены или закодированы, данные в памяти находятся в формате, пригодном для прямого использования. Он также имеет структуру, не зависящую от проблем с блокировкой диска, что позволяет осуществлять прямую навигацию от столбца к столбцу, от строки к строке или индекса к строке, что позволяет вносить изменения путем выделения блоков памяти и перестановки указателей.
Как данные в памяти распределяются между несколькими задачами?
Ответ двоякий: быстрее и быстрее. Для тех, кто знаком с транзакционным файловым сервером RDM (TFS), который можно использовать для совместного использования базы данных между пользовательскими процессами на одном компьютере, в офисной локальной сети или по всему миру, база данных может управляться в памяти с помощью TFS. Это быстрее, чем на дисковых базах данных, управляемых TFS.
Но самый быстрый способ поделиться одной базой данных между несколькими задачами — запустить один процесс с несколькими потоками, где каждая задача выполняется в своем собственном потоке. Эта форма приложения работает на одном компьютере и позволяет каждому потоку обращаться к базе данных непосредственно в локальном хранилище кучи. Это также позволяет избежать необходимости считывать неизмененные объекты базы данных в локальный кеш, поскольку исходный объект можно просматривать непосредственно из памяти базы данных. Это очень быстрый способ совместного использования базы данных в многопользовательском режиме.
Можно ли использовать базу данных на диске в памяти?
При использовании RDM ответ — «Да!» Базы данных в памяти могут быть загружены с диска при их открытии, а также могут быть сохранены на диск при их закрытии или при запросе «точек сохранения». Точки сохранения являются атомарными, что означает, что все изменения данных с момента последней точки сохранения записываются на диск вместе, или ни одно из них не записывается. Это делает их транзакционными, но не на тех же границах транзакций, что и база данных на диске.
Каковы преимущества и недостатки баз данных в памяти?
Базы данных в памяти , по определению, обрабатывают данные, которые они обрабатывают в основной памяти. Нет необходимости иметь дело с вторичным хранилищем, которое может быть на несколько порядков медленнее, чем доступ к данным, хранящимся в основной памяти. Устранение требования доступа к более медленному вторичному хранилищу позволяет использовать алгоритмы в базе данных в памяти, что было бы невозможно для базы данных на диске. Например, дисковая база данных обычно использует индекс на основе b-дерева, чтобы ограничить количество обращений к диску, необходимых для поиска строки. База данных в памяти может использовать Tree AVL вместо B-Tree, которое уменьшает (или устраняет) необходимость дублирования данных, но увеличивает количество строк, к которым осуществляется доступ во время обхода.
Без необходимости во вторичном хранилище база данных в памяти может использоваться в системах без какого-либо вторичного хранилища.
Это позволяет использовать ядро базы данных во многих встроенных системах, которые не могут поддерживать традиционный дисковый движок.
Обычно тип памяти, используемый в системе баз данных в памяти, не является постоянным. Когда приложение закрывается, чисто или неожиданно, данные, хранящиеся в базе данных в памяти, будут потеряны. Некоторые домены приложений не требуют сохранения данных между запусками, но другие могут. Те приложения, которые требуют высокой степени постоянства, могут не подходить для использования базы данных в памяти.
База данных в памяти хранит все данные в основной памяти, что может серьезно ограничить объем данных, которые могут быть сохранены. Большинство систем баз данных могут обрабатывать выделение памяти для хранения объектов базы данных или им может быть предоставлен фрагмент памяти для использования в качестве хранилища. В любом случае объем данных, которые могут храниться в базе данных в памяти, обычно намного меньше, чем объем данных, хранящихся в дисковой системе.
В чем разница между базой данных в памяти и простым хранением данных в сегментах разделяемой памяти?
Самая большая разница между базами данных в памяти и хранением данных в сегментах разделяемой памяти связана со структурированным подходом к доступу к данным. Базы данных в памяти поддерживают компоненты атрибутов « ACID » механизмов хранения данных. Свойства ACID включают атомарность, согласованность, изоляцию и долговечность. Хотя базы данных в памяти могут ослабить свойство долговечности из-за непостоянного хранилища, они обычно поддерживают другие свойства:
• Атомарность — множественные изменения фиксируются в базе данных как операция «все или ничего»
• Согласованность — структурные правила и отношения поддерживаются для всех пользователей
• Изоляция — транзакционные изменения не могут быть видны другим пользователям, пока они не будут зафиксированы
Реализация этой функции поверх сегментов совместно используемой памяти может занять много времени и привести к ошибкам.
Помимо свойств транзакций баз данных в памяти, есть много других
готовых преимуществ, в том числе:
Использование общих четко определенных языков определения данных (операторы SQL DDL) Использование общих четко определенных языков запросов данных (операторы SQL DML) Удаленный доступ к данным по сетевому протоколу связи
Возможность хранения данных в независимом от платформы формате
Инструменты, доступные для импорта / экспорта через CSV, XML, JSON и т. Д. Возможность сохранения данных в памяти на диск
База данных в оперативной памяти может потерять данные, если что-то перестает работать: как вы с этим справляетесь?
Разработчик приложения должен понимать, что при работе с базой данных в памяти возможна потеря данных. Существует несколько подходов, таких как постоянство и репликация, которые используются для смягчения сценариев потери данных, но потеря данных все еще возможна.
Постоянство
Raima поддерживает два режима открытия базы данных в памяти.
• Неустойчивый — база данных пуста при первом открытии, и все содержимое удаляется при закрытии базы данных
• Постоянное — при открытии база данных заполняется из содержимого во вторичном хранилище, при закрытии измененные данные (вставки, обновления, удаления) записываются в вторичное хранилище
Если база данных открыта с использованием постоянного режима в памяти, измененное содержимое будет автоматически записано во вторичное хранилище при закрытии базы данных. Кроме того, разработчик может сохранить изменение на вторичное хранилище по запросу. Использование
сохраняемости может ограничить потерю данных тем, что произошло с момента последней операции сохранения.
Репликация
Многие системы баз данных поддерживают репликацию изменений в другой экземпляр базы данных (или другую систему базы данных). Использование репликации позволяет восстановить данные, которые могли быть потеряны из копии в памяти, из реплицированной копии.
Все ли встроенные базы данных также находятся в памяти?
Встроенная база данных может быть определена как ядро базы данных , которая работает в рамках приложения , и не требует других процессов , которые будут установлены, настроены или доступ. Носители данных, которыми управляет механизм, зависят от реализации.
Первоначально большинство движков баз данных использовали жесткий диск для хранения данных, так как объем доступной памяти не позволял разместить достаточный объем данных для полезных наборов данных. По мере увеличения размера памяти многие производители начали добавлять возможности оперативной памяти. Сегодня многие механизмы баз данных, встроенные или традиционные, имеют некоторую поддержку оперативной памяти.
Узнайте о том, как Raima предоставляет высокопроизводительные портативные решения для встроенных баз данных и мобильных баз данных .
Raima Database Manager Version 14.1 In-memory Database Engine Техническое описание
Содержание
By Jeffrey R. Parsons, Chief Engineer – January 2019
Raima Database Manager (RDM) v14.1 содержит совершенно новый механизм хранения данных, оптимизированный специально для работы с наборами резидентных данных в памяти. Этот новый компонент базы данных в памяти (IMDB) позволяет значительно повысить производительность и снизить требования к обработке по сравнению с механизмом на диске. База данных RDM IMDB работает вместе с механизмом RDM на диске, и базы данных можно открывать с помощью любого из них. В этом документе описывается использование, сильные стороны и ограничения RDM IMDB, чтобы разработчик мог знать, когда его следует использовать.
ИСПОЛЬЗОВАНИЕ RDM IMDB
RDM IMDB разработан таким образом, чтобы быть очень простым в использовании. Нет необходимости в проприетарных ключевых словах в схеме базы данных для использования IMDB вместо движка на диске. Вместо этого разработчик устанавливает опцию перед открытием базы данных для настройки и использования IMDB. Это позволяет использовать одну и ту же базу данных либо с дисковым движком, либо с IMDB.
Параметры конфигурации IMDB
При открытии базы данных доступно несколько параметров для настройки механизма хранения RDM. Если значение параметра не задано, RDM по умолчанию использует механизм на диске. Различные конфигурации сообщают движку, какие действия следует выполнять при первом открытии базы данных и при закрытии базы данных последним клиентом, который ее открыл. Все клиенты, у которых база данных открыта одновременно, должны использовать одни и те же параметры конфигурации хранилища. Кроме того, требуется, чтобы клиенты, одновременно открывающие базу данных, использовали идентичную схему (или вообще не использовали схему). Поддерживаются следующие параметры конфигурации хранилища
На диске
Когда первый клиент открывает базу данных без заданного параметра конфигурации хранилища или для параметра конфигурации хранилища
установлено значение “ondisk”, будет использоваться механизм на диске.
Переменная в памяти
Когда первый клиент открывает базу данных с параметром конфигурации хранилища, установленным в “inmemory_volatile”, вновь созданная база данных считается “выброшенной”. Содержимое базы данных будет сохранено только программным вызовом API rdm_dbPersistInMemory. Когда последний клиент закроет базу данных, все изменения, внесенные с момента последнего вызова rdm_dbPersistInMemory, будут удалены. Если не было сделано никаких вызовов rdm_dbPersistInMemory, то вся база данных будет удалена. Файловый сервер транзакций RDM (TFS) поддерживает счетчик открытых данных, чтобы определить, когда база данных впервые открыта и когда она больше не используется клиентами.
Более подробную информацию о TFS RDM можно найти здесь.
Загрузка в память
Когда первый клиент открывает базу данных с параметром конфигурации хранилища, установленным в “inmemory_load”, TFS RDM будет искать idindex и файл пакета на диске. Если они будут найдены, база данных в памяти будет загружена с текущим содержимым файлов на диске. Когда последний клиент закроет базу данных, любые обновления не будут автоматически записываться в файлы на диске. Изменения могут быть сохранены программно с помощью API rdm_dbPersistInMemory.
Удержание в памяти
Когда первый клиент открывает базу данных с параметром конфигурации хранилища “inmemory_keep”, она будет открыта без каких-либо строк в таблицах. Когда последний клиент закроет базу данных, все добавленные строки будут записаны в файлы на диске. Все содержимое любых существующих файлов на диске будет заменено содержимым в памяти. Это также верно, если вызывается API rdm_dbPersistInMemory.
Сохранение в памяти
Когда первый клиент открывает базу данных с параметром конфигурации хранилища, установленным в “inmemory_persist”. TFS будет искать файл idindex и пакета на диске. Если они будут найдены, база данных в памяти будет загружена с текущим содержимым файлов на диске. Когда последний клиент закроет базу данных, все измененные строки будут записаны в файлы на диске. В любое время изменения могут быть сохранены программно с помощью API rdm_dbPersistInMemory, в этом случае на диск необходимо будет записать только изменения, внесенные с момента последнего сохранения базы данных.
Открытие базы данных
Параметры конфигурации задаются для RDM с помощью пар key/value. В то время как различные наборы API RDM имеют функцию для указания пары key/value конфигурации, пары, используемые для настройки, согласованы во всех API. Ключ, используемый для указания конфигурации механизма хранения при открытии базы данных, называется “storage”. Если база данных не открыта на хостинге TFS, она будет открыта с указанным значением конфигурации хранилища. Если база данных уже открыта на хостинге TFS, то указанное значение конфигурации хранилища должно соответствовать используемой в настоящее время конфигурации хранилища. Клиент, который запрашивает открытие базы данных с использованием значения конфигурации хранилища, отличного от используемого в настоящее время, получит код ошибки error code.
Поддерживаются следующие значения хранилища :
Value | Setting | Meaning |
ondisk | “storage=ondisk” | Используйте дисковый движок |
Inmemory_volatile | “storage=inmemory_volatile” | Используйте механизм inmemory. База данных пуста, когда ее открывает первый клиент, и все содержимое удаляется, когда последний клиент закрывает ее. |
Inmemory_load | “storage=inmemory_load” | Используйте механизм inmemory. Содержимое базы данных загружается с диска, когда первый клиент открывает ее, и содержимое не сохраняется автоматически, когда последний клиент закрывает ее. |
Inmemory_keep | “storage=inmemory_save” | Используйте механизм inmemory. База данных пуста, когда ее открывает первый клиент, и все строки в базе данных будут записаны на диск, когда последний клиент закроет ее. Любые существующие файлы на диске будут перезаписаны содержимым базы данных в памяти. |
Inmemory_persist | “storage=inmemory_persist” | Use the in-memory engine. The database contents are loaded from disk when the first client opens it and contents are automatically saved when the last client closes it. |
Core API
API ядра RDM использует API rdm_dbSetOption для установки параметров механизма хранения. Этот параметр необходимо установить до открытия базы данных. параметр необходимо установить до открытия базы данных.
RDM_RETCODE coreOpenDbInMemory( RDM_TFS *pTfs,
RDM_DB *pDb)
{
RDM_RETCODE rc; RDM_TFS tfs = NULL; RDM_DB db = NULL;
rc = rdm_rdmAllocTFS("", &tfs); if (rc == sOKAY)
{
rc = rdm_tfsAllocDatabase(tfs, &db); if (rc == sOKAY)
{
rc = rdm_dbSetOptions(db, "storage=inmemory_volatile"); if (rc == sOKAY)
{
rc = rdm_dbOpen(db, "testdb", RDM_OPEN_SHARED);
}
}
}
if (rc != sOKAY)
{
rdm_dbFree(db); rdm_tfsFree(tfs);
}
else
{
*pTfs = tfs;
*Db = db;
}
return rc;
}
SQL API
API SQL RDM использует API параметров набора rdm_sql для настройки параметров механизма хранения. Этот параметр необходимо установить до открытия базы данных.
RDM_RETCODE sqlOpenDbInMemory( RDM_TFS *pTfs,
RDM_SQL *pSql)
{
RDM_RETCODE rc; RDM_TFS tfs = NULL; RDM_SQL sql = NULL;
rc = rdm_rdmAllocTFS("", &tfs); if (rc == sOKAY)
{
rc = rdm_tfsAllocSql(tfs, &sql); if (rc == sOKAY)
{
rc = rdm_sqlSetOptions(sql, "storage=inmemory_volatile"); if (rc == sOKAY)
{
rc = rdm_sqlOpenDatabase(sql, "testdb", RDM_OPEN_SHARED);
}
}
}
if (rc != sOKAY)
{
rdm_sqlFree(sql); rdm_tfsFree(tfs);
}
else
{
*pTfs = tfs;
*pSql = sql;
}
return rc;
}
ODBC
API ODBC использует API SQLSetConnectAttr для установки атрибутов дескриптора подключения. Атрибут
SQL_ATTR_RDM_SQL_OPTIONS может задавать режим памяти, используя строку параметра “inmemory=».
SQLRETURN odbcOpenDbInMemory( SQLHENV *phEnv,
SQLHDBC *phCon)
{
SQLRETURN ret;
SQLHENV hEnv = SQL_NULL_HENV; SQLHDBC hCon = SQL_NULL_HDBC;
ret = SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &hEnv); if (ret == SQL_SUCCESS)
{
ret = SQLSetEnvAttr(hEnv, SQL_ATTR_ODBC_VERSION, (SQLPOINTER)SQL_OV_ODBC3, 0); if (ret == SQL_SUCCESS)
{
ret = SQLAllocHandle(SQL_HANDLE_DBC, hEnv, &hCon); if (ret == SQL_SUCCESS)
{
ret = SQLSetConnectAttr(hCon, SQL_ATTR_CURRENT_CATALOG, “testdb”, SQL_NTS);
if (ret == SQL_SUCCESS)
{
ret = SQLSetConnectAttr(hCon, SQL_ATTR_RDM_SQL_OPTIONS,
“storage=inmemory_persistent”, SQL_NTS);
if (ret == SQL_SUCCESS)
{
ret = SQLConnect(hCon, SQL_EMPSTR, SQL_NTS, SQL_EMPSTR, SQL_NTS, SQL_EMPSTR, SQL_NTS);
}
}
}
}
}
if (ret != SQL_SUCCESS)
{
SQLFreeHandle(SQL_HANDLE_DBC, hCon); SQLFreeHandle(SQL_HANDLE_ENV, hEnv);
}
else
{
*phCon = hCon;
*phEnc = hEnv;
}
return ret;
}
ФОРМАТ ХРАНЕНИЯ НА ДИСКЕ против ФОРМАТ ХРАНЕНИЯ IMDB
Хранилище на диске
Физически база данных RDM на диске состоит из набора файлов, хранящихся вместе в подкаталоге корневого документа сервера транзакций RDM (TFS). Подкаталог назван в честь базы данных с суффиксом “.rdm». Типы файлов, содержащихся в каталоге базы данных, следующие
- Один файл каталога (c00000000.cat), содержащий метаданные базы данных в формате JSON
- Один или несколько файлов пакета (p00000000.pack), содержащих объекты базы данных
- Один или несколько файлов idindex (i00000000.idindex), содержащих индекс с размером и расположением объектов базы данных в файле (- ах) пакета.
- Один или несколько файлов журнала (j00000000.journal), содержащих журнал обновлений idindex
- Один или несколько временных временных файлов, используемых для обработки транзакций
Логически, база данных RDM организована в ряд ящиков. Выдвижной ящик-это логическая группировка аналогичных типов объектов базы данных. У каждой таблицы будет ящик, содержащий все объекты строк для этой таблицы. Там будет отдельный ящик для каждой таблицы, определенной в базе данных. В ящике будет храниться только один тип объекта, и каждый объект базы данных будет индексироваться значением идентификатора объекта. Типы объектов базы данных включают :
- Rows Строки
- B-tree Nodes Узлы B-Tree
- Hash buckets Хэш
- References Ссылки
- Variable data chunks (binary, char, or widechar) Блоки переменных данных (двоичные, символьные или расширенные)
Ящик содержит записи, сохраненные в файле (- ах) idindex, чтобы определить, где находятся объекты ящика в файле (- ах) пакета. Когда запрашивается конкретный объект базы данных, механизм попросит TFS выполнить поиск объекта на основе ящика и идентификатора объекта. TFS будет искать в записях idindex указанный ящик, пока не найдет идентификатор запрошенного объекта. Запись idindex содержит как смещение, так и размер объекта в файле пакета. TFS считает данные объектов из файла пакета и отправляет их обратно во время выполнения для декодирования.
Когда объект обновляется. сначала данные будут записаны в файл пакета в смежном расположении. Кэш журнала и idindex будет обновлен с учетом нового местоположения и размера объекта. Фактическая запись idindex в файле idindex будет обновлена позже. Если произойдет сбой, idindex будет обновлен во время обработки восстановления.
Концепция пакета, idindex, журнала-это очень эффективный метод хранения объектов базы данных на диске. Он был разработан и настроен специально для того, чтобы быстро находить и эффективно обновлять большие наборы данных. При ведении журнала TFS не нужно записывать несколько копий данных — ему просто нужно зарегистрировать новое местоположение объекта. Большинство новых объектов будут записаны в конец файла пакета, и внутренние алгоритмы повторного использования пространства устанавливают приоритет при размещении нескольких обновлений в одном блоке. Однако при работе с необработанными наборами данных в памяти все эти разработки и реализации, которые делают этот подход эффективным для дисковой системы, являются ненужными накладными расходами.
Объекты In-memory
Возможно, самое важное различие между базами данных в памяти и дисковыми базами данных заключается в том, что при доступе к объектам в памяти нет необходимости считывать объекты в кэш с диска. Все блокировки, индексирование, упаковка и ведение журнала, необходимые для постоянных таблиц на диске, не нужны для аналогов в памяти. Фактически, хотя логическое представление IMDB аналогично традиционному движку на основе дисков, реализация имеет только каталог и идентификатор. Пакет и журнал необходимы только для баз данных в памяти, которые будут сохранены на диске.
Механизм хранения в памяти поддерживает идентификатор idindex для каждого ящика в базе данных. Подобно движку на основе диска, idindex используется для поиска определенного объекта. Однако вместо того, чтобы быть файлом, который кэшируется в TFS, индекс в памяти хранится полностью в памяти. Кроме того, idindex в памяти не содержит смещения и размера объекта, но содержит указатель на сам объект.
Чтобы получить доступ к объекту базы данных, среда выполнения попросит TFS просмотреть его на основе ящика и идентификатора объекта. TFS будет искать idindex указанного ящика для запрошенного объекта. Как только он найдет запись idindex для строки, ему просто нужно отправить информацию обратно во время выполнения. Если среда выполнения находится в тех же пространствах памяти, что и TFS, ей нужно только отправить указатель на данные объекта. Если среда выполнения находится в отдельном пространстве памяти, она отправит копию данных объекта.
Обновление объекта более эффективно с помощью механизма в памяти. Движку в памяти не нужно отслеживать блоки для повторного использования, но он обновит существующий буфер памяти или перераспределит буфер памяти, если размер объекта увеличился. Поскольку механизм в памяти использует диспетчер памяти RDM для оптимизации распределения и отслеживания памяти, перераспределение, как правило, не требует доступа к ресурсам операционной системы.
Rows
Строки упорядочиваются, идентифицируются и связываются друг с другом с помощью виртуального ключа в идентификаторе объекта. Идентификатор объекта для объекта строки называется идентификатором строки. Файловый сервер транзакций RDM (TFS) поддерживает индекс в файле индекса по идентификатору строки для каждой таблицы. Этот индекс позволяет TFS находить информацию о строке и возвращать ее в механизм выполнения для обработки.
Packed Row Format
Чтобы уменьшить объем данных, считываемых/записываемых на диск, стандартный механизм хранения RDM на основе дисков использует формат “упакованных” строк. Этот формат упаковывает строку в поток байтов, который является компактным и переносимым для разных семейств процессоров. Чтобы преобразовать строку в этот формат пакета, механизм хранения выполняет ряд преобразований данных :
Целочисленные данные преобразуются в переменный целочисленный формат. Формат переменной целого числа не зависит от порядка байтов и определяется в зависимости от сохраненного значения, а не от типа столбца. Целое значение 10 будет храниться в одном и том же количестве байтов независимо от того, является ли столбец INT, SMALLINT или BIGINT.
Типы с плавающей запятой преобразуются в сетевой порядок байтов
Все символьные строки хранятся в формате UTF-8, а завершающий NULL символ (и все байты после NULL) не сохраняются. Вместо этого столбец символов будет храниться с переменной целочисленной длиной в байтах, за которой следуют соответствующие символы UTF-8
• Двоичные типы хранятся с переменной целочисленной кодированной длиной байта, за которой следуют данные столбца
• Все данные заголовка строки хранятся в целочисленном формате переменной.Таблица 1: Формат упакованной строки RDM
AVL Data
Reference Data
Column Data
AVL Data
Данные AVL состоят из
- * Вариант (целое число переменной без знака) кодирует количество записей AVL в строке
- * Для каждой записи ACL в строке содержится следующая информация
o Кодированный вариант идентификатора ключа Key ID, идентифицирующего AVL
o Вариант кодированного идентификатора строки RowID, идентифицирующего левую строку AVL
o Кодированный в варианте идентификатор строки RowID, идентифицирующий правую строку AVL
o Значение флага кодирования варианта
Более подробную информацию можно найти в разделе, описывающем RDM AVL
Reference Data
Справочные данные состоят из
- * Вариант кодированного количества ссылок в строке
- Для каждой ссылки имеется следующая информация
o Кодированный вариант идентификатора ссылки Reference ID, идентифицирующий ссылку
o Кодированный в варианте идентификатор строки RowID, идентифицирующий указанную (основную) строку
Column Data
Данные столбца состоят из одной или нескольких групп столбцов. Каждая группа содержит информацию об идентификаторах непрерывных столбцов. Группы столбцов используются для того, чтобы нам не нужно было хранить информацию о столбцах, имеющих нулевые значения. Если столбец равен НУЛЮ, мы не будем помещать данные в строку. Кроме того, если столбец удален, нам не нужно изменять строки, хранящиеся на диске. Удаленные столбцы будут просто проигнорированы, когда столбец будет распакован
- • * Вариант кодированного количества столбцов в группе
• * Варианты кодируют ID начальных столбцов для группы
• Для каждого столбца в группе
o Кодированное значение столбца
Упакованная строка также может быть сжата и зашифрована.
Расширенный ROW Format
Во многих аспектах формат упакованных строк не подходит для базы данных в памяти. Кодирование/декодирование, необходимое для использования строк в упакованном формате, имеет важное значение для наборов данных в памяти. Если только база данных не запущенав среде с ограниченным объемом памяти или разделяемой между процессорами, использующими другой порядок байтов, предпочтительно использовать Expanded Row Format (расширенный формат строк), соответствующий внутреннему формату, используемому средой выполнения.
- Целочисленные данные хранятся в размере, указанном в схеме, и в порядке байтов машины, открывшей базу данных.
- Данные с плавающей запятой хранятся в порядке байтов машины, открывшей базу данных.
- Символьные строки хранятся в формате и полном размере, указанных в схеме. Для строк с широкими символами порядок байтов будет соответствовать порядку машины, открывшей базу данных.
- Двоичные типы хранятся в полном размере, указанном в схеме
Таблица 2: Расширенный формат строки RDM
Row Header
| Row Data
|
Заголовок строки состоит из
- * 32-разрядное целое число без знака, указывающее размер данных строки, из которых состоят необработанные данные
- * Массив структур RDM_AVL (по одной для каждого AVLindex, определенного в схеме)
- Массив структур RDM_JOIN (по одной для каждой таблицы, на которую ссылается строка)
- Массив значений VAL_STATUS (по одному для каждого активного столбца в строке)
- Массив байтов данных столбцов на основе структуры таблицы, определенной схемой
Расширенный формат строк идеально подходит для базы данных в памяти, поскольку он практически не требует обработки при перемещении строки из TFS во время выполнения. Фактически, в тех случаях, когда TFS и среда выполнения выполняются в одном и том же пространстве памяти, среда выполнения может напрямую считывать память из TFS. Среде выполнения потребуется создать копию строки только в том случае, если ей потребуется выполнить обновление.
ДИЗАЙН В RDM 14.1
Хотя причиной создания Raima механизма хранения данных с полной памятью была низкая производительность, для разработки продукта было несколько ключевых
конструктивных соображений. Эти соображения были:
1. Сделайте его простым в использовании.
2. Сделайте его эффективным
Простота использования
Существует множество подходов для обеспечения простоты использования. Чтобы сделать RDM IMDB простым в использовании, решение о том, использовать ли диск или механизм IMDB, принимается во время выполнения, а не во время компиляции или разработки. Помимо установки режима перед открытием базы данных, используются одни и те же интерфейсы разработки и API, независимо от того, хранится ли база данных на диске или в памяти. Однако внутри движка все обстоит совсем по-другому, поскольку формат хранения, требования к ведению журнала, структуры данных и алгоритмы будут адаптированы к эффективной реализации в памяти.
Эффективность
База данных на диске предполагает чтение и запись данных, хранящихся на медленном носителе (относительно основной памяти).
Дисковый движок тратит много ресурсов, уменьшая объем данных, которые необходимо записать, и оптимизируя формат этих данных для эффективного доступа к диску. Когда необходимость физического доступа к более медленным носителям данных устраняется, механизм должен быть достаточно эффективным, чтобы воспользоваться этим преимуществом для обеспечения более высокой
производительности. RDM IMDB повышает эту эффективность за счет
- Использование реализации расположения объектов базы данных, оптимизированной для резидентных данных в памяти
- Использование формата хранения, специфичного для наборов резидентных данных в памяти
- Использование формата хранения объектов базы данных, соответствующего формату, используемому внутри ядра
- Предоставление дополнительных алгоритмов индексирования, оптимизированных для наборов данных в памяти.
- Предоставление альтернативных реализаций для универсальных алгоритмов индексирования, оптимизированных для наборов данных в памяти.
- Таблица ведения журнала изменяется только по требованию
РАЗРАБОТКА ТАБЛИЦ ДЛЯ ИСПОЛЬЗОВАНИЯ RDM IMDB
Индексация
B-Tree
Метод индексирования по умолчанию для RDM-это B-Tree. B-Tree -это самобалансирующаяся древовидная структура, которая упорядочивает данные для обеспечения как поиска, так и последовательного доступа. Вставки, удаления, обновления и поиск могут выполняться в логарифмическом масштабе. B-Tree является хорошим решением для баз данных на диске, поскольку ширина узлов B-Tree может уменьшить глубину дерева узлов по сравнению с самобалансирующимся двоичным деревом. Это приводит к уменьшению доступа к диску, необходимого для поиска и обновления дерева.
Реализация B-Tree RDM представляет собой некластеризованное внешнее дерево, отсортированное по значениям столбцов, указанным в определении индекса. В узле B-Tree есть запись для каждой строки таблицы, из которой получен индекс. Узлы идентифицируются по их идентификатору объекта, называемому идентификатором узла для объектов узла. Это позволяет эффективно реализовать реализацию для баз данных, использующих либо движок на диске, либо IMDB. В обоих движках ссылки на идентификатор узла будут отображаться через индекс идентификатора для ящика, в котором хранится B-Tree. В движке на диске идентификатор-индекс будет содержать смещение и размер узла в файле пакета. В IMDB индекс идентификатора будет содержать указатель на узел. Реализация B-Tree RDM использует размер узла 32 элемента; однако в TFS будут храниться только используемые элементы. Узлы B-Tree RDM никогда не обновляются; вместо этого создается новый узел и обновляется индекс идентификатора, указывающий на местоположение нового узла. Старый узел будет доступен для повторного использования в последующих транзакциях.
HASH
Реализация хэша в RDM 14.1 была обновлена для использования расширяемого алгоритма хэширования. Расширяемый алгоритм хэширования не требует, чтобы разработчик угадывал мощность индекса во время разработки. Это важно для механизма хранения в памяти, так как нет необходимости резервировать память для набора сегментов, которые могут никогда не использоваться. Вместо этого по мере увеличения количества сегментов в хэше размер каталога будет увеличиваться. Текущая реализация допускает только уникальные ключи и упорядочивает данные на основе столбцов с ключами (данные организованы на основе хэша этих столбцов). Это означает, что хэш можно использовать для поиска, но нельзя использовать для последовательного доступа или диапазонов.
AVL
В RDM 14.1 добавлен алгоритм индексирования, специально предназначенный для использования механизмом хранения в памяти, называемым деревом AVL. AVL-это самобалансирующееся двоичное дерево, которое в RDM реализовано внутри строки, а не снаружи. В AVL нет дублирования данных, так как, в отличие от B-Tree, внешние узлы, содержащие копии индексированных столбцов, не поддерживаются. AVL-это двоичное дерево, что означает, что глубина дерева будет намного больше, чем у B-Tree. По этой причине индекс AVL лучше подходит для механизма хранения в памяти, использующего расширенный формат строк, чем Механизм на основе диска, использующий формат упакованных строк. Формат упакованных строк действительно содержит реализацию индекса AVL, но он включен в первую очередь для сохранения образа в памяти на диске и не предназначен для общего использования в дисковых таблицах.
AVL может использоваться для любых операций, для которых будет использоваться индекс B- Tree. AVL поддерживает поиск, диапазоны, сканирование и как повторяющиеся, так и уникальные ограничения. Оптимизатор SQL будет использовать AVL таким же образом, как и B-Tree, но будет использовать несколько иной вес, основанный на различиях в реализации между B- Tree и AVL.
R- Tree
В RDM 14.1 также добавлен алгоритм индексирования, разработанный специально для геопространственных данных, называемый R- Tree. Это сбалансированное дерево поиска, которое организует свои данные по страницам и предназначено для группировки близлежащих объектов, а затем представляет их на следующем уровне дерева. Это позволяет быстро извлекать многомерные данные в ограничивающем прямоугольнике.
КРАТКАЯ ИСТОРИЯ ХРАНЕНИЯ ДАННЫХ RDM
В этом разделе дается краткое описание истории механизма хранения RDM.
Оригинальная Конструкция Движка
RDM был первоначально выпущен в 1984 году. Во время первоначального дизайна процессоры были одноядерными (и медленными), дисководы были дорогими (и медленными), а основная память была еще дороже. Конструкция механизма хранения RDM была продиктована этими аппаратными ограничениями, и данные, хранящиеся в механизме, оставались на диске до тех пор, пока не було активного запроса, и только тогда они загружались в основную память. В большинстве случаев запись (строка) оставалась бы в основной памяти лишь короткое время, прежде чем было запрошено что-то еще и запись была отправлена обратно на диск.Методы оптимизации были разработаны с учетом очень ограниченного объема основной памяти и одноядерного процессора.
Настраиваемый Кэш
По мере того как шло время и закон Мура продолжал действовать, стоимость памяти начала снижаться, а количество, доступное для RDM-движка, начало расти. Первой попыткой воспользоваться преимуществами всей этой памяти было разрешить кэш RDM иметь настраиваемый размер. Разработчик может оценить, насколько большой будет его база данных, и запросить кэш, достаточно большой, чтобы вместить большую часть, если не все, данных в кэше времени выполнения. Данные будут считаны с диска при первом запросе, и им не грозит замена на диск при считывании других данных. Это имело преимущества в производительности, но только для довольно ограниченного набора вариантов использования (в основном для приложений с интенсивным чтением для одного пользователя). Поскольку базовый движок по-прежнему был основан на диске, все изменения требовали записи данных на диск, часто несколько раз, если было включено ведение журнала. Кроме того, другие клиенты могут обновить базу данных и аннулировать часть (или весь) большого кэша.
Эмулируемая Файловая система
Наиболее дорогостоящей операцией при работе с дисковой базой данных является очистка, при которой данные записываются на физический носитель в обход любой файловой системы или аппаратного кэша. Для выполнения транзакций, совместимых с ACID, база данных должна периодически выполнять очистку одного (или нескольких) файлов базы данных. Если база данных не требует никаких операций очистки. производительность будет увеличиваться. Для того, чтобы иметь решение, которое использует преимущества большого объема доступной памяти, Raima реализовала виртуальную файловую систему для RDM. Эта файловая система была полностью в памяти, поэтому отличалась от настраиваемого кэша. Преимущества в производительности были как для reading так и для writing. Во многих случаях эта жертва в отношении долговечности транзакций может привести к повышению пропускной способности на порядок.
Потребность в обновлении
Реализация эмулированной файловой системы обеспечивала повышенную производительность для гораздо большего подмножества приложений, но он не достиг уровня производительности, возможного при использовании механизма хранения, разработанного с нуля для поддержки таблиц в памяти. Например, RDM также позволяет разработчику выполнять операции на диске, но избегать всех операций очистки файлов. Несколько вариантов использования могут использовать этот режим работы и работать так же или даже лучше, чем база данных, в которой использовалась реализация виртуальной файловой системы в памяти. Требовалось что-то, что было бы разработано исключительно для резидентных наборов данных в памяти. Этот новый механизм должен был бы хранить данные по-другому и использовать структуры данных и алгоритмы, позволяющие обрабатывать данные гораздо эффективнее, чем дисковый механизм.
ОГРАНИЧЕНИЯ
Существует несколько ограничений для баз данных, использующих механизм в памяти, по сравнению с базами данных, использующими традиционный дисковый механизм. Эти ограничения, как правило, связаны с проектными решениями, принятыми по соображениям производительности.
Динамический DDL
Динамическое изменение схемы не поддерживается для баз данных, открытых в памяти в RDM версии 14.1. Планируется добавить эту возможность в будущем обновлении.
Совместимость данных
Данные в механизме в памяти хранятся в формате, определенном для конкретной платформы. Все клиенты, обращающиеся к базе данных с помощью IMDB, должны использовать одинаковое выравнивание, порядок байтов и собственный широкосимвольный формат (если база данных содержит столбцы с широкими символами).
Живучесть
При использовании RDM IMDB транзакции не следует считать совместимыми с ACID. Для повышения пропускной способности компонент “D” (долговечность) транзакции приносится в жертву. Другие свойства ACID сохраняются, но изменения в базе данных, работающей в памяти, не регистрируются в журнале. Можно сохранить состояние базы данных в памяти в файлах на диске, чтобы содержимое можно было загрузить при следующем открытии базы данных.
Хотя отдельные транзакции, использующие RDM IMDB, не совместимы с ACID, процесс сохранения базы данных в памяти на диске выполняется. Когда база данных сохраняется, RDM IMDB просматривает все объекты базы данных, которые были вставлены/удалены/изменены с момента последнего сохранения базы данных, и записывает их в файл пакета. Файл idindex на диске обновляется с указанием местоположения и размера объектов в процессе ведения журнала. Как только изменения будут внесены в журнал, они гарантированно будут видны при следующем открытии базы данных.
32-разрядная поддержка
В то время как RDM IMDB поддерживается как в 32-разрядных, так и в 64-разрядных системах, ограничения памяти 32-разрядных систем приводят к значительно меньшему потенциальному размеру набора данных. RDM IMDB может в полной мере использовать большие возможности памяти, доступные в 64-разрядных системах.
Резюме
Механизм хранения данных RDM в памяти обеспечивает возможность работы с базами данных, оптимизированными для хранения всего набора данных в памяти. Организация и формат базы данных специально спроектированы таким образом, чтобы быть эффективными для использования в памяти, чтобы обеспечить производительность, превышающую возможности дискового движка. Отдельные транзакции в базе данных, открытой с помощью механизма в памяти, не являются постоянными, но база данных в целом (или только дельты) может сохраняться по требованию или автоматически при закрытии. Для использования RDM IMDB требуется только установить параметр перед открытием базы данных, после открытия базы данных в памяти все клиенты, использующие эту базу данных, должны использовать одни и те же параметры.