Написано, т.к. возник очередной холивар в комментариях на тему SQL vs ORM в High-Load Project (HL)

Преамбула

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

• Никогда нельзя реализовать HL-проект на основе только одной манипуляции с ORM
• Никогда не складывайте сложные вещи на плечи БД. Она нужна Вам чтобы хранить инфу, а не считать факториалы!
• Если вы не можете реализовать интересующую Вас идею простыми средствами ORM — не используйте ORM для прямого решения задачи. И тем более не лезте в более низкий уровень, костыли сломаете. Найдите более элегантное решение.
• Извините за издевательски-юмористический тон статьи. По другому скучно :)
• Вся информация взята по мотивам Django версии 1.3.4
• Будьте проще!

И-и-и да, в статье будут показаны ошибки понимания ORM, с которыми я столкнулся за три с лишним года работы с Django.

Сегодня я хочу поделиться с вами моим вольным переводом статьи, написанной Сергеем Повзнером (Sergey Povzner). Сергей ведёт блог bongizmo.com и занимается разработкой туристических гидов под общим названием Citybot.

В то время как Android продолжает свой невероятный рост, всё больше и больше программистов начинают разрабатывать приложения на этой платформе. Если ты начинаешь свой путь сегодня, то ты определенно — счастливчик. За последние годы Android значительно повзрослел и избавился от множества детских болезней. Информации по платформе более чем достаточно. Я же расскажу о самых важных ресурсах.

Статья будет полезна как новичкам, так и опытным разработчикам. Это гид по миру Android-разработки.

Ночи доброй всем текущим и утра пятничного всем, кто в пятницу начинает рабочий день с Хабра…
Снова я.
Вот, выбрался, вернее сказать — чутка урвал часок от сна на тему: надо маленько написать (да и с умыслом шкурным тоже), как дела обстоят и как оно идет вообще по моей разработке. Для тех, кто не в теме, далее ссылки на предыдущие статьи:
Часть№1: habrahabr.ru/post/124427
Часть№2: habrahabr.ru/post/138874
Часть№3: habrahabr.ru/post/150196
Часть№4: habrahabr.ru/post/156573

Ну, а кто уже в теме — продолжим.

Мы продолжаем серию публикаций о нашем фреймворке FML, который автоматизировал работу с машинным обучением и позволил разработчикам Яндекса использовать его в своих задачах проще и чаще. Предыдущий пост рассказывал о том, что такое функция ранжирования и как мы научились строить её, имея на входе лишь достаточно большое число оценок от асессоров и достаточно разнообразный набор признаков (факторов) документов по большому количеству запросов.

Из этого поста вы узнаете:

1. Почему нам нужно подбирать новую формулу ранжирования очень часто, и как именно нам в этом помогает FML;
2. Как мы разрабатываем новые факторы и оцениваем их эффективность.

Я хочу описать историю одного заносчивого и самовлюбленного студента Академического Университета, коим я, конечно, не являюсь, но хорошо представляю его мысли и переживания. Будем называть этого студента, например, Шурик. На момент поступления Шурика в Академический Университет (АУ), согласно его программистскому резюме, он уже был экспертом в области алгоритмов. Он мастерски владел алгоритмом поиска в глубину, знал несколько методов сортировки массивов, и имел представление о двоичном поиске. Естественно, курс алгоритмов его не интересовал совершенно, да и вообще, мало чему можно научить программиста с пятилетним опытом. Программа теоретической информатики АУ его заинтересовала тем, что в темах по известным ему предметам было слишком много неизвестных ему слов. Но это же Питер, там они и бордюр то странным словом называют, вероятно, и для поиска в глубину красивых слов понавыдумывали. Он тщательно изучил слайды и видеозаписи курсов. Оказалось, что существует какая-то там информатика, которой Шурик не владеет в совершенстве. Шурик собрал книги, носки и пять лет опыта, и отправился в Питер на собеседование. Там он встретил людей, которые могут научить чему-то даже программиста с таким опытом. Это все рушило Шурикову картину мира, в которой знание информатики измерялось количеством написанных классов на C#.
Во время учëбы в магистратуре Шурик занимался исследованиями в области схемной сложности и области экспоненциальных алгоритмов. Это действительно очень интересно и, что не менее важно, полезно для поступления в аспирантуру.
На данный момент Шурик является счастливым аспирантом New York University, использует слово «поребрик», и с глубокой благодарностью вспоминает Академический Университет. А кафедра математических и информационных технологий АУ и сейчас ведет набор новых магистрантов, в частности, по направлению «теоретическая информатика».
Сейчас я передаю слово Шурику, который и расскажет об одном своëм исследовании.

