Немного статей на хабре посвящены новому движению в IT индустрии — NoSQL. Я решил изменить это и написал статью-перевод-обзор об одном из докладов с конференции NoSQL прошедшей 5 октября в Нью-Йорке. В этой статье будет говорится о системе Riak, с которой мне довелось иметь счастье работать последнее время.

Что такое Riak? Многие модные слова популярные сейчас, можно отнести к Riak. Riak — это документно-ориентированная база данных. Riak — это децентрализованное key-value хранилище данных, с поддержкой стандартных операций — get, put и delete. Riak — это распределенное, масштабируемое, отказоустойчивое решение для хранения информации. А так же Riak — это система с открытым исходным кодом и поддержкой обращений с помощью HTTP, JSON и REST. Ну и конечно RIAK — это NoSQL.

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

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

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



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

Вчера я задал вопрос в своем ХабраБлоге — интересно ли людям узнать, что такое Hadoop с точки зрения его реального применения? Оказалось, интересно. Дело недолгое — статью я написал довольно быстро (по крайней мере, ее первую часть) — как минимум, потому, что уже давно знал, о чем собираюсь написать (потому как еще неплохо помню как я сам тыкался в поиске информации, когда начинал пользоваться Hadoop). В первой статье речь пойдет об основах — но совсем не о тех, про которые обычно рассказывают :-)

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

Что такое Hadoop?

Ну скажите, какой смысл об этом писать? Уже не раз это проговаривалось, неоднократно начинали писаться посты на тему Hadoop, HDFS и прочая. К сожалению, обычно все заканчивалось на довольно пространном введении и фразе “Продолжение следует”. Так вот: это — продолжение. Кому-то тема, затрагиваемая в этой статье может показаться совершенно тривиальной и неинтересной, однако же лиха беда начало — любые сложные задачи надо решать по частям. Это утверждение, в частности, мы и реализуем в ходе статьи. Сразу замечу, что я постараюсь избежать написания кода в рамках этой конкретной статьи — это может подождать, а понять принципы построения программ, работающих с Map/Reduce можно и “на кошках” (к тому же с текущей частотой кардинального изменения API Hadoop любой код становится obsolete примерно через месяц).

Когда я начинал разбираться с Хадупом, очень большой сложностью лично для меня стало первоначальное понимание идеологии Map/Reduce (я предпочитаю писать это словосочетание именно так, чтобы подчеркнуть, что речь идет не о продукте, а о принципе). Суть и ценность метода станет понятна в самом конце — после того, как мы решим несложную задачу.

Введение

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

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

Драфт течпревью игры для программистов. (очень грязный, опубликовал, чтобы собрать мнения и замечания, не минусуйте сильно, пожалуйста) По мотивам
habrahabr.ru/blogs/sport_programming/74536
и
habrahabr.ru/blogs/sport_programming/74523
Готов в общем-то движок. Игра пошаговая, интерфейс к программам-игрокам — STDIN STDOUT, т.е. можно использовать любые языки программирования (хоть brainfuck, если он ввод-вывод поддерживает.)
Будет гуй-тестер на wxPython (Linux/Windows/OSX) и сайт с возможностью загрузки своих скриптов или бинарников, развернутой системой рейтинга игроков (в т.ч. по времени выполнения кода). Планируются коммандные бои и sdk для нескольких языков.
Все (включая сайт) будет под GPL и некоммерческим.
Приглашаются дезагнеры и флешеры

PS. Строго не судите, написанно absolute бегиннером буквально за ночь, под влиянием обсуждения на хабре. Лучше поддержите советом и коммитом
Update: Написал рабочее описание формата ввода/вывода программ-игроков
UPD Тут лежит примерное недоделаное сдк, код бота на питоне будет вроде такого:

Свой первый пробный пост на хабре решил посвятить очень, на мой взгляд, интересной железяке — одноплатному компьютеру BeagleBoard, основанному на процессоре OMAP3530 от Texas Instrumentals. Немного о характеристиках этого «камушка»:

