Russian Fedora

cообщество русскоязычных участников
международного проекта Fedora

И опять про бинарные логи

Это архивная статья

Gergely Nagy, инженер Balabit (создатели syslog-ng) и участник Debian, попытался объяснить, почему бинарные логи, это хорошо, а текстовые плохо.

Чуда не случилось - анонимные коллеги-аналитики привычно обвинили его в поццерингофилии, в том, что он некомпетентен, не умеет регекспы, и т.п. Мы очень сочувствуем Gergely - он не понимает, почему на технический пост понеслись персональные оценки его личности, и ему это в новинку, походу. Ну, пусть привыкает. Мы регулярно рассказываем, про бинарные логи с примерами, но админы-киборги, читающие логи глазами прямо с секторов жесткого диска, все так же непоколебимо уверены в превосходстве текстовичков и grep.

Weave и flannel

Одной из слабых сторон Docker является просто все. Среди этого недлинного списка особо хочется отметить управление сетью. Когда нужно запустить три разных версии руби (например для сборочных тестов в разных дистрибутивах), все хорошо - отработало, и отвалилось. В более сложных случаях (миграция, например), нужно что-то делать с адресами и портами.

Осознание этой необходимости породило ряд решений по управлению сетевым трафиком внутри гипервизора или между ними. Некоторые проектировались именно с прицелом на Docker, и с пониманием того, что целевая система отстает от Red Hat на несколько лет, а в ряде ключевых моментов, принципиально не поддерживает ряд т.н. "ненужных" фич (например, как в случае упорного игнорирования systemd, мол "ненужно"). Тем не менее, система, повторимся, оказалась популярна, и это давление снизу заставляет проектировать решения в т.ч. и на ее основе. А это накладывает отпечаток на используемые технологии, разрешая полагаться лишь на доступный функционал.

Когда представитель Docker выступал в столице, на YaC 2014, он предложил новый класс компонентов, "Ambassador". Это прокси-сервер (прокси-серверы), принимающий соединения, и обладающий информацией об актуальной топологии распределенной системы, обновляющейся с помощью одного из существующих механизмов service discovery.

Если контейнер мигрируется или перезапускается на другой машине, то Ambassador перевосстановит связь согласно изменившейся топологии. Ни клиент, ни контейнер, предоставляющий сервис, изменений не увидят, и соединение не пострадает. Одно скажем сразу - благодаря этому архитектурному элементу, ряд анонимных коллег-экспертов получил шанс понять, что средства service discovery, даже тот же Avahi, это не "ненужно", а очень даже нужная вещь.

Помимо концепции Ambassador, появились и другие варианты организации сети. Ambassador плох хотя бы тем, что если мы нарисуем схему того, как по нему идут пакеты данных, то увидим несколько нырков из ядра в юзерспейс и обратно. Хорош же он тем, что следуя концепции "лучше сделать быстро, чем хорошо" он прост и в реализации, и в использовании.

Сложность там в основном идет на решение задачи о поддержании актуальной информации о топологии, ну и как то надо решать задачу связности системы (А видит B, B видит С, А и C не соединены напрямую - как передать данные от A к C?).

Надо отдельно упомянуть грустную, но вполне обычную картину слабости горизонтальных связей в больших компаниях. Под укреплением внутрикорпоративных связей девушками, на которых обычно и взваливается непонятная им задача повышения внутрикорпоративного духа, чаще всего понимается некая оффлайновая добровольно-приказная активность (хорошо если с алкоголем, а то порой и без него - нам рассказывали как-то печальную историю корпоративного мероприятия в США, в вегетарианском ресторане), где народ быстро разбивается по привычным кучкам, не изменяя конфигурацию кластера. Чего тут говорить, если на мероприятии Google I/O 2013, разработчики AudioFlinger, аналога Pulseaudio для Android, рассказалли, как они с удивлением ознакомились с подсистемой cgroups, разработанной несколько лет назад их же коллегами, буквально за соседней дверью? Если уж в настолько новаторской компании есть такой неосвоенный ресурс для улучшения ситуации, то что говорить о других? Так вот, в ряде организаций есть нездоровый недостаток общения между программистами / девопсами [STRIKEOUT:и бухгалтерией] и инженерами NOC. Это выливается в то, что там, где можно стукнуть парой команд на Cisco-свитче, программист, не зная о том, что (и не зная как) задачу решили лет 30 назад, упорно долбится с отбойным молотком Golang. Результат скорее всего будет далек от оптимального.

