Зачитался я последнее время про Tarantool, интересно стало. Идея хорошая — код рядом с базой данных, хранимка в такой быстрой Redis-подобной среде.

И что-то задумался — мы вот сейчас используем активно на работе Golang, собственно, мысль пришла что на Go написано много всего, в т.ч. и встраиваемых баз. А что если сравнить, например, Go+LevelDB (собственно, можно было бы и любую другую) против Tarantool. Тестировал еще Go+RocksDB, но там оказалось все немного сложнее, а результат примерно тот же на небольших данных.

Тестировал простую задачу — HTTP сервер, при запросе — записать ключик в базу, достать его же по имени (без всяких проверок на race), отправить назад простенький JSON из этого value.

Сравнил: go+leveldb, tarantool, go+go-tarantool, nginx upstream tnt_pass

Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.

На самом деле, мало кто действительно понимает, как работают реляционные БД. А многие разработчики очень не любят, когда они чего-то не понимают. Если реляционные БД используют порядка 40 лет, значит тому есть причина. РБД — штука очень интересная, поскольку в ее основе лежат полезные и широко используемые понятия. Если вы хотели бы разобраться в том, как работают РБД, то эта статья для вас.

На Хабре уже есть статьи о NoSQL СУБД Tarantool и о том, как его используют в Mail.Ru Group (и не только). Однако нет рецептов того, как работать с Tarantool на Python. В своей статье я хочу рассказать о том, как мы готовим Tarantool Python в своих проектах, какие проблемы и сложности при этом возникают, плюсы, минусы, подводные камни и, конечно же, «в чем фишка». Итак, обо всем по порядку.



Tarantool представляет собой Application Server для Lua. Он умеет хранить данные на диске, обеспечивает быстрый доступ к ним. Tarantool используется в задачах с большими потоками данных в единицу времени. Если говорить о цифрах, то это десятки и сотни тысяч операций в секунду. Например, в одном из моих проектов генерируется более 80 000 запросов в секунду (выборка, вставка, обновление, удаление), при этом нагрузка равномерно распределяется по 4 серверам с 12 инстансами Tarantool. Не все современные СУБД готовы работать с такими нагрузками. Кроме того, при таком количестве данных, очень дорого ожидание выполнения запроса, поэтому сами программы должны быстро переключаться от одной задачи к другой. Для эффективной и равномерной загрузки CPU сервера (всех его ядер) как раз нужен Tarantool и асинхронные приемы в программировании.

Привет. Это пост о новой версии Тарантула «от автора». Интернет занятно устроен: если поискать про Тарантул, то найдётся статья от 2011 года, о версии 1.3. И ещё какой-то перфоратор, кажется. На форумах-бордах вообще стоит густой туман. Тарантул «ну это как Редис, только»…

Или ещё, недавно сделал для себя открытие, на Тостере кто-то написал «София — это такое append-only хранилище по типу Тарантула». С такими постами я скоро стану фанатом сайта «сделано у нас», автомата Калашникова и Саяно-Шушенской ГЭС. Правда, мне сложно понять, почему мы восхищаемся западными инструментами, при этом представления не имеем о своих. Итак, Tarantool 1.6. В чём фишка?

Треды, или цепочки писем, всегда были одной из самых желаемых фич в Почте Mail.Ru, при условии, что опрос «Какого функционала вам не хватает?» проводился среди продвинутой аудитории (например, среди программистов или хабраюзеров). Вторая по популярности фича среди гиков — это, пожалуй, двухфакторная аутентификация, но о ней в отдельном посте.

Однако все наши юзабилити-тестирования показывали, что для менее продвинутой аудитории треды — фича довольно сложная и не всегда удобная. Многие приходили в ужас, «потеряв» свои письма во Входящих, не могли понять, как ответить на конкретное сообщение в цепочке, и многое другое.

Тем не менее, нам самим (команде Почты Mail.Ru), как людям, относящимся к первой группе (гики, любители продуктивити и программисты), идея тредов была близка и понятна. Поэтому мы решили пойти навстречу пожеланиям продвинутого сообщества и реализовать треды в опциональном режиме (включить их можно в меню «Вид» в правом верхнем углу над списком писем).



Однако легко решить, но не так легко сделать. На этапе продумывания логики обнаружилась масса нюансов. Хотя треды уже были реализованы в других почтовых службах, нам все равно пришлось разрабатывать собственный алгоритм. Во-первых, какие-то чужие решения нам казались ошибочными, и мы решили их исправить, во-вторых, логика работы некоторого базового функционала нашей почты отличается от работы похожего функционала у других, поэтому просто «перенять опыт» as is невозможно.

В этом посте мы хотим рассказать о том, какие трудности нас ждали и как нам удалось их преодолеть.

В преддверии своего доклада на конференции PGCONF.RUSSIA 2015 я поделюсь некоторыми наблюдениями о важных различиях между СУБД MySQL и PostgreSQL. Этот материал будет полезен всем тем, кого уже не устраивают возможности и особенности MySQL, а также тем, кто делает первые шаги в Postgres. Конечно, не стоит рассматривать этот пост как исчерпывающий список различий, но для принятия решения в пользу той или иной СУБД его будет вполне достаточно.