**Over 1,200 Dhrystone MIPS using the superscalar ARM Cortex-A8 with highly accurate branch prediction and 256KB L2 cache running at up to 600MHz

**OpenGL© ES 2.0 capable 2D/3D graphics accelerator capable of rendering 10 million polygons per second

**HD video capable TMS320C64x+ DSP for versatile signal processing at up to 430MHz

**USB power via complete chip-set with minimal additional power-consuming logic

Многие мои знакомые так или иначе используют протокол SSH (заходя на свои роутеры, веб хостинги и непосредственно на собственные компьютеры дома и в офисе), при этом не все об этом знают.



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

В этой заметке вы узнаете:

• как прописать псевдонимы для соединений
• как настроить авторизацию без пароля
• как передавать файлы по SSH
• как запускать графические приложения по SSH
• а так же получите общие советы по опциям SSHD

Введение

Коллеги, при разработке приложений, мы каждый день сталкиваемся с потребностью в гибком хранении информации (обновлении, поиске по ней, и т.д.). Класс продуктов, которые решают этот круг задач, как все мы знаем — Базы данных. Но что это такое в нашем понимании? У многих «база данных» твердо ассоциируется с MySQL, таблицами и SQL-запросами. И это устраивает до определенного момента. Действительно, реляционные базы данных дают массу преимуществ в работе: поскольку данные имеют сильную связанность, не нужно контролировать целостность базы данных. Используя простой под-запрос можно выбрать количество комментариев к каждому посту в блоге. Используя JOIN нетрудно делать сложные связанные выборки и получать данные сразу о нескольких сущностях.

Привет, хабралюди!

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

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

Часть 1. Вступление.
Часть 2. Сбор данных.
Часть 3. Базовые метрики.
Часть 4. От статистики к аналитике

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

Каким же образом опытные аналитики “залезают в голову” пользователю, имея лишь усредненные данные по сайту? Никакой магии. Они проводят процедуры, которые разбирают эти авгиевы конюшни:

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

— Строят предположения и проверяют их: выискивают вероятные объяснения для сложившейся ситуации и пытаются повлиять на ситуацию исходя из этих предположений, наблюдая за результатом.

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

Итак, ряд простых, но полезных советов

В web-сервер и reverse-proxy nginx встроены очень мощные возможности по кэшированию HTTP-ответов. Однако в ряде случаев документации и примеров не хватает, в результате не все получается так легко и просто, как хотелось бы. Например, мои конфиги nginx-а местами написаны кровью. Этой статьей я попробую немного улучшить ситуацию.

В этой статье: а) подводные камни при полностраничном кэшировании; б) кэширование с ротацией; в) создание динамического «окна» в закэшированной странице.

Я буду предполагать, что вы используете связку nginx+fastcgi_php. Если вы применяете nginx+apache+mod_php, просто замените имена директив с fastcgi_cache* на proxy_cache*

Если выбирать, кэшировать ли страницу на стороне PHP или на стороне nginx, я выбираю nginx. Во-первых, это позволяет отдавать 5-10 тыс. запросов в секунду без каких-либо сложностей и без умных разговоров о «высокой нагрузке». Во-вторых, nginx самостоятельно следит за размером кэша и чистит его как при устаревании, так и при вытеснении нечасто используемых данных.

Кэширование всей страницы целиком

Если на вашем сайте главная страница хоть и генерируется динамически, но меняется достаточно редко, можно сильно снизить нагрузку на сервер, закэшировав ее в nginx. При высокой посещаемости даже кэширование на короткий срок (5 минут и меньше) уже дает огромный прирост в производительности, ведь кэш работает очень быстро. Даже закэшировав страницу всего на 30 секунд, вы все равно добьетесь значительной разгрузки сервера, сохранив при этом динамичность обновления данных (во многих случаях обновления раз в 30 секунд вполне достаточно).

Бодрый день, хаброчеловеки!

