Для PostgreSQL существует множество так называемых high availability решений, наиболее известными из которых, пожалуй, являются repmgr и patroni. Согласно некоторым отзывам, они не слишком удобны в использовании и иногда могут терять данные. Поэтому сегодня мне хотелось бы рассказать о более новом решении под названием Stolon. Разработка Stolon ведется с сентября 2015-го года. Он написан на языке Go, активно паразитирует на Consul или etcd (на выбор пользователя) и из коробки имеет интеграцию с Kubernetes. Но самое главное — он сравнительно прост в использовании и выглядит очень правильно с точки зрения дизайна системы. При правильном использовании Stolon переживает нетсплиты и не теряет данные.
Недавно я выложил на GitHub ZSON, расширение к PostgreSQL для сжатия JSONB. Сжатие происходит путем анализа существующих в базе документов и создания словаря с наиболее часто встречающимися в документах строками. Притом строки могут быть не только именами ключей, но и значениями в массивах, и так далее. В этой статье на примере ZSON мы разберемся, как вообще пишутся расширения к PostgreSQL, как они покрываются тестами, как происходит их установка и удаление, и так далее.
CouchDB (не путать с Couchbase!) — документо-ориентированная СУБД, написанная на языке Erlang. В вышедшей недавно версии 2.0 в CouchDB добавили Riak-подобное шардирование, что наконец-то делает эту СУБД кому-то интересной. К тому же, в отличие от Riak, в CouchDB всегда была совершенно бесплатная (не в enterprise edition версии и т.д.) кросс-датацентровая master-slave и master-master репликация. Давайте попробуем разобраться, как же этим хозяйством вообще пользоваться, и подходит ли оно уже для продакшена.
Мне нравится Python, а также мне нравится PostgreSQL. И вот я подумал — ей, а почему бы не использовать их вместе? :) Для работы с PostgreSQL в мире Python большой популярностью пользуется пакет psycopg2. Но он, по всей видимости, до сих пор не поддерживает prepared statements. Поэтому для своих задач я пока что остановился на чуть менее популярном пакете py-postgresql. Этот пакет, как я понимаю, поддерживает все, что нужно.
Многие скажут, что сегодня я выступаю в роли Капитана Очевидности, и будут совершенно правы. Тем не менее, в разных мейлинг листах и чятиках то и дело появляются люди с вопросами типа «посоветуйте мне идеальную базу данных, а то у меня SQL тормозит и вообще все говорят, что MongoDB сейчас в моде». C 2007-го года я успел поработать со многими СУБД, не исключая ряда NoSQL решений, и по данному вопросу я имею сказать следующее.
СУБД является важнейшим компонентом многих современных систем. Поэтому совершенно естественным является желание собрать эту СУБД из исходников самостоятельно с флагами -march=native -O3, не говоря уже о куда более тонкой настойке при помощи скрипта configure. В этом случае вы также можете подобрать компилятор, который лучше оптимизирует конкретную СУБД под ваши конкретные задачи. Не исключено также, что готового бинарного пакета нужной вам версии приложения еще попросту не существует. Наконец, умение самостоятельно собирать и настраивать приложение дает куда более лучшее понимание его работы, чем простое запоминание каталогов с конфигами и логами. В силу названных причин, давайте попробуем разобраться, как собрать из исходников PostgreSQL, а затем настроить его для полноценной работы.
Вот многие жалуются, что PostgreSQL сложно масштабировать и нужно быть в нем очень большим специалистом, чтобы настроить обычную master-slave репликацию. По-моему, это все чушь. Не так давно мне потребовалась всего лишь пара часов вдумчивого чтения документации, чтобы во всем разобраться. В этой заметке я постараюсь показать, что с репликацией в PostgreSQL все очень просто. Заодно мы также разберемся, чем потоковая репликация отличается от логической, что такое синхронная и асинхронная репликация, а также как сделать фейловер в случае падения мастера.
Пожалуйста, без паники! Да, РСУБД с открытым исходным кодом — наше все. Но если вы тру программист, то ваше приложение должно поддерживать много разных СУБД, в том числе такую эзотерику, как Microsoft SQL Server :) В этой заметке мы научимся основам работы с Microsoft SQL Server и убедимся, что в действительности он мало чем отличается от тех же PostgreSQL или MySQL.
Некоторое время назад мы с вами успешно разобрались, что такое Cassandra, а также как установить и настроить Cassandra-кластер в облаке от Amazon. В чем мы не разобрались, это в том, как использовать Cassandra в наших программах. Настало время исправить столь вопиющую несправедливость!
На момент написания этих строк существует как минимум два SDK для работы с Couchbase на языках под JVM — как бы старый SDK 1.4 и новый SDK 2.1. SDK версий 1.x основан на spymemcached, и потому практически такой же, включая всякие некрасивости вроде преобразований asInstanceOf. А вот SDK версий 2.x стильный, модный, молодежный, c RxJava внутри.