<сарказм> MongoDB правит бал в мире слабо-структурированных данных. Привлеченные в MongoDB инвестиции часто затмевают разум (особенно начинающих и доверчивых) разработчиков, которые с радостью бросаются в океан возможностей, предоставляемых NoSQL (это же круто!). Энтузиазм затихает после осознания того факта, что бесплатно ничего не бывает и надо писать своими руками то, что десятилетиями хорошо работает в традиционных реляционных базах данных, которые прекрасно справляются с нагрузками и данными 99% проектов, и ваш проект не входит в оставшийся один процент. </сарказм>
Мир баз данных за последние годы существенно изменился. Всеместное проникновение Интернет-технологий привело к необходимости работы с большим количеством разнородных данных в реальном времени, к чему традиционные реляционные СУБД оказались не готовы. Принято считать, что слабая масштабируемость и излишняя “жесткость” модели данных реляционных СУБД и являются основными причинами появляния и роста популярности NoSQL баз данных (далее, NoSQL).
В докладе мы остановимся на концептуальных предпосылках появления NoSQL и их классификации. Одним из “жупелов” NoSQL является поддержка типа данных JSON, который реализует документо-ориентированную модель данных. Документо-ориентированная модель данных является более гибкой и позволяет менять схему данных “на лету”, что сделать очень трудно в реляционных СУБД, особенно в системах, работающих под большой нагрузкой. Несмотря на успех NoSQL (активно распиаренный использованием в некоторых популярных Интернет-проектах), многие пользователи не готовы приносить в жертву целостность данных в угоду масштабируемости, но хотят иметь гибкость схемы данных в проверенных и надежных реляционных СУБД.
Темпы роста компьютерной индустрии (процессоры, дисковые подсистемы и сетевые устройства) позволяют большому количеству проектов успешно функционировать на одном сервере и не требовать горизонтальной масштабируемости NoSQL. Более того, при правильном проектировании архитектуры приложения возможно добиться горизонтальной масштабируемости реляционной СУБД, что подтверждает пример Instagram с использованием открытой реляционной СУБД PostgreSQL.
Нами была предложена и реализована поддержка документо-ориентированной модели в PostgreSQL (версия 9.4). Уже более 10 лет в PostgreSQL существует возможность работать со schema-less данными, используя наш модуль расширения hstore. Hstore предлагает хранилище вида "ключ-значение" с сохранением всех реляционных возможностей, что сделало его самым используемым расширением PostgreSQL. Однако, возникающие технологии, основанные на популярном стандарте JSON, требуют от баз данных встроенную поддержку иерархических структур. Мы разработали бинарное хранение для вложенных структур с поддержкой массивов и типов, что позволило реализовать новый тип данных jsonb и гибкий язык запросов jsquery с индексной поддержкой.
Таким образом, открытая СУБД PostgreSQL получила полноценную поддержку JSON и стала серьезным конкурентом MongoDB. Мы также расскажем об экспериментальном новом типе индексного метода доступа VODKA, который дает возможность комбинировать разные существующие индексные методы доступа, что, в частности, позволило эффективно индексировать вложенные структуры. Можно сказать, что VODKA CONNECTING INDEXES!
Результаты наших работ были доложены на международных конференциях разработчиков PostgreSQL и некоторые уже вошли в предстоящий осенний релиз. Работа была поддержана компанией Heroku, которой авторы выражают благодарность.