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 кодымен ортақ емес. H2 бастапқыда, дербес әзірленді.

SQL-ті қолдану

SQL (Structured Query Language) стандартының бір бөлігі қолдау көрсетіледі. Басты бағдарламалау API-лары SQL және JDBC, алайда деректер базасы PostgreSQL сервері сияқты жұмыс істеу арқылы PostgreSQL ODBC драйверін де қолдайды.

Кесте түрлері

Жадта кестелерді де, дискідегі кестелерді де құру мүмкін. Кестелер тұрақты немесе уақытша болуы мүмкін. Жадтағы кестелер үшін индекс түрлері – хэш-кесте және ағаш, ал дискідегі кестелер үшін – b-ағаш. Барлық деректерді өңдеу операциялары транзакциялық болып келеді. Кесте деңгейінде құлыптау және көп нұсқалы бақылау жүзеге асырылады. 2 кезеңді міндеттеме протоколы да қолдау көрсетіледі, бірақ таратылған транзакциялар үшін стандартты API іске асырылмаған.

Қауіпсіздік белгілері

Деректер қорының қауіпсіздік мүмкіндіктері: рөлге негізделген кіру құқықтары, парольді SHA 256 алгоритмімен, ал деректерді AES немесе Tiny Encryption Algorithm, XTEA алгоритмдерімен шифрлау. Криптографиялық мүмкіндіктер дерекқор ішіндегі функциялар арқылы да қолжетімді. Клиент-сервер режимінде де, консольдік қолданбаны пайдаланғанда да SSL / TLS қосылымдары қолдау көрсетіледі. Деректер қоры параметрленген сұранымдарды міндетті түрде қолдану арқылы SQL инъекциясынан қорғауды қамтамасыз етеді. H2 дерекқорында бұл мүмкіндік "литералдарды өшіру" деп аталады.

Толық мәтіндік іздеу мүмкіндігі

Екі толық мәтіндік іздеу жүзеге асырылуы қоса берілген, біреуі түпкілікті, екіншісі Lucene негізінде.

Жоғары қол жетімділік

Жоғары қолжетімділіктің қарапайым түрі іске асырылған: клиент-сервер режимінде қолданғанда деректер қоры қозғалтқышы ыстық ауысуды қолдайды (бұл әдетте кластерлеу деп аталады). Дегенмен, кластерлік режим ақау болғаннан кейін қолмен қосылуы тиіс.

Бұлтты нұсқасы

1.1.111 нұсқасынан бастап, H2 жадтағы дерекқоры Google App Engine ортасында жұмыс істей алады.

Реляциялық деректер қорларының тұрақтылығына әсер ететін қиындықтар

H2 құжаттамасы негізгі аппараттық жабдықтағы, әсіресе қуат жүйелеріндегі проблемалардың реляциялық деректер базаларының тұрақтылығына қалай әсер ететінін егжей-тегжейлі түсіндіреді. H2 құжаттамасына сәйкес, мұндай проблемалар DB қозғалтқышының дизайнына ғана емес, сонымен қатар сақтау кэшін сақтау механизміне де байланысты. Деректерді сақтау құрылғылары жылдамдықты арттыру үшін жазу кэшін пайдаланатындықтан, қуат жоғалған жағдайда құрылғы кэшіндегі деректер жоғалады. Әкімшілер бизнес талаптарын ескере отырып, жылдамдық пен деректерді жоғалту тәуекелі арасындағы жиі кездесетін компромисті бағалауы керек және маңызды серверлердің қуат көзі мен UPS құрылымын мұқият қарастыруы керек. Кейбір жағдайларда сақтауды деректерді жиі немесе тіпті дереу кэшке жазуға мәжбүрлеуге болады, бұл fsync арқылы жазу процесін баяулатады, немесе құрылғы буферінде кэшке сақтау қуат жоғалған жағдайда деректерді жоғалту қаупін тудырады. fsync қолданудың тиімділігі шектеулі, себебі көптеген қатты дискілерде зауыттық параметрлер бойынша жазу кэші қосулы болады, сондықтан деректер базасының дизайны немесе операциялық жүйе деңгейіндегі командалар кенеттен қуат жоғалған жағдайда деректердің жоғалуына немесе бұзылуына жол бермейді. Операциялық жүйе мен аппараттық параметрлермен жұмыс істеу арқылы барлық кэшке сақтауды өшіру және деректерді нақты уақытта жазу өнімділікке елеулі әсер етуі мүмкін, өйткені айналмалы дискілерді пайдаланғанда секундтына шамамен 100 ғана жазу операциясын орындауға болады. H2 құжаттамасы қуат жоғалған жағдайда міндеттелген транзакциялардың деректерінің жоғалуынан туындайтын тұрақтылық (ACID-тің бір бөлігі) мәселелерін егжей-тегжейлі сипаттауға тырысады. Аппараттық шектеулерді ескере отырып, деректерді сақтау мүмкіндігі күтпеген қуат жоғалған жағдайда және әзірлеушілер қолданатын әдеттегі әдістердің тиімсіздігін ескере отырып, көптеген деректер базасы қозғалтқыштары әдетте әрбір міндеттеме үшін FileDescriptor.sync, FileChannel.force немесе fsync немесе олардың баламаларын шақырмайды, өйткені бұл жүйе өнімділігін едәуір төмендетеді, бірақ тұрақтылықты едәуір арттырмайды. HSQLDB құжаттамасында ұқсас мәселелерге қатысты шешімдер ұсынылған. Microsoft Knowledge Base қуат жоғалған жағдайлар, жазу кэші және т.б. сияқты мәселелердің өнімділікке және тұрақтылыққа қалай әсер ететінін сипаттайды. Білім базасында өнімділік пен дискіге жазу кэшінің осалдығы арасындағы компромисс туралы, сондай-ақ әкімшілер оларды теңестіру үшін пайдалана алатын параметрлер туралы ақпарат берілген.

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.

Коммуналдық қызметтер

Браузерлік консольдық қолданбасы бар кіріктірілген веб-сервер, сондай-ақ серверді іске қосу және тоқтату, дерекқорына сақтық көшірме жасау және оны қалпына келтіруге арналған командалық қатар құралдары мен командалық қатарлық қабықша құралы қоса берілген.