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

Помните, как около года назад мы учились работать с базами данных в Haskell при помощи пакета HDBC, а также его форка HDBI, который от HDBC почти ничем не отличается? Тогда я отмечал, что вместо HDBC некоторые предпочитают использовать пакет postgresql-simple. Давайте попробуем разобраться, что это за пакет такой и почему он интереснее, чем HDBC. А также заодно познакомимся с пакетом postgresql-simple-migration.

Итак, мы с вами настроили окружение для программирования на Java. Давайте же теперь попробуем что ли написать на ней какую-нибудь несложную программку, посерьезнее, чем Hello World. Например, программу, которая ходит в реляционную базу данных, выполняет какие-то запросы и получает результат.

Есть два взгляда на распределенные отказоустойчивые системы — теоретический и практический. В то время, как теоретики (a.k.a distributed systems nerds) пиарят так называемые NewSQL базы данных, рассуждают о Paxos и векторных часах, большинство практикующих программистов совершенно закономерно относятся к Spanner и аналогичным решениям с большим скепсисом. А значит, в реальных системах, как правило, все еще используется PostgreSQL и другие традиционные реляционные СУБД.

Дело было вечером, делать было нечего, и я пошел гулять по интернетам в поисках существующих встраиваемых (embedded) баз данных для Erlang. Вот, скажем, есть у нас приложенька, которая работает с небольшими (десяток-другой гигабайт) объемами не саммых ценных в системе данных. Ну не поднимать же Riak кластер только ради этой приложеньки и не таскать же за ней повсюду PostgreSQL? В общем, посмотрел я на существующие решения (DETS, Mnesia, Bitcask, LevelDB, SQLite, Innostore, HanoiDB) и пошел классно писать очередной ненужный KV-велосипед.

Время от времени я заглядываю на toster.ru и иногда даже отвечаю там на вопросы. Чаще всего люди спрашивают две вещи — как стать программистом и как правильно спроектировать схему базы данных. Мне лично кажется очень странным, что так много людей задают последний вопрос. Мне почему-то всегда казалось, что это такая простая вещь, которую умеют вообще все. Но, раз так много людей интересуются, здесь я постараюсь дать достаточно развернутый и в то же время краткий ответ.

Темы третьего выпуска: где используется Erlang, о профессиональной этике, Riak, почему все неправильно понимают CAP-теорему, а также о движении NewSQL и базах данных ActorDB, VoltDB, Spanner, Scalaris, Hibari, RethinkDB, FoundationDB, InfiniSQL и Calvin. Предыдущие выпуски: второй, первый.

В прошлой части мы познакомились с теорией, касающейся устройства Riak. Сегодня же придется запачкать руки — установить и настроить Riak под Ubuntu Linux, а также познакомиться с REST API этой СУБД.

Настало время разобраться, что представляет собой Riak, как установить и настроить его в Ubuntu Linux, а также узнать, как использовать некоторые его возможности через REST API. Эта памятка не заменит вам чтения книг по Riak, но поможет составить общее впечатление об этой СУБД.

Сегодня мы научимся работать с реляционными базами данных из Haskell. Будет написана небольшая «телефонная книга» с CLI, которая будет хранить наши контакты в PostgreSQL. В мире Haskell есть много библиотек для работы с базами данных. Мы воспользуемся HDBC.