PostgreSQL vs Redis: Making the Right Choice
With the rise of NoSQL databases, a number of falsehoods have flourished regarding how to choose a database engine. This talk focuses specifically on Redis and PostgreSQL, and why one might choose one or the other.
At small scales, we can often get by thinking of database servers as black boxes, but as we scale, the internals and architecture become more and more important. This talk focuses on behavior of these systems at scale and under load.
In this presentation you will learn:
- How Redis and PostgreSQL differ architecturally
- How differences in architecture affect scalability and performance
- Cases here Redis is the clear winner
- Cases where PostgreSQL is the clear winner
Additionally, some notes will be offered in terms of where PostgreSQL can improve in to compete with the sorts of workloads that generally favor Redis.
Слайды
Видео
Видео доступно участникам мероприятия, выполнившим вход в личный кабинет
Другие доклады
-
45 мин
Игорь Мельников Postgres Professional ConsultantПоддержка пакетов Oracle (packages) в СУБД Postgres Pro 15 Enterprise
Одной из основных проблем при миграции с СУБД Oracle на PostgreSQL, являются пакеты PL/SQL.
В СУБД PostgreSQL отсутствует такой функционал - это приводит к необходимости переписывания (вплоть до его редизайна!) кода Oracle PL/SQL на PL/pgSQL.
В новой версии своего флагманского дистрибутива Postgres Pro 15 Enterpise компания Postgres Pro добавила поддержку функциональности пакетов: расширен синтаксис PL/pgSQL и добавлены новые механизмы в среду выполнения хранимых процедур. В докладе речь пойдет идет о поддержке функциональности пакетов в Postgres Pro 15 Enterpise: - группировка типов переменных процедур и функций в пакет; - поддержка секции инициализации пакетов; - поддержка глобальных переменных пакета доступных в течении всей "жизни" сессии.
Также в докладе будут рассмотрены особенности миграции пакетов из Oracle в СУБД Postgres Pro Enterprise.
-
22 мин
Игорь Алов Yandex.Bank SREPgpool-II работа в режиме "Master-Master" или Как должна выглядеть балансировка нагрузки PostgreSQL глазами сетевого инженера.
Одна из базовых задач для высоконагруженных проектов – это «правильно» настроенное распределение нагрузки внутри кластера базы данных (балансировка), которое бы отвечало определенным параметрам SLA. Большинство решений, с которыми я познакомился, в том числе и Pgpool-II, не в полной мере могли соответствовать требованиям бизнеса. Руками и глазами сетевого инженера мы попытаемся улучшить решение от Pgpool-II и настроим его работу в режиме «Master-Master», а так же рассмотрим случаи, в которых без аналогичных решений не обойтись.
-
45 мин
Владимир Липунов ГАИШ МГУ профессорЭкстремальная астрономия
Популярная лекция с картинками о самых мощных во Вселенной явлениях, которые ставят пространство и время в неудобное положение и заставляют раскрывать его тайны мироздания тем, у кого есть пытливый ум и постгрес! Рассказ В.М. Липунова, профессора МГУ, автора известных в мире популярных и научных книг, теоретика, экспериментатора и создателя сети астрономических роботов.
-
45 мин
Альфред Столяров ООО "Еваппс" (EvApps) директорКак мы перевели клиента с Oracle на PostgreSQL до того, как это стало мейнстримом
Импортозамещение не началось в прошлом году после всем известных событий. Его старт датируется 2014 годом. Именно с этого года государственные и окологосударственные компании начали прорабатывать вопрос перехода на рекомендованное ПО. Одна из таких компаний и обратилась к нам еще в 20-м году с проектом перехода с Oracle на PostgreSQL. Данный проект был призван решить накопившиеся архитектурные проблемы (не оптимальное хранение телеметрических данных, сама СУБД работала внутри виртуальной машины), оптимизировать использование дискового пространства (освободить основное хранилище, отладить сохранение архивных данных, обеспечить корректное резервное копирование). Так как система заказчика должна работать бесперебойно 24/7, то требовался переход с одной СУБД на другую без простоев, с одновременной работой обеих для обеспечения пошагового перевода подсистем и возможности контролировать корректность данных. И, само собой, работы нужно было завершить как можно быстрее.
В докладе расскажем, как нам удалось решить этот кейс.