Что такое Redis?

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

Чем Redis отличается от существующих решений?

API для работы с Memcached (MemcacheDB) позволяет хранить массивы, но эти массивы будут сериализованы и сохранены как строки, таким образом атомарные операции над такими массивами не возможны.
Redis позволяет хранить как строки, так и массивы, к которым можно применять атомарные операции pop / push, делать выборки из таких массивов, выполнять сортировку элементов, получать объединения и пересечения массивов.

Производительность

110000 запросов SET в секунду, 81000 запросов GET в секунду на Linux-сервере начального уровня (тесты).

Высокая скорость работы Redis обеспечивается тем, что данные хранятся в оперативной памяти и сохраняются на диск либо через равные промежутки времени, либо при превышении определённого количества не сохранённых запросов. Из этого вытекает, что используя Redis, вы можете потерять результаты нескольких последних запросов, что вполне приемлимо для большинства веб-приложений, учитывая, что обращение к Redis по скорости сравнимо с обращением к оперативной памяти. Тем не менее, потерь можно избежать через избыточность — Redis поддерживает неблокирующую master-slave репликацию.

Sharding

Redis, как и Memcached, может работать как распределённое хранилище на многих физических серверах. Такой функционал реализуется в клиентских библиотеках, и к сожалению, «из коробки» этот функционал реализован пока только в Ruby API, однако это не мешает вам хешировать ключ самостоятельно и получать ID сервера, к которому с этим ключом обращаться.

API

API доступно для следующих языков:

• Ruby
• Python
• PHP
• Erlang
• Tcl
• Perl
• Lua
• Java

API для PHP доступно как в виде модуля, написанного на C, так и в виде PHP5 класса, который общается с Redis-сервером через сокеты, таким образом не требуется устанавливать модуль.
Кроме того существует PHP5 класс от отечественного разрабочика (с именем, заслуживающим доверия. Я серьёзно.) — IMemcacheClient. (Спасибо DYPA за наводку)

Перспективы развития

Разработка ведётся очень активно, комиты происходят почти каждый день, сейчас доступна версия Redis 0.900 (1.0 release candidate 1), которая очень скоро станет версией 1.0
В ближайшем будущем авторы обещают внедрить разные интересные фичи, в том числе и сжатие данных.

Лицензия и поддерживаемые платформы

Redis — написан на ANSI C и работает на большинстве POSIX-систем (Linux, MacOS X). Это бесплатное открытое ПО под BSD лицензией =)

Up: Rediska — удобный PHP-клиент для key-value базы Redis. Оф.сайт.

Доброе утро|день|вечер|ночь, %username%!

