17.2
Karma
0
Rating
Александр Макеев @SantyagoSeaman

User

NPM и left-pad: мы разучились программировать?

+2
Ух жесть. Битовый сдвиг и конкатенация строки на себя же чтобы немного уменьшить алгоритмическую сложность и нагрузку на GC, но оставив по-сути проблему треша на своём месте… Мир JS жесток и беспощаден. )))

NPM и left-pad: мы разучились программировать?

+3
Да, Вы правы. Тогда push в массив и join. Но никак не тот лютый трындец в сырце.

NPM и left-pad: мы разучились программировать?

+6
Странно, что у автора этой заметки, ведущего инженера Stack Overflow, нет претензий к дичайшему гавнокоду в указанном "ключевом модуле" и что никто до сих пор его не выправил. Делать в цикле конкатенации по количеству необходимых символов с генерацией каждый раз нового String объекта на каждой итерации вместо "return ch.repeat(len — str.length) + str" — это какой-то эпикфейл.

Badoo перешли на PHP7 и сэкономили $1M

0
И что? Вопрос же не в том, как хранить и преобразовывать, а в том, чтобы вообще не создавать тяжёлые объекты на каждый запрос, а пользоваться расшаренными. Кеши байткода избавляют от стадии компиляции. Но не избавляют от процесса создания объекта. А это те самые потерянные миллисекунды и процессорное время, которое вполне можно было бы потратить на что-то полезное. Да и конфиги — это малая из бед. Половину аппликейшена можно было бы реюзать если был бы нормальный инструмент. Естественно, апплекейшн пришлось бы изначально проектировать как стейтлесс, но это уже тема для отдельного топика.
Конечно, можно было бы использовать язык, изначально заточенный под event-loop или с легковесными потоками как в Go. Но не вижу никаких препятствий запилить нечто подобное и в Пыхе. Всё равно имхо к этому идёт.

Badoo перешли на PHP7 и сэкономили $1M

0
Да, это отличный подход, если конфиг не представляет собой здоровенное DOM-дерево с обёрткой вокруг для унификации и упрощения доступа.

Badoo перешли на PHP7 и сэкономили $1M

+1
Шарить что-то между серверами — это совсем другой уровень. Межпроцессный шаринг объектов очень пригодился бы для хранения тяжёлых read-only объектов вроде конфигов. На больших нагрузках может неплохо съэкономить на создании сокета, хендшейке, поиске информации в хранилище, отправке, закрытии соединения, десериализации. Всё это абсолютно лишнее, если уже готовый собранный конфиг лежит в виде zval где-то в памяти.

Badoo перешли на PHP7 и сэкономили $1M

+2
pthreads — совсем не то
shmop — почти то, если к нему ещё прикрутить мьютексы. И всё равно требует сериализации.
Идеально было бы: высокоуровневая языковая конструкция, позволяющая создавать и использовать объекты в разделяемой памяти с внутренней имплементацией exclusive&shared locking и TTL чтобы у дева голова об это не болела.

Badoo перешли на PHP7 и сэкономили $1M

+1
Я к тому, что идея shared memory в PHP имеет право на жизнь. Хранить сериализованные данные в одном из хранилищ — это не всегда выход. Собственно, APCU частично решает эту задачу. Но было бы круто вслед за мега-фичей в виде PHP FPM следующим шагом дать нативный инструмент работы с объектами в shared memory.
Мне довелось поработать с true Fast CGI на С++. Это ад. Но сама идея иметь объекты, живущие между запросами, жива и её вполне можно было бы органично имплементировать в стандарте языка.

Badoo перешли на PHP7 и сэкономили $1M

0
Нужно хранить объекты в памяти? вот вам memcache.

  1. Сериализация-десериализация крупных объектов может стать проблемой. Гораздо логичнее использовать уже созданный объект в shared memory. Конечно, это добавляет головняка с race conditions и на любое обновление данных придётся вешать мьютекс, но производительность сего решения может стоить того. Особенно если задача состоит в хранении крупного иммутабельного объекта вроде конфига, редко меняющегося и часто читаемого.
  2. Данный подход хорош для атомарных сущностей. Если же для инициализации объекта необходима инициализация зависимостей, то тут уже без велосипеда на костылях не обойтись.

Архитектура Stack Overflow

Повышаем производительность поиска с помощью партиционирования индекса в Apache Solr

