Tactoom.com изнутри — социальная блог-платформа на NodeJS/NoSQL

    Tactoom.com - under the hoodИтак, пришло время раскрыть некоторые карты и рассказать о том, как устроен Tactoom изнутри.

    В этой статье я расскажу о разработке и выведении в production веб-сервиса с использованием:
    NodeJS (fibers), MongoDB, Redis, ElasticSearch, Capistrano, Rackspace.


    Вступление


    Три недели назад мы с Давидом (DMiloshev) запустили инфосоциальную сеть Tactoom.com. О том, что это такое можно почитать здесь.

    На фоне шума, недавно поднятого вокруг NodeJS, вероятно, многим интересно, что же эта технология представляет из себя не на словах, а на деле.

    NodeJS — это вовсе не панацея. Это просто еще одна технология, по сути, ничем не лучше других. Для того чтобы добиться хорошей производительности и масштабируемости, вам придется хорошенько попотеть — так же, как и везде.

    Архитектура приложения


    NodeJS приложение делится на два вида процессов:
    1. Web процесс (http)
    2. Cloud процесс (очереди)

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

    Web процессы обслуживают прямые http запросы пользователей. Каждый процесс может обрабатывать множество запросов одновременно. Учитывая специфику Eventloop, в зависимости от соотношения CPU/IO каждого конкретного запроса, предел параллельной обработки может либо снижаться, либо повышаться для отдельного процесса на момент времени.

    Cloud процессы производят операции, которые не связаны напрямую с пользовательскими запросами. Например: отправка email-ов, денормализация данных, поисковая индексация. Как и Web, один Cloud процесс может обрабатывать множество задач разных типов одновременно.
    Стоит отметить, что здесь очень важна «атомарность» задач/запросов. То есть, нужно следить за тем, чтобы емкая задача/вычисление было разбито на множество более мелких частей, которые затем будут равномерно распределены по остальным процессам. Это повысит скорость выполнения задачи, отказоустойчивость и снизит потребление памяти и коэффициент блокировки каждого процесса и сервера целиком.

    Web → Cloud
    Я стараюсь организовать Web процессы таким образом, чтобы повысить общий коэффициент времени IO против CPU, а значит сфокусировать их на быстрой выдаче http при высокой конкурентности запросов. Это значит, что Web делегирует high-cpu логику в Cloud, ждет ее выполнения, затем получает результат вычислений. Соответственно, в силу асинхронной архитектуры nodejs, во время ожидания Web может выполнять другие запросы.

    Кластеризация
    Архитектура Web и Cloud очень схожа, за исключением того, что вместо http сокета Cloud «слушает» redis очередь.

    Кластеризация node процессов происходит по следующим принципам:
    1. На каждом физическом сервере запущен один процесс-супервизор (node-cluster)
    2. Дочерние процессы супервизора и есть наши Web-ы и Cloud-ы, количество которых всегда равно количеству ядер сервера.
    3. Супервизор контролирует потребление памяти каждым дочерним процессом и, в случае превышения заданной нормы, перезапускает его (предварительно дождавшись завершения текущих запросов этого процесса).

    Tactoom nodejs cluster

    Fibers


    Весь высокоуровневый слой приложения написан с использованием node-sync (fibers), без которого я вообще слабо себе представляю его разработку. Дело в том, что такие сложные вещи, как та же сборка статики, реализовать на «официальной» callback-driven парадигме весьма сложно, если не глупо. Тем, кто еще не видел код того же npm, настоятельно рекомендую на него посмотреть, и попытаться понять, что там происходит, а главное — зачем. А холивары и троллинг, которые разрастаются вокруг асинхронной парадигмы nodejs чуть ли не каждый день, мягко говоря, вызывают у меня недоумение.

    Подробнее о node-sync вы можете узнать в моей статье:
    node-sync — псевдо-синхронное программирование на nodejs с использованием fibers

    Web


    Общая логика Web приложения реализована на фреймворке expressjs в стиле «express». За исключением того, что каждый запрос заворачивается в отдельный Fiber, внутри которого все операции выполняются в синхронном стиле.

    В силу невозможности переопределить некоторые участки функциональности expressjs, в частности роутинга, его пришлось вынести из npm и включить в основной репозиторий проекта. Это же касается и ряда других модулей (особенно тех, которые разработаны LearnBoost), ибо contributing в их проекты дается очень большим трудом и вообще не всегда удается.

    CSS генерируется через stylus. Это действительно очень удобно.
    Шаблонизатор — ejs (как на сервере, так и на клиенте).
    Загрузка файлов — connect-form.

    Web работает очень быстро, поскольку все модули и инициализация загружаются в память процесса при запуске. Я стараюсь держать среднее время отклика Web процесса на любую страницу — до 300ms (исключая загрузку изображений, регистрацию и т.д.). Проводя профайлинг, я с удивлением обнаружил, что 70% этого времени отнимает работа mongoose (mongodb ORM для nodejs) — об этом ниже.

    i18n
    Долго искал подходящее решение для интернационализации в nodejs, и мои поиски сошлись на node-gettext с небольшим допиливанием. Работает как часы, файлы локалей подтягиваются «на лету» серверными nodejs процессами при обновлении.

    Кэш
    Функциональность кэширования со всей своей логикой уместилась в два экрана кода. В качестве cache-backend используется redis.

    Память
    У Web процессов память течет рекой, как позднее оказалось, из-за mongoose. Один процесс (днем, во время средней нагрузки), съедает до 800MB за два часа, после чего перезапускается супервизором.
    Утечки памяти в nodejs искать довольно сложно, если вы знаете интересные способы — дайте мне знать.

    Данные


    Как показала практика, schema-less парадигма mongodb идеально подходит для модели Tactoom. Сама БД ведет себя хорошо (весит 376MB, из них 122MB — индекс), данные выбираются исключительно по индексам, поэтому результат любого запроса — не больше 30ms, даже при высокой нагрузке (большинство запросов вообще <1ms).

    Если интересно, во второй части могу более подробно рассказать о том, как удалось «приручить» mongodb для ряда нетривиальных задач (и как не удалось).

    mongoosejs (mongodb ORM для nodejs)
    О нем хочу отдельно сказать. Выбор списка 20-ти пользователей: запрос и выбор данных в mongo занимает 2ms, передача данных — 10ms, потом mongoose делает что-то еще 200ms (уже молчу про память) и в итоге получаю объекты. Если переписать это на более низкоуровневый node-mongodb-native, то все это займет 30ms.
    Постепенно, мне пришлось переписать практически все на mongodb-native, при этом, повысив быстродействие системы в целом раз в 10.

    Статика


    Вся статика Tactoom хранится на Rackspace Cloud Storage. При этом я использую статический домен cdnX.infosocial.net, где X — 1..n. Этот домен пробрасывает через DNS на внутренний домен контейнера в Cloud Storage, позволяя браузерам грузить статические файлы параллельно. Каждый статический файл хранится в двух копиях (plain и gzip) и имеет уникальное имя, в которое зашита версия. Если версия файла обновится — адрес изменится, и браузеры загрузят новый файл.

    Сборка статики приложения (клиентский js и css, картинки) происходит через самописный механизм, который определяет измененные файлы (через git-log), делает minify, делает gzip копию и загружает их на CDN. Скрипт сборки так же следит за измененными изображениями и обновляет их адреса в соответствующих css файлах.
    Список (mapping) статики адресов всех файлов хранится в Redis. Этот список загружает в память каждый Web процесс при запуске либо при обновлении статических версий.
    По сути, дэплоймент любых изменений статики осуществляется одной командой, которая делает все сама. Причем это не требует никакой перезагрузки, поскольку nodejs приложения подхватывают измененные адреса статических файлов на лету через redis pub/sub.

    Пользовательская статика тоже хранится на Rackspace, но в отличие от статики приложения, не имеет версий, а просто проходит определенную канонизацию, позволяющую по хэшу картинки получить адреса всех ее размеров на CDN.

    Для определений хоста (cdnX), на котором хранится конкретный статический файл, используется consistent hashing.

    Серверная архитектура




    По сути, Tactoom раскидан на 3 гермозоны:
    1. Rackspace — площадка для быстрого масштабирования и хранения статики
    2. Площадка в Европе — здесь наши физические сервера
    3. Секрет (сюда ротэйтятся логи, производятся фоновые вычисления и собирается статистика)

    В мир смотрит только один сервер — nginx, с открытыми портами 80 и 4000. Последний используется для COMET соединений.
    Остальные сервера общаются между собой по прямым ip, закрыты от мира через iptables.

    :80
    nginx проксирует запросы через upstream конфигурацию на Web серверы. На данный момент есть два апстрима: tac_main и tac_media. Каждый из них содержит список Web серверов, на которых работает node-cluster по 3000 порту, у каждого Web сервера есть свой приоритет при распределении запросов.
    tac_main — кластер Web серверов, которые находятся близко к базе данных и отвечают за выдачу большинства веб-страниц для зарегистрированных пользователей Tactoom.
    tac_media — кластер Web серверов, находящихся близко к CDN. Через них происходят все операции по загрузке и ресайзингу изображений.

    Сервера webN и cloudN изображены, чтобы показать, где я добавляю сервера при хабраэффекте и других приятных событиях.
    Новые сервера поднимаются в течение 10 минут — по образу, сохраненному на CDN.

    :4000
    Тут обычный proxy-pass на сервер comet, где работает nodejs COMET приложение Beseda, о которой я расскажу во второй части.

    tac1, tac2, data1
    Это главные сервера Tactoom: XEON X3440 4x2.53 ГГц 16 ГБ 2x1500 ГБ Raid1.
    На каждом работает Mongod процесс, все они объединены в ReplicaSet с автоматическим failover-ом и дистрибьюцией операций чтения на slave-ы.

    На tac1 — главный Web кластер, на tac2 — Cloud кластер. В каждом кластере по 8 nodejs процессов.

    В ближайшее время создам еще один upstream tac_search, на который будут роутиться исключительно поисковые запросы. В нем будет Web-cluster, который поставлю рядом с elasticsearch (про него во второй части) сервером.

    Выводы


    Цитируя лозунг создателей NodeJS:
    «Because nothing blocks, less-than-expert programmers are able to develop fast systems.»
    «Из-за того, что ничего не блокируется, менее-чем-эксперты могут разрабатывать быстрые системы.»

    1. Это обман. Я использую nodejs уже почти 2 года и на собственном опыте знаю, что для того, чтобы на нем разрабатывать «быстрые системы», нужно не меньше опыта (а то и больше), чем на любой другой технологии. В реальности же с callback-driven парадигмой в nodejs и особенностями javascript в целом, скорее легче сделать ошибку (и потом очень долго ее искать), чем выиграть в производительности.
    2. С другой стороны, троллинг господина Ted Dziuba тоже полный бред, ибо пример с «числами фибоначчи» высосан из пальца. Так будет делать только человек, не понимающий, как работает Eventloop и зачем он вообще нужен (что, кстати, доказывает пункт 1).


    После доклада на DevConf этой весной, мне часто задают вопросы о том, стоит ли делать новый проект на NodeJS. Мой ответ всем:
    Если у вас куча времени и вы готовы проинвестировать его в развитие новой, сырой и спорной технологии — валяйте. Но если перед вами сроки/заказчики/инвесторы и у вас нет большого опыта с серверным JS за спиной — не стоит.

    Как показала практика, поднять проект на NodeJS — реально. Это работает. Но это стоило мне очень многого. Чего только стоит node open-source сообщество, о котором я еще постараюсь успеть написать.

    Часть 2


    Вторая часть статьи будет на днях. Вот краткий список того, о чем я в ней напишу:
    1. Поиск (elasticsearch)
    2. Почта (google app engine)
    3. Деплоймент (capistrano, npm)
    4. Очереди (redis, kue)
    5. COMET сервер (beseda)

    Слишком много информации для одной статьи.
    Если в комментариях увижу интересные вопросы, на них отвечу во второй части.

    P.S.


    1. Еды не будет. Любые комментарии, содержащие критику, без ссылки на собственные достижения буду игнорировать
    2. Мы ищем front-end ниндзя, детали здесь
    3. Напомню, что Tactoom — в закрытом beta-тестировании. Регистрация ограничена. Оставляйте email, и вам в скором времени, возможно, придет инвайт.


    UPD 19.10:
    Вторая часть задерживается, ибо много работы.
    Поделиться публикацией

    Комментарии 76

      +17
      Прекрасная и очень вменяемая статья, спасибо большое.

      Внятно, по делу и без приукрас вида «мы тут hello world за 10 минут сделали».

      Комментарий: Sync, безусловно жизненно необходим, хотя и уродлив. Лучше, чем без него, но что поделать. Как он, кстати, будет пробрасывать исключения? Файбер или тред клевы именно тем, что в них внятно пробрасываются исключения.

      Вопрос: можете ли вы отказаться от nginx в этой ситуации? Я бы ради кометов и вебсокетов не особо волнуясь поставил бы веб-сервер на erlang вместо nginx.

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

        +7
        > Комментарий: Sync, безусловно жизненно необходим, хотя и уродлив.
        Нотацию «someObject.someMethod.sync(someObject, arg1, arg2)» необходимо использовать только для вызова сторонних функций, которые не обернуты в ".async()". Свои же функции можно вызывать напрямую: gist.github.com/1159101 (getUserSummary_nodejs_sync.js)

        > Как он, кстати, будет пробрасывать исключения?
        Так же, как и Fiber — нативно.

        > Вопрос: можете ли вы отказаться от nginx в этой ситуации?
        Не могу. На нем много другой логики, которую очень не хочется доверять nodejs.

        > Я бы ради кометов и вебсокетов не особо волнуясь поставил бы веб-сервер на erlang вместо nginx.
        Я вообще скоро комет перепишу на Erlang :)

        > Просто порт 4000 — всё таки штука стремная, отвалится у многих пользователей.
        Пока не сталкивался, вроде у всех работает. А в чем может быть проблема?

        > Насколько можно сервер на ноде втыкать вперед?
        Не стоит. Nginx сейчас — как «guard», в котором я всегда уверен, который никогда не отвалится. Тем более, upstream позволяет в случае таймаута перебросить запрос на другой сервер. Он, как бы, сглаживает нестабильность nodejs.
          +2
          Проблема с 4000 в том, что у админов параноиков все порты закрыты, а 80-й ходит через squid.
          Там даже PUT запрещен.

          Насчёт nginx понял. Выставить erlang на гигабитный интерфейс — не страшно. Дальше, пока не знаю.
            0
            сталкивались. решаеться переводом комета на 443 порт — он обычно даже не проверяеться на траффик и по нему можно плаин-сокетами ходить или вебсокетами
              +2
              Хорошая мысль, надо посмотреть. Хотя, не исключаю больной на голову политики отсекать не SSL трафик по 443
                0
                там фишка в том, что сначала идет стандартный HTTP-заголовок Connection:upgrade и все такое, поэтому даже если есть промежуточные проверки, то они проходятся. А дальше уже соединение открыто и обычно ssl внутри не проверяеться. Будет сложно только с сильно умными, которые проверяют траффик и все пакеты, тогда да — не пройдет. Пока с такими не встречались
              +1
              Точно. Сделаю завтра comet.tactoom.com:80
                +1
                а у вас нет в планах реализации тэгов в двух языках(оригинальном и русском), а так же утверждение единого варианта некоторых тэгов для того чтобы сообщество не разделялось?
          +1
          Спасибо за статью.
          Несколько вопросов:
          Насколько node-cluster надёжен? Как вы его контролируете?
          Пользовались ли чем-то другим кроме него (forever)?
            +1
            > Насколько node-cluster надёжен?
            В плане работы — надежен. Но у него глючный интерфейс cli() start/restart/shutdown. Иногда, при удаленном запуске (через capistrano) не убивает старые процессы, либо вообще ничего не делает. Если зайти на сервер напрямую, то все работает нормально. Все никак не могу с этим разобраться.
            У node-cluster нет нативной демонизации, по сему пришлось писать обертку, которая форкает сама себя с setsid=true.

            При работае со «stand-alone» (для Cloud процессов, которые не слушают http), пришлось допиливать graceful shutdown/restart.

            Еще панисал плагин для node-cluster для слежения за памятью воркеров (если нужно, могу выложить).

            > Пользовались ли чем-то другим кроме него (forever)?
            Да, forever использую для демонизации Beseda (COMET), поскольку у него всего один процесс.
              +2
              не пользуйтесь вы собственной кластеризацией. Запускайте через runit, это надежнее всего остального вместе взятого.
            +3
            Откройте секрет вот такого подхода:

            <div class="json-data" style="display: none" data-data="%JSON_STRING%"></div>
            
              0
              А по вашему мнению тут есть какой-то секрет? :)
                +3
                В смысле почему не так:
                var json_data = {...};
                
                  +2
                  Раньше было так, дайте-ка вспомню, почему…

                  Потому что записи приходят через ajax в виде html, и нужно проассоциировать json данные с каждой конкретной записью. Через атрибут оказалось удобнее.
              +6
              Простите, а какая нагрузка на ваш проект в целом? (сколько примерно пользователей, сколько уников в день)

              Тот же вопрос по-другому: нужна ли вся эта чехарда с масштабированием и т.п., явно нацеленная на огромную аудиторию проекта, непосредственно вам?
                +1
                > Простите, а какая нагрузка на ваш проект в целом? (сколько примерно пользователей, сколько уников в день)
                ~2к хостов в день
                ~300-500 человек онлайн

                > Тот же вопрос по-другому: нужна ли вся эта чехарда с масштабированием и т.п.
                А вы попробуйте без «чехарды» поднять такой проект и держать хотя бы 100 онлайн :)
                  +2
                  2000 хостов в день это мало. Справиться один сервер, по крайней мере для обычного сайта.
                  А как вы считаете количество человек онлайн?

                  Нашёл тут у вас одну неэффективность — на странице tactoom.com/interest/Tactoom-Feedback при наведении на подпись (Tactoom-Feedback, например) делается POST Ajax запрос для каждой ссылки заново.
                    +1
                    А в чем проблема?
                    Стандартные форумы на относительно стандартных виртуальных хостингах такую нагрузку держат легко. nginx, разумеется, поднят.
                      +1
                      Стандартные форумы на стандартных виртуальных хостингах (не впс, а именно хостинг) сто человек онлайн?
                      Ну-ну.
                      Не, если там только текст, если нгинкс поднят с proxy_cache/fastcgi_cache, то еще может быть и поверю, но даже если на сервере просто странички с большим количеством графики и комментариев, не удержит хостинг за ~100 рублей 100 человек онлайн, точно говорю.
                        0
                        Ну один выделенный сервер точно удержит 100 человек онлайн и больше. Что вы там делаете с этими людьми онлайн, что требуется такая развесистая архитектура?
                          0
                          Дык то выделенный сервер, в том-то и дело. Даже слабенький сервер при наличии рук, растущих из правильного места, удержит. И более того, может творить те еще чудеса.
                          А виртуальный хостинг — увы, нет, не удержит.
                            0
                            Так тут-то не виртуальный хостинг, тут дофига серверов, а нагрузки всего ничего.
                              0
                              Я отвечал на коммент, что стандартный форум на стандартном виртуальном хостинге легко удержит нагрузку порядка ~100 человек онлайн.

                              Я не автор и к разработке tactoom никакого отношения не имею.
                              А что в tactoom такого сложного делается, не знаю.
                              Подозреваю, что они постоянно на любое действие пользователя через ajax (а то и через websocket) дергают слой бизнес-логики, а то и базу данных, отсюда и нагрузка такая, более высокая, чем от стандартного plain web 1.0 форума.

                              Только что глянул: да, там от каждого залогиненного пользователя раз в ~10 секунд отходит ajax-запрос — видимо, используется технология long polling для организации чата.
                              Ну и практически нет переходов по страничкам, практически все действия осуществляются через ajax — все взаимодействие с людьми, новые посты и т.п.
                          0
                          И кстати, более интересно сколько запросов выполняется за день
                            +2
                            IP.Board
                            5-6k хостов, 70-75k хитов в сутки
                            в пиках около 300-350 человек онлайн (сейчас прямо 200)

                            nginx на отдачу статики, за ним apache с mod_php5 (практически не тюненый, много лишнего висит)

                            Что мы неправильно делаем? :)

                            Хостинг, правда, за 510 рублей и с несколько задранными параметрами (для новых аккаунтов их урезали). Памяти 500 метров — сейчас упираемся в предел и ищем варианты оптимизации.
                              0
                              Дык у вас vps, судя по тому, что вы запросы на бэкенд через nginx проксируете.
                              Плюс к тому, по стоимости подороже.
                              Поставьте еще php APC + memcached какой-нибудь, удивительный прирост производительности даже без настройки дает.
                          +4
                          Видимо вы фанат nodejs :) 2К хостов в день это как раз на тему преждевременной оптимазации, что говорят зло (многие умные и известные дядьки в их книгах по программированию).

                          Жду инвайтов на сайт, зарегался не дали мне ничо, элита блин с 2К хостами… :)
                            0
                            У нас один серв на достаточно обычном Core2Duo с четырмя Гб ОЗУ и обычных сказёвых дисках выдерживает при еджениксе-«тупом и медленном пыхе» (самописный движок) сносно держит до 700 активных пользователей и роботов (специально отключали кеш и проверяли). Это социальная сеть с общением, блогами, файлохранилищем и магазином.
                            Ваше заявление настораживает. Вы проведите нагрузочное тестирование на всякий случай. Может овчинка выделки не стоит в общем процессе.
                            +4
                            Выглядит так что было интереснее написать сверхэффективный проект на node.js способный невиданно масштабироваться, до того как понять будет ли это востебованно.
                              +2
                              Вы не путайте максимальную нагрузочную ёмкость и скорость генерации страницы.

                              Человек описывал, как он хотел сделать быстро работающий сайт.
                                +2
                                Как я понял ее просто как хотел, а как сделал. И я понял как раз как наоборот, сделано так чтобы можно было легко и масштабировать, когда web/cloud процессы могут работать на любых машинах. Наверника техническая задача решена отлично, хочется пожелаем проекту испытать ту нагрузку, на которую заложена архитектура.
                            +2
                            Инвайт можно получить также от других участников тут
                              +2
                              С @visionmedia в плане пуллов действительно всё очень грустно. С другой стороны они в числе тех, кто добился чего-то на Ноде и может немного позволить расслабится. С удовольствием прочитаю вторую часть :)

                              P.S. А не много ли 300мс в среднем при такой масштабной подготовке?
                                +5
                                > кто добился чего-то на Ноде и может немного позволить расслабится
                                Они гипер-вальяжные.

                                > P.S. А не много ли 300мс в среднем при такой масштабной подготовке?
                                Есть минимум, ниже которого отклик не может быть быстрее физически, как не масштабируй. 300ms — это золотая середина. И это не много.

                                Поиск, например, 10-50ms.
                                  +1
                                  Да, есть такое, потому решил с ними не связываться.

                                  Отлично, я считаю :)
                                +1
                                Вы написали, что использовали redis в качестве очереди. Скажите, рассматривали ли вы другие альтернативы (например, rabbitmq) и почему именно redis.
                                  +4
                                  Я работал с MemcacheQ, Amazon SQS, Active MQ… Все они неплохие. Но зачем добавлять еще одну технологию в стэк, если Redis справляется с этой задачей просто идеально?
                                    +1
                                    то есть вы решили не увеличивать сложность системы, это логично
                                    +2
                                    редис очень-очень быстрый и не только очереди, тогда как все остальное — большое и дает только очереди (при этом с сложным протоколом и большим оверхедом — это я про AMQP)
                                      +2
                                      то, что AMQP — бинарный протокол, еще не значит, что он сложный, да и какой там оверхед?
                                        +3
                                        ну вы посмотрите на спецификацию, даже просто на количество страниц.
                                          +3
                                          смотрел и даже разрабатывал клиент, не так страшен чёрт
                                    +3
                                    Участвовало только 2 человека в разработке? Сколько времени потребовалось на нее?
                                      +4
                                      Нас двое, но Давид — дизайнер, он не программист.
                                      Я сам написал этот проект за 8 месяцев.
                                        +7
                                        В свободное от работы время или основное вренмя уходило на проект?
                                          +1
                                          10-15 часов в сутки
                                      +1
                                      Как бекапы устроены?
                                        +1
                                        Это там, где «секрет»
                                        Mongodb journaling, Mongodelay 4h, redis slave + snapshots.
                                          +2
                                          В смысле задержка репликации 4 часа при slaveOK? Не бывает проблем с тем, что пользователи видят вообще разные данные?
                                            0
                                            Mongodelay это специальная фича, позволяющая принудительно держать slave в 4-х часах.
                                            С него чтение не происходит — это бэкап.
                                              0
                                              Я понял. Мне просто казалось, что нельзя потом запретить чтение с такой реплики. Или как-то решается?
                                                0
                                                По умолчанию с реплики вообще читать нельзя. Только если принудительно указать slaveOk=1.
                                                А Mongodelay вообще просто в списке серверов нет (для клиента).
                                        +3
                                        Почему Rackspace Cloud Storage, а не Amazon S3?
                                          0
                                          Не имею однозначного ответа на этот вопрос. Исторически так сложилось.
                                          Когда-то были на амазоне, потом оказалось, что Rackspace дешевле и саппорт лучше + OpenStack открытая и знакомая платформа. Сейчас CDN как-то странно лагает, может переберемся обратно на Amazon.
                                          +3
                                          Ощущения от прочтения схожи с ощущениями от экскурсии с рассказом о том, как строили пирамиды. Дикое количество кода, огромное количество проблем… И ещё один G+ в результате.
                                          Ну и от описания просто дико, люто, бешено веет ровно тем же самым снобизмом, которым веет от поста и комментариев автора. В принципе, это можно считать комплиментом — настолько, насколько снобизм можно считать стилем.
                                            +1
                                            Хорошо написано, спасибо. Наглядная иллюстрация к принципу о танцоре и тапочках. И проект интересный, жду инвайта.
                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                0
                                                Поддерживаю. Тоже весьма заинтересовало, видимо есть смысл в npm remove mongoose и переписывании части кода :)
                                                  0
                                                  Во второй статье собираюсь об этом написать.
                                                  Ключевой момент — «волшебность» mongoose, а именно его StateMachine.
                                                +1
                                                Напишите во второй части про монго, пожалуйста.
                                                  +1
                                                  А чем профилируете? Вы там писали, что профилировали сборку объектов из базы.
                                                    0
                                                    new Date
                                                    +5
                                                    Собственно, а почему вы выбрали «сырую и спорную технологию» для реализации?
                                                      +1
                                                      Хотелось попробовать «сырую и спорную технологию».
                                                      +2
                                                      Спасибо за статью, с нетерпением буду ждать второй части, очень не хватает таких обзоров реальных рабочих проектов.
                                                      Кстати, сходу вопрос, а вот не пожалели что связались с нодой? Стоило ли потраченное время полученной отдачи?
                                                      Там выше в комментариях говорили что 300-500 онлайн это мало, но я так понимаю все делалось не для 300-500, а с зазором на рост в десятки и сотни раз. Если все правильно понимаю держать это все будет в разы дольше. Кстати не проводили нагрузочное тестирование, каков потолок при нынешних ресурсах и насколько легко все это будет масштабироваться (горизонтально как я понимаю).
                                                      Кстати, а чего связались со статикой на ноде против того же nginx, это хоть как-то оправдано?

                                                      P.S. < 0ms это сколько? o_O
                                                        +3
                                                        [-Inf; 0)
                                                          0
                                                          > Кстати, сходу вопрос, а вот не пожалели что связались с нодой? Стоило ли потраченное время полученной отдачи?
                                                          Не жалею. Но и не скажу, что особо рад.

                                                          > Кстати, а чего связались со статикой на ноде против того же nginx, это хоть как-то оправдано?
                                                          Статику отдает nginx. На node написаны скрипты, которые ее собирают.

                                                          > < 0ms это сколько
                                                          0.9 ms
                                                          0
                                                          Какая версия Mongoose текла и коматозила? В комментах вы упоминали, что все было написано за 8 месяцев. Вторая версия mongoose была выпущена меньше 2х месяцев назад, вроде переделали ее хорошо. Я сам отказался от первой — она не так сильно тормозила, как была сырая. Если у вас не взлетела вторая, значит, не стоит переходить на нее?
                                                            0
                                                            2x.

                                                            > Если у вас не взлетела вторая, значит, не стоит переходить на нее?
                                                            Было бы время, я бы вообще выбросил mongoose из стэка.
                                                            0
                                                            Я сейчас занимаюсь разработкой проекта на ноде + html5. В качестве kvs и связи между серверами разделенной логики redis, в качестве основной БД — mongo и как ORM — mongoose. Было интересно почитать.

                                                            Есть и вопрос. Судя по вашим словам mongoose показал себя не с очень хорошей стороны. А вы не пробовали определить какие именно места являются самыми проблемными? Все же не хотелось бы от него отказываться, но сделать реальные замеры производительности сейчас не является возможным.
                                                              0
                                                              Я тоже особо не сильно мерял, почему именно он тормозит. Интуитивно — это все их StateMachine.
                                                              Созбать объект/провалидировать/сохранить — ок. Но выбрать 100 объектов, каждый из которых содержит вложенные коллекции — лучше делать на mongodb-native.
                                                              +1
                                                              Недавно пробовали MongoDB в свое проекте. Несколько смутило отсутствие транзакций. Расскажите, пожалуйста, о свое опыте обеспечения целостности данных в монго.
                                                                0
                                                                Поклацайте вот этот доклад spf13.com/post/mongodb-e-commerce-and-transactions
                                                                Там все сказано по поводу целостности и атомарных операций в mongo.

                                                                Денормализации много, на каждое денормализованное значение есть функция пересчета/починки.
                                                                0
                                                                все очень интересно
                                                                спасибо
                                                                  0
                                                                  Добрый день. Прошло 3 года с момента написания этой статьи (вроде как самой свежей Вашей статьи). Статья написана очень подробно и интересно. Но всё-таки прошло некоторое время, достаточно большое для современных технологий. Хотелось бы узнать Вашу точку зрения, насколько такая модель оказалась эффективной? Или Вы что-то более интересное нашли? Было рад услышать от Вас комментарии, а также мысли на тему «плюсы, минусы, подводные камни».

                                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                  Самое читаемое