_{Фото: ivan dupont}

Всем привет! Меня зовут Дмитрий Исайкин, и с недавних пор я занимаюсь мобильной разработкой. Почему с недавних? Еще три месяца назад я был руководителем группы C/C++-разработки Почты Mail.Ru. Но однажды я в очередной раз задумался о том, что мне всё меньше и меньше нравится то, чем я занимаюсь. Больше времени стали отнимать обязанности тимлида: мотивация, стимуляция, отчётность, административные заботы. И тогда я решил: пора что-то менять. Разместил резюме, сходил на несколько собеседований. Всё это время я размышлял о том, чего же я хочу. Мне предложили возглавить направление разработки в одной достаточно крупной фирме, и я практически согласился. Но, «переспав» с этим решением бессонную ночь, я понял, что такая работа будет мне не в радость. Ещё был вариант пойти старшим разработчиком в другую хорошую фирму. Но там пришлось бы заниматься примерно той же работой, что и в предыдущие годы.

На Гайдаровском форуме Герман Греф заявил, что Сбербанк будет переходить на новые информационные технологии, выбрав в качестве основного партнёра российско-американскую компанию с численностью 60 чел. При этом Сбербанк потратил 65 млрд. руб. на амбициозный и сложный проект централизации ИТ- структуры и на сегодняшний день у него более 22 000 ИТ-сотрудников, включая 6 тыс. человек в Сбертехе. Основная причина перехода — скорость внесения изменений в ИТ, которая была низка и привела к отставанию ИТ Сбербанка от лидеров по развитию и гибкости ИТ-инфраструктуры. А насколько важна скорость внесения изменений в разработке? На что нужно обратить внимание в управлении процессом разработки? Стоит ли использовать модели и методологии? Попробуем разобраться.

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

DataPro на улице Авиамоторная относится к самым надежным ЦОДам Tier III, является одним из немногих коммерческих ЦОД в России, получивших сертификацию Uptime Design и Facility. Сегодня мы немного расскажем о проекте и максимально подробно рассмотрим техническую реализацию и особенности системы энергоснабжения.

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



Рассмотрим небольшой пример развертывания S3-совместимого хранилища на основе объектного хранилища Ceph

Здравствуйте, уважаемые читатели!

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

• высокая надежность хранения
• высокая доступность данных, то есть минимальное время простоя при авариях
• высокая скорость доступа и минимальные задержки
• низкая удельная стоимость хранения
• различные прикладные возможности: клонирование, снимки состояния и т.д.

Ни RAID-массивы, ни «железные» СХД не способны решить все перечисленные задачи одновременно. Именно поэтому все большее распространение в индустрии хостинга приобретает Software-defined storage. Одним из ярких представителей SDS является распределенное хранилище под названием Ceph.

Мы решили рассказать об этом замечательном продукте, который используется в CERN, 2GIS, Mail.ru и в нашем облачном хостинге.

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

Большой мир генерирует большие данные. Вот и на нашу голову свалился большой граф. Настолько большой, что мы можем удержать в памяти его вершины, но не ребра. Кроме того, относительно графа приходят обновления – какое ребро добавить, какое удалить. Можно сказать, что каждое такое обновление мы видим в первый и последний раз. В таких условиях необходимо найти компоненты связности.

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

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

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

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

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.

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

Мы в 1cloud стараемся рассказывать о различных технологиях — например, контейнерах, SSL или флеш-памяти.

Сегодня мы продолжим тему памяти. Разработчик Роберт Элдер (Robert Elder) в своем блоге опубликовал материал с описанием возможностей виртуальной памяти, которые известны не всем инженерам. Мы представляем вашему вниманию основные мысли этой заметки.

Сегодня мы разберем профильную тему на основе кейса Google Tech Talks, которым поделился один из инженеров компании, а тематических журнал High Scalability проанализировал рассказ ИТ-специалиста Google.

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

… но это нормально. Любое проектирование отстой. И всегда будет отстоем.

Если вы мне не верите, давайте объясню…

Ни один проект не переживает встречи с реализацией

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

Данные, которые вы ожидали как обязательные в ответе внешнего сервиса, могут отсутствовать (или быть невалидными). Ожидаемая уникальность может оказаться совсем не уникальной на практике (даже в sha1 когда-нибудь случаются коллизии). Процессы, которые предполагались надежными, будут падать гораздо чаще, чем вы ожидали.

Это нормально.

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

Недостающие данные могут быть сделаны опциональными или заменены умолчальными.

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

Ограничение уникальности можно

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

Например, совсем недавно мы рассказывали:

• о том, как Spotify масштабирует Apache Storm,
• рассматривали аппаратное обеспечение для глубокого обучения
• и бегло поговорили о примере оптимизации полосу пропускания в сетях Ethernet.

Сегодня мы расскажем о главных отличиях между PaaS и IaaS.

Язык логического программирования PROLOG (далее – ПРОЛОГ) большинству программистов представляется чем-то запутанным и малопригодным для практического применения. В то же время, Интернет основан на символьной информации, поэтому практически все современные программисты сталкиваются с необходимостью обрабатывать символьные структуры данных, а ведь для этого и предназначен язык логического программирования ПРОЛОГ. Этот язык – идеальный для работы с символьными структурами, текстовыми файлами и для построения интеллектуальных программ.

При разработке баз данных зачастую требуется обеспечить поддержку версионности и хранения истории объектов. Например, у работника может изменяться должность, у должности в свою очередь может меняться оклад — в многомерном моделировании это называется Slowly changing dimensions(далее SCD) — редко изменяющиеся измерения, то есть измерения, не ключевые атрибуты которых имеют тенденцию со временем изменяться. Всего существует 6 основных типов(методов) SCD, которые определяют как история изменений может быть отражена в модели.

Функцией партиционирования таблиц в PostgreSQL, к сожалению, активно пользуются пока не многие. На мой взгляд, очень достойно о ней рассказывает в своей работе Hubert Lubaczewski (depesz.com). Предлагаю вам еще один перевод его статьи!

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

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

Не так давно мой коллега переводил интересную статью о code review, перевод хабражителям понравился. А сегодня утром запутанный граф кроссылок вывел eyeofhell на еще более крутую статью. Вашему вниманию предлагается перевод краткой, но емкой инструкции о том, как делать review чужого кода и пережить review собственного. В отличие от упомянутой выше статьи, эта больше фокусируется на практических аспектах code review и содержит множество полезных рекомендаций как и что делать, чтобы не было мучительно больно. Хинт: чтобы почитать оригинал, кликните на имени автора в плашке под переводом.

Всем привет!

В этот раз я расскажу не про использование Python или очередной трюк с CSS/HTML и, увы, не про то, как я 5 лет портировал Вангеры, а про один важный аспект написания расширений для замечательной СУБД PostgresSQL.

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

К таблицам из Си можно получить доступ через хорошо описанный но медленный SPI (Server Programming Interface), также есть очень сложный способ, через буферы, а я расскажу про компромиссный вариант. Под катом я постарался дать примеры кода с подробными пояснениями.

Аннотация

При помощи московского представительства компании IBM мы провели тестирование производительности последних версий СУБД PostgreSQL на серверах Power8, изучили масштабируемость зависимость производительности от количества одновременных запросов, нашли узкие места ограничивающие производительность, предложили новые технические решения и добились рекордной производительности.

Введение

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

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

Для решения таких проблем существуют механизмы управления доступом к ресурсам — использование блокировок, а также пригодные в некоторых случаях неблокирующие (lock-free) подходы. Рост производительности этих механизмов, а также детализация блокировок дает возможность снизить издержки, связанные с одновременным (конкурентным) доступом.

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