0
В моём понимании splitshard — это скорее скорая помощь при дизбалансе шарды, а не инструмент шардирования. Нативных инструментов шардинга в Solr два: composite и implicit методики шардирования. Оба с предзаданным количеством шард. И split, если что-то пошло не так.
Из моего личного опыта шардирование из коробки на 100 инстансов плюс пара кастомных плагинов а-ла триггеры моего авторства работало на постоянную дозаливку и апдейт 2 ярда+ широких документов как часы. Но изначально был выбран правильный двухуровневый ключ, благодаря которому запросы формировались максимум к 3 шардам.
Строго говоря, сильно смутил только один аргумент в статье «Автоматическая ребалансировка по шардам предполагает, что одна наша партиция может быть разбросана по нескольким шардам». Как это и почему?

ЗЫ. Три Solr инстанса на отдельных портах плюс ZK поднимается для дев-машин за полчаса. Зато каждый дев может сразу прочувствовать, как его запросы будут работать в распределённой среде. Ибо, как говорят у нас в Одессе, это две большие разницы. :)

Повышаем производительность поиска с помощью партиционирования индекса в Apache Solr

0
Почему решили не использовать композитный ключ формата «batchId!docId» и запросы соответственно с указанием _route_? Это бы гарантировало попадание всех документов из одного батча в одну шарду и балансировку по пулу шард без дополнительных бубнов. В случае, если по-факту работы на проде будут появляться перекосы в размерах шард, в качестве решения всё тот же split.

Нужен ли человек для построения самообучающихся моделей?

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

Найди коррупционера. Анализ данных чиновников из проектов Канцелярской сотни (с примерами на R)

Найди коррупционера. Анализ данных чиновников из проектов Канцелярской сотни (с примерами на R)

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

Найди коррупционера. Анализ данных чиновников из проектов Канцелярской сотни (с примерами на R)

+5
Спасибо!
Первый персонаж шикарный. Круглая сирота без семьи и доходов. С квартирой в Киеве и Лексусом.

Найди коррупционера. Анализ данных чиновников из проектов Канцелярской сотни (с примерами на R)

Найди коррупционера. Анализ данных чиновников из проектов Канцелярской сотни (с примерами на R)

0
Датасет не смотрел, но судя по графикам действительно есть декларации с нулевыми доходами или это вероятные ошибки парсинга деклараций?

Лучше или хуже

0
Что-то вспомнились из моего детства 4 дискеты, принесенные из института старшим братом моего друга, со словами «Это С++! Самый крутой язык в мире!» И тоненькая жёлтая книжка, сразу начинавшаяся с сакрального «Объект — это инкапсулированная абстракция, которая включает информацию о состоянии и чётко определённое множество протоколов доступа». Что это такое я понял только несколько лет спустя. :)

Вышел Magento 2.0 Release Candidate

0
Спасибо за замечание. В следующей новости о релизе обязательно уточню «лидер opensource ecommerce систем». :)

Как я победил в конкурсе BigData от Beeline

0
Тоже участвовал в этом конкурсе, но в привате оказался только на 80-м месте с результатом 75.67%.
Схема работы с данными приблизительно такая же. Отчистка данных, предварительные прогоны по xgb/glm/nn, анализ предикторов с высоким показателем важности. Была попытка генерации доп-фич в виде CTR для каждой пары класс-предиктор для ряда хорошо показавших себя предикторов. На тестовой выборке доп. фичи скорее мешали, чем помогали. Поэтому были исключены. Но благодаря им была найдена взаимосвязь между предикторами x55-60 и финальным классом. Так же обнаружилось, что каждый класс помимо самых жирных предикторов вроде x8 или x29/x30 наилучшим образом предсказывался своим набором предикторов и поэтому была сделана модель на основании xgboost, предсказывающая каждый класс в отдельности и потом делающая свёртку с коррекцией весов для каждого класса. В конечном итоге упёрся в те самые 25% выборки, которые по моим выводам предсказать было невозможно. Видимо, это те самые пенсионеры, покупающие молодёжные тарифы в подарок внучке :) И, судя по финальному месту, просто не хватило времени/терпения чтобы сделать тонкую настройку модели.

Elasticsearch — сортируем выдачу руками