С 6 по 7 февраля в бизнес-центре Digital October в Москве пройдёт конференция PGCONF.RUSSIA 2015, одним из организаторов которой я являюсь. PostgreSQL — одна из наиболее перспективных современных свободно распространяемых СУБД, активно развивающаяся и во многих случаях уже не уступающая флагману коммерческих СУБД Oracle, а в чем-то и превосходящая его. При этом что Postgres распространяется по очень свободной лицензии, близкой к BSD и MIT-лицензиям, позволяющей делать с ним что угодно — даже продавать от своего имени. Поэтому нет препятствий в создании на базе постгреса коммерческих СУБД и прикладных систем, и этим многие пользуются. Это, в свою очередь, дает возможность участвовать в разработке большему количеству людей, и активнее подпитываться новыми идеями. На страницах данного поста мы расскажем о том, как возникла и развивалась эта СУБД, каковы её сильные и слабые стороны, в том числе с точки зрения широкого распространения.

При написании любого достаточно крупного проекта всегда встают более-менее похожие проблемы. Одна из них — проблема скорости получения обновлений системы. Относительно легко можно наладить быстрое получение небольших обновлений. Довольно просто изредка получать обновления большого объема. Но что если надо быстро обновлять большой массив данных?

Для Таргета Mail.Ru, как и для всякой рекламной системы, быстрый учет изменений важен по следующим причинам:
• возможность быстрого отключения показа кампании, если рекламодатель остановил ее в интерфейсе или если у него кончились деньги, а значит, мы не будем показывать ее бесплатно;
• удобство для рекламодателя: он может поменять цену баннера в интерфейсе, и уже через несколько секунд его баннеры начнут показываться по новой стоимости;
• быстрое реагирование на изменение ситуации: изменение CTR, поступление новых данных для обучения математических моделей. Все это позволяет корректировать стратегию показа рекламы, чутко реагируя на внешние факторы.

В этой статье я расскажу об обновлении данных, лежащих в больших таблицах в БД MySQL, фокусируясь на скорости и консистентности — ведь не хотелось бы уже получить новый заведенный баннер, но при этом не получить данную рекламную кампанию.

Откуда появилась проблема

Многие из вас пользуются VPN подключением к рабочей локальной сети из дома.
Благодаря этому, подключив VPN вы работаете с рабочей сетью «как будто находясь в ней».

Как выглядит типичная настройка в linux?
В /etc/resolv.conf прописывается (при помощи openresolv или NetworkManager)

search local.company.name
nameserver 10.0.20.186

Где local.company.name — домен компании, а 10.0.20.186 — ip адрес локального (в рабочей сети) DNS сервера.

Как выглядит работа?

root@t510 0 ~ % ping -c 1 cdash-master
PING cdash-master.local.company.name (10.0.20.237) 56(84) bytes of data.
64 bytes from 10.0.20.237: icmp_seq=1 ttl=63 time=214 ms
...

Что произошло?

1. search добавил к cdash-master суффикс local.company.name
2. DNS сервер в рабочей сети преобразовал cdash-master.local.company.name в 10.0.20.237

Всё прекрасно работает, пока у вас VPN подключение… одно.
Мне захотелось подключать одновременно два VPN и прописывать два DNS — один для рабочей сети, другой для локальной сети на hetzner, где крутятся мои виртуальные машины.

Казалось бы, что может быть проще? Однако путь к решению был долгим и извилистым.

Rebase — один из двух способов объединить изменения, сделанные в одной ветке, с другой веткой. Начинающие и даже опытные пользователи git иногда испытывают нежелание пользоваться ей, так как не видят смысла осваивать еще один способ объединять изменения, когда уже и так прекрасно владеют операцией merge. В этой статье я бы хотел подробно разобрать теорию и практику использования rebase.

Теория

Итак, освежим теоретические знания о том, что же такое rebase. Для начала вкратце — у вас есть две ветки — master и feature, обе локальные, feature была создана от master в состоянии A и содержит в себе коммиты C, D и E. В ветку master после отделения от нее ветки feature был сделан 1 коммит B.

От переводчика: в этой статье нет описания команд git, она подразумевает, что вы уже знакомы с ним. Здесь описывается вполне здравый, на мой взгляд, подход к содержанию публичной истории в чистоте и порядке.

Если вы не понимаете, что побудило сделать git именно таким, то вас ждут страдания. Используя множество флагов (--flag), вы сможете заставить git работать так, как по вашему мнению он должен работать, вместо того, чтобы работать так, как git того хочет. Это как забивать гвозди отверткой. Работа делается, но хуже, медленнее, да и отвертка портится.

Всем здравствуйте, меня зовут Олег, мне 17 лет, и сегодня я расскажу вам о процессе поступления в MIT.
Дабы сохранить цельность повествования, следует отметить, что статья написана 15 марта 2013 года, в день оглашения вердиктов о зачислении студентов.

Картинка для привлечения внимания

Когда я поступал в Массачусетский технологический институт, я с удивлением обнаружил, что в рунете нет не то что мало-мальски съедобной «истории успеха», связанной с поступлением в MIT, а вообще хоть какого-то руководства по поступлению в топовые американские университеты своими силами. Особенно на бакалавриат. Я подумал: «Что ж, видимо, придется написать мне». Я постараюсь донести информацию в наиболее понятном виде.