HhyperR HhyperR

В версии 1.9 избавились (но GIL остался).

Однако, у этого способа есть недостаток. Форки процессов копируют память создавшего их процесса, и таким образом сервер Unicorn с тремя «работниками» может забирать 1ГБ памяти, едва начав работу. Тоже самое касается библиотек для исполнения фоновых задач, например Resque.

В Ruby 2.0 оптимизировали GC для copy-on-write, так что теперь форки потребляют значительно меньше памяти.

В Ruby методы являются объектами. Просто obj.f — вызов метода, а obj.method(:f) — объект.

А напишите неизбыточный эквивалент объявления по условию:

if prompt() == 'square'
  f = (x) -> x * x
else
  f = (x) -> x * x * x

Посмотрел. Я так понял это далеко не полный транслятор. Если тут перечислены все фичи, то в coffescript реализовано почти всё из этого, и ещё намного больше. Вряд ли все фичи ES6 можно эмулировать в ES5.

Где есть транслятор ES6?

CoffeeScript очень хорошо сочетается с ExtJS, помогает бороться с большой вложенностью декларативного кода.

В смысле зачем? Я имел в виду, что в Vim есть стандартная команда gq, которая переразбивает выделенный текст так, чтобы он вместился в заданное количество символов по ширине.

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

Очередной пример превосходства Vim над другими жалкими редакторами. ;)

С 4-мя чуть не так, кворум то есть, но он достижим при том же количестве упавших нод, что и с 3-мя. То есть преимущества нет. Но если одному дать дополнительный голос, то кластер выдержит сбой от 1 до 2-х нод. Кластер не может выдержать сбой серверов в количестве большем или равным половине серверов, так как невозможно изнутри узнать причину сбоя — сеть или питание.

3-х серверный кластер может выдержать сбой одного сервера. Если все три потеряли связь, то ни один работать не будет, так как нужен кворум. А с 4-мя серверами кворума нет, но можно одному из них дать дополнительный голос. Это касается автоматического режима. Но если произошел сбой большей части кластера, то можно еще вручную указать какому-то серверу продолжать работать, это тоже будет безопасно для данных.

Если на разных серверах обновить одну и ту же запись разными значениями, то серверы так просто не синхронизируются. Чтобы такого не было, надо непарное количество серверов, тогда каждый сервер будет знать, находится он в большей части повреждённого кластера или в меньшей. Если в меньшей, то он перестаёт принимать запросы. Другой вариант — база может в любой момент вернуть несколько версий документа, и пусть приложение решает как обьеденить их. Так сделано в Amazon Dynamo и Riak, для MySql, конечно, не подойдёт.

Разве что у вас нет ни одного апдейта. Данная архитектура не может быть полностью отказоустойчивой.

Что будет при разделении сети? То есть серверы друг друга не видят, но некоторым клиентам удаётся соединиться, причем к обоим серверам.

Знание основ теории вычислительных систем позволяет вам брать проблему X, которую вы понятия не имеете как решать, и применять к ней подход: «Я не знаю, как решить X, но я знаю, как решить Y и как привести решение для Y к решению для X. Вот почему теперь я знаю, как решить X».

Наверно индус, который писал этот код, тоже так думал:

uint i;
...
if (i.ToString().Length == 1)
{
  ...
}

При чем тут руби?

Зачем так делать? То что монго поддерживает такие структуры — не означает, что надо везде их применять. Стандартный подход с двумя коллекциями никто не отбирал. В документации всё расписано, когда стоит это применять, а когда нет.

JOIN'ы можно делать на клиенте, GROUP BY — с помощью агрегаций или map/reduce, нормализация — это хорошо пока не начнет тормозить.

Поскольку БД не предоставляет запросов для таких нужд, не сложно оказаться в ситуации, когда вы вынуждены извлечь все данные для их автономной обработки через MapReduce.

Зачем и куда извлекать данные, если map/reduce сам их извлекает?

Если запросы становятся медленными, вы можете просто добавить индексы в тех местах, в которых это необходимо.

До некоторого предела. А потом придется переписывать без всех этих join'ов и транзакций.

Странно, дизайнерша на картинке с усами и хотдогом.

Вот с последним абсолютно согласен.