Я уже писал про составные части умного дома — систему управления освещением. Умный дом, как и любой робот должен подчиняться трем законам робототехники, третий из которых гласит: робот должен заботиться о своей безопасности в той мере, в которой это не противоречит Первому и Второму Законам. Т.е. одной из задач умного дома — заботиться о своей сохранности, не допускать взломов, пожаров, затоплений, и прочих повреждений. Вот о защите от протечек и затопления мы сегодня и поговорим.

Аквасторож — это система которая автоматически перекрывает воду при обнаружении затопления. Прорвало трубу — вода хлещет на пол, попадает на сенсор, и сервопривод перекрывает краны на стояках. Конечно, от мокрых полов это вас не спасет — часть воды все равно окажется на полу, но ремонт обезопасит, а заодно и оградит от компенсации после затопления соседям ниже. Посмотрим, разберем систему Аквасторож на части и узнаем, так ли она хороша?

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

И вот, появился долгожданный «кубик Lego» для систем автоматизации на базе технологии Z-Wave, который обладает желаемой гибкостью и в то же время большим функционалом и низкой ценой.

Плата расширения RaZberry для Raspberry Pi, превращает самый популярный и дешёвый мини-компьютер в Z-Wave контроллер домашней автоматизации.

На хабре уже было несколько статей про lock-free алгоритмы. Этот пост — это перевод статьи моего коллеги, которую мы планируем публиковать в нашем корпоративном блоге. По роду деятельности мы пишем огромное количество lock-free алгоритмов и структур данных, и этой статьей хочется показать, насколько это интересно и сложно одновременно.



Эта статья во многом похожа на эту статью, но в той статье рассматриваются не все проблемы, с которыми можно столкнуться, разрабатывая lock-free структуры данных, и уделяется очень мало внимания решению этих проблем. В этой статье хочется детально остановиться на некоторых решениях, которые мы используем в реальной реализации lock-free структур данных в нашем продукте, и больше внимания уделить оценке производительности.

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

Сначала немного статистики для того, чтобы показать важность настоящего исследования. Около 50% пользователей нашей системы регистрируются с привязкой аккаунтов социальных сетей vkontakte (VK) и facebook (FB). Причем из зарегистрированных через социальные сети 71% приходится на VK и 29% на FB.

API FB и API VK позволяют извлекать некоторые данные об интересах и предпочтениях пользователя. Но не все так просто, как может показаться. Для получения данных пользователя нужно получить особые права, согласие на которые дает сам пользователь при регистрации в системе. Здесь возникает тонкий момент. С одной стороны, мы ходим вытянуть как можно больше информации о пользователе. С другой стороны, просить слишком много прав — наглость, которая может отпугнуть пользователя. Нужно найти компромисс — тонкое равновесие между полезностью получаемых данных для улучшения рекомендаций и «суммой» кредита доверия от пользователя, который соглашается, чтобы мы залезли в его персональные данные.

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

Решаемая задача. Исходные данные

Итак, имеем сервер БД, с которым работают клиенты, и резервный сервер, на который надо настроить репликацию с основной базы данных.
В моём случае используется PostgreSQL 9.2.1, который установлен на обоих серверах и поддерживает потоковую репликацию. Предположим что база данных на основном сервере развернута и работает, на резервном только установлен, но не настроен PostgreSQL. Для примера возьмем IP-адрес 192.168.1.1 за адрес основного сервера, IP-адрес 192.168.1.2 — за адрес резервного.

Задача Яндекса – найти ответ на вопрос пользователя. Но технологии поиска этого самого ответа бывают разными. Скажем, поиск по интернету и по письмам очень сильно различаются. Поиск по почте – это особенный продукт, уникальный и сложный.

В первую очередь, Яндекс.Почта – это огромный объём данных. У нас хранится около 10 миллиардов писем – это почти столько же, сколько страниц в индексе веб-поиска Яндекса. При этом поисковых запросов примерно в 1000 раз меньше, чем запросов к поиску по интернету.

Зато в поиске по Почте очень важна полнота результатов: если поиск по интернету не найдёт один-единственный сайт из трёх миллионов по запросу «пластиковые стулья», этого никто (кроме, разумеется, вебмастера этого сайта) не заметит. Гораздо критичнее, если потеряется письмо с важным адресом или паролем.

По этим причинам в поиске по Почте существует ряд архитектурных и технологических особенностей.

Архитектурные особенности

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

Чтобы обеспечить полноту результатов, весь поисковый индекс для некоторого пользователя хранится на одном сервере и полностью дублируется на другом – если один сервер недоступен, то мы ищем на дублирующем.

Когда система работает в штатном режиме (все серверы функционируют, все дата-центры доступны), половина поисков отправляется на сервер в одном ДЦ, а вторая половина – на сервер в другом ДЦ. Благодаря этому поисковая производительность увеличивается в два раза.

Технологические особенности

