В этой статье я решил собрать сборную солянку из советов о том, как разрабатывать высоконагруженные сервисы, полученных практическим путем. Для каждого совета я постараюсь приводить небольшое обоснование, без подробностей (иначе статья бы получилась бы сравнима по размеру с войной и миром). Поскольку обоснований я буду приводить не очень много, не стоит воспринимать эту статью, как догму — в каждом конкретном случае приведенные здесь советы могут быть вредны. Всегда думайте своей головой перед тем, как что-то делать.
Зоджи-Ла, Индия
Привет, Хабр! Меня зовут Олег Ефимов, я работаю в Badoo в команде «Платформа», занимаюсь задачами хранения фотографий, интерфейсами сервисов и много чем ещё.
Мне часто приходится слышать, что в том, что касается серверных технологий, Badoo – довольно консервативная компания. Отчасти это так, но на самом деле мы используем много молодых языков программирования, новых инструментов и технологий. Одна из них – RocksDB, на основе которой Facebook создал MySQL storage engine – MyRocks. Пост о том, как Facebook осуществлял миграцию одной из своих баз данных с InnoDB на MyRocks, мне и захотелось для вас перевести.
Когортный анализ возвратности пользователей является мощным способом для понимания разных групп клиентов — их поведения и значимости для бизнеса. Однако итоговые таблицы бывает трудно понять с первого раза, а с ходу придумать, как их построить, ещё сложнее.
В статье будет описан относительно простой, но полезный алгоритм построения когортой таблицы, а также приведены наброски кода с Python/Pandas и SQL. Если Вам необходимо программно реализовать построение когортного отчёта или просто интересно узнать этот алгоритм — прошу под кат.
Практически каждый человек сталкивается с ведением какого-либо учета, сбором и анализом данных: от использования таблиц в экселе до работы с данными в клиент-банковском приложении. Повсеместно для такого учета используются различные системы управления базами данных (СУБД).
В статье я хотел бы рассказать о своем пути поиска такой системы.
Межсетевой экран уровня приложений предназначен для анализа и фильтрации трафика в отношении какого-либо приложения или класса приложений, например веб-приложений или СУБД. При его построении возникает необходимость разговаривать на языке этого приложения. Для реляционной СУБД таким языком становится диалект SQL. Предположим, что необходимо построить межсетевой экран для СУБД. В этом случае потребуется распознавать и анализировать предложения SQL для принятия решения об их соответствии заданной политике безопасности. В зависимости от решаемых задач (например, обнаружение атак типа SQL-инъекция, управление доступом, корреляция SQL- и HTTP-запросов) будет необходима та или иная глубина анализа SQL. Так или иначе, потребуется выполнять лексический, синтаксический и семантический анализ предложений SQL.
Привет, Хабр, давно не виделись! Со времени моих предыдущих публикаций в
серии «Памятка евангелиста PostgreSQL» (1, 2, 3) прошло довольно много времени, и многое изменилось. Вышли новые релизы MySQL и PostgreSQL с интересными фичами (хотя содержимое моих статей остаётся по большей части актуальным, я старался вносить мелкие обновления там, где это требовалось). В моду вошёл ко-маркетинг (с ко-франшизингом и местами даже ко-лизингом), когда доклады о PostgreSQL звучат на конференциях, посвящённых MySQL, и наоборот. Появились даже совместные доклады, где предпринимаются попытки объективного сравнения MySQL и PostgreSQL в тех или иных плоскостях. Отгремела история с Uber, с протяжённой по времени дискуссией, в которую я тоже внёс свой скромный вклад.
В целом, диалог между двумя проектами становится более содержательным. Я всё реже слышу страшилки и мифы, о которых я рассказывал в предыдущих статьях. Однако есть один устойчивый миф, который по-прежнему раскручивается сообществом PostgreSQL. Если быть точным, раскручивается он моей любимой компанией Postgres Professional – от представителей других компаний я пока такого не слышал. Это миф о «проприетарности» MySQL. В беседах руководство Postgres Professional демонстрирует какое-то дикое незнание матчасти и своеобразное толкование терминов. А значит пришло время дорогой редакции снова взобраться на броневичок!
Крутой varanio буквально на прошлой неделе прочитал на DevConf забойный доклад для всех кто пересел на Посгрес с MySQL, но до сих пор не использует новую базу данных в полной мере. По мотивам выступления родилась эта публикация.
Мы рады сообщить, что подготовка к PG Day'17 Russia идет полным ходом! Мы опубликовали полное расписание предстоящего мероприятия. Приглашаем всех желающих прийти и похоливарить с Антоном лично
Поскольку доклад на DevConf вызвал в целом положительные отзывы, я решил оформить его в виде статьи для тех, кто по каким-то причинам не смог присутствовать на конференции.
Почему вообще возникла идея такого доклада? Дело в том, что PostgreSQL сейчас явно хайповая технология, и многие переходят на эту СУБД. Иногда — по объективным причинам, иногда — просто потому что это модно.
Но сплошь и рядом складывается такая ситуация, когда какой-нибудь условный программист Вася вчера писал на MySQL, а сегодня вдруг начал писать на Посгресе. Как он будет писать? Да в целом также, как и раньше, используя лишь самый минимальный набор возможностей новой базы. Практика показывает, что проходят годы, прежде чем СУБД начинает использоваться более менее полноценно.
Привет, Хабр! Меня зовут Павел Мурзаков, я – PHP-тимлид в Badoo, и сегодня я расскажу вам о новой возможности получить предложение по работе в Лондоне за один день. Как вы, возможно, знаете, недавно в Москве прошло рекрутинговое мероприятие Badoo по поиску мобильных разработчиков. Оно оказалось очень успешным – мы предложили работу в Лондоне восьми ребятам и надеемся скоро увидеть их в составе нашей мобильной команды.
И, чтобы не отставать от наших iOS- и Android-команд (ведь их теперь на восемь человек больше!), мы решили ответить достойно и провести аналогичное мероприятие, на котором рассчитываем найти server-side-коллег нашим новым мобильным разработчикам!