Вариант poor-man's SDN Weave, от одноименной команды из разработчиков RabbitMQ, выглядит интереснее, т.к. помимо всего прочего они обещают решить задачу сложной, многозвенной топологии.

Но какой ценой? Как выяснилось, ценой падения пропускной способности до 6% номинальной, и повышения latency в 4 раза. До 6 процентов от номинала, и в 4 раза, Карл! Можно ли лучше? Можно! Тут то как раз и стоило бы обратиться к опыту коллег из NOC. Инкапсуляция трафика, отказоустойчивость точек его приема и обновление таблиц маршрутизации, это даже на слух не очень современная задача, и в ядре уже давно включены протоколы и механизмы, позволяющие делать это оптимальнее, чем поднимать из ядра в юзерспейс, принимать решение, заталкивать обратно в ядро, передавая дальше, по цепочке. Как раз flannel, о котором мы периодически упоминаем, и который уже включен в Fedora, может работать в т.ч. и на уровне ядра. Каковы же его показатели в сравнении с Weave и нативной сетью?

Name TCP BW (MB/s) TCP Lat (µs) BW % Lat %
Native 116 91.8 100.00 100.00
Weave 6.91 372 5.96 405.23
Flannel UDP 23 164 19.83 178.65
Flannel VXLan 112 129 96.55 140.52

Не хочется особо никого ругать, просто политкорректно скажем, что у ряда участников тестирования есть перспективы роста.

Особо отметим, что тема SDN потеряла тэг "дивная зверушка", и переходит в раздел "надо попробовать". Мы некоторое время назад видели, как один из первых энтузиастов SDN в России был поставлен в тупик вопросом "кому это надо?" на одном из столичных мероприятий. Теперь, что уже понятно, такого не будет. Как мы видим, даже управляя трафиком из userspace можно получить приличную производительность, и некоторое падение показателей выглядит вполне допустимым, учитывая то, какие возможности открываются.

Основным открытым вариантом SDN пока является OpenDaylight. Недавно про него хорошую обзорную статью написали в Mirantis. Проект уже довольно серьезный, что немного пугает проприетарных вендоров, некоторые из них (VMware и Juniper - опять VMware, да что это с ними такое?) снижают степень вовлеченности в проект. Зря, кстати.

Проблема с открытыми SDN-системами ровно одна - законченных продуктов не было. До сих пор не было. Первого апреля был интересный анонс - CloudRouter, специализированный Linux-дистрибутив для создания роутеров для облачных систем. Среди участников есть дружественная нам Cloudius Systems, уже известные вам разработчики OSv и Seastar, и компания нашего соотечественника Игоря Сысоева, Nginx. Проект базируется на Fedora. Учитывая, что параллельно вовсю разрабатывается открытое аппаратное решение для роутеров уровня дата-центра, не стоило бы проприетарным вендорам отворачиваться от OpenDaylight. А ведь открытые SDN уже рассматриваются, как кандидаты для модернизации беспроводных сетей.

Docker напрягся.

Docker, упорно пытающийся вылезти за пределы "запустить три версии руби одновременно", возможно переживает сильнейший удар. Три больших игрока объединились против него. На недавно прошедшем CoreOS Fest Google, Red Hat, и VMware официально поддержали стандарт App Container в своих продуктах. Этот стандарт уже поддерживается в собственном продукте CoreOS, Rocket, а теперь будет поддерживаться и другими компаниями и коммьюнити.

Архитектурно, повторимся, Docker ничем похвалиться не может - это еще один из продуктов, чья популярность возникла впопреки. Это вас не должно удивлять - дело в том, что зачастую делать правильно сложнее, чем неправильно. Да, если делаешь не по инструкции, то результат может быть плохой. А что если он будет хороший? О плохих историях почти никто не рассказывает (что рассказывать-то? сам дурак, сделал неправильно), да и вообще, плохое возникает реже, чем хорошее. Вот по блогам и форумам кочуют прекраснодушные рассказчики с их "отключил SELinux, и ничего!", "поставил венду, и не ослеп", "не учил математику, и не дурее других".