На каждом сервере располагается индекс по письмам пяти миллионов пользователей. Можно строить его разными способами: например, по индексу на пользователя, но в таком случае возникает большая нагрузка на файловую систему, а также требуется огромное количество аппаратных ресурсов и ресурсов операционной системы (потоки и файловые дескрипторы) для поиска.

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

1-й вариант решения: Индекс размером до 10 Гб
Мы попробовали промежуточный вариант: выбрали максимальный размер каждого индекса 10 Гб. Следовательно, на каждом сервере получилось по 50-100 индексов, которые создаются в порядке поступления писем, а данные пользователя, таким образом, могут находиться в любом из индексов. Но письма часто содержат большое количество однотипной информации («привет», «пока», «@yandex.ru»), которая подходит под 46% всех запросов к поиску по Почте. Получалось, что ответ на такой запрос требовал поднять около 20% всех писем, хранящихся на сервере — это занимало десятки секунд.

2-й вариант решения: Префиксный индекс
Мы оставили максимальный размер индекса равным 10Гб, но перед каждым словом добавили ID пользователя. В результате каждый поиск сразу ограничивался количеством и размером писем в почтовом ящике текущего пользователя. Это снизило объем находимых данных и на порядок ускорило поиск. Но когда на диске – сотни индексов, то из-за большого числа дисковых операций поиск занимает несколько секунд. Наша же цель – десятые доли секунд.

3-й вариант решения: Шардирование по пользователям
Все индексы на сервере были разделены на 1000 сегментов (шардов). В каждом из них – от пяти до двадцати индексов размером до 1 Гб, и данные конкретного пользователя всегда находятся в определённом сегменте. В результате число дисковых операций было снижено до 20 раз по сравнению со вторым вариантом. Скорость поиска также увеличилась в разы. Так мы получили поиск за доли секунд.

Онлайн-индексация
Для того чтобы все поступающие письма практически сразу появлялись в результатах поиска, мы разработали специальный инкрементальный индекс в памяти. Особенность индекса в том, что в него можно добавлять по одному документу, а после добавления документ сразу появляется в поиске.
Процесс индексации выглядит так:
Поступающие письма попадают в инкрементальный индекс в памяти. Когда в памяти накапливается определенное количество писем или занят определенный объем,  запускается процесс переноса данных из индекса в памяти в дисковый индекс.  В этот же момент прекращается индексация в памяти №1 и создается индекс в памяти №2.

Конечно, это – лишь часть того, что мы делаем для улучшения качества нашего поиска по Яндекс.Почте. Может быть, у вас есть какие-то вопросы? Мы с радостью на них ответим.

От переводчика. Искал в интернете простой и легко применимый гайдлайн по написанию программ на C++. Мне понравился один из вариантов, и я решил его перевести и опубликовать. Если хабрапользователи хорошо встретят этот топик, могу перевести и другие связанные документы, а также гайдлайны по написанию кода от других компаний.

1 Введение

Настоящий документ содержит рекомендации по написанию программ на языке C++.

Рекомендации основаны на установившихся стандартах, собранных из различных источников, личного опыта, частных требований и потребностей определённых проектов, а также почерпнутых из источников (см. ниже).

Но для появления ещё одного списка рекомендаций, помимо указанных источников, есть несколько причин. Основная причина — их излишняя обобщённость, поскольку зачастую требуется задать частные правила (в особенности правила именования). Данный документ содержит комментарии, что делает его более удобным в использовании при проведении ревизий кода, чем другие уже существующие документы. К тому же, рекомендации по программированию обычно вперемешку содержат описания проблем стиля и технических проблем, что не совсем удобно. Этот документ не содержит каких-либо технических рекомендаций по C++, делая упор на вопросах стиля.

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

Для создания плоских моделей списков и таблиц можно использовать заготовки QAbstractListModel и QAbstractTableModel. Доведение их до готовности не составляет большого труда, поэтому рассматривать их подробно нет необходимости.

Создание же иерархических моделей – более сложная задача. О ней и пойдет речь в этой статье.

Продолжая статью “Использование Hadoop для решения реальных задач”, хочу напомнить, что в прошлой статье мы остановились на том, что посчитали такую характеристику как tf(t,d), и сказали, что в следующем посте мы будем считать idf(t) и завершим процесс вычисления значения TF-IDF для данного документа и термина. Поэтому предлагаю долго не откладывать и переходить к этой задаче.

Важно заметить, что idf(t) не зависит от документа, потому как считается на всем корпусе. Это нетрудно увидеть, посмотрев на формулу:



Вероятно, она нуждается в некоторых пояснениях. Итак, |D| это мощность корпуса документов — иными словами, просто количество документов. Мы знаем его, поэтому считать ничего не надо. Знаменатель же логарифма — это количество таких документов d которые содержат интересующий нас токен t_i.

В данном руководстве описаны процедуры запроса, изучения и анализа данных Twitter с помощью служб на базе Apache Hadoop для Windows Azure, а также Hive-запрос в Excel. Социальные сети — это главный источник больших данных. Поэтому общедоступные API таких социальных медиа, как Twitter, служат источником полезной информации и помогают лучше понять сетевые тренды.

Руководство состоит из следующих разделов.

1. Поиск, загрузка, установка и использование Microsoft Analytics для Twitter
2. Получение фидов Twitter с помощью cURL и Twitter Streaming API
3. Запрос и настройка нового Hadoop на кластере Windows Azure
4. Обработка данных Twitter с помощью Hive на Hadoop в кластере Windows
5. Настройка Hive ODBC и панели Hive в Excel для получения данных Hive

Если ты ИТшник, то нельзя просто так взять и выйти на работу 2-го января: пересмотреть 3-ий сезон битвы экстрасенсов или запись программы «Гордон» на НТВ (дело умственных способностей вкуса).
Нельзя потому, что у других сотрудников обязательно будут для тебя подарки: у секретарши закончился кофе, у МП — закончились дедлайны, а у администратора баз данных — амнезия память.
Оказалось, что инженеры из команды Hadoop тоже любят побаловать друг друга новогодними сюрпризами.

2008

2 января. Упуская подробное описание эмоционально-психологического состояния лиц, участвующих в описанных ниже событиях, сразу перейду к факту: поставлен таск MAPREDUCE-279 «Map-Reduce 2.0». Оставив шутки про число, обращу внимание, что до 1-ой стабильной версии Hadoop остается чуть менее 4 лет.

За это время проект Hadoop пройдет эволюцию из маленького инновационного снежка, запущенного в 2005, в большой снежный com ком, надвигающийся на ИТ, в 2012.
Ниже мы предпримем попытку разобраться, какое же значение январский таск MAPREDUCE-279 играл (и, уверен, еще сыграет в 2013) в эволюции платформы Hadoop.

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

До весны 2012 года у нас вместо такой базы существовали две базы данных разного уровня — со стороны спайдера, который имел свою собственную базу URL-ов, и со стороны индексатора. Это было крайне неудобно: допустим, если пользователь жаловался, что его сайт не индексируется, то для того, чтобы найти причину, при старой архитектуре пришлось бы анализировать массу данных. На это требовалось день-два, иногда даже неделя.

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

Я учился в Канаде (в моих старых постах на Хабре можно проследить за тем процессом) благодаря стипендии правительства Казахстана под названием «Болашак» (каз. «будущее»). Ребята с сайта essay.kz совместно с администрацией этой стипендии регулярно приглашают выпускников «Болашака» и снимают мини-лекции. Недавно позвали и меня, решил рассказать об алгоритмах.

На мой взгляд вышло довольно сумбурно, но многим понравилось. Вот примерный план лекции:

• Что такое информатика и computer science?
• Что такое алгоритм?
• Лучшие решения обычно не очевидны
• Машина Тьюринга и фундаментальные ограничения копьютеров
• Что такое простые и сложные задачи?
• Задача Коммивояжера
• Почему языки программирования не похожи на человеческие языки?

Видео разбито на две части (один, два). Чтобы пропустить введение – начинайте смотреть с 2:56.

Часть 1:

— Дай мне справку, что моя программа безопасна.

— Нет проблем! А что ты для этого делал?

— Э… Ну… Это… Ничего…

— А почему ты тогда думаешь, что она безопасна?

— Ну, ты проверь!

— Нет проблем! Все удовольствие будет стоить X0000 долларов.

— ?!

О статье

В этой статье я рассказываю о некоторых практиках создания безопасного программного обеспечения.

Первая ее часть посвящена безопасному программированию.

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

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

Статья, конечно, не претендует на полное освещение этого вопроса. Но пусть это будет маленький шажок в нужном направлении. И, надеюсь, вы убедитесь, что в безопасном программировании нет ничего такого уж необычного.

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

Внимание! Статья большая и подразумевает внимательное прочтение.

Всем привет. В прошлом посте я рассказывал про некоторые базовые методы классификации. Сегодня, в силу специфики последней домашки, пост будет не столько про сами методы, сколько про обработку данных и анализ полученных моделей.

Задача

Данные были предоставлены факультетом статистики Мюнхенского университета. Вот здесь можно взять сам датасет, а также само описание данных (названия полей даны на немецком). В данных собраны заявки на предоставление кредита, где каждая заявка описывается 20 переменными. Помимо этого, каждой заявке соответствует, выдали ли заявителю кредит, или нет. Вот здесь можно подробно посмотреть, что какая из переменных означает.

Нашей задачей стояло построить модель, которая предсказывала бы решение, которое будет вынесено по тому или иному заявителю.