H2: Реляционная база данных на Java

Введение

H2 — это реляционная система управления базами данных, написанная на Java. Она может быть встроена в Java-приложения или работать в режиме клиент-сервер. Программное обеспечение распространяется под лицензией Mozilla Public License 2.0 или оригинальной Eclipse Public License с открытым исходным кодом.

История

Разработка движка базы данных H2 началась в мае 2004 года, а первая публикация состоялась в декабре 2005 года. Двигатель базы данных был написан Томасом Мюллером. Он также разработал движок баз данных Java Hypersonic SQL. В 2001 году проект Hypersonic SQL был прекращен, и группа HSQLDB была сформирована для продолжения работы над кодом Hypersonic SQL. Название H2 происходит от Hypersonic 2, однако H2 не использует общий код с Hypersonic SQL или HSQLDB – он создан с нуля.

Использование SQL

Поддерживается подмножество стандарта SQL (Structured Query Language). Основными API программирования являются SQL и JDBC, однако база данных также поддерживает использование драйвера PostgreSQL ODBC, эмулируя сервер PostgreSQL.

Типы таблиц

Можно создавать как таблицы в памяти, так и таблицы на диске. Таблицы могут быть постоянными или временными. Для таблиц в памяти доступны индексы хеш-таблица и дерево, а для таблиц на диске – b-дерево. Все операции манипулирования данными выполняются в рамках транзакций. Реализованы блокировка на уровне таблицы и многоверсионное управление конкурентным доступом. Также поддерживается протокол двухфазной фиксации, однако стандартный API для распределенных транзакций не реализован.

Особенности безопасности

Особенности безопасности базы данных включают в себя: разграничение прав доступа на основе ролей, шифрование паролей с использованием SHA 256 и данных с использованием AES или алгоритма Tiny Encryption Algorithm (XTEA). Криптографические функции также доступны как встроенные функции базы данных. Поддерживаются SSL/TLS-соединения как в клиент-серверном режиме, так и при использовании консольного приложения. База данных обеспечивает защиту от SQL-инъекций посредством обязательного использования параметризованных запросов. В H2 эта функция называется "запрет литералов".

Возможность поиска полного текста

Включены две реализации полнотекстового поиска: собственная и на основе Lucene.

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

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

Облачная версия

С версии 1.1.111 база данных H2 в оперативной памяти может работать в среде Google App Engine.

Проблемы, влияющие на долговечность реляционных баз данных

В документации H2 подробно описывается несколько способов, которыми проблемы в базовом оборудовании и, в частности, в системах электропитания могут повлиять на надежность реляционных баз данных. Согласно документации H2, такие проблемы связаны не только с архитектурой движка базы данных, но и с механизмом кэширования хранилища. Поскольку устройства хранения используют кэш записи для повышения скорости, при отключении электроэнергии данные в кэше устройства теряются. Администраторам необходимо оценивать компромисс между скоростью и риском потери данных с учетом бизнес-требований и тщательно проектировать систему электропитания и ИБП для критически важных серверов. В некоторых случаях можно принудительно часто или даже немедленно сбрасывать кэш хранилища с помощью fsync, что замедляет процесс записи, либо можно принять тот факт, что кэширование в буфере устройства создает определенный риск потери данных при отключении электроэнергии. Эффективность использования fsync ограничена тем, что многие жесткие диски имеют включенное кэширование записи по умолчанию, и в этом случае ни конструкция базы данных, ни настройки операционной системы не могут полностью исключить возможность потери или повреждения данных при внезапном отключении электроэнергии. Работа с настройками операционной системы и аппаратного обеспечения для отключения всего кэширования и записи данных в реальном времени может существенно снизить производительность, поскольку при использовании механических дисков можно будет выполнять лишь около 100 операций записи в секунду. В документации H2 предпринята попытка подробно описать потенциальные проблемы с надежностью (часть ACID), возникающие из-за возможной потери данных зафиксированных транзакций при отключении электроэнергии. Учитывая аппаратные ограничения по сохранению данных при внезапном отключении питания и неэффективность подходов, обычно используемых разработчиками для предотвращения подобных потерь, многие движки баз данных по умолчанию не вызывают FileDescriptor.sync, FileChannel.force или fsync (или их эквиваленты) для каждой фиксации, поскольку это значительно снижает производительность системы, не существенно повышая надежность. В документации HSQLDB упоминаются обходные решения для аналогичного набора проблем. База знаний Microsoft описывает влияние таких проблем, как отключения электроэнергии и кэширование записи, на производительность и надежность. В базе знаний рассматриваются компромиссы между производительностью и уязвимостью кэширования записи на диск, а также настройки, которые администратор может использовать для балансировки этих параметров.

The H2 documentation explains in detail several ways in which problems in underlying hardware and in particular power systems can impact durability of relational databases. According to the H2 documentation, such problems are related not only to the DB engine design, but also to the storage caching mechanism. As storage devices use write cache in order to increase speed, in a situation of power failure, data in the device's cache is lost. Administrators have then to assess the common trade off between speed and data loss risks in the context of the business requirements and must carefully consider the design of the power supply and UPS of critical servers. It is possible in some cases to force the storage to write cache frequently or even immediately using fsync which slows the writing process or one can accept that caching in the device buffer introduces some risk of data loss in case of power failure. The effectiveness of using fsync is limited by the fact that many HDD have write caching enabled by factory default in which case there is nothing about the design or settings of the database nor OS level commands that will be able to eliminate the chance of lost or inconsistent data in the event of a sudden power failure. Working with the OS and hardware settings to disable all caching so as to write data in real time can have significant impacts on performance in that only around 100 write operations per second would be achievable when using spinning disks. The H2 documentation makes an effort to describe in detail potential problems with durability (part of ACID) resulting from the potential data loss of committed transactions in case of a power failure. Considering the hardware limitations regarding preservation of data in the event of sudden power loss and the ineffectiveness of approaches commonly employed by developers to prevent these sorts of losses, many database engines do not by default call FileDescriptor. sync nor FileChannel. force nor fsync or equivalents for every commit because they significantly degrade system performance without significantly increasing durability. HSQLDB documentation references workarounds to a similar set of issues in their documentation. The Microsoft Knowledge Base describes the impact issues like power failures, write caching, etc. can have on performance and durability. The knowledge base discusses the trade offs between performance and the vulnerability of disk write caching as well as settings that an administrator can use to balance these.

Коммунальные услуги

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