И до Docker были контейнеры (LXC, Parallels, и т.п.), но его разработчики сделали одно простое, но умное решение - ставка на начинающих, и поддержка популярного у них дистрибутива, одновременно предложив рабочее решение, обходящее все его недостатки. Тем не менее, остались открытыми вопросы безопасности, управления сетью (хотя в последнее время управление сетью в Docker начало улучшаться, как благодаря работе независимых разработчиков, так и благодаря усилиям их команды), зависимостей между процессами (а зависимости никуда не делись, как ни радуйся тому, что можно "запустить три версии руби одновременно"), управление хранилищем, декомпозиция толстого бинарника на работающие независимо компоненты (как это было сделано в systemd). Разумеется, со временем, у Docker будет решение всех этих и прочих проблем, но нашими друзьями из CoreOS, как нам кажется, было предложено архитектурно гораздо более правильное решение. Которое, теперь, еще и будет стандартизировано.

Стандартизация App Container, и управление оргвопросами коммьюнити будет осуществляться на демократической модели, с помощью выбираемых по совокупности заслуг участниками (как это делается почти везде в успешных OpenSource-проектах). Пока проектом управляют пятеро человек - Charles Aylward из Twitter, Vincent Batts из Red Hat, Tim Hockin из Google, и Brandon Philips и Jonathan Boulle из CoreOS.

Интересно, что стандарт уже поддерживается и на FreeBSD, в продукте Jetpack.

https://regmedia.co.uk/2014/12/01/container_disaster.jpg

Может уже пора сбегать?

g_autoptr ()

Это архивная статья

Вот уже некоторое время GCC поддерживает хороший способ для автоматической очистки переменных, когда они перестают использоваться -- __attribute__((cleanup)).
Некоторое время назад, разработчик GLib, Ryan Lortie,добавил специальные макросы, чтобы упростить работу программистам по очистке памяти. Они работают только с GCC и Clang, так что если вы хотите собирать программу используя MSVC ([STRIKEOUT:кто-то ещё использует это?]) - вы не должны их использовать.
Новое API лучше всего продемонстрированно на следующем примере:
{
  g_autoptr(GObject) object;
  g_autoptr(gchar) tmp;
  g_auto(GQueue) queue;

  g_queue_init (&queue);
  object = g_object_new (...);
  tmp = g_strdup_printf (...);

  // no free required
}
Чтобы добавить поддержку собственных типов - нужно использовать G_DEFINE_AUTOPTR_CLEANUP_FUNC и подобные макросы. Это будет происходить автоматически, если вы используете недавно-добавленные в API G_DECLARE_DERIVABLE_TYPE или G_DECLARE_FINAL_TYPE макросы.
Для тех, кто пишет на C, GLib может показаться очень удобным дополнением, там есть удобная реализация потоков, списков, классов (да-да, вы не ослышались), асинхронность, таймеры, парсеры конфигов и ещё много-много всего. Вы только посмотрите на документацию!
Давайте рассмотрим более детальный пример:
// gcc `pkg-config --libs --cflags glib-2.0` -g g_autoptr.c
#include

G_DEFINE_AUTOPTR_CLEANUP_FUNC (gchar, g_free);

void
print_elem (gpointer data,
            gpointer user_data)
{
  g_print ("GList: %s\n", (gchar *) data);
}

gint
main (gint   argc,
      gchar *argv[])
{
  g_autoptr(gchar) tmp = g_strdup ("Hello, I'm gchar!");
  g_autoptr(GList) lst = NULL;
  lst = g_list_append (lst, tmp);

  g_print ("gchar: %s\n", tmp);
  g_list_foreach (lst, (GFunc) print_elem, NULL);

  return 0;
}

Давайте скомпилируем и запустим наш пример под valgrind и посмотрим на утечки в памяти..

$ valgrind --tool=memcheck --leak-check=full ./g_autoptr
==9620== HEAP SUMMARY:
==9620==     in use at exit: 2,094 bytes in 6 blocks
==9620==   total heap usage: 22 allocs, 16 frees, 68,943 bytes allocated
==9620==
==9620== LEAK SUMMARY:
==9620==    definitely lost: 0 bytes in 0 blocks
==9620==    indirectly lost: 0 bytes in 0 blocks
==9620==      possibly lost: 0 bytes in 0 blocks
==9620==    still reachable: 2,094 bytes in 6 blocks
==9620==         suppressed: 0 bytes in 0 blocks

А теперь уберём g_autoptr и ещё раз посмотрим.

