Сегодня разнообразные открытые СУБД встают лицом к лицу против массивных, неуклюжих и дорогостоящих «корпоративных» систем, таких как SQL Server и Oracle. Часто открытые СУБД прекрасно работают лучше закрытых систем, не уступая даже в функциональных возможностях.
Из всех открытых систем управления базами данных самой умной, производительной и функциональной системой является Postgres, которая заслуженно привлекает всё больше и больше внимания.
Уже одно только название продукта вызывает неподдельный интерес у читателя: «эй, какого чёрта оно так называется?!» На этот вопрос хорошо ответил один из разработчиков — Том Лэйн, в списке рассылки pgsql-novice:
Правильное название — PostgreSQL или Postgres, но не “postgre”. Вероятно, принятое в 1996 году решение назвать систему PostgreSQL вместо простого Postgres является единственной чудовищной ошибкой за всю историю проекта. И я думаю что сейчас уже поздно что-то менять.
Проект Postgres являлся попыткой переработки очень старой СУБД Ingres с целью создания модульной, масштабирумой, производительной системы управления базами данных, удобной для конечного пользователя тех времён. Таким образом предполагалось, что название “POSTgres” будет являться отсылкой к родительскому проекту — “After Ingres”. Так получилось.
Кого это волнует?
В действительности, это волнует не так уж много людей. Бурный рост популярности языка PHP сопровождался достаточно интенсивным развитием более «дружественной» платформы MySQL. Да, проект MySQL развивался значительно быстрее, чем более строгая платформа Postgres. К сожалению, вместо дружественности приходится говорить о глупости.
Это сильное утверждение, но давайте попробуем его обосновать. Например, вот этим видео, что я недавно залил на Tekpub под названием «Опасности MySQL». Приведу краткое содержание видеоролика, если у вас нет возможности или желания его смотреть:
- MySQL, будучи недостаточно строгой СУБД, задорно игнорирует ваши настройки и ограничения целостности (она просто хочет помочь);
- она легко вставит пустую строку
""в колонку с запретом на добавление пустых значений; - она с радостью вставит бесполезные даты (вроде
0000-00-00) в колонки с датами при запрете добавления пустых значений; - она умеет делить на ноль и вернёт
NULLпри вычислении1/0; - она вернёт
NULLпри делении строки на ноль; - если вы попробуете вставить значение
1000в колонку с длиной равной двум, то она просто немного округлит это значение до99.
Всё это должно дать вам повод задуматься об использовании MySQL: эта система не проверяет ваши данные, зато она пытается показаться «удобной» ценой целостности данных. Мне кажется, это довольно плохо.
Если ничего из вышеизложенного не повергло вас в ужас, то у меня есть единственное слово про вас: Oracle.
Быстро, масштабируемо, весело
Функциональность Postgres достаточно обширна, и многие люди даже не подозревают о возможностях этой СУБД. Стоит отметить, что система обладает таким синтаксическим сахаром, как:
- ключевое слово “infinity”, означающее «больше, чем любое введённое значение» — работает для чисел и дат;
- нежные выражения для работы с датами: “today”, “tomorrow”, “yesterday” (и в Postgres 9.2 всё будет ещё лучше);
- замечательные типы данных: массивы, IP-адреса (с поддержкой IPv6), а также пространственные типы данных (линии, квадраты, круги);
- наследование таблиц — хитрая возможность унаследовать одну таблицу от другой;
- полнотекстовый поиск по неструктурированному тексту на естественном языке — из коробки.
Все эти возмножости бессмысленны, если система не в состоянии показывать масштабируемость и высокую производельность. К счастью, с этими вещами у Postgres полный порядок.
У меня есть друг. Его зовут Роб Салливан и он DBA. Вместе с ним мы провели небольшой эксперимент: загрузили в Postgres архив данных StackOverflow, содержащий шесть миллионов текстовых записей. После этого мы расчехлили свои инструменты (для запросов к базе данных) и начали оптимизировать нашу систему, сравнивая её поведение с поведением SQL Server. Postgres не просто показал сравнимую производительность, он во многих случаях значительно превзошёл решение от Microsoft!
Отдельные слова стоит посвятить индексированию. Благодаря наследованию таблиц мы легко можем партиционировать таблицы и выжать из СУБД лучшую производительность благодаря сокращённому объёму индекса. Конечно, это можно реализовать и средствами SQL Server, но эта задача решается не столь очевидно, а также требует приобретения дорогостоящей лицензии.
И это ещё не всё! Прямо из коробки Postgres умеет сжимать таблицы на лету: этот подход получил название “TOAST”, образованный от фразы “Automatic Table Compression”. Благодаря сжатию данных сокращается как расходование ОЗУ, так и объёма дискового пространства.
Благодаря TOAST нам удалось снизить место, занимаемое данными из StackOverflow с двадцати четырёх гигабайт до шести гигабайт, и это довольно серьёзная экономия. Эта возможность бесплатна и включена в стандартную поставку Postgres. Для использования этой возможности в SQL Server необходимо приобрести Enterprise-лицензию.
Пять вещей, которые вы не знаете
О возможностях Postgres можно писать много, очень много. Вместо этого я просто дам вам ссылку на мой доклад с конференции NDC 2012: «Пять вещей, которые вы не знаете о PostgreSQL». В докладе я рассмотрел такие нюансы, как:
- выполнение запросов к Twitter при помощи механизма foreign data wrappers;
- написание функций на JavaScript при помощи движка V8 от Google;
- убойные трюки с MySQL;
- предотвращение блокировок при помощи встроенного в Postgres механизма снимков;
- наследование таблиц;
- чумовые типы данных.
Надеюсь, вам понравится.
Автор: eveel
