Записки программиста

Многие скажут, что сегодня я выступаю в роли Капитана Очевидности, и будут совершенно правы. Тем не менее, в разных мейлинг листах и чятиках то и дело появляются люди с вопросами типа «посоветуйте мне идеальную базу данных, а то у меня 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 внутри.

Созданная в 2008-м году ребятами из Facebook, на сегодняшний день Cassandra (название иногда сокращают до «C*») является одним из наиболее популярных NoSQL решений. Проект полностью написан на Java и успешно используется в IBM, Apple, Netflix, Twitter, Яндексе, CERN, SoundCloud, Rackspace, а также множестве других компаний. Сегодня мы поднимем наш собственный маленький Cassandra-кластер в облаке Амазона, но сначала, как обычно, немного теории.

Couchbase — это документо-ориентированная база данных (не путать с CouchDB и Membase!), интересная своей относительной простотой, исключительной легкостью в настройке и поддержке, высокой скоростью выполнения запросов за счет размещения «горячих» данных в памяти, масштабируемостью, а также автоматическим восстановлением кластера в случае падения машин и рядом других моментов. Например, поддержкой вторичных индексов, вьюх, репликации между дата-центрами (XDCR, как master-slave, так и master-master), обратной совместимостью с Memcached и не только. Написано все это на С/C++ и Erlang. Couchbase используется в AOL, Cisco, LinkedIn и множестве других компаний.

Пожалуй, основной областью применения Go на сегодня является написание серверных приложений. А их трудно представить в отрыве от какой-нибудь базы данных. В этой заметке я опишу создание простой телефонной книги с интерфейсом командной строки и PostgeSQL в качестве хранилища.

Каждый раз одно и то же. Программист что-то там понаписал, его коллега что-то там наревьювил, код вмержен, сторипоинты засчитаны, все здорово, все просто замечательно. Тот факт, что общение с приложением происходит по какому-то протоколу, или что у базы данных есть какая-то схема, почему-то вспоминается в самый последний момент.