+1
У меня был похожий кейс на одном из проектов. Требовалось сохранить 10+ миллиардов туристических предложений. В качестве основного хранилища был выбран Solr. Почему именно он — вопрос второй. Суть в том, что помимо сохранения информации, нужно было вести историю изменения цен (редкие апдейты) и актуализировать наличие авиарейсов по каждому из миллиардов предложений в момент запроса для фильтрации и аналитики.
В итоге, апдейты цен с историей делались через самописанный модуль к Solr. Операция была тяжёлая из-за append-only архитектуры, но требования позволяли. Актуализация авиарейсов — это был крайне интересный хардкор. Рейсы хранились в кластере Redis. Информация по наличию мест и их количеству обновлялась практически в реалтайме. Чтобы это всё жило, я запилил несколько кастомных типов данных, которые использовались в схеме и просчитывались в реалтайме. При старте нод Solr делался прогрев внутреннего кеша инфой из Редиса. Памяти было много, можно было себе позволить.
Особый треш был в том, что всё это должно было работать на 100 шардах помноженных на коэффициент репликации. Плюс круглосуточный входной поток данных.

Сравнение цен на Европейские и Российские «облака» с SSD-дисками

Сравнение цен на Европейские и Российские «облака» с SSD-дисками

-1
Я наслышан о нареканиях на Хецнеровские сервера, за три года использования через меня прошёл десяток серверов и всё было в порядке. Быть может мне повезло… :)

Сравнение цен на Европейские и Российские «облака» с SSD-дисками

-3
И теперь победитель во всех категориях… Тадам!
Цена — 66,39 € для кастомеров из России
Intel® Xeon® E3-1270 v3
Quad-Core Haswell
RAM — 32 GB ECC RAM
Hard Drive — 2 x 240 GB SATA 6 Gb/s Data Center Series SSD (Software-RAID 1)
Connection — 1 Gbit/s-Port
Guaranteed Bandwidth — 200 Mbit/s
Backup Space — 100 GB
Inclusive Traffic — 30 TB
http://ru.hetzner.com/hosting/produkte_rootserver/px60ssd

Практический опыт работы с малоизвестными европейскими облачными хостингами

0
На столько же быстро, как у Амазона — конечно нет. Но можно создать свои образы под каждый тип нод и накатывать их при инсталяции свежей железяки.

Уязвимость wordpress

+1
Там вообще нет обрезки тегов. Все аргументы ескейптся с помощью мускульной функции. В базу попадает уже отъескепленный текст любого размера. И уже база делает отлуп превышения размерности.
Коммит — очередной костыль, к XSS не имеющий никакого отношения.
А это вообще шедевр
public function escape_by_ref( &$string ) { 
    if ( ! is_float( $string ) ) 
        $string = $this->_real_escape( $string ); 
}

Как, собственно, и весь ВП :)

PostgreSQL vs MySQL

+3
Фигня — это предлагать сделать foreign key на двигле, который foreign key не поддерживает и говорить при этом «фигня» )))

PostgreSQL vs MySQL

PostgreSQL vs MySQL

+2
Вас удовлетворит, если я скажу, что все проблемы с целостностью данных которые встречались нам были связаны с ошибками приложения-писателя, и ни разу не было проблем, связанных с libslave?

Ну тут не в удовлетворении дело… :) Меня просто интересуют сложные ситуации на продакшене. Вот и докапываюсь, откуда ноги растут, наступившие и победившие грабли.
По поводу CHECK я понял. Хоть это и не имеет отношения конкретно к ссылочной целостности, но мы точки на i расставили. Спасибо.

PostgreSQL vs MySQL

+5
Вы ошибаетесь. Подробней читайте тут: habrahabr.ru/company/mailru/blog/219015/

Если я всё правильно понял из статьи, то там прямо говорится, что Бегун запилил свой libslave, занимающийся разбором бинлога, под свои узкопрофильные задачи, и что проверка консистентности данных проводится демоном потому что «Заметим, что на этапе первоначальной выборки данных их неконсистентность не говорит о том, что ошибки присутствуют в базе — просто это такая особенность процесса загрузки данных. Такая неконсистентность будет исправлена далее демоном при дочитывании данных. А вот если после этого в них есть какие-то несоответствия — тогда уже да, тогда это база.»

Проблема именно в том, что в MySQL вставляют некорректные данные, и в нём нету возможности запретить такие данные вставлять.

dev.mysql.com/doc/refman/5.6/en/create-table-foreign-keys.html
Бажное(зарепорчено?)/не использовалось вообще/сливало данные в бинлог до проверки (зарепорчено?)?