$ valgrind --tool=memcheck --leak-check=full ./no_g_autoptr
==9705== HEAP SUMMARY:
==9705==     in use at exit: 2,136 bytes in 8 blocks
==9705==   total heap usage: 22 allocs, 14 frees, 68,943 bytes allocated
==9705==
==9705== 42 (24 direct, 18 indirect) bytes in 1 blocks are definitely lost in loss record 7 of 8
==9705==    at 0x4C2AC10: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==9705==    by 0x4E82769: g_malloc (in /usr/lib64/libglib-2.0.so.0.4501.0)
==9705==    by 0x4E99DC2: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.4501.0)
==9705==    by 0x4E78EE3: g_list_append (in /usr/lib64/libglib-2.0.so.0.4501.0)
==9705==    by 0x400848: main (no_g_autoptr.c:16)
==9705==
==9705== LEAK SUMMARY:
==9705==    definitely lost: 24 bytes in 1 blocks
==9705==    indirectly lost: 18 bytes in 1 blocks
==9705==      possibly lost: 0 bytes in 0 blocks
==9705==    still reachable: 2,094 bytes in 6 blocks
==9705==         suppressed: 0 bytes in 0 blocks

Сейчас, некоторые наши коллеги, используют такие конструкции:

#define GS_DEFINE_CLEANUP_FUNCTION0(Type, name, func) \
  static inline void name (void *v) \
  { \
    if (*(Type*)v) \
      func (*(Type*)v); \
  }
#define _cleanup_error_free_ __attribute__ ((cleanup(gs_local_free_error)))
GS_DEFINE_CLEANUP_FUNCTION0(GError*, gs_local_free_error, g_error_free)

_cleanup_error_free_ GError *error = NULL;

Некрасиво, правда? К тому же ещё и код дублируется из проекта в проект.

Virt-manager 1.2.0

Это архивная статья

Cole Robinson официально анонсировал virt-manager версии 1.2.0. С версии 1.1.0 прошло чуть больше полугода. В этой версии, в отличие от предыдущей, есть интересные изменения - OVMF и AAVMF (поддержка UEFI в виртуалках) и улучшенная поддержка AArch64.

Напомним про конкурирующий проект от нашего коллеги - qt-virt-manager. Пусть расцветают сто цветов, пусть соперничают сто школ!

Тестовые дни Fedora 22 по облакам и Fedora Atomic

Это архивная статья

Официально объявлено о совмещенном мероприятии, запланированном на 7е мая - тестовый день по облакам и тестовый день по Fedora Atomic.

Присоединяйтесь! Немного статистики. Количество тестовых дней перевалило за 200. Первый тестовый день был организован чуть менее 7 лет назад, что дает примерно 2 тестовых дня в месяц. Неплохой результат, как нам кажется.

Next Big Thing

Это архивная статья

Нас порой спрашивают, что будет следующей важной темой (после GNU, Linux, Internet, облаков, биткойнов и т.п.). Ответим не задумываясь - роботы, maker movement, 3D-печать, и Internet-of-Things.

Наше мнение полностью разделяется и коллегами. Мы не только создали, и по возможности поддерживаем в рамках Fedora Project хорошую и надежную платформу для робототехники, привлекающую успешных игроков, но и активно помогаем всему коммьюнити как в оргвопросах, так и по теоретической части. Уж что, что, а то, как создавать коммьюнити и поддерживать комфортные рабочие отношения, наши коллеги знают. Мы прошли долгий путь, и хотели бы предостеречь начинающих от повторения наших ошибок. К сожалению, в maker movenent очень много людей, заходящих с другой стороны - понятие "открытость" и "свобода" для них в новинку. Они инженеры и не хотят ничего решать, им нужен 3D-принтер и токарный станок. Понимая, куда это может завести, наши участники активно выступают с обзорными лекциями на тему открытости. Не так давно Ruth Suehle выступила на SCALE 13x. Она очень обеспокоена тем, что open hardware movement отходит от приниципа "открытый по умолчанию".

К счастью, еще не поздно перехватить тренд и перенаправить энергию.

К сожалению, есть важный фактор, отличающий maker movement от нас. Это стоимость экспериментов. У нас есть виртуалки, дебаггеры, эмуляторы - эксперименты у нас считай бесплатны (ну и время, сэкономленное на посещении социальных сетей). Компьютеры-то и так у всех есть, и для того, чтоб программировать, ничего покупать не надо. А вот для того, чтоб заняться роботами, нужно хотя бы купить молоток. А если купил 3D-принтер, то понесенные существенные затраты вызывают желание их как-то отбить. Ход мыслей нам понятен, но мы считаем, что компенсировать расходы, закрыв созданные вами дизайны, не получится. Открытость - ваш возможно самый главный козырь. Не стоит его отдавать другим. Надо признать, эту мысль принять непросто. Особенно, если учесть, что много инженеров, купивших 3D-принтер и/или играющихся с Arduino, используют проприетарные системы, и не знакомы с нашими порой экстремистскими идеями свободы и открытости.

