Однако, у этого способа есть недостаток. Форки процессов копируют память создавшего их процесса, и таким образом сервер Unicorn с тремя «работниками» может забирать 1ГБ памяти, едва начав работу. Тоже самое касается библиотек для исполнения фоновых задач, например Resque.
В Ruby 2.0 оптимизировали GC для copy-on-write, так что теперь форки потребляют значительно меньше памяти.
Посмотрел. Я так понял это далеко не полный транслятор. Если тут перечислены все фичи, то в coffescript реализовано почти всё из этого, и ещё намного больше. Вряд ли все фичи ES6 можно эмулировать в ES5.
В смысле зачем? Я имел в виду, что в Vim есть стандартная команда gq, которая переразбивает выделенный текст так, чтобы он вместился в заданное количество символов по ширине.
С 4-мя чуть не так, кворум то есть, но он достижим при том же количестве упавших нод, что и с 3-мя. То есть преимущества нет. Но если одному дать дополнительный голос, то кластер выдержит сбой от 1 до 2-х нод. Кластер не может выдержать сбой серверов в количестве большем или равным половине серверов, так как невозможно изнутри узнать причину сбоя — сеть или питание.
3-х серверный кластер может выдержать сбой одного сервера. Если все три потеряли связь, то ни один работать не будет, так как нужен кворум. А с 4-мя серверами кворума нет, но можно одному из них дать дополнительный голос. Это касается автоматического режима. Но если произошел сбой большей части кластера, то можно еще вручную указать какому-то серверу продолжать работать, это тоже будет безопасно для данных.
Если на разных серверах обновить одну и ту же запись разными значениями, то серверы так просто не синхронизируются. Чтобы такого не было, надо непарное количество серверов, тогда каждый сервер будет знать, находится он в большей части повреждённого кластера или в меньшей. Если в меньшей, то он перестаёт принимать запросы. Другой вариант — база может в любой момент вернуть несколько версий документа, и пусть приложение решает как обьеденить их. Так сделано в Amazon Dynamo и Riak, для MySql, конечно, не подойдёт.
Знание основ теории вычислительных систем позволяет вам брать проблему X, которую вы понятия не имеете как решать, и применять к ней подход: «Я не знаю, как решить X, но я знаю, как решить Y и как привести решение для Y к решению для X. Вот почему теперь я знаю, как решить X».
Наверно индус, который писал этот код, тоже так думал:
Зачем так делать? То что монго поддерживает такие структуры — не означает, что надо везде их применять. Стандартный подход с двумя коллекциями никто не отбирал. В документации всё расписано, когда стоит это применять, а когда нет.
JOIN'ы можно делать на клиенте, GROUP BY — с помощью агрегаций или map/reduce, нормализация — это хорошо пока не начнет тормозить.
Поскольку БД не предоставляет запросов для таких нужд, не сложно оказаться в ситуации, когда вы вынуждены извлечь все данные для их автономной обработки через MapReduce.
Зачем и куда извлекать данные, если map/reduce сам их извлекает?
Если запросы становятся медленными, вы можете просто добавить индексы в тех местах, в которых это необходимо.
До некоторого предела. А потом придется переписывать без всех этих join'ов и транзакций.
obj.f— вызов метода, аobj.method(:f)— объект.echo "ActionController::Base.param_parsers.delete(Mime::XML)" >> RAILS_DIR/config/environment.rbЗачем и куда извлекать данные, если map/reduce сам их извлекает?
До некоторого предела. А потом придется переписывать без всех этих join'ов и транзакций.