Затем, что проекты сидящие на 5.5 часто используют одновременно MyISAM таблицы для полнотекстового поиска и InnoDB таблицы для всего остального.

Низкопроизводительный костыль, нет?

Да, тот самый пресловутый CHECK, без которого в сложных проектах жизнь становится горькой

CHECK отсутствует, но легко реализуем через триггеры.
Остальные «constraint'ы общего вида» в MySQL присутствуют из коробки и вполне работоспособны.
dev.mysql.com/doc/refman/5.6/en/create-table.html

PostgreSQL vs MySQL

+2
Он не может загрузить таргетинги, например, если в таргетингах кривая косвенная ссылка на баннер или кампанию — т.е. демон обнаруживает неконсистентность данных, и в такой ситуации рапортует о ней.

Вангую, что это не проблема проверки ссылочной целостности на уровне БД (foreign key запретили что ли?), а проблема рассинхрона данных в БД и их копии в памяти, из-за которой и пришлось городить костыли. К выбору MySQL/PostgreSQL никакого отношения не имеющая. Поправьте меня, если ошибаюсь.

Совершенно неочевидно. До, кажется, 5.6 в InnoDB не было полнотекстового поиска, а в 5.6 уже есть регрессия производительности репликации, потому многие сидят на 5.5

Мы обсуждали ссылочную целостность. Отсюда и контекст. При чём тут полнотекстовый поиск? Да и вообще для этих задач из опенсорса есть Solr/Elasticsearch/Sphinx. Всё остальное — зло.

Без поддержки table inheritance и constraint'ов общего вида проверять валидность таких ссылок можно лишь на уровне приложения, а это очень неудобно.

Начнём с того, что PostgreSQL изначально была Object-Relational DB. И её по фичам невозможно сравнивать с классической RDBMS.
Во-вторых, вопрос был в том, что именно из sql constraints (за исключением check) реализовано в PostgreSQL и отсутствует в MySQL или же реализовано «не достаточно»?

PostgreSQL vs MySQL

+6
Демон подбирает баннеры рекламной системы Таргет

И какое это имеет отношение к ссылочной целостности?

Не в MySQL, а в InnoDB. И таких базовых проверок явно недостаточно.

То что в InnoDB в данном контексте это очевидно, думаю.
Не очевидно, каких именно проверок ссылочной целостности не хватает в Мускуле для полного счастья?

PostgreSQL vs MySQL

+1
Один из наших демонов, работающий как slave к MySQL, мониторит ссылочную целостность

Можно чуть подробнее, что именно делает ваш демон?

В PostgreSQL практически все наши хотелки описываются через constraints общего вида.

Если речь идёт о CHECK, то это проверка не ссылочной целостности, а данных. При желании отлично решается через триггеры.
Всё остальное (not null, unique, foreign keys) реализовано в MySQL в рамках стандарта SQL-92.

PostgreSQL vs MySQL

+5
«Например, в MySQL приходится писать собственные инструменты для верификации обычной ссылочной целостности базы.»
Вы это серьёзно?

Adobe представила стриминговую версию Photoshop для ChromeOS

+1
Я так понимаю, ни о цветовых профайлах, ни о кастомных плагинах в SaaS решении речи не едёт?

Безопасное развертывание ElasticSearch сервера

0
Я имею в виду мэпинг физических файлов в память, входящий в стандарт posix и активно используемый Еластиком при работе с индексами при включенном mmapfs. Я не в курсе подробностей, умеет ли контейнер работать с этой фичей. По-верхам погуглил и ничего внятного не нашёл.
ЗЫ. Тому кто не понял вопрос и влепил минус отдельное спасибо.

Безопасное развертывание ElasticSearch сервера

Lean Big Data на 6 сервисах Google

0
У нас 100 млн. событий в час и мы (хоть и потратили на это пару человеко-месяцев) научились их обрабатывать в штатном MySQL.

Можно об этом чуть подробнее?

Масштабируем Elasticsearch на примере кластера с индексами в несколько терабайт

0
3. Помимо индексирования текста документа используются дополнительные индексированные атрибуты: дата создания, категория, код, владелец/автор, etc?
4. Да, согласен про палец :) Задал вопрос, смотря на тему со своей колокольни. Среднюю температуру по больнице понял, спасибо!
1 There