Тем не менее, мы продолжим работать с аудиторией. Вообще, не бойтесь затрат на 3D-принтер или набор для электротехнического моделирования.

Это не только хорошее и обучающее хобби, которое наверняка оценят ваши дети, но и потенциально перспективное вложение в карьерный рост.

Компания Adafruit, где тоже есть наши друзья, разместила в своем блоге статью из IEEE, где оценивается, что на 35% инженерных вакансий уже требуется опыт работы с 3D-принтерами.

Учитывая, что их теперь применяют даже в космосе, этот процент будет лишь увеличиваться.

image0 Возможно вы удивитесь, но Red Hat уже вкладывается в эту революцию в индустрии. У компании уже формируется пакет предложений для Internet-of-Things.

Ничего удивительного, кстати. Свои варианты развитя IoT есть и у IBM, и у Google.

Вышел OpenStack Kilo и другие новости

Это архивная статья

Официально объявлено о выходе OpenStack Kilo, уже одинадцатой версии OpenStack. Пресс-релиз уже перевели на русский и обсуждают на OpenNET.ru.

Одновременно опубликовали и радующую глаз статистику по разработчикам этой версии OpenStack. Как и всегда радуемся успехам наших соотечественников из Mirantis, и ведущей роли наших коллег из Red Hat.

System Message: ERROR/3 (<string>, line 13)

Error in "image" directive: "center" is not a valid value for the "align" option within a substitution definition. Valid values for "align" are: "top", "middle", "bottom".

image:: https://bitergia.files.wordpress.com/2015/04/companies-contributions.png
   :align: center
   :target: http://blog.bitergia.com/2015/04/30/kilo-the-new-openstack-release/

System Message: WARNING/2 (<string>, line 13)

Substitution definition "image0" empty or invalid.

.. |image0| image:: https://bitergia.files.wordpress.com/2015/04/companies-contributions.png
   :align: center
   :target: http://blog.bitergia.com/2015/04/30/kilo-the-new-openstack-release/

Из интересных новостей стоит отметить инициативу группы разработчиков OpenStack по переписыванию компонентов Swift на golang. Теоретически это должно повысить производительность, а как оно реально получится - посмотрим.

Вообще, в последнее время за подсистемы хранения данных взялись серьезно. Идея о том, чтоб из "рассыпухи" серверов собрать отказоустойчивое хранилище данных (необязательно файлов, можно и оперировать данными на уровне приложений, целыми объектами), оказалась не только заманчивой, но и вполне реализуемой. Проблема в том, что не только сетевые задержки превосходят задержки при работе с грампластинками, но и демоны, обеспечивающие работоспособность системы в целом, тупят и тормозят. Неудивительно, что есть желание переписать отдельные компоненты на более шустром компилируемом современном языке, который бы предоставлял возможности интерпретируемых. Но даже если и не перепишут, то уже достигнутый результат уже нарушает сон представителей проприетарных компаний (да, NetApp, пора перестраиваться, иначе события пойдут по плохому сценарию). А вот кое кто быстро перестраивается. Например Seagate, традиционный участник RICON, который обещает вскоре открыть Kinetic Storage platform, свое решение для облачного хранилища объектов. Это очередной уровень абстракции - хранить не файлики, а сразу готовые объекты уровня бизнес-логики. Seagate собирается запрыгнуть в этот поезд, чтобы по праву архитектора подсистемы устанавливать стандарты и технические требования, обеспечивая своим продажникам преимущество.

У Red Hat, само собой, есть хорошее портфолио решений для облачных хранилищ. К сожалению, из-за того, что тема только пошла, варианты перехлестываются (Ceph vs. Gluster). Это очень плохо, т.к. создает вредный юниксвэй из вариантов, и решения по которому заказчики принимать не хотят. К счастью, в марте этого года Red Hat предложило свое архитектурное видение, где четко разграничило сферы применения. Берите Gluster для использования в Enterprise Virtualization, аналитических задачах, и для разделения и синхронизации данных уровня Enterprise. А [STRIKEOUT:если вы не зарабатываете деньги] для OpenStack и AWS берите Ceph. Для хранения архивных данных используйте любой вариант из этих двух.

