Часть Java Standard Edition, начиная с выпуска Java Development Kit 1.1, API Java Database Connectivity (JDBC) стал отраслевым стандартом для обеспечения доступа к данным на основе стандартов из Java. Он позволяет вам иметь единый API в драйвере подключения к базе данных — будь то Oracle, SQL-сервер или DB2 — и писать код приложения таким образом, чтобы вам не нужно было беспокоиться о базовом источнике данных.
Эволюция драйверов JDBC
Спецификация JDBC API и драйверы, которые он включает, со временем эволюционировали от оригинальных драйверов (Type1) — мостов JDBC-ODBC, которые зависят от драйверов ODBC и собственных библиотек баз данных на стороне клиента и которые сравнительно не имеют функций — к драйверам с собственным протоколом (тип 4), также известным как Direct to Database Pure Java Drivers, которые полностью написаны на Java, независимы от платформы и запускаются на виртуальной машине Java клиента (JVM), не требующей ассоциативного программного обеспечения (такого как как библиотеки) работать. Некоторые драйверы типа 4 также предлагают множество функций — например, единую регистрацию, безопасность Kerberos и проверку подлинности NTLM — в значительной степени для решения проблемы безопасной интеграции драйверов JDBC со сложными серверами приложений и функциями базы данных, ориентированными на корпоративный рынок.
Как бы ни развивалась архитектура драйвера JDBC, эволюция внутри корпоративной Java-экосистемы оставила в ней некоторые неприятные недостатки. По иронии судьбы, одна тенденция, которая помогла сделать приложения, основанные на данных Java, столь распространенными в глобальных ИТ-организациях, также вывела JDBC из радара для многих разработчиков, которые не знают об этих недостатках и / или о том, как их устранить. Эта тенденция — переход от модели доступа к данным, где Java-разработчики программируют непосредственно в JDBC, к модели, в которой они вместо этого используют технологию объектно-реляционного отображения на основе фреймворка (такую как JPA, Hibernate или Spring) или сервер приложений, такой как JBoss, который находится поверх JDBC. С этими более новыми, более доступными моделями данных, которые не разрешают доступ к базовым вызовам JDBC,разработчики почти никогда не задумываются о JDBC или о том, какой драйвер JDBC использовать для определения стратегии доступа к данным.
Однако стоит подумать о драйверах JDBC, используемых в современных сценариях проектирования, развертывания и выполнения корпоративных приложений. В настоящее время оценка драйвера JDBC означает простой выбор драйвера JDBC с наилучшей архитектурой, то есть драйвером JDBC типа 4. Однако до самого недавнего времени типы архитектуры JDBC оставались неизменными перед лицом быстро меняющихся условий ИТ на предприятии. Помимо широкого применения моделей доступа к данным на основе ORM, о которых говорилось выше, некоторые из наиболее масштабных и значительных разработок включают в себя виртуализацию, усовершенствования и новые функции в технологиях баз данных, а также быстрое внедрение инициатив бизнес-аналитики и хранилищ данных:
- Распространение виртуализации как аппаратных, так и программных ресурсов позволило ИТ-организациям обеспечить огромную масштабируемость по доступной кривой роста, придавая гораздо более высокую ценность, чем когда-либо прежде, эффективности и оптимальной производительности во всем стеке приложений.
- Все более сложные функции и функциональные возможности предложений реляционных баз данных, несмотря на высокий спрос со стороны клиентов, часто включают в себя сложные и запатентованные реализации, которые сделали их практически недоступными для большинства приложений.
- А корпоративные организации, использующие единую платформу СУБД в качестве своего хранилища данных, должны перемещать огромные объемы данных из разных систем и обнаруживают, что длительная загрузка данных с использованием пакетных механизмов препятствует подготовке своевременных отчетов бизнес-аналитики.
Ограничения драйверов JDBC типа 4
Несмотря на превосходство над другими типами архитектуры драйверов JDBC, большинство драйверов типа 4 имеют явные ограничения, которые делают их непрактичными в современных средах корпоративных приложений на основе Java. Большинство, например, требуют изменений в коде JDBC приложения для настройки на производительность. Делать это для каждого уникального сценария развертывания приложения неуправляемо и нецелесообразно. Когда вы добавляете ORM сверху, если у вас должен быть метод оператора, зависящий от поставщика, вы не сможете выполнить это приведение без изменения кода ORM. Поэтому, если вы не хотите вносить изменения, скажем, в реализацию Hibernate, вам нужно убедиться, что эти драйверы JDBC чистые, то есть они соответствуют стандарту и в то же время гибко выполняют задачи.
Предположим, вам поручено отслеживать использование памяти приложением, написанным вами в Hibernate. Вы отследили и настроили и думаете, что сможете выжать больше из своих драйверов баз данных Oracle. Для этого конкретного примера мы скажем, что нам нужно настроить привязки параметров.
Чтобы более точно контролировать объем памяти, выделяемый драйвером для каждого параметра в PreparedStatement с помощью тонкого драйвера Oracle, необходимо использовать метод OraclePremparedStatement.defineColumnType () (который не является частью спецификации JDBC).
Листинг 1
PreparedStatement pstmt = con.prepareStatement(
"insert into perftest (id, code, descr, insert_user, insert_date)
values (?,?,?,?,?)");
((OraclePreparedStatement)pstmt).defineColumnType(1, Types.INTEGER);
((OraclePreparedStatement)pstmt).defineColumnType(2, Types.VARCHAR, 50);
((OraclePreparedStatement)pstmt).defineColumnType(3, Types.VARCHAR, 100);
((OraclePreparedStatement)pstmt).defineColumnType(4, Types.VARCHAR, 100);
((OraclePreparedStatement)pstmt).defineColumnType(5, Types.TIMESTAMP);
pstmt.setInt(1, count);
pstmt.setString(2, Integer.toString(count));
pstmt.setString(3, "123456789012345678901234567890");
pstmt.setString(4, "TONGUC");
pstmt.setDate(5, new java.sql.Date(System.currentTimeMillis()));
pstmt.execute();
Тем не менее, если при последующем выполнении вам необходимо повторно привязать ваши параметры с использованием больших размеров данных, драйвер будет автоматически урезан до указанного размера — не очень хорошая вещь. Кроме того, из-за того, что Hibernate абстрагирует сами вызовы JDBC, вы теряете возможность настраивать эти вызовы, если не изменяете сам код Hibernate, тем самым преобразуя PreparedStatement в OraclePreparedStatement в процессе. Как правило, это неприемлемо, поскольку изменение кода Hibernate является дорогостоящим, и вы должны дублировать изменения кода каждый раз, когда обновляете используемую вами версию Hibernate.
Гораздо менее затратный вариант — настроить память на уровне драйвера JDBC, где можно указать параметры подключения, чтобы задать начальный размер для каждого параметра. Это простое решение избавит вас от необходимости изменять код Hibernate для настройки приложения, а также может — с помощью автоматической настройки драйвера для размера параметра — снять ограничение на усечение данных при последующих выполнениях и связываниях, избавляя вас от необходимости тратить время на анализ каждой привязки параметров.
Одно из обещаний, которое не удалось реализовать типичной архитектуре драйвера типа 4, — простое и несложное развертывание. Это что угодно, но. Несколько файлов JAR необходимы для поддержки развертывания на разных виртуальных машинах или оборудовании, а также для доступа ко всем поддерживаемым версиям конкретной базы данных. Это ограничение можно преодолеть, упаковав драйвер JDBC в один файл JAR независимо от ИТ-среды, не имея зависимостей от внешних библиотек DLL или общих библиотек или компонентов собственной базы данных вне JVM.
Листинг 2. Пример кода, иллюстрирующий единую (чистую) реализацию.
con = DriverManager.getConnection("jdbc:datadirect:oracle://nc-pgm1;
databaseName=orcl; user=scott; password=tiger;
initialColumnBufferSize=128");
PreparedStatement pstmt = con.prepareStatement(
"insert into perftest (id, code, descr, insert_user, insert_date)
values (?,?,?,?,?)");
pstmt.setInt(1, count);
pstmt.setString(2, Integer.toString(count));
pstmt.setString(3, "123456789012345678901234567890");
pstmt.setString(4, "TONGUC");
pstmt.setDate(5, new java.sql.Date(System.currentTimeMillis()));
pstmt.execute();
Поддержка типичных драйверов Type 4 для критически важных функций баз данных, нацеленных на предприятие, почти всегда ограничена минимальным набором функций. Для многих таких функций требуется собственный код и использование внешних библиотек DLL или общих библиотек — например, обычно используются функции безопасности, объемная загрузка данных, высокая доступность и функции XA. С каждым источником данных, который должно поддерживать приложение, увеличивается объем кода, специфичного для источника данных, который необходимо поддерживать. В большинстве случаев драйвер просто предоставляет любую поддержку этих функций, реализованную на уровне базы данных. Последствия этой стратегии включают неэффективность из-за снижения производительности, использования закрытого кода и требований к лицензированию дорогостоящих технологий кластеризации баз данных.Они могут быть решены с помощью JDBC-совместимых реализаций только на уровне драйвера.
Массовая загрузка и драйверы JDBC
Массовая загрузка, тип функции, которая учитывает ограничения пакетной загрузки данных, упомянутые ранее, заслуживает более пристального взгляда в этом контексте — не в последнюю очередь потому, что у нее есть реальный потенциал для того, чтобы действительно изменить концепцию игры для организаций, внедряющих или планирующих внедрить данные хранилище для отчетов, поддержки принятия решений и анализа данных — иными словами, практически для любой организации корпоративного масштаба.
Традиционно для перемещения очень больших объемов данных требовалось использовать инструмент, называемый средством массовой загрузки или средством массовой загрузки. Примером может служить загрузчик SQL или BCP Sybase SQL Server или команда загрузки DB2. Доступные на протяжении десятилетий, это инструменты, которые люди используют и создают в своей инфраструктуре на бэкэнде. Потребность в данных на предприятии делает такие инструменты необходимыми; однако в свете тенденции к стандартизации данных на единой платформе хранилища возникает вопрос, можно ли использовать эти инструменты стандартным способом. У вас есть загрузчик SQL, BCP и DB2 Load, и все они разные. К этому моменту единственный способ сделать это в любом API был через пакетный механизм, такой как пакеты JDBC. Но пакетные методы непомерно медленны для большинства инициатив хранилищ данных.
Благодаря технологии драйвера JDBC, которая обменивается данными непосредственно в собственных «проводных» протоколах целевых баз данных, технология массовой загрузки, которая уже давно заблокирована в коде C, может быть применена к Java для массовой загрузки даже нереляционных данных с платформы мэйнфрейма в хранилище реляционных данных. , Скажем, у вас есть ключевое приложение в вашей организации, которое хранит свои данные в файле VSAM на мэйнфрейме. Но все ваши инструментальные панели BI и анализ отчетов работают на базе Oracle. Как вы разблокируете эти важные данные и сделаете их доступными для своих аналитиков, чтобы они могли работать с данными, используя свои привычные инструменты?
Вы можете развернуть управляемый событиями сценарий для запуска массовой загрузки в Oracle из файла VSAM при выполнении определенного набора условий. Он выполнит один оператор Select из файла VSAM, передаст ResultSet методу загрузки объекта массовой загрузки для базы данных Oracle и вставит данные. Если вы представите, что для этого потребуется очень много кода, вы ошибетесь. На этом рисунке приведен реальный пример кода, использованного для реализации одного такого сценария.
Рисунок 1. Взгляд на код
В этом примере всего пять строк кода были использованы для извлечения данных из VSAM и массовой загрузки их в базу данных Oracle!
Вывод
Драйверы JDBC Type 4 предлагают лучшую архитектуру и подходят для многих управляемых данными Java-приложений и сценариев. Тем не менее, многочисленные решения, необходимые для устранения серьезных недостатков в требовательных, сложных и сложных корпоративных средах, требуют выхода за рамки того, что обычно предлагает простая архитектура типа 4 — то есть клиентская одноуровневая 100-процентная архитектура Java. Разработанный таким образом драйвер JDBC, который также включает в себя полный набор таких решений, может даже, возможно, быть лучше воспринят как драйвер JDBC «Типа 5». Подводя итог, что водитель «Тип 5» должен предложить:
- Неограниченная производительность . Пропускная способность данных максимальна независимо от среды выполнения или модели доступа к данным.
- Улучшение без кода : функции и возможности можно добавлять, настраивать или настраивать для любого приложения без изменения кода приложения, независимо от времени выполнения или модели доступа к данным.
- Эффективность использования ресурсов . Использование ресурсов ЦП и памяти во время выполнения приложения сведено к минимуму и может быть настроено по мере необходимости для соответствия конкретным параметрам или ограничениям среды выполнения.
- Развертывание «все в одном» : файл JAR с одним драйвером, который максимально упрощает доступ к данным для любой среды Java или приложения.
- Оптимизированный стандарт : для любого поддерживаемого источника данных не требуется никаких собственных расширений спецификации JDBC — «чистая» реализация спецификации.
Такие драйверы JDBC типа 5 действительно позволили бы современным Java-приложениям, управляемым данными, воспользоваться преимуществами многолетних инноваций в функциях баз данных, моделях доступа к данным и технологиях виртуализации — во многих случаях без необходимости изменения кода. Это, в свою очередь, сэкономило бы организациям значительное время и деньги, улучшив их современные Java-приложения, управляемые данными, за счет расширения наборов функций и повышения производительности и надежности без необходимости внесения серьезных изменений в эти приложения.