Есть много статистики по поводу снижения преступности при разрешении скрытого ношения короткоствола. Нам это не помогает принять такой закон. С чего вдруг с автопилотами поможет?

У нас на данный момент судебная практика такова, что при любом ДТП с участием пешехода, суд обычно становится на сторону последнего. Допустим автопилот сбивает человека на трассе вне пешеходного перехода — выскочил прямо перед машиной, а сцепления с дорогой не хватило (а таких случаев будет очень много). Вижу три варианта развития событий:
1. Приговор выносят водителю. Сесть невиновному обидно, а не держав даже руль — вдвойне.
2. Виновным признают производителя. Кто захочет вообще продавать такую технику при таких раскладах?
3. Самый фантастический. Кто-то придет и исправит нам наши суды.
В итоге даже когда на западе это как-то решат, нас это вряд ли коснётся.

Сверху уже давали ссылку на описание two phase commit, заметьте — она находиться в официальной документации. Почему-то часто забывают, что MongoDB заточена под распределенность. А знаете как реализованы распределенные транзакции в, например, Oracle? Правильно — всё тот же two phase commit.
По поводу Durability — настоящая надежность обеспечивается только репликацией. Можно даже без журналирования. Односерверная конфигурация не переживет физического уничтожения сервера в любой базе данных.

Выходит консистентность сохраняется, но теряется availability. Ну правильно, это прямое следствие CAP-теоремы — если добавить распределенность, надо убрать или availability или consistency.

А консистентность и изоляция сохраняется? Если да, то наверняка это очень медленно, если нет — тоже самое можно сделать в NoSQL вручную.

Мощный сервер стоит гораздо дороже чем кластер из слабых, еще надо умножить на количество реплик. При этом если база всё таки достигнет потолка — будет очень неприятно. И зачем нужен этот риск?
Для заведомо простых приложений есть еще Redis. Супер быстрый и прикольный — сделан для программистов, работа с данными происходит похоже на работу с памятью, привычные структуры данных и т.д.

В реляционных базах тоже нельзя джойнить между шардами.

Под надежностью обычно понимают другое. А вообще, то что всё должен делать прикладной программист — это правда. Более того NoSQL базы намного более понятны и приятны в работе для программистов. Следовательно DBA теряют востребованность и им это не нравится. :)

db.system.js.save( { _id: «foo», value: function( x, y ){ return x + y; } } );

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

а что делать — если индексов куча и все не вмещаются???

Ну конечно sharding. Это же основная идея почти всех NoSQL хранилищ — легкое горизонтальное масштабирования. У монго оно еще и автоматическое.

как на счет БД в 60 Гб?

Например, тут размер базы 10TB.

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

Дело в том, что можно регулировать durability очень гибко в широких пределах и для каждого запроса. Так чтобы одновременно и быстро и надежно физически не может быть.

Монго всегда будет занимать всю свободную память, потому что это просто файловый кэш ОС. Главное чтобы индексы вмещались в память.

По поводу бекапов, мне кажется, что вы используете mongodump/mongorestore. Они подходят для работы с отдельными коллекциями, и, например, индексы не сохраняют. Восстановление из правильного бекапа — это просто копирование директории data. Бекап должен выглядеть так: заходим на вторичную реплику, переводим процесс в режим только для чтения, копируем файлы данных, снимаем блокировку. Тут главное чтобы не кончился oplog. Если делать снапшот файловой системы, то разблокировать можно сразу же.

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

user1.balance+=amount user2.balance-=amount user1.save user2.save

Тут как раз описан этот пример.

32-битная версия имеет много ограничений, легче вообще её не рассматривать.

В то же время, журнал невозможно настроить на полностью синхронную запись (по умолчанию — интервал 100мс). Конечно, в большинстве случаев это приемлемо, но уже компромисс.

Всё наоборот. Для каждого запроса можно синхронизировать журнал на диск, базу данных на диск, минимальное количество реплик, минимально количество датацентров и т.д. Никаких компромиссов.

> Хорошо известными вам декларативными ЯП являются правила описания страницы HTML и CSS.
Всё ясно.

Хм… «Новое исследование [...] доказывает, что умные люди сильнее подвержены подобным ошибкам.»

Ну и бред. На javascript написали виртуальную машину, на которой запустили бинарник.

Особенно если использовать вместе с HAML и CoffeeScript, получается красивая связка.