• Я больше не хочу работать, никогда и ни над чем. Но из меня научились выжимать результаты
    +2
    Мне одному кажется, что проблема высосана из пальца, а статья — просто сплошное нытье и негатив? Тут достается не только мифическим «злобным менеджерам», но даже жене и детям.
    Автору:
    1. обратиться к психотерапевту
    2. найти коворкинг/снять квартиру для работы
    3. пересмотреть приоритеты в жизни, найти пару хобби, не связанных с IT. Желательно что-то спортивное (бег, волейбол, плаванье)
    4. возможно поменять работу, благо вариантов на рынке — предостаточно. То что описано в статье, может и встречается, но точно — не всегда и не везде, полно продуктовых компаний, которые готовы жертвовать скоростью в пользу качества. Другое дело, если ты всё делаешь в последний момент, а вместо работы строчишь на хабре статью как у тебя все плохо — разве это потому, что менеджеры плохие?
  • Почему понадобилось разработать «русский дропбокс»
    0
    https://disk.megafon.ru
  • Почему понадобилось разработать «русский дропбокс»
    +5
    Почему вы не доработали NextCloud (OwnCloud) пользы от вас было бы больше

    Мне кажется автор этого комментария даже отдаленно не имел дела с OwnCloud. Просто ради интереса посмотрите на их багтрекер на гитхабе — сколько там критикал багов, да и вообще какой процент от всего их функционала реально нужен, а какой лишь привносит дополнительный оверхед в перфоманс

    E2E шифрование

    в данного рода решениях — это сразу ставит крест на юзабилити. хотите e2e — пользуйте BitTorrent Sync.
  • Почему не все так просто с MongoDB
    0
    >ReadPreference.SECONDARY_PREFERRED не значит, что «если мастер недоступен, то читать с slave», но значит, что мы всегда позволяем читать с него.

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

    >Затем, что если остановка инстанса не закрывает коннект (я такое читал на их форуме) по причинам/особенностям организации сетевого стека AWS,

    Как то очень странно звучит. У других приложений такой проблемы не наблюдалось :-)

    >А какого волшебного поведения вы в этой ситуации ожидали?

    Ну как минимум, что будет гарантирован результат — удалось записать данные или не удалось. А не просто «ошибка, а дальше сам гадай, записалось оно или нет». Тут дело не в транзакциях. Тарнзакции это дело 10ое. В тех же самых РСУБД вы можете не использовать транзакции, и тем не менее они гарантируют результат записи.
  • Почему не все так просто с MongoDB
    0
    >А зачем ReadPreference.SECONDARY_PREFERRED, как оно вообще относится к отказо-устойчивам write?

    потому что read тоже зависает. чтобы он не зависал при гибели мастера нужно чтобы он читал с secondary

    >По поводу проблем подвисания коннекта, я советую попробовать вместо остановки инстанса в вашем тест убить процесс монги — результат может удивить

    зачем? мне интересна именно смерть инстанса а не смерть процесса. Смерть процесса это как раз-таки случай не такой частый

    >Ну и очевидно, что и без всякой поддержки в драйвере это решается элементарно, созданием DBObject (или что там вместо него в питоне) вне цикла, и запись с одним и тем же _id не пройдет.

    ну собственно в статье про это и написано. Только это совсем не элементарно и не интуитивно понятно. Да и выглядит как костыль костылем

    >Тут какая-то путаница. Эти 5 секунд не таймаут на запрос, но таймаут на коннект. И если запрос выполняется даже 10 минут, драйвер его не сбросит, во всяком случае нормально написанный драйвер.

    нет, на коннект как раз-таки есть свой таймаут. он называется connectTimeoutMS: api.mongodb.org/python/current/api/pymongo/mongo_client.html#pymongo.mongo_client.MongoClient

  • Почему не все так просто с MongoDB
    0
    Это зависит от задачи, можно наделать тестов где mysql будет проигрывать, например поиск в массивах, вычерпывание очереди, upsert, sparse, плавающие размеры данных и т.д.
    Тут например монга обошла в 20-100 раз mysql.
    Тесты тестам рознь. Если тестировать БД что называется «из коробки», то грош цена таким тестам. В той статье, что вы привели, помоему так и есть. Особенно судя по вот этому абзацу:
    >Use case #1: Insertion of millions of records in parallel:

    >The winner in this use case is MyISAM engine. MyISAM doesn’t neither support foreign key constraint nor transactions (unlike InnoDB). MyISAM index works good in insertion operation given that the record size will be changed, but it will be bad in case of delete/update operation.
    То есть люди явно не настроили параметр innodb_flush_log_at_trx_commit в конфигах для InnoDB. Но казалось бы и пофик. Пусть даже этот тест правдив. Еще раз хочу сказать, цель данной статьи — не сказать, какая MongoDB плохая, а MySQL такой весь из себя хороший. Цель — поделиться мнением, когда MongoDB можно использовать, а когда могут возникнуть сложности.

    А то что у вас такие конские апдейты, возможно говорит о не продуманной архитектуре
    Конкретно в моем проекте такого количества апдейтов нет. Но тем не менее проблема с массовыми операциями есть — они выполняются не так быстро, как хотелось бы. Пример, который я привел в статье — это бэнчмарк.
  • Почему не все так просто с MongoDB
    +1
    1. Ещё раз, DB Level Lock был пофикшен в MongoDB 2.2 ещё в далёком 2012 году.
    У меня складывается ощущение что вы не смотрели ссылку, которую сюда же сами и написали. Там написано «MongoDB 2.2 increases the server’s capacity for concurrent operations with the following improvements: DB Level Locking, Improved Yielding on Page Faults»
    В MongoDB 2.2 global lock был переведен с уровня процесса mongod на уровень базы. Плюс добавили «приспускание» лока во время долгих операций (аля update/delete). Ни о каком фиксе и речи не идет. Он как был так до сих пор и есть. Просто сужают область — сначала был процесс mongod, потом сделали на уровне БД. В MongoDB 3.0 сделали на уровне коллекции.

    WiredTiger пока не по умолчанию исключительно по одной причине: чтобы разработчики не боялись обновляться на 3-ю версию.
    Сомневаюсь. Баги на багтрекере говорят об обратном

    Да, вот так жестоко зарублена обратная совместимость, что даже новый, полностью совместимый движок, не включен по умолчанию.
    Про проблемы обратной совместимости хотя бы между 2.4 и 2.6 я писал уже выше.
  • Почему не все так просто с MongoDB
    +1
    1. То что в Mongo 3.0 MMAP лок на уровне коллекции, а не на уровне базы — это не сильно спасает. А про WiredTiger в плане производительности говорить о каком-то прорыве еще рано. Да он в каких-то кейсах он быстрее MMAP, но реляционным БД продолжает проигрывать. Вот тут например пишут, что у WiredTiger медленный поиск по ключу, потому что он не может поместить индекс в память. Совсем не good.

    2. Даже если проект делается с нуля — использовать ли WiredTiger или не использовать — это большой вопрос. WiredTiger — если что, еще даже не движок по умолчанию. Если посмотреть багтрекер 10gen, то в WiredTiger много всего интересного. Например, вот:
    jira.mongodb.org/browse/SERVER-20204
    или вот:
    jira.mongodb.org/browse/SERVER-17456
    Вы с такими багами пойдете в продакшен? я вот что-то сомневаюсь.

    3.
    смигрировать на WiredTiger можно очень быстро

    Начнем с того, что данные надо мигрировать через backup-restore. Это процедура совсем не быстрая Вот у меня есть база 2.6 на 20млн нод активных данных с двумя шардами и репликацией. Запись идет постоянно, чтение тоже постоянно.
    Вы думаете я рискну взять и обновить базу только потому что вышел новый движок? :-) Да даже если бы и не надо было делать backup-restore обновление продакшен базы с одной мажорной версии на другую черевато проблемами. А уж зная MongoDB и как ребята по стартаперски рубят обратную совместимость…
  • Почему не все так просто с MongoDB
    0
    Мне кажется вы как-то поспешно делате выводы, не прочитав пункт про Global lock. Там говорится и про 3.0 и про WiredTiger в том числе
  • Почему не все так просто с MongoDB
    0
    Да, точно. С 3.0 блокировка на уровне коллекций:
    docs.mongodb.org/manual/release-notes/3.0/#mmapv1-concurrency-improvement
    MMAPv1 Concurrency Improvement
    In version 3.0, the MMAPv1 storage engine adds support for collection-level locking.

    Как-то упустил это из виду. Видимо слишком увлекся релиз нотисами про WiredTiger.
  • Почему не все так просто с MongoDB
    +2
    Дико извиняюсь. Конечно же опечатка.
  • Почему не все так просто с MongoDB
    0
    ok! спасибо за совет — учтем.
  • Почему не все так просто с MongoDB
    +2
    Почему эксепшен это проблема?

    Потому что эксепшен в данном конкретном случае не гарантирует, что запись не прошла — она могла пройти, а погла не пройти. write concern здесь вообще не при чем
    emptysqua.re/blog/save-the-monkey-reliably-writing-to-mongodb
    jira.mongodb.org/browse/PYTHON-197
  • Почему не все так просто с MongoDB
    0
    ну я бы для начала накатил бы коллекцию без индексов (mongorestore --noIndexRestore), далее посмотрел бы какие индексы используются в той коллекции, с которой вы сняли дамп, затем по одной начал бы накатывать эти индексы на восстановленную коллекцию, а там уже — на каком индексе сломалось, надо смотреть, что не так с данными. Скорее всего команда, которая ракатывает индекс, выдаст сообщение на каких конкретно данных она сломалась, и что ей не понравилось.

    Да, я понимаю, что процесс не быстрый. Но как вариант решения — сгодится
  • Почему не все так просто с MongoDB
    –1
    Вы не совсем меня поняли, да и наверное я объяснил не совсем правильно. Все почему-то набросились на 15ть секунд таймаута, хотя это тут вообще дело 10ое.

    Основная проблема в эксепшенах типа AutoReconnect. Эти эксепшены происходят из-за проблем с сетью, не важно работаете ли вы на репликсете или шардированной конфигурации или же на одном сервере монги без ничего. Т.е. если драйвер pymongo в какой-то момент работы не получает ответ от сервера, то он райзит такой эксепшен. Один из частных случаев, как это воспроизвести — это отрубание primary в репликсете из 3х машин.

    Проблема pymongo (и возможно MongoDB тоже) в том, что он не может проконтролировать, добавился ли документ в момент insert-а или же нет. Т.е. вы должны контролировать это сами в своем коде.
  • Почему не все так просто с MongoDB
    0
    не, ну я к тому, что для начала надо понять почему нельзя сделать нормальный ресторе. Т.е. локализовать проблему — т.е. это проблема утилиты mongorestore или проблема схемы данных или проблема что дамп при помощи утилиты mongodump делается как-то неправильно. Т.е. один раз руками расковырять, разобраться, решить проблему, а потом автоматизация и пр.
  • Почему не все так просто с MongoDB
    0
    По поводу бага 2 — вы какую версию mongo используете (с которой дамп снимаете)? случаем не 2.4? а в какую версию восстанавливаете — 2.6-3.0?
    Просто интерсный баг был в версии 2.4. Вот например есть у нас коллекция со следующей структурой:

    >db.entites.findOne()
    {
            "_id" : ObjectId("54837b27bf0a898b0cbb3b78"),
            "path" : "/home/foo/bar/",
            "owner_id" : 42,
            "some_value_1" : 1,
            "some_value_2" : 2,
            "some_value_3" : 3
    }
    
    >db.entites.ensureIndex({"path": 1, “owner_id”: 1})
    


    Т.е. поле path — хранит путь — строку произвольной длины. И вот, допустим, пользователь создает документ, где поле path длиной более 1024 символов:

    >db.entites.insert({path: new Array(1025).join('x'), owner_id: 42, "some_value_1" : 1, "some_value_2" : 2, "some_value_3" : 3})
    


    И все. Документ пропал. Выполняя запрос:

    >db.entites.find({path: new Array(1025).join('x'), owner_id: 42}).count()
    0
    

    вы его не найдете. А все потому-то:
    http://docs.mongodb.org/manual/reference/limits/#Index-Key-Limit
    The total size of an index entry, which can include structural overhead depending on the BSON type, must be less than 1024 bytes.

    То есть монга 2.4 разрешает документ создать, но не добавляет его в индекс, потому что поле path больше максимально возможной длины.
    Кстати вот такой запрос-таки найдет пропавший документ:

    >db.entites.find({path: new Array(1025).join('x'), owner_id: 42}).hint({_id: 1}).pretty()
    


    А вот монга 2.6 такой документ создавать не разрешает и на моменте insert-а кидает эксепшен:

    > db.entites.insert({path: new Array(1025).join('x'), owner_id: 42, "some_value_1" : 1, "some_value_2" : 2, "some_value_3" : 3})
    WriteResult({
            "nInserted" : 0,
            "writeError" : {
                    "code" : 17280,
                    "errmsg" : "insertDocument :: caused by :: 17280 Btree::insert: key too large to index, failing test.entites.$path_1_owner_id_1 1037 { : \"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...\" }"
            }
    })
    


    В любом случае, я бы посоветовал бы вам делать mongorestore c ключиками --drop (чтобы на всякий пожарный удалить существующую коллекцию если она есть) и --noIndexRestore (чтобы при восстановлении восстановить без индексов, а потом их нагнать руками)
  • Почему не все так просто с MongoDB
    –1
    Дык я и не говорю, что «Монго — это зло, давайте дружно переходить на MySQL» :-)
    Репликация и шардинг из коробки вообще как киллер фича монги, очень подкупают.
    Про эти 15ть секунд, как я и писал выше в комментариях, тоже не так страшно.
    Основная траббла, в подвисании воркеров, ошибках AutoReconnect и в том, что pymongo не знает, удалось ли ему создать документ или не удалось. А самому руками генерить ObjectId в коде на каждый insert — далеко нетривиальная штука.
  • Почему не все так просто с MongoDB
    +1
    Про общее затраченное время — в случае MySQL оно составляет в районе 18ти секунд на один проход количеством N (1..30) процессов по всем юзерам и практически не меняется при нарастани числа воркеров. В случае MongoDB оно составляет в районе 40секунд:
    вывод консоли тут
    (mongodb-performance-tests)[foo@ip-10-0-0-158 tool]$ python run_test.py --adapter mongodb --name mongodb_3_0_wt
    Running «mongodb_3_0_wt» test
    Prepare database

    Create user documents
    Full time: 97.6963868141
    OK! Users were created!

    Run test with 1 proceses
    Test is finished! Save results

    Full time: 145.417565107

    Run test with 2 proceses
    Test is finished! Save results

    Full time: 72.3193061352

    Run test with 3 proceses
    Test is finished! Save results

    Full time: 56.4604640007

    Run test with 4 proceses
    Test is finished! Save results

    Full time: 43.2622559071

    Run test with 5 proceses
    Test is finished! Save results

    Full time: 38.1150348186



    Run test with 10 proceses
    Test is finished! Save results

    Full time: 40.7822709084

    Run test with 11 proceses
    Test is finished! Save results

    Full time: 39.3015518188

    Run test with 12 proceses
    Test is finished! Save results

    Full time: 37.2085850239

    Run test with 13 proceses
    Test is finished! Save results

    Full time: 42.0286569595

    Run test with 14 proceses
    Test is finished! Save results

    Full time: 40.7457239628

    Run test with 15 proceses
    Test is finished! Save results

    Full time: 45.9798600674



    Run test with 20 proceses
    Test is finished! Save results

    Full time: 44.4311590195

    Run test with 21 proceses
    Test is finished! Save results

    Full time: 46.1173479557



    Run test with 25 proceses
    Test is finished! Save results

    Full time: 43.7823390961



    Run test with 29 proceses
    Test is finished! Save results

    Full time: 42.1524219513

    Run test with 30 proceses
    Test is finished! Save results

    Full time: 43.6515491009

    Finish!


    По поводу обновления большого количества документов — ну вот не факт. Например, если ваша структура данных аля древовидная (каталоги, подкаталоги, подподкаталоги и т.п.), то без массовых обновлений не обойтись
  • Почему не все так просто с MongoDB
    0
    Ненене, всего в реплик сете должно быть четное количество машин (минимум 3). У меня в тесте — как раз 3 машины. То, что третья машина — арбитр или просто ещё один secondary — это уже не принципиально. Если мощностей достаточно и хочется более надежной реплизкации, то делаем его еще одной репликой, если мощностей мало — то только под арбитр. При голосовании их голоса равноценны.
  • Почему не все так просто с MongoDB
    0
    А в какой инфраструктуре смотрели? В Amazon/DigitalPcean/VPS или прям на железках?
    У меня стабильно воспроизводится на Amazon-е для версии MongoDB 2.6.x (3ку не смотрел).
    Кстати, а как проверяли? Просто описанная траббла с подвисанием особенно актуальна для процессов-демонов, которые держат коннект постоянно.

    Но казалось бы и фик с этой проблемой, в конце концов 45сек-1минуту даунтайма может и можно себе позволить в случае аварии, в конце концов сервера тоже не каждый день вылетают. Меня больше смущают эксепшены типа AutoReconnect, дубликаты и неоднозначное поведение python-драйвера
  • Почему не все так просто с MongoDB
    +1
    Да на двух машинах отказоустойчивость тестировать смысла особо нет. Надо как минимум 3 машины для кворума, ну или любое нечетное число больше 3х.
  • Почему не все так просто с MongoDB
    +6
    Ни в коем разе не хотел этой статьёй сказать «как все плохо и близко не подходите».
    Когда на рынке появляется новая технология, которая при этом еще и активно раскручивается, то хочешь-не хочешь по началу люди начинают исполюзовать её везде, где только можно и где нельзя. Смысл этой статьи как раз в том, чтобы поделиться сложностями и своим видением на то, когда эту базу лучше использовать.
  • Прощай, MongoDB, здравствуй, PostgreSQL
    +2
    Это очень-очень частный случай, когда отсутствие схемы действительно выгоднее, но возвращаясь к контексту MongoDB — большинство идеологов монги проповедуют отсутствие схемы несколько в ином ключе — в духе что мол код писать быстрое, не надо проектировать схему — самое то для стартапов. Поставил базу и побежали.
    Собственно в статье основная претензия к монге в плане отсутствия схемы — что приходится логику приложения усложнять. И это действительно так. Без схемы и правда получается быстрее на каких-то ранних этапах развития некоторого абстрактного проекта в вакууме. Но в последствии это преимущество сводится на нет фиксом всяких нетривиальных багов. Да и самый частый кейс — программист уволился/заболел/ушел в астрал, и пади там разбери без схемы, что происходит в базе на 20 млн. документов. Конечно идеологи монги могут сказать — «смотри в код», но тут надо понимать что чтобы понять что происходит в базе нужно смотреть не только текущий код но и все ревизии кода с самого начала, потому что хрен его знает как там база менялась на протяжении жизни проекта.
    Конечно можно использовать всякие mongoid или там mongoengine (в python), но зачем? Если в этом действительно появилась потребность, то лучше чтобы за целостность схемы отвечала БД, а не приложение. Так что на мой взгляд претензии к shemaless, описанные в статье, вполне себе обоснованные.
    Но кейс, описанный вами, оправданный.
  • Анонс MongoDB 3
    +4
    Это все ОК, но почему в тегах присутствует «Amazon Web Services»? :-)
  • PostgreSQL vs MySQL
    +3
    Не совсем согласен с автором по поводу пункта «Документация». Точнее как — быть может документация на сайте MySQL и правда уступает документации PostgreSQL (хотя это весьма спорное утверждение), но вот в принципе в интернетах информационных ресурсов по MySQL в десятки раз больше чем по PostgreSQL. Взять хотя бы stackoverflow — 298,085 тредов против 35,063.

    Ещё не указан один из весомейших на мой взгляд плюсов PostgreSQL — это PL/SQL. В MySQL-е с этим все очень и очень плохо, и сами разработчики не стесняются признаваться в этом. К этому же пункту можно отнести специализированные геоиндексы, JSONB и т.п.

    И отсюда по-моему не совсем правильный вывод в финале статьи. Я бы сказал так — если вы точно, знаете, что собираетесь использовать все эти специализированные фичи (в особенности PL/SQL), то выбор в пользу PostgreSQL — однозначен. В остальных случаях — выбор в пользу того, с какой из БД больше всего знакома команда. И про «серьезные амбиции» и «большой проект» — считаю вообще не аргумент. Опыт таких гигантов как Google, Facebook, VK, twitter, badoo показал, что на MySQL можно более чем успешно разрабатывать вполне себе «большие проекты».

    P.S. К слову, коль в статье была упомянута percona с их собственными тулами, то помимо их решений так же есть весьма неплохие патчи от Google code.google.com/p/google-mysql/.
  • Опрос. Как вы делаете деплой на production сервер(а)?
    0
    RPM собирается по спекам при помощи rpmbuild-а
  • Задай вопрос эксперту и выиграй билет на Highload!
    +5
    Вопрос: как устроена система хранения и анализа логов в Badoo?

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

    У нас на проекте мы используем связку logstash + elasticsearch + kibana. Каждый из API backend-ов пишет логи в формате JSON в rsyslog, который переправляет их на специализированный сервер, где они парсятся logstash-ем и пишутся в индекс поискового движка elasticsearch. Проблемы большого количества логов решаются встроенным механизмом автоматического шардирования индексов. Для каждого запроса на nginx-е генерится некий уникальный идентификатор запроса, который затем проталкивается на API backend (если backend создает какую-то отложенную background задачу — то проталкиваем этот идентификатор в эту задачу), и потом через интерфейс kibana собираем все реакции системы на некий запрос по его идентификатору.
  • Тестовое задание моей мечты
    +2
    В корне не согласен с автором
    Мой будущий коллега потом объяснил, что целью этого тестового задания было определить, как я буду работать в условиях жёсткой нехватки времени.

    B зачем такое надо? Мне просто интересно зачем при поиске кандидатов делать основную ставку на стрессоустойчивость? Если в компании данная ситуация постоянного ASAP-а и дедлайна в порядке нормы, то это ни разу не круто. Очевидно, что в компании явно что-то не в порядке с менеджментом, и такого рода собеседование должно быть первым звоночком соискателю — а стоит ли вообще идти в эту компанию? Не, ну правда, нервы-то дороже. Да и решение, которое человек выдает в условиях неоправданно лимитированного времени, вряд ли будет хоть сколько-нибудь поддерживаемым и расширяемым. Непонятно зачем это надо компании, если она занимается более-менее серьезными проектами, а не клепает сайты-однодневки?

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

    Единственное с чем я могу согласиться с автором — это нафиг не нужные логические задачи аля «канализационные люки», «как сдвинуть гору Фудзи» и пр. По-моему даже Google, который ввел моду на них, уже признал бессмысленность такого подхода.
    В остальном же мне кажется автору не следует путать кислое с пресным — наследование через прототип и замыкания это как бы основы основ. Как же вы код пишете, не зная этих вещей? Взять вот хотя бы замыкания — если вы будете копаться во внутренностях большинства JS-фреймворков, то там сплошь и рядом замыкания. А ведь если вы позиционируете себя как javascript ninja, то заглядывать под капот так или иначе придется.
    И вот как раз-таки не соглашусь, что с ростом числа библиотек все эти знания теряют смысл — зависимость совершенно обратная. Чем больше библиотек, тем лучше человек должен уметь ориентироваться в том, что у них происходит под капотом. Иначе можно всю жизнь быть jQuery-программистом и под любую задачу 2+2 искать плагин.
  • Настройка централизованного логирования с LogAnalyzer и Rsyslog
    0
    Я имел ввиду именно что полнотекстовый поиск. Но это лишь предположение — я не копался во внутренностях, поэтому не могу сказать ничего конкретного. Может быть там делается полнотекстовый поиск, а может быть просто что-то на подобии like %...%. В любом случае если не выносить искомые значения в кастомные предопределенные поля, то «сложный» поиск по телу сообщения при больших объемах логов будет работать медленно — у нас по крайне мере так было
  • Настройка централизованного логирования с LogAnalyzer и Rsyslog
    0
    На самом деле MongoDB в случае LogAnalyzer позиционируется как альтернативное хранилище данных, а не как хранилище, которое даст improvement производительности. То есть по принципу «Вот у нас в проекте одна монга — зачем нам ещё MySQL? Коль уж используем монгу, то давайте и логи туда складировать.»
    Объясняю основную причину, почему нас не устроил ни MySQL, ни MongoDB. Вот у нас есть, скажем, логи от сервера приложений, и разработчики обязуются слать логи в формате JSON, проталкивая при этом параметр user_id в каждом из логов. Благодаря этому мы сможем легко и непринужденно получить информацию об активности пользователя за прошедшее время. А такое зачастую очень даже надо. Например в случае багфикса. Так вот, в принципе в LogAnalyzer можно задавать кастомные поля для выборки логов, но так, как это так реализовано, нам показалось далеко не юзер-френдли. То ли дело в logstash, где данная задача решается на уровне встроенных фильтров. А если искать значение тупо по регулярке по телу message-а, то насколько я понимаю на уровне базы данных делается что-то на подобии Full-Text Search, и база просто настолько долго делает скан, что веб-интерфейс не дождавшись ответа умирает с ошибкой. И тут дело не в MySQL или MongoDB, тут скорее вопрос, идет запрос в индекс или нет.
  • Настройка централизованного логирования с LogAnalyzer и Rsyslog
    0
    Настраивали в основном по официальной документации logstash.net/docs/1.3.3/ и плюс немного по статьям с хабра
  • Настройка централизованного логирования с LogAnalyzer и Rsyslog
    +3
    Какое-то непродолжительное время мы тоже использовали связку rsyslog+mysql+LogAnalyzer и в итоге оказались от неё в пользу rsyslog+logstash+elasticsearch+kibana.
    Причины собственно две:
    1. В LogAnalyzer уууужасный web-интерфейс. Это по-моему что-то даже более доисторическое, чем web 1.0. А ещё очень сильно раздражает popup, который всплывает на каждую строку лога в листинге.
    2. MySQL из коробки банально не справляется при большом количестве логов и хитрой выборке данных. То есть банальный листинг и pagination всех имеющихся логов конечно не тормозит, но вот если надо выбрать например только логи nginx-а и только за определённый период времени, и только те, где встречается определенный user-agent, то тут и начинаются проблемы.

    Связка rsyslog+logstash+elasticsearch+kibana решила эти две проблемы.
    1. Logstash позволяет осуществлять парсинг и нормализацию логов. При помощи фильтров можно выдрать из логов по определенному шаблону конкретные кастомные значения для того, чтобы в дальнейшем добавить их в поисковый индекс.
    2. Kibana няшка demo.kibana.org/, даст 100 очков форы LogAnalyzer-у
    3. Elasticsearch — поисковый сервер на основе Apache Lucene. Масштабируемый из коробки. Одна из частных задач, которую он решает вкупе с logstash — организация хранения логов
  • Опрос. Как вы делаете деплой на production сервер(а)?
    0
    1. Нажимаем на кнопку в Jenkins-е -> Делается git clone репозитория, нагоняется buildout (buildout т.к. проекта на python-е, в случае php для этих целей мы используем phing), билдится rpm-ка проекта и кладется в rpm-репозиторий
    2. Даем команду salt-у (cм. SaltStack), который раскатывает собранную rpm-ку по серверам, вносит на каждом из серверов необходимые изменения в файлы конфигураций, после чего выполняется миграция БД и делается синхронный рестарт веб-серверов
  • В Облака на Zeppelin: опыт создания облачного сервиса Mail.Ru Group
    0
    А если не секрет, сколько человек у вас занимается разработкой этого проекта?
    Самописную базу данных в open source не собираетесь выкладывать? или она узко специализирована?
  • «ZeroMQ».Глава 1: Приступая к работе
    +1
    Спасибо за перевод! Было бы здорово увидеть продолжение
  • Инфраструктура и жизненный цикл разработки веб-проекта
    +2
    Спасибо за интересный пост.
    мы используем virtualenv при разработке и развёртывании системы, поэтому для установки всех библиотек нужно всего лишь запустить команду

    а не смотрели в сторону buildout?

    Про графит — я правильно понимаю, что графит вы используете для реал-тайм статистики? А используется что-то для бизнес-аналитики (для всяких специфических метрик, завязанных на бизнес-логике)? Или такие метрики тоже посылаются в графит?
    И ещё один вопрос про логи. Вы писали что используете Sentry для ошибок. А всякие логи уровня info собираете? И если да, то используете syslog и его вариации или что-то другое?
  • Модульного тестирования недостаточно. Нужна статическая типизация!
    +4
    мне одному кажется, что по 4м случайным проектам нельзя делать такие поспешные выводы? o_O
  • KPHP от ВКонтакте
    +2
    Это ВК и Фейсбуку деваться уже некуда, у них приличная часть всего написана на PHP, но мы то в сами сегодня располагаем более широким инструментарием, чем даже 5 лет назад, верно? Где нужно, применим Node, где оправдано — Erlang или, прости господи, Go, а всякую обвязку — на PHP. И не нужно говорить, что потом это все будет сложно поддерживать, поддерживать конкретную реализацию, заточенную под конкретную задачу куда эффективнее, чем мостырить PHP для всего-всего.

    Я думаю, что при большом желании такие монстры как VK и FB могут себе позволить переписать все на Node / Erlang и т.п. И по времени это займет скорее всего меньше, чем писать свой компилятор для PHP. И кстати у VK по-моему довольно много сервисов работает на Node.js (по крайне мере Node.js они точно используют в качестве прослойки для реализации XMPP). Я думаю, что все они используют PHP более чем эффективно и как раз-таки по месту, где и надо. Другое дело что, как вы правильно заметили, с их масштабами все время приходится придумывать что-то новое и выкручиваться.
    Плюс выбор PHP как языка (а не какого-нить Erlang-а или там чего-нить ещё) обусловлен ещё тем, что ребята просто хорошо умеют его готовить. А зачем использовать что-то новомодное, если ты хорошо справляешься и со старым?
  • Так ли быстр ваш Framework или хватит тестировать производительность Нello World
    +2
    Вообще не понимаю синтетические тесты производительности фреймворков/языков программирования, когда в реальности в 99,9% все тормоза банально упираются банально в базу (и кривые руки которые пишут кривые запросы).
    На самом деле скорость выполнения скриптов вообще 20ое дело. И если она так важна, то следовательно проект высоконагруженный и суперпосещаемый, а следовательно проще добавить дополнительный сервер, и за счет грамотной монетизации (клиентура то есть, иначе откуда взяться нагрузкам), проект быстро отобьет затраченные на сервер деньги.
    На самом деле в случае гонки за скоростью обычно стоит выбирать — либо разрабатываем супергибкий движок, и он будет средним по скорости, либо же забиваем на гибкость, и пишем код так, чтобы все работло супер быстро. Вот кстати пример из реальной жизни — например используем мы супер крутяццкий ORM, извлекаем из БД 500 объектов, и в лучших традициях жанра ORM оборачивает каждый извлеченный элемент в объект. При большом количестве извлеченных объектов (200-300) задержка выполнения скрипта может варьироваться от 50 до 150 ms. И тут уже надо выбирать — либо гибкий ORM, либо выигрываем 50 ms в каких-то кейсах, но забивем на гибкость.