Оба проекта до сих пор на стадии "work-in-progress", но нужно отметить, что Gluster начали пораньше, и фич в нем больше - лучше производительность на малых файлах, интеграция с SELinux, развитый фреймворк для управления. Ceph пока застрял на POSIX-интерфейсе (CephFS).

Напомним мнение инженера Seagate, James Hughes, который на RICON 2013 сказал, что "Any distributed filesystem like GlusterFS or Ceph that tries to preserve the POSIX API will go the way of the dodo bird". Может и не стоить тащить этот POSIX? Но хозяин-барин, конечно.

Для справки, основной проблемой POSIX, архитектурно подразумевающей существование в системе некоего синглтона, эффективно упорядочивающего операции над FS самим своим существованием, является то, что это резко усложняет масштабируемость. Если кто не верит, то задайтесь вопросом, как получив файловый дескриптор, узнать по нему, не изменилось ли содержимое файла с момента открытия и как предохраниться от неожиданных изменений? Рекомендуем дальше поинтересоваться тонкостями на любой из конференций, где будут наши коллеги, например, на том же FOSDEM. К сожалению, мы на айти-мероприятиях в России, часто встречались со свежей мыслью, что разработчики должны во что бы то ни стало следовать стандартам из 1970x-1990x (X11, SysV, POSIX, файловый API для всего - от конфигураций до хранения данных, текстовички и текстовые протоколы, т.к. "читать глазами" кококо, пайпы и т.п.). Это лишь показывает невысокий уровень знакомства с открытыми системами у ряда коллег-аналитиков. Кстати, Embedded-разработчики вышли из положения до тупости просто - скидывать файлы на телефон или аудиоплэйер можно лишь через спецпротокол (несоответствующий POSIX), либо переключив его в режим флэшки (отдав проблемы на откуп хостовой системе). А представьте, что Vkontakte или Twitter лочили бы всю систему, когда кто-нибудь постил фоточку. К счастью, социальные сети построены не на POSIX-стандарте, и поэтому они быстро и хорошо работают.

Вернемся к Ceph. Несоответствие (или неполное соответствие) POSIX, это, как полагает ряд экспертов, не такая уж и проблема. А вот отсутствие fsck - это уже стоп-слово.

https://pbs.twimg.com/media/Bx2AO-JCMAIcuHb.jpg

Играл с клубком, забыл stop word

Postgres Professional предлагает работу

Это архивная статья

С интересом ознакомились с вакансией разработчика баз данных от компании Postrges Professional, основанной известным соотечественником, Олегом Бартуновым. Приводим ее текст:
Разработчик ядра PostgreSQL
Компания Postgres Professional приглашает разработчиков на языке C для работы над ядром СУБД PostgreSQL. Мы предоставляем достойным специалистам уникальный шанс поменять свою ежедневную рутину на работу над амбициозными задачами в дружном коллективе, где вы можете профессионально вырасти и сделать карьеру в опенсорсе.
Обязанности:
  • Разработка новой функциональности ядра СУБД PostgreSQL
  • Участие в Open Source проектах
  • Обеспечение поддержки 3­го уровня (багфиксы, поиск и решение проблем)

Профессиональные требования:
  • Уверенное владение языком C
  • Опыт системного ­серверного программирования
  • Технический английский
  • Навыки работы с Git
  • ~Профильное высшее образование
  • Знание основных технологий СУБД
  • Структуры данных во внешней памяти, их concurrency и recovery
  • MVCC
  • undo/redo логи
  • принципы ACID и BASE
  • Умение привести свой код в соответствие со стандартами, задокументировать, покрыть регрессионными тестами
  • ~Умение представлять результаты своей работы коллегам на внутренних семинарах, российских и международных конференциях

Личные требования:
  • Желание расти и развиваться в направлении сложных и амбициозных технических задач.
  • Высокое чувство ответственности, умение работать в команде.
  • Любовь к качественному коду, стремление к постоянному улучшению продукта.

Мы, в свою очередь, предлагаем Вам:
  • Высокую, конкурентоспособную заработную плату.
  • Работу над интересным проектом.
  • Профессиональный и дружный коллектив.
  • Отличные возможности для профессионального и карьерного роста.
  • Корпоративные мероприятия, чай, кофе, печенье и т. д.
  • Светлый и просторный современный офис в шаговой доступности от м. Академическая.

Тип занятости:
  • Полная занятость
  • ~полный день
  • Обязательные семинары

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