Не для кого уже не секрет о том, что рано или поздно у вас на сайте (сервисе, web-приложении, ...) в какой-то момент начинает расти активность и число пользователей. Вот некоторые шаги/рекомендации как не «упасть» и поддерживать стабильную работу.
Читать полностью »
При разработке ПО часто возникают интересные задачи. Одна из таких: работа с гео-координатами пользователей. Если вашим сервисом пользуются миллионы пользователей и запросы к РСУБД происходят часто, то выбор алгоритма играет важную роль. О том как оптимально обрабатывать большое количество запросов и искать ближайшие гео-позиции рассказано под катом.
В этом посте хотелось бы рассказать больше про концепцию панели аналитики. Собственно именно она дает разработчикам уникальные возможности для поиска проблемных по производительности мест в коде.
PRFLR — это система аналитики, направленная на скорейшее обнаружения проблемных по производительности мест в работе приложений. Realtime и непосредственно на Production серверах.
В первую очередь PRFLR ориентирован на высоконагруженные серверные приложения работающие на больших кластерах, однако применим для небольших проектов, десктоп и мобильных приложений. Конечно если вас действительно волнует вопрос их быстродействия.
В нашем проекте возникла следующая задача — есть база с большим количеством товаров, на уровне сотен тысяч. У каждого товара есть сотни динамически создаваемых характеристик. Необходимо обеспечить быструю фильтрацию по товарам по набору различных характеристик. Время формирования ответа должно быть не более 0.3 секунды, нужно поддерживать сложную логику в стиле.
(характеристика1 = true AND (характеристика2 < 100)) OR (характеристика1 = false AND (характеристика3 > 17)) ... далее обычно мешанина из ANDORТипичный пример подобного функционала — hotline.ua/computer/myshi-klaviatury/
У нас все реализовано в рамках MySQL + Symfony2/Doctrine, скорость неудовлетворительная — ответы формируются в течении 1-10 секунд. Мои попытки оптимизировать все это хозяйство — под катом.
Читать полностью »
Один из наших кластеров для пилотных задач (Data node: 18 servers /2 CPUs, 12 Cores, 64GB RAM/, 12 Disks, 3 TB, SATA — HP DL380g)
— Что такое Big Data вообще?
Все знают, что это обработка огромных массивов данных. Но, например, работа с Oracle-базой на 20 Гигабайт или 4 Петабайта — это ещё не Big Data, это просто highload-БД.
— Так в чём ключевое отличие Big Data от «обычных» highload-систем?
В возможности строить гибкие запросы. Реляционная база данных, в силу своей архитектуры, предназначена для коротких быстрых запросов, идущих однотипным потоком. Если вы вдруг решите выйти за пределы таких запросов и собрать новый сложный, то базу придётся переписывать – или же она умрёт под нагрузкой.
— Откуда берётся эта новая нагрузка?
Если чуть углубиться в архитектуру, то можно увидеть, что традиционные базы данных хранят информацию очень дисперсионно. Например, у нас номер абонента может быть на одном сервере в одной таблице, а его баланс — в другой таблице. Быстродействие требует максимального разбиения данных. Как только мы начинаем делать сложные join'ы, производительность резко падает. Читать полностью »
В данной статье я постараюсь вспомнить и описать все сложности и подводные камни, которые встречались на пути реализации задач, связанных с проектом Ответы, также расскажу и про архитектуру проекта.
Все началось с того, что мой контракт подошел к концу (в течение года я участвовал в работе над почтой Mail.ru). «Снова меня ждут приключения», — пронеслось в мыслях, — «новая страна, новая работа». Я пошел к своему начальству и в ходе обсуждений все-таки получил порцию приключений в виде интересной задачки — заняться проектом Ответы.Читать полностью »
В последнее время набирают популярность различные NoSQL базы данных. Эта статья начиналась как изучение особенностей графитовой графовой базы данных Neo4j. Но, в процессе подбора информации, мне захотелось систематизировать информацию о NoSQL решениях и о графовых базах данных, в частности.
В ходе этого небольшого исследования, были выбраны для подробного рассмотрения СУБД, успешно применяющиеся в области Web. И, поскольку в тегах присутствует «PHP», я выбирал СУБД, которые уже можно использовать с этим языком.
Для тех, кто знаком с Magento, не секрет, что этот e-commerce движок довольно требователен к железу. Но разработчики этого интернет-магазина попытались решить эту проблему и придумали много различного рода «ускорялок», без которых, пожалуй, запускать магазин на движке Magento в продакшн не стоит. Слишком долго Magento будет отдавать конечному пользователю страницу. Среди таких «ускорялок» кеши, индексы, компиляция, объединение JS/CSS в один сжатый файл и др.
Одной из основных «фишек» Magento Enterprise является Full Page Cache (далее FPC). Эту «фишку» реализует модуль Enterprise_PageCache, входящий в состав пакета Magento Enterprise.
В статье рассматривается самая свежая на момент написания статьи версия Magento Enterprise: 1.13.1.
FPC позволяет отдавать серверу страницу за считанные миллисекунды, практически не нагружая сервер. Я провел замеры времени отдачи страницы продукта сервером (в одном из проектов, над которым работал), вот результаты:
Почему разница настолько велика? Давайте разберёмся.
Доброго времени суток.
Сегодня поговорим о Highload инфоблоках. Точнее как с ними работать. Если вы посмотрите в инете, то везде есть как с них взять инфу, но как наоборот записать-изменить-удалить — этого я не нашел (наверное просто я плохо искал), но мне ооочень надо было.
Поэтому я обратился к ЛайфАПИ и раскопал кое-что. Начнем по порядку.
Как вы наверное заметили, эти инфоблоки содержат пользовательские поля. Т.е. каждое поле начинается с UF. Но я не буду разжевывать, т.к. кто кодит на битриксе, тот знает это.
.jpg "Оптимизация запросов. Основы EXPLAIN в PostgreSQL (часть 3)")
Подолжаю публиковать авторскую переработку Understanding EXPLAIN от Guillaume Lelarge.
Ещё раз обращу внимание, что часть информации для краткости опущено, так что настоятельно рекомендую ознакомиться с оригиналом.