Мы продолжаем серию статей, посвященных теоретическим и практическим особенностям баз данных. Сегодня мы обсудим еще одну из основных характеристик баз данных – API или прикладной интерфейс программирования.
Характеристики БД: API
Если коротко, API (application programming interface, прикладной интерфейс программирования) представляет собой совокупность неких методов взаимодействия с базой данных. Как водится, классификаций много, но мы предлагаем остановиться на двух основных – внутрипроцессных/внепроцессных API и SQL/NoSQL.
Внутрипроцессные vs внепроцессные интерфейсы
Если БД (по крайней мере, частично) работает внутри клиентского процесса, то ее интерфейс называется внутрипроцессным (in-process API). В этом случае последний располагает библиотекой функций, которые вызывают методы напрямую в процессоре базы данных. Такой механизм снижает время ожидания до минимума и увеличивает пропускную способность до максимума (то есть по максимуму использует предоставленную память). Однако при внутрипроцессном подходе только одно клиентское приложение единовременно имеет доступ к БД, так что API теряет очки в гибкости. Кроме того, подход связан с дополнительным риском: если клиентское приложение зависает или дает сбой, то же происходит со всей БД – ведь они делят один процесс на двоих.
Если же БД работает в отдельном процессе (в этом случае мы говорим о внепроцессном API (out-of-process API), то для доступа к ней обычно используется протокол, основанный на TCP/IP. Многие СУРБД (системы управления реляционными базами данных) – в последнее время и другие виды БД – поддерживают либо ODBC (open database connectivity, открытый механизм взаимодействия с БД), либо JDBC (java database connectivity, соединение с БД на Java). Это упрощает создание клиентских приложений – существует более чем достаточно библиотек, использующих две вышеуказанных технологии. Использование сетевого протокола позволяет значительно увеличить гибкость базы данных (точнее, доступа к ней), но TCP проигрывает по сравнению с прямым доступом в отношении показателей использования памяти и времени ожидания системы.
SQL vs NoSQL
SQL – это декларативный язык, первоначально разработанный для того, чтобы упростить хранение и извлечение данных из реляционных БД. Сегодня его используют повсеместно – поэтому неудивительно, что большинство разработчиков «говорит» на SQL весьма бегло – и это несомненный плюс для внедрения любой БД.
Что касается NoSQL, то самой значительной «инновацией» этого подхода является повышение скорости операций за счет устранения транзакций и реляционных таблиц. Многие из NoSQL баз данных, как ни парадоксально, поддерживают SQL как язык прикладных интерфейсов, хотя изначально не пользовались его реляционными «фишками» — а вот запросы, фильтры и функции агрегации оказались весьма полезны. Отсюда и взялась идея о том, что логичнее было бы переименовать технологию в NoACID (атомарность, последовательность, отделение, сохраняемость) – ведь она не противоречит сути SQL, а просто не поддерживает транзакции. В 2014 году все те же NoSQL БД стали поддерживать и транзакции, поэтому более точным названием для технологии могло бы быть выражение NoRelational – однако закрепившееся за ней и более-менее точное NoSQL так и осталось.
Одна из главных проблем, связанных с использованием SQL, состоит в том, что перед использованием данные должны быть разделены на составные части и скомпилированы процессором БД – а это, естественно, чревато задержками. Большинство процессоров БД и клиентских API решают эту проблему при помощи прекомпиляции или компиляции во время первого прогона, соответственно, функции на базе SQL обращаются к вновь сформированным таблицам. Скомпилированная версия затем сохраняется и используется для будущих обращений.
Еще одна проблема состоит в том, что SQL не может корректно и эффективно описать все виды связей внутри данных – к примеру, это касается иерархической структуры. И еще: в исходной спецификации SQL как декларативного языка не описаны такие крайне важные операции как итерация. В конечном итоге спецификацию пришлось расширить – и современный SQL поддерживает рекурсию, что позволяет работать с итерацией и иерархическими структурами. Кроме того, вендоры добавляют языку собственные нестандартные расширения. Впрочем, эти расширения поддерживаются не везде – и точно так же далеко не все знают, как их применять. Вообще говоря, очень многие базы данных вообще не требуют индексации и агрегации – и тогда причин использовать SQL с его сложными механизмами работы с данными практически не остается. Яркий пример – большинство хранилищ, организованных по принципу «ключ-значение».
Послесловие
В сегодняшнем материале мы подробно обсудили основные виды прикладных интерфейсов, использующихся для хранения, управления и доступа к данным в БД. В следующих статьях речь пойдет о трех оставшихся характеристиках баз данных – транзакциях, персистенции и индексации.
Автор: Лиза Филиппова
В основу статьи легли материалы ACM.
Тоже интересная статья , как и первая, но тут что-то уж как-то сложно было для любительского понимания.
Все равно, СПАСИБО!
Ждем следующих статей!