При использовании Memcached, иногда могут возникнуть вопросы: «А как посмотреть все ключи Memcached?» или «Как найти все ключи по маске „*“ или „sql_*“ ?»
Вот тогда открываются мануалы и начинается поиск такой функции, но, к сожалению, такой не оказывается :-(
Потом начинается Гугление… И там особо ничего нет :-(
А потом начинается поиск незадокументированных возможностей :-) и тут «Ура! Нашел!»

Введение

С момента написания мной предыдущей статьи по оптимизации этой связки прошло довольно много времени. Тот многострадальный Pentium 4 c 512Мб памяти, обслуживающий одновременно до тысячи человек на форуме и до 150,000 пиров на трекере уже давно покоится на какой-нить немецкой, свалке, а клуб сменил уже не один сервер. Всё сказанное в ней всё ещё остаётся актуальным, однако есть вещи которые стоит добавить.
Статья большая, так что будет поделена на логические блоки:

0. Зачем вообще что-то оптимизировать?
  
1. Оптимизация ОС (FreeBSD)
  1.1 Переход на 7.х 
  1.2 Переход на 7.2
  1.3 Переход на amd64
  1.4 Разгрузка сетевой подсистемы
  1.5 FreeBSD и большое кол-во файлов
  1.6 Softupdates, gjournal и mount options
  
2. Оптимизация фронтенда (nginx)
  2.1 Accept Filters
  2.2 Кеширование
  2.3 AIO
  
3. Оптимизация бэкенда
  3.1 APC
  3.1.1 APC locking
  3.1.2 APC hints
  3.1.3 APC fragmentation
  3.2 PHP 5.3
  
4. Оптимизация базы данных
  4.1 MySQL 
  4.1.1 Переход на 5.1
  4.1.2 Переход на InnoDB
  4.1.3 Встроеный кеш MySQL - Query Cache
  4.1.4 Индексы
  
4.2 PostgreSQL
  4.2.1 Индексы
  4.2.2 pgBouncer и другие.
  4.2.3 pgFouine
  
4.3 Разгрузка базы данных
  4.3.1 SphinxQL
  4.3.2 Не-RDBMS хранилище
  4.4 Кодировки
  4.5 Асинхронность
  
Приложение. Мелочи.
  1. SSHGuard или альтернатива.
  2. xtrabackup
  3. Перенос почты на другой хост
  4. Интеграция со сторонним ПО
  5. Мониторинг
  
 6. Минусы оптимизации

За последнее время видел пару хабратопиков (раз, два), в которых описывается использование неблокирующих сокетов и событийно-ориентированного программирования в вебе. Хочу поделиться своим опытом создания веб-приложения на этой технологии.

Недавно захотел создать свой сервис проверки номеров ICQ на невидимость. Алгоритм проверки старый и известный, но до сих пор работающий — отправка специально сформированного служебного сообщения и анализ ответа сервера. Необходимо было держать несколько постоянных подключений к серверу ICQ, а также иметь веб-интерфейс для запросов на проверку. Очевидное решение — создание демона, который создает несколько потоков для ICQ-соединений, и как-либо получает команды от веб-приложения, использующего несколько процессов-воркеров (или на preforked архитектуре) — для возможности обрабатывать http-запросы от нескольких клиентов. Но я решил освоить новую для себя технологию и сделать приложение, поддерживающее несколько соединений и отвечающее клиентам, используя всего лишь один поток.

Сегодня наткнулся во френдфиде исследователя фонда inVenture Ярослава Грешилова на 9 интереснейших правил проектной работы. Оговорюсь, что далеко не со всем здесь согласен, но пища для размышлений тем не менее превосходнейшая. Привожу здесь в удобном для чтения виде.

UPD от Ярослава: «Это не «правила Ярослава Грешилова», а правила *для* Ярослава Грешилова. И направлены они вовсе не на проектную работу, а на то, чтобы не потерять себя. Обсуждение того, что происходит с проектами при применении этих правил, не входило в мою задачу.»

Правило первое: работать имеет смысл не «над проектами», а «с людьми». Проекты всё равно имеют свойство со временем мутировать до неузнаваемости, а вот люди, как правило не меняются.

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

О чём это говорит? О том, что наше с ним взаимодействие — для обоих является пространством попробовать что-то непросчитываемое, то, что мы раньше не делали, толком никому не нужное. Получается не так много, но это наш способ развивать друг через друга и через то, что мы делаем. Казалось бы, после четырёх «неудач» нужно любые совместные инициативы рубить ещё на этапе обдумывания. Однако сотрудничество с этим человеком кажется мне одним из наиболее перспективных направлений жизни :-)

Правило второе: нельзя полностью растворяться в том, что ты делаешь, и ассоциировать себя с этим делом. Мои проекты — это не я. Они — лишь средство моего движения, самовыражения, исследования этого мира.

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

Люди не очень любят регистрироваться. Это же нужно (в общем случае) придумать логин и пароль, зайти в свою почту, дождаться письма, открыть его, перейти по ссылке активации аккаунта, а потом еще этот логин с паролем не забыть. Но ведь уже давно есть способ, с помощью которого все эти шаги не нужны. Более того, не нужно вообще ничего вводить с клавиатуры, 2 щелчка мышью и все, человек зарегистрирован.