Ограничения PostgreSql
Существуют следующие ограничения:
Максимальный размер базы неограничен (есть базы на 32 TB)
Максимальный размер таблицы 32 TB
Максимальный размер записи 1.6 TB
Максимальный размер поля 1 GB
Разумеется, понятие "неограниченно" на самом деле ограничивается доступным дисковым пространством и размерами памяти/своппинга. Когда значения перечисленные выше неоправданно большие, может пострадать производительность.
Максимальный размер таблицы в 32 TB не требует чтобы операционная система поддерживала файлы больших размеров. Большие таблицы хранятся как множество файлов размером в 1 GB, так что ограничения, которые накладывает файловая система не важны.
Обзор применения последней версии PostgreSql 8.1.
Версия 8.1 является новым шагом в сторону больших и нагруженных систем, предназначенных для непрерывной работы в режиме 24x7x365. Это подтверждается тем, что большие компании начинают использовать PostgreSQL в реальном бизнесе. Так, Sony Online Entertainment объявила [SOE05] об инвестировании 1.5 млн. USD в Enterprise DB для перехода с Oracle на PostgreSQL 8.1. В России крупнейший оператор сотовой связи компания Вымпелком (Beeline) тестирует ПО работающее с PostgreSQL и находится на стадии заключения контракта на поддержку кластера PostgreSQL. Компания Sun Microsystem объявила [SUN05] об официальной поддержке PostgreSQL (входит в Solaris10), "beta" версия пакетов, оптимизированных для Solaris, уже доступна [SUN06]. Кроме этого, Sun поддерживает PostgreSQL в режиме 24x7.
Традиционно, PostgreSQL широко используется в научных проектах. Так, был запущен проект SAI CAS (Catalog Access Service), в рамках международной программы Virtual Observatory (Виртуальная Обсерватория), как часть проекта Астронет (wwww.astronet.ru), ориентированного на профессиональное астрономическое сообщество и где в качестве СУБД для работы с очень большими астрономическими каталогами (1Tb), используется PostgreSQL 8.1. Сервер БД HP rx1620 (Itanium2) был предоставлен HP Russia.
PGDG
PostgreSQL развивается силами международной группы разработчиков (PGDG), в которую входят как непосредственно программисты, так и те, кто отвечают за продвижение PostgreSQL (Public Relation), за поддержание серверов и сервисов, написание и перевод документации, всего на 2007 год насчитывается около 300 человек. Другими словами, PGDG - это сложившийся коллектив, который полностью самодостаточен и устойчив. Проект развивается по общепринятой среди открытых проектов схеме, когда приоритеты определяются реальными нуждами и возможностями. При этом, практикуется публичное обсуждение всех вопросов в списке рассылке, что практически исключает возможность неправильных и несогласованных решений. Это относится и к тем предложениям, которые уже имеют или рассчитывают на финансовую поддержку коммерческих компаний.
Т.к. при создании интерфейса мне пришлось открывать доступ к своей базе из среды Exlips, то нужно сказать еще и об этом.
Доступ к базам данных из Java-программ
Разумеется, что организовать доступ к базам данных из современного языка программирования в наше время не представляет никакой сложности. Более того, и сами языки программирования более всего оцениваются разработчиками по типу и возможностям заложенных в них средств доступа к базам данных, удобству и полноте интерфейсов. В этом смысле Javaне представляет исключения. Уже в версииJDK1.1 появился пакет классовjava.sql, обеспечивающий больщинство функций, известных к тому времени разработчикамODBC-приложений. В этом пакете содержится ряд замечательных классов, например:java.sql.CallableStatement, который обеспечивает выполнение наJavaхранимых процедур;java.sql.DatabaseMetaData, который исследует базу данных на предмет ее реляционной полноты и целостности с получением самых разнообразных данных о типах и содержимом таблиц, колонок, индексов, ключей и т.д.; наконец, -java.sql.ResultSetMetaData, с помощью которого можно выводить в удобном виде всю необходимую информацию из таблиц базы данных или печатать сами метаданные в виде названий таблиц и колонок.
Однако, коренное отличие Javaот других традиционных языков программирования заключается в том, что одни и те же функции доступа к базам данных, с помощью универсальности и кроссплатформенностиJava, можно организовать чрезвычайно гибко, используя все преимущества современных объектно-ориентированных технологий
1. Java-программы и апплеты с интерфейсом JDBC-ODBC
JDBC (Java Database Connectivity) является не протоколом, а интерфейсом и основан на спецификациях SAG CLI (SQL Access Group Call Level Interface - интерфейс уровня вызова группы доступа SQL).
Сам по себе JDBC работать не может и использует основные абстракции и методы ODBC. Хотя в стандарте JDBC API и предусмотрена возможность работы не только через ODBC, а и через использование прямых линков к базам данных по двух- или трех-звенной схеме (см. Рис.1), эту схему используют гораздо реже, чем повсеместно используемый JDBC-ODBC-Bridge занимающий центральное место в общей схеме взаимодействия интерфейсов (см. Рис. 2)
Рис. 1. Непосредственный доступ к базе данных по 3-х-звенной схеме.
Рис. 2. Схема взаимодействия интерфейсов.
Даже беглого взгляда на Рис. 2 вполне достаточно, чтобы понять - общая схема взаимодействия интерфейсов в Java удивительным образом напоминает столь всем знакомую схему ODBC с ее гениальным изобретением драйвер-менеджера к различным СУБД и единого универсального пользовательского интерфейса. JDBC Driver Manager - это основной ствол JDBC-архитектуры. Его первичные функции очень просты - соединить Java-программу и соответствующий JDBC драйвер и затем выйти из игры. Естественно, что ODBC был взят в качестве основы JDBC из-за его популярности среди независимых поставщиков программного обеспечения и пользователей. Но тогда возникает законный вопрос - а зачем вообще нужен JDBC и не легче ли было организовать интерфейсный доступ к ODBC-драйверам непосредственно из Java? Ответом на этот вопрос может быть только однозначное нет. Путь через JDBC-ODBC-Bridge, как ни странно, может оказаться гораздо короче.
1. ODBC нельзя использовать непосредственно из Java, поскольку он основан на C-интерфейсе. Вызов из Java C-кода нарушает целостную концепцию Java, пробивает брешь в защите и делает программу трудно-переносимой.
2. Перенос ODBC C-API в Java-API нежелателен. К примеру, Java не имеет указателей, в то время как в ODBC они используются.
3. ODBC слишком сложен для понимания. В нем смешаны простые и сложные вещи, причем сложные опции иногда применяются для самых простых запросов.
4. Java-API необходим, чтобы добиться абсолютно чистых Java решений. Когда ODBC используется, то ODBC-драйвер и ODBC менеджер должны быть инсталлированы на каждой клиентской машине. В то же время, JDBC драйвер написан полностью на Java и может быть легко переносим на любые платформы от сетевых компьютеров до мэйнфреймов.
JDBC API - это естественный Java-интерфейс к базовым SQL абстракциям и, восприняв дух и основные абстракции концепции ODBC, он реализован, все-таки, как настоящий Java-интерфейс, согласующийся с остальными частями системы Java.
В отличие от интерфейса ODBC,JDBCорганизован намного проще. Главной его частью является драйвер, поставляемый фирмойJavaSoftдля доступа изJDBCк источникам данных. Этот драйвер является самым верхним в иерархии классовJDBCи называетсяDriverManager. Согласно, установившимся правиламInternet, база данных и средства ее обслуживания идентифируются при помощиURL.
Однако, как уже говорилось выше, чаще всего, все-таки используется механизм ODBCблагодаря его универсальности и доступности. Программа взаимодействия между драйверомJDBCиODBCразработана фирмойJavaSoftв сотрудничестве сInterSolvи называетсяJDBC-ODBC-Bridge. Она реализована в видеJdbcOdbc.class(для платформыWindowsJdbcOdbc.dll) и входит в поставкуJDK1.1. ПомимоJdbcOdbc-библиотек должны существовать специальные драйвера (библиотеки), которые реализуют непосредственный доступ к базам данных через стандартный интерфейсODBC. Как правило эти библиотеки описываются в файлеODBC.INI. На внутреннем уровнеJDBC-ODBC-Bridgeотображает медодыJavaв вызовыODBCи тем самым позволяет использовать любые существующие драйверыODBC, которых к настоящему времени накоплено в изобилии.