Как стать автором
Обновить
-1
0
HhyperR @HhyperR

Пользователь

Отправить сообщение
/(?<hi>hello)/ =~ 'hello'
Вот с последним абсолютно согласен.
Есть много статистики по поводу снижения преступности при разрешении скрытого ношения короткоствола. Нам это не помогает принять такой закон. С чего вдруг с автопилотами поможет?
У нас на данный момент судебная практика такова, что при любом ДТП с участием пешехода, суд обычно становится на сторону последнего. Допустим автопилот сбивает человека на трассе вне пешеходного перехода — выскочил прямо перед машиной, а сцепления с дорогой не хватило (а таких случаев будет очень много). Вижу три варианта развития событий:
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, получается красивая связка.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность