Кто использует Node.js: Trello (Часть 2)

Original author: Brett Kiefer
  • Translation
Это продолжение перевода «The Trello Tech Stack».

Часть 1
  • CoffeeScript
  • Клиент
    * Backbone.js
    * HTML5 History API
    * Mustache
  • Pushing and Polling
    * Socket.io and WebSockets
    * AJAX запросы

Часть 2
  • Сервер
    * node.js
    * HAProxy
    * Redis
    * MongoDB
  • Итак, нравится ли нам это?


Сервер


Node.js


Серверная часть Trello основана на Node.js. Мы знали, что нам будет необходимо мгновенное распространение обновлений, что означает необходимость держать открытыми много соединений [с сервером], таким образом, управляемый событиями (event-driven) не блокирующий (non-blocking) сервер казался хорошим выбором. Node.js также оказался изумительным инструментом для построения прототипа одностраничного приложения. Прототип сервера Trello был на самом деле простой библиотекой функций, которая обрабатывала массивы моделей, расположенные в памяти одного процесса Node.js, и клиентское приложение просто вызывало эти функции с помощью небольшой обертки WebSocket. Для нас это был наискорейший способ начать попытки использовать Trello и убедиться, что разработка движется в правильную сторону. Мы использовали версию-прототип для управления разработкой Trello и остальных внутренних проектов Fog Creek.

К тому моменту, как закончили прототип, у нас был достаточный опыт с Node.js и нас потрясали его возможности и производительность. Таким образом мы продолжали работать и сделали из нашего Trello-Буратино настоящего мальчика, мы дали ему:
  • настоящую БД и схему (node-mongodb-native и Mongoose)
  • основные веб технологии, такие как маршруты (routes) и куки (cookies) (Express и Connect)
  • много процессов на сервере с отсутствием простоев при рестарте [процессов] (Cluster)
  • межпроцессное взаимодействие (publish/subscribe) и обмен (sharing) структурными данными посредством Redis (node_redis)

Node.js великолепен и становится лучше каждый раз, когда активное сообщество выпускает новые и полезные библиотеки. Громадное количество [и вложенность] колбэков, которое вы вынуждены использовать, по началу кажется проблемой, но через пару недель привыкаешь. Мы используем отличную библиотеку async (а так же краткость кода, которую дает CoffeeScript) для сохранения контроля над нашим кодом. Существуют и другие изящные решения, но нам достаточно использования async, чье поведение мы полностью понимаем.

HAProxy


Мы используем HAProxy для балансировки нагрузки между нашими веб-серверами. Он распределяет TCP-соединения между «каруселью» (round robin) серверов, а все остальное оставляет Node.js. Он держит соединения открытыми достаточно долго для возможности применения WebSockets и возможности повторного использования соединения для AJAX запросов.

Redis


Trello использует Redis для недолго живущих данных, которые используются при обмене между серверными процессами, но не сохраняются на диск. Такие объекты как уровень активности сессии или временный ключ OpenID хранятся в Redis, и приложение построено таким образом, чтобы нормально восстановиться после частичной (или полной) потери этих данных. Мы запускаем [Redis] с заданным ключом 'allkeys-lru' и рабочим пространством (working set) по крайней мере раз в пять большим, чем требуется. Таким образом, Redis автоматически удаляет данные, которые давно не были использованы, и восстанавливает их при необходимости.

Одно из наших наиболее интересных использований Redis — это альтернативное использование коротких запросов при рассылке изменений модели обратно в браузеры. Когда объект изменяется на сервере, мы посылаем JSON сообщение во все соответствующие WebSockets для уведомления клиентов и сохраняем это сообщение в списке фиксированной длины для задействованной модели, отмечая, сколько сообщений было добавлено в этот список за все время. Затем, когда клиент, использующий AJAX запросы [а не WebSocket соединение], пингует сервер на предмет обновлений, с момента его последнего запроса, мы можем получить весь серверный ответ до проверки разрешений а в большинстве случаев проверки одного значения Redis. Redis быстр до безумия настолько, что он может обработать тысячи таких проверок за секунду без существенного проседания [производительности] на одном CPU.

Также, Redis служит нашим publish/subscribe сервером, и мы используем его для распространения сообщений об изменении объекта из серверного процесса, сделавшего начальный запрос, во все остальные серверные процессы. Как только у вас появляется настроенный Redis сервер, вы начинаете использовать его для разного рода вещей.

MongoDB


MongoDB удовлетворяет большинству наших запросов к базе данных. Мы хотели, чтобы [сервер] Trello был очень быстр. Одна из крутейших и наиболее озабоченных производительностью команд, которых мы знаем, является располагающаяся по соседству партнерская компания StackExchange. В один из дней, разговаривая за обедом с их ведущим разработчиком Дэвидом (David), я узнал, что хотя они и используют SQL сервер для хранения данных, в действительности они хранят много данных в де-нормированном виде для улучшения производительности и нормализуют их только при необходимости.

image
Trello сегодня.

В MongoDB мы отказались от использования возможностей реляционных БД (то есть произвольных JOIN) в пользу очень быстрой записи, в большинстве случаев более быстрого чтения, и лучшей поддержки де-нормированных данных — мы можем хранить свойства карточки [элемент Trello] в одном документе в БД и все еще иметь возможность запрашивать (и индексировать) вложенные поля документа. Так как мы быстро выросли, то обладание базой данных с производительностью, способной выдержать изрядное количество нарушений в терминах чтения/записи — было очень хорошей вещью. Также, MongoDB очень просто реплицировать, резервировать и восстанавливать (несмотря на фиаско Foursquare).

Еще одна выгода от использования хранилища несвязных документов — это простое использование разных версий кода Trello с одной и той же базой данных, без плясок с бубном вокруг миграций схем БД. У этого много преимуществ при выпуске новой версии Trello — очень редка (если вообще есть) потребность закрывать доступ к приложению, пока мы обновляем или заполняем БД.

Для разработки это тоже просто супер — когда ты используешь hg bisect (или git bisect) для поиска бага в исходниках и тестовую реляционную БД, то для нее нужны дополнительные действия по откату или возврату БД до тестируемой версии (или создания новой БД с нужными полями). Это может серьезно замедлить работу.

Итак, нравится ли нам это?


Нам нравится наш набор технологий. Как заметил Джоел (Joel), мы истекали кровью на всем протяжении разработки, но я не никогда не видел команды, делающей интересное приложение, без кровопролития, связанного с инструментами и компонентами. И не каждый может сказать, что ему действительно нравится то, с чем они пришли к финишу. Как справедливо для большинства приложений, нет компонентов или деталей реализации, необходимых по своей природе. Однако, мы считаем, что это множество отличных open-source проектов ускорило нашу разработку, дало нам солидную и поддерживаемую кодовую базу, с которой мы интенсивно продвигались вперед и сделали Trello более отзывчивым и красивым приложением. Спасибо всем, кто участвовал в этих проектах, это прекрасное время, чтобы быть программистом.

Звучит привлекательно? Попробуй Trello! Это бесплатно.

Все еще не достаточно разговоров? Вот презентация Trello, которую я делал для недавних обсуждений.
Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 63

    0
    > node.js
    > Redis
    > MongoDB

    три пункта, которые наглядно показывают, что вдохновляться этими ребятами не надо — повторить не удастся. О чем, собственно, они и говорят:

    > мы истекали кровью на всем протяжении разработки
      +1
      А можно поподробнее — что именно плохо? (Пробую писать с использованием node.js)
        0
        А что подробнее?

        — node.js: vm неспособна утилизировать больше одного ядра, их надо запускать несколько штук и кластеризовать, единствьенный способ решать проблемы: «а, убъем и перезапустим, это быстро», большое количество сырых библиотек непонятного качества, асинхронные коллбэки — это хорошо, пока не начинается достаточного размера система, которую надо как-то отлаживать

        — mongodb: настраивать, настраивать, и еще раз настраивать. Про проблемы MongoDB под нагрузкой, про проблемы с репликацией, локами и т.п. в инете не писал только ленивый

        — ну и поверх всего этого езе и redis, который надо примирять со всем вышесуществующим (то есть +еще одна технология, которую надо интегрировать)

        Что имеется в итоге? «мы истекали кровью на всем протяжении разработки» Неудивительно
          0
          А про проблемы с блокировками в MongoDB можно подробнее? Хоть про них не писал только ленивый, гугл мне не смог помочь…
            –1
            До 2.2 в MongoDB был глобальный lock на базу данных (!) при записи
              0
              Сейчас актуальной является 2.2.1 — выходит ваша информация устарела?
                –1
                Когда Trellio только начинал разрабатываться, уже была 2.2.1? То есть они и машину времени изобрели?
                  +1
                  Мне гораздо интереснее что есть сейчас, а не то что было тогда. Сейчас изучаю mongo на досуге, мне пока нравится. :)

                  Вот когда то ваш коммент мог быть актуален, но сейчас как Вы сами написали — поздновато.
                    0
                    > Мне гораздо интереснее что есть сейчас, а не то что было тогда.

                    Да и сейчас с Монго не все в порядке. Сейчас, к сожалению уже не найду :( Но где-то месяц назад была серия статей разных компаний о проблемах с Монго (срочно переходили на что угодно — от редиса до mysql)

                    Быстрый гуглинг находит, например, www.zopyx.de/blog/goodbye-mongodb Там описаны основные проблемы, многие из которых есть до сих пор
                      0
                      Спасибо, почитаю на досуге.
                      0
                      Использую монго как хранилище для горячих данных: около 30Мб, которые очень быстро обновляются. Оно умудряется время от времени создавать серьезную нагрузку на диск и совершенно не ясно как это регулировать.
                      Вот взять Postgres: есть частые обновления/запись — включаем delayed_commit небольшой; нагрузка возросла — увеличиваем задержку; совсем уж не справляется — делаем репликацию и отключаем fsync.
                      много запросов на чтение — загоняем всю базу в shared_buffers.

                      В монго ничего такого нет. Есть mmap файл и хз как с ним обращаться. Разве что в последних версиях прикрутили журналирование. Но и журналирование не синхронное — остается возможность потерять часть данных. Если использовать getLastEror, то производительность станет ничем не лучше того же Postgres и красивых бенчмарков уже не получится.
              +1
              — nide,js великолепная штука

              да, она не может больше одного ядра и нужен кластер. так он ис каропки есть, в чем проблема-то?
              да, много сырых либ странного вида — в чем проблема переписать то, что вас смущает?
              да, асинхронные коллбеки — тот еще ад, но есть масса способов решить вопрос, как async ko, так и message passing-ом, типа обсерверов всяких

              но она очень простая, быстро разворачивается и стабильно живет + под ноду можно писать на CoffeeScript — самом человечном из языков :)
                –1
                > да, она не может больше одного ядра и нужен кластер. так он ис каропки есть, в чем проблема-то?

                В том, что это — костыль. «Масштабируемая мегасуперсистема», которая неспособна использовать более одного ядра? В топку.

                > в чем проблема переписать то, что вас смущает?

                И сколько времени займет переписывание?

                > но есть масса способов решить вопрос, как async ko, так и message passing-ом, типа обсерверов всяких

                Ни один из которых не является стандартным или обкатанным в деле, да еще в комбинации с вышеупомянутой кластеризацией.

                В итоге «мы истекали кровью на всем протяжении разработки»

                > но она очень простая, быстро разворачивается и стабильно живет + под ноду можно писать на CoffeeScript — самом человечном из языков :)

                Аргументы школьников
                  –1
                  > В том, что это — костыль. «Масштабируемая мегасуперсистема», которая неспособна использовать более одного ядра? В топку.

                  У Вас пруф отклеился :) Смысли какая фик разница как она это делает? Кроме ощущения фатального недостатка?

                  > И сколько времени займет переписывание?

                  Ну, вы же не школьник, можете сами прикинуть время разработки :)

                  > Ни один из которых не является стандартным или обкатанным в деле, да еще в комбинации с вышеупомянутой кластеризацией.

                  Эрлангерам расскажите, вот они удивятся :) И еще тем типам, которые книжки пишут. По паттерны программирования и всякое такое. Вы на ноде писали чего-нить? Маны читали?

                  > Аргументы школьников

                  Да я на большее и не претендую, ИМХО лучше писать на приятном языке стройные алгоритмы в понятных программах, чем пехепешить на перле, потому что «риальному спицу сирано на каком языке быдлокодить», а в результате ад и израиль — экспорт переменных, везде глобали, ре-юз кода копипастой и ифы с пролетом на триста-четыреста строк :)
                    +1
                    > Смысли какая фик разница как она это делает?

                    В школу! Учить русский язык!

                    > Кроме ощущения фатального недостатка?

                    Это не ощущение. Это именно фатальный недостаток.

                    > Ну, вы же не школьник, можете сами прикинуть время разработки:

                    Ну так прикидывайте. Если все подряд переписывать, жизни не хватит.

                    > Эрлангерам расскажите, вот они удивятся

                    Я сам эрлангер.Там для этого есть стандартные давно отлаженные приемы. Да-да, те самые паттерны. КОторые в ноде банально отсутсвуют или неприменимы.

                    > а в результате ад и израиль — экспорт переменных, везде глобали, ре-юз кода копипастой и ифы с пролетом на триста-четыреста строк :)

                    Это вы как раз про ноду, судя по всему. Как там разработчики Трелло написали? «мы истекали кровью на всем протяжении разработки».
                      –1
                      > Это не ощущение. Это именно фатальный недостаток.

                      Иииии, «это фатальный недостаток, потому что...»? Что? Общественность в моем лице ждет ломающихся новостей :)

                      > Я сам эрлангер.

                      Мммм… и эрленгер недоволен чистой смертью процесса, потому что жизнь того дешевле медяка? Я-то думал у вас так клуб культа процессовой смерти :)

                      > Там для этого есть стандартные давно отлаженные приемы.

                      ЛОЛ. Все приемы работы с асинхронностью — по сути дела синтаксический сахар над коллбековым адом, если по сути.

                      > Да-да, те самые паттерны. КОторые в ноде банально отсутсвуют или неприменимы.

                      МегаЛОЛ. И какой-же паттерн не может быть применен в ноде?

                      > Это вы как раз про ноду, судя по всему.

                      О, Вам виднее что же я на самом деле имел в виду? :) Нет, в ноде все отлично, а если я говорю «пехепешить на перле», значит так оно и есть.

                        +1
                        > Иииии, «это фатальный недостаток, потому что...»? Что? Общественность в моем лице ждет ломающихся новостей :)

                        Действительно, зачем использовать больше одного ядра, если они есть в системе? Обойдемся одним
                        Действительно, зачем VM возможность оптимизировать исполнение, раскидывая работу по нескольким ядрам
                        Действительно зачем избегать копирования данных при передачи их с одной VM на другую при работе на одной и той же машине?
                        Действительно, зачем избегать cache miss, переключения контекстов исполнения, и прочей мишуры связанной с ограничениями на один процессор и необходимостью запускать несколько VM?

                        Ведь «истинно масштабируемой системе» это все не надо, так ведь?

                        > и эрленгер недоволен чистой смертью процесса, потому что жизнь того дешевле медяка?

                        Школота неспособна понять, что я писал не об этом?

                        > Все приемы работы с асинхронностью — по сути дела синтаксический сахар над коллбековым адом, если по сути.

                        Нет

                        > И какой-же паттерн не может быть применен в ноде?

                        www.erlang.org/doc/design_principles/des_princ.html например
                          0
                          > Действительно, зачем использовать больше одного ядра, если они есть в системе? Обойдемся одним
                          > Действительно, зачем VM возможность оптимизировать исполнение, раскидывая работу по нескольким ядрам

                          Запустите кластер. Я даже и не знаю как вам это еще донести.

                          > Действительно зачем избегать копирования данных при передачи их с одной VM на другую при работе на одной и той же машине?
                          > Действительно, зачем избегать cache miss, переключения контекстов исполнения, и прочей мишуры связанной с ограничениями на один процессор и необходимостью запускать несколько VM?

                          Мы все еще о ноде и JavaScript говорим? Вы не в состоянии сделать первое (во всяком случае разумными методами) и не в состоянии контролировать второе, пусть у VM голова и болит, что и как делать.

                          > Школота неспособна понять, что я писал не об этом?

                          Хм, а о чем?

                          > www.erlang.org/doc/design_principles/des_princ.html например

                          Многатекста про OTP Design Principles. А я спрашивал — какой конкретный паттерн проектирования не может быть реализован в ноде.
                            0
                            > Мы все еще о ноде и JavaScript говорим?

                            Да

                            > Вы не в состоянии сделать первое (во всяком случае разумными методами) и не в состоянии контролировать второе, пусть у VM голова и болит, что и как делать.

                            Вы не способны понять, что VM неспособна сделать все, о чем я говорил

                            > А я спрашивал — какой конкретный паттерн проектирования не может быть реализован в ноде.

                            Школоло. Паттерны программирования не ограничиваются паттернами объектно-ориентированного программирования.

                            В общем, прекращаю этот разговор в одностороннем порядке. Мне не платят за то, чтобы обучать школьников.
                              0
                              > В общем, прекращаю этот разговор в одностороннем порядке. Мне не платят за то, чтобы обучать школьников.

                              Прям пичалька.

                              PS. Надеюсь никогда не придется столкнутся с тем, за что вам платят. Не в обиду :)
                        +1
                        Давайте я вам помогу дочитать, а то вы все время вырываете цитату из контекста — «мы истекали кровью на всем протяжении разработки, но я не никогда не видел команды, делающей интересное приложение, без кровопролития, связанного с инструментами и компонентами».
                        По поводу многопроцессорности, так в JS совсем недавно появилась поддержка потоков (воркеров), и люди начали ее понимать. Почему бы не сделать по такой же схеме многопроцессорное распределение? Да, печалько, что оно не шарит память, но возможности для машстабирования предусматривают не только наращивание процессоров, а и серверов и вы сможете легко и безболезненно перейти к выполнению скриптов на другом сервере (потому что память у вас не шарится и вы общаетесь только сообщениями).
                        А вот что меня действительно пугает, так это популярность forever. Это как бы признание того, что быстроподнятное упавшим не считается.
                          0
                          > а то вы все время вырываете цитату из контекста — «мы истекали кровью на всем протяжении разработки, но я не никогда не видел команды, делающей интересное приложение, без кровопролития, связанного с инструментами и компонентами».

                          Люде не говорят «истекали кровью», а «было сложно», «мы столкнулись с такими-то и такими-то трудностями» и т.п.

                          > в JS совсем недавно появилась поддержка потоков (воркеров), и люди начали ее понимать. Почему бы не сделать по такой же схеме многопроцессорное распределение?

                          Ну попытайтесь его сделать в VM/фреймворке, который не поддерживает многопроцессорность и является однопоточной по определению.

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

                          Тогда нет никакой разницы между node.js и, скажем, php-fpm. Но я понимаю, хайп, да. Не говоря о том, что возможность использовать несколько ядер не отменяет возможности масштабирования на несколько серверов, и наоборот.

                          > Это как бы признание того, что быстроподнятное упавшим не считается.

                          Ситуация с node.js вообще напомниает ранние Rails, в которых тоже все падало, глючило, все было дико сырое, но все делали хорошую мину при плохой игре. И только пару лет спустя DHH, автор Rails, сказал: это было такое говно, что мы его по скрипту прибивали и перезапускали раз в нцать минут. Точно такие же детские проблемы сейчас переживает и node.
                          –1
                          Извините, а Nginx это костыль или нет? он кстати работает так же )
                            +1
                            Выше, в моем комментарии: «Тогда нет никакой разницы между node.js и, скажем, php-fpm. Но я понимаю, хайп, да.»

                            Только nginx + php-fpm (или ruby или питон или...) не притворяются «platform for easily building fast, scalable network applications».

                            Если взять только Nginx, то он явно отличается от node.js хотя бы тем, что умеет работать с несколькими ядрами: nginx.org/en/docs/ngx_core_module.html#worker_cpu_affinity
                              0
                              Нода так же умеет работать — точно теми же механизмами вроде передачи открытого сокета — nodejs.org/api/cluster.html или вас смущает название кластер — ну термин такой.

                              P.S. Признайтесь, что пофигу что там нода — важно, что не ваш любимый ерланг?
                                +1
                                > или вас смущает название кластер — ну термин такой.

                                Он меня не смущает. Он показывает, насколько это костыль. здесь я уже все описал

                                > P.S. Признайтесь, что пофигу что там нода — важно, что не ваш любимый ерланг?

                                Да пофиг, что. Хоть Ява. Но я понимаю, хайп — это дело такое. Заставляет любить даже очевидные недостатки.
                                  –2
                                  Погодите, не понял. Это стандартные механизмы ОС. Или ерланг не использует передачу сокета между процессами?????????????????
                                    0
                                    > Погодите, не понял. Это стандартные механизмы ОС.

                                    Вы вообще поняли, что я написал?

                                    > Или ерланг не использует передачу сокета между процессами?????????????????

                                    Что вы имеет в виду под «передачей сокета между процессами» и зачем это нужно процессам в Эрланге?
                                      –1
                                      А, то есть вы даже не понимаете, как это работает на уровне ОС? ясненько :)
                                        0
                                        Вы читали комментарий по ссылке, что я привел? Видимо, не читали. Понять, что там написано, вы тоже не в состоянии.

                                        Дам только домашнее задание.

                                        Дано: обработка данных.

                                        В случае, если VM одна, и она способна перекидывать задания самостоятельно между CPU, такая VM способна распределить нагрузку между ядрами самостоятельно. При этом той же VM доступна простейшая оптимизация: так как VM одна, то данные туда-сюда копировать не надо, достаточно передавать указатель.

                                        В случае, если VM несколько? А ничего. Любые данные между этими VM будут копироваться при каждой попытке передать данные туда-сюда. Это, безусловно, архитектурно правильное и мегаудобное решение, ага.

                                        Про то, что VM, знающая, что такое multicore, способна грамотно управлять процессами и структурами данных, чтобы минимизировать прочие накладные расходы, я умолчу, для вас это будет высшая математика. Радуйтесь, что вы переизобрели nginx + php-fpm под другим, более хайповым названием.
                                      0
                                      Эрланг не использует передачу сокетов между процессами ОС.
                                      В эрланге для SMP используются потоки а не процессы, так что передавать сокеты (как и любые другие данные) по пайпам нет необходимости.
                        0
                        Вот вам пример задачки, которую я не уверен что можно в NodeJS + cluster решить:

                        Есть сервер с 12 ядрами. На нём запущено 12 копий NodeJS. Они обслуживают, например, 20000 клиентов.
                        Есть сервер с БД.
                        NodeJS нужно иногда к этому серверу обращаться. Чтобы не создавать на каждую сессию новое подключение к БД, нужно поддерживать пул подключений.
                        Как мне сделать общий пул подключений для всех 12-ти воркеров? Или скажете держать отдельный маленький пул для каждого воркера?
                          0
                          Ох, ну как-то типа так ricochen.wordpress.com/2011/11/01/node-js-improve-mysql-query-performance-with-mysql-pool-and-cluster/
                          мопэд не мой, но общая идея думаю должна быть ясна.

                            0
                            В итоге и получается набор костылей, скотча и «мы истекали кровью на всем протяжении разработки».
                              –1
                              твердо решили вибиться в топ серпа по ключевым словам «костыль» и «мы истекали кровью»?
                              фарма? :)
                              0
                              Хм, интересненько.
                              Смущает только плашка "(!!! The project is dead !!)" на гитхабе github.com/Kijewski/node-mysql-pool

                              Идея не совсем ясна — как они между собой общаются? Через EventEmitter?

                              Пока гуглил, наткнулся на вот это: stackoverflow.com/questions/7658333/benchmarking-performance-of-node-js-cluster-with-mysql-pools-lighttpd-php
                                0
                                наверняка есть другие варианты, у меня задачи такой не стояло, так что не в курсе как это на самом деле решается.

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

                                так, оффтопом — мерялись Perl, Twiggy and Redis VS CoffeeScript, Node and Redis — на разных платформах\конфигах результаты немного разные, но нода как минимум НЕ медленнее, а местами на 30% привозит. на примере простого url-shortener
                                так что можно спокойно писать, хуже уже не будет.
                                  0
                                  > на примере простого url-shortener
                                  > так что можно спокойно писать, хуже уже не будет.

                                  # should be
                                  # res.redirect long_url, 301
                                  # but crashes and I dont know why :(

                                  и трижды скопипастеный код в разных файлах.

                                  О да, хуже действительно не будет. Просто некуда.
                            • UFO just landed and posted this here
                                0
                                Ну ок, если вы так считаете, ещё несколько примеров, с которыми я лично имел дело, помимо пула подключений к БД:
                                http клиент с поддержкой keep-alive (должен где-то хранить пул подключенных сокетов);
                                шейпер, ограничивающий максимальную скорость обработки запросов на всю систему (в Mongo/Redis хранить счетчики?)

                                Плюс, когда переписывал эту систему с Python + gevent на Erlang, сумел ПОЛНОСТЬЮ отказаться от MongoDB, заменив её на хранилище в локальной памяти.
                                • UFO just landed and posted this here
                                    0
                                    HTTP клиент с поддержкой keep-alive должен хранить открытые keep-alive сокеты.

                                    Например, нам нужно послать 100 тыс запросов к example.com в 500 потоков. example.com выставляет keep-alive в 2 минуты.
                                    Один поток сделал запрос, получил результат и начал его обрабатывать. Вернул открытый сокет в пул. Пока поток обрабатывает полученные данные, какой-то другой поток может взять уже открытый сокет из пула и сделать запрос через него.
                                    По сути то же, что и пул подключений к бд. Да, можно держать локальные пулы для каждого процесса. Но так накапливается — пул для редиса, пул для монги пул для Postgres, пул keep-alive.
                                    • UFO just landed and posted this here
                                        0
                                        Понимаю, что для БД и HTTP пулы разные. Просто говорю, что на машине с 24 ядрами в Node cluster будет 24 маленьких пула для БД, 24 маленьких пула для HTTP 24 маленьких чего-то ещё для чего то ещё.
                                        Хотя, по хорошему, для оптимальной утилизации ресурсов должен быть один пул для бд на всех, один пул keep-alive на всех (или не одно но, по крайней мере, контролируемое, а не навязываемое количество).
                                        • UFO just landed and posted this here
                                            0
                                            Ну так это и не оптимизация. Просто пишешь наиболее естественным способом, а оно само собой получается оптимизированным. Уж не знаю почему вам это так не нравится, но если можно оптимизировать что-то не прилагая никаких усилий, то почему нет?
                                            Выходит, что если работа с HTTP везде одинаковая, то какая вообще разница на чем писать?
                                            Примеры с пулом коннектов к БД, шейпером и keep-alive кешем привел как самые простые.

                                            Но тот же отказ от Mongo в пользу хранения данных в Erlang процессе в локальной памяти уже дал заметный прирост, т.к. не нужно делать по несколько сотен мелких запросов к БД в секунду.

                                            Очередной пример (не из моего проекта, но похожая задача) — рекурсивный веб-граббер. Скачал страничку — на ней 1500 ссылок. Нужно выяснить какие мы уже посетили, какие нет.
                                            Что лучше — сериализовать и прогнать туда-обратно по TCP к Mongo/redis или проверить в локальной памяти?

                                            Не спорю, что отсутствие в Node Cluster удобной общей памяти не всем мешает. Но если необходимость возникает, начинают лепить заплатки в виде хранения данных во внешних хранилищах и пр.

                                            А представьте, что вы разрабатываете «отчуждаемое решение», вроде Erlyvideo (или Jabber сервера или базы данных какой то) и для того, чтобы оно завелось, требуется поставить монго/редис?

                                            P.S.: что-то я разошелся…
                                            • UFO just landed and posted this here
                                                0
                                                > Но я ж не бегаю по этому поводу срать кирпичами в эрланговский блог, как товарисч из первого поста.

                                                Товарищ из первого поста внятно и аргументировал свою позицию, в отличие от школоты на ноде, у которой единственные «аргументы»:
                                                — зато удобно писать
                                                — кофескрипт — это удобно
                                                и не забыть
                                                — зато удобно писать

                                                Остальное тут: habrahabr.ru/post/160447/#comment_5505921
                        • UFO just landed and posted this here
                            0
                            Было бы от чего быть батхерту. Батхерт на протяжении всего этого топика (и любого другого про ноду) у нодежсников. Еще бы его у них не было. Им впарили аналог nginx+php-fpm, а они рады. Вот и приходится делать невероятные усилия, чтобы не обращать на этот факт внимания. От этого и попоболь.
                            • UFO just landed and posted this here
                                0
                                > Прибегать фанатично покакать про эрланг в каждый нодовский пост

                                Про Erlang я речь даже не заводил. Но ваш текст показателен по силе батхерта у нодежсников.

                                > рассказывать про высосанные из пальца проблемы

                                Высосаные из пальца? Ну-ну.
                        0
                        Непонятно, как они обходили временные паузы Redis при сбросе данных на диск.

                        Или это уже не проблема?
                          +1
                          Если я ничего не перепутал, то Redis у них не сбрасывал данные на диск…

                          Trello использует Redis для недолго живущих данных, которые используются при обмене между серверными процессами, но не сохраняются на диск
                          +2
                          Почему-то большенство, кто пишет или начинает писать на nodeJs, используют MongoDB. Нет, я ничего не имею против, но пока не понимаю, почему так мало решений в связке nodejs + mysql.
                          Создаётся впечатление, что существует какое-то табу: если php, то только mysql, если nodejs, то nosql.
                          В силу специфики проектов, в которых учавствую, использую именно mysql и не вижу никаких проблем в принципе.
                          node-mysql — это кто не знает вдруг.
                            +1
                            Тоже заметил

                            Node → MongoDB
                            PHP → MySQL
                            ruby | python → PostgreSQL
                            Java → Oracle
                            .NET → MSSQL
                            Erlang → Mnesia Riak

                            Причем первые 2 крайне ярко выраженные.
                            Может кто-то продолжить список?
                              0
                              У PHP так повелось со знаменитой связки LAMP (Linux Apache MySql PHP). Не в обиду будет сказано, но на Ruby и Python процент школьников заметно меньше, люди более серьезнее что ли подходят к разработке продуктов. Не хочу развивать тут холивар, но мне непонятен выбор MySql в качестве СУБД для проектов, учитывая что хранимые процедуры в ней появились вроде как только с 5 версии. На мой взгляд в PostgreSQL есть все что нужно для работы на проектах любого уровня.
                                0
                                > но мне непонятен выбор MySql в качестве СУБД для проектов

                                вдоль и поперек изученный движок с шаговой доступностью до администраторов любого уровня?
                                  0
                                  Тоже не хочу развивать дискуссию по поводу баз данных. Просто любопытно ваше мнение. Вчера в одном из камментов на хабре кто-то высказался, что хранимые процедуры в бд создают vendor-lock и повышают стоимость и сложность переезда на другие бд.
                                  +1
                                  У нас был тяжёлый путь от Java + MySQL и Java + Oracle к менее традиционным Java + Postgresql и Java + DB2/zOS. MySQL неплохая СУБД для маленьких и лёгких проектов, но при росте базы выше 20 ГБайт в нём открывается портал в ад. Проблема усиливалась тем, что на момент начала проекта InnoDB существовал только в зародыше и масса production environment была запущена и крутилась на MyISAM.
                                  0
                                  потому что mongo работает с json вероятно?
                                  0
                                  когда ты используешь hg bisect
                                  Разработчики Trello использую Mercurial?

                                Only users with full accounts can post comments. Log in, please.