Иногда «табанят» не просто для торможения, а для того чтобы вернуться назад (чтобы выполнить маневр или вернуться к тому, что проскочили). Так что все же корректней «грести в обратную сторону».
монга позиционируется как AP система с eventual consistency
… и, как не трудно догадаться — это типичная маркетинговая чушь :)
По факту MongoDB
1) В каждый момент времени обрабатывает только один запрос (т.е. о параллельности там нет и речи). Как следствие тот же PostgreSQL выигрывает у MongoDB по скорости, если число операций записи высоко по сравнению с числом чтений.
2) По-умолчанию используется поведение, когда клиенту отправляется ответ об успешности операции еще до того, как запрос был хоть в каком-то виде записан на диск (на хоть какой-нибудь из нод).
3) Более того, в конфигурации по-умолчанию клиенту шлется ответ об успешности операции сразу после того, как мастер-нода обработалса запрос. Если получится так, что мастер-нода умерла и так и не вернулась потом обратно — информация о записи будет потеряна безвозвратно, а клиент так и останется уверен, что всё ОК.
Ну и опять же, если начинать крутить настройки Монги, чтобы она стала сопоставима по надежности/доступности с чем-то из обычных реляционных БД, то ВНЕЗАПНО оказывается, что Монга начинает работать во много раз медленнее и эти самые традиционные реляционные БД её обгоняют.
Автор указывает, что у Монги хватает нюансов, о которых обычно на всяких уроках/тренингах/ознакомительной документации обычно не упоминается, но которые делают использование Монги во многих проектах неуместным. И я в этом с автором согласен. В том числе потому, что у самого был проект, где в качестве одной из БД была выбрана MongoDB и впоследствии этот выбор был признан неудачным.
Ну почему же. У Монги целая масса всякой специфики: начиная с глобалных блокировок на запись и заканчивая отсутствием какой-либо компресии хранимых данных и рекомендацией авторов Монги использовать короткие имена полей в объектах (что для меня выглядит глупо и несерьезно).
Т.е. даже если вы были несправедливо обвинены, опровергли все обвинения, доказали свою честность и правоту, то напавший на вас тролль не страдает.
Не совсем верно. Тролль оплачивает своих адвокатов, вы — своих. Поэтому корректней было бы сказать:
Т.е. даже если вы были несправедливо обвинены, опровергли все обвинения, доказали свою честность и правоту, то вы всё равно несете тяжелые финансовые потери из-за расходов на адвокатов.
Про веб-компоненты я читал, представляю как они работают (даже на Хабре уже были стаьи). Но это не отменяет претензии к вам, так как вы подаете заведомо неверную информацию, когда пишете «для подключения нужно лишь добавить в коде» и пишете строчку с единственным «link».
Но ведь не правда же! У вас помимо этого «нужно лишь» будет еще дополнительный код, который подцепит результат импорта в нужное место. И если это делать как в статье выше — никаких дополнительных фич по сравнению с обычным AJAX вы не получите.
Очень многие задачи упираются в IO, а не в CPU. Чаще всего в БД. Для таких задач то, что они реализованы на Python или Ruby, не имеет существенной разницы с точки зрения производительности — от переписывания на Java/C#/C++/asm сильно быстрее не станет. А вот скорость разработки будет различаться в разы.
Бафиксы — это понятно. Но какой такой новый функционал новые версии Windows предоставляют, ради которого стоило бы поменять систему? В Win7 основным улучшением было принципиальное изменение подхода к безопасности системы. Но это, в первую очередь, всего лишь доказывает, что XP была дырявой. Так что же нам в первую очередь обещает Win8? Поддержку планшетов? На десктопах это не нужно. Отсюда и эти метания по поводу убирания/возвращения кнопки пуск и других типовых элементов.
Уточнение: сейчас блокировка не на коллекцию, а на базу. Т.е. пока у вас идет запись в одну коллекцию у вас запись в другую коллекцию в этой же базе — блокирована.
На практике тот же PostgreSQL на многих задачах показывает лучшую производительность, чем монга.
У Винжа в «Глубина в небе» (приквел «Пламени над бездной») была остылка на софт из нашего времени, но, на сколько я помню, там была речь не про Windows, а про что-то из Unix. Кажется там было что-то от сокетов, могу ошибаться. И еще там была самая высокооплачиваемая профессия «программист-археолог» )
Это лишь ваше мнение, что чему-то там далеко до правильного. Я так не считаю.
Описанная схема более-менее хорошо работает, когда все соединения равноценным между собой и, например, пользователь просто качает большие файлы. Но как-только появляется какая-либо ассиметрия, то начинаются проблемы.
Поясню на примерах.
Пусть у нас выстален общий лимит 100k.
Кейс 1:
Пользователь качает два файла, по одному соденинению каждый. Лимит скорости на соединение получается 50k. 50k*2=100k.
Всё ОК.
Кейс 2:
Помимо двух скачивания двух файлов пользователь начинает активно ходить по сайту. Пусть бразуер пользователя использует 6 соединений для параллельного скачивания контента: страницы, JS-скрипты, CSS-файлы, прочее. Реальная скорость по этим соединениям может быть невысокой, но не из-за лимита, а из-за того, что сервер не так быстро отвечает либо браузер делает запросы не один за другим, а с паузами (в частности потому, что должен выполнять JS последовательно). А еще есть keep alive, который соединение держит, но скорость передачи по нему может быть 0. Допустим по этим 6 соединениям реальная средняя скорость — 5k. 2+6=8 соединений всего, 100k/8=12.5k лимит скорости, выставляемый обсуждаемым модулем. 2 соединения качают файлы, так что они будут утилизировать этот лимит полностью, а вот остальные соединения — нет. Итого получаем, что общий реальный лимит на соединения от пользователя получился 2*12.5 + 6*5 = 55k, хотя в конфиге вы выставили лимит 100k.
Вот поэтому есть большие сомнения по поводу «правильности» данного подхода.
Эээ, вы хоть до конца читали-то мой комментарий? )
В любом случае, ограничению скорости по этой формуле очень далеко до «правильного». Скорее всего в nginx ограничения не делали как раз по той причине, что правильно сделать ограничение по сумме не так-то просто (особенно с учетом того, что придется выбирать, какому из соединений пользователя резать скорость в текущий момент).
Правильно ли я понимаю, что если вы выставили суммарный лимит на скорость 100k и, по доброте душевной, разрешили делать до 100 соедиений, то у вас по каждому соединению будет жесткий лимит 1k. Соответственно если пользователь будет использовать всего одно соединение, то он всё равно будет качать на скорости лишь 1к, а не 100к. Или же ls->conn — это _текущее_ количество соединений?
По факту MongoDB
1) В каждый момент времени обрабатывает только один запрос (т.е. о параллельности там нет и речи). Как следствие тот же PostgreSQL выигрывает у MongoDB по скорости, если число операций записи высоко по сравнению с числом чтений.
2) По-умолчанию используется поведение, когда клиенту отправляется ответ об успешности операции еще до того, как запрос был хоть в каком-то виде записан на диск (на хоть какой-нибудь из нод).
3) Более того, в конфигурации по-умолчанию клиенту шлется ответ об успешности операции сразу после того, как мастер-нода обработалса запрос. Если получится так, что мастер-нода умерла и так и не вернулась потом обратно — информация о записи будет потеряна безвозвратно, а клиент так и останется уверен, что всё ОК.
Ну и опять же, если начинать крутить настройки Монги, чтобы она стала сопоставима по надежности/доступности с чем-то из обычных реляционных БД, то ВНЕЗАПНО оказывается, что Монга начинает работать во много раз медленнее и эти самые традиционные реляционные БД её обгоняют.
А заголовок, конечно, слишком желтый.
Но вообще, если не выискивать специально отличия, то разница не видна.
На практике тот же PostgreSQL на многих задачах показывает лучшую производительность, чем монга.
Поясню на примерах.
Пусть у нас выстален общий лимит 100k.
Кейс 1:
Пользователь качает два файла, по одному соденинению каждый. Лимит скорости на соединение получается 50k. 50k*2=100k.
Всё ОК.
Кейс 2:
Помимо двух скачивания двух файлов пользователь начинает активно ходить по сайту. Пусть бразуер пользователя использует 6 соединений для параллельного скачивания контента: страницы, JS-скрипты, CSS-файлы, прочее. Реальная скорость по этим соединениям может быть невысокой, но не из-за лимита, а из-за того, что сервер не так быстро отвечает либо браузер делает запросы не один за другим, а с паузами (в частности потому, что должен выполнять JS последовательно). А еще есть keep alive, который соединение держит, но скорость передачи по нему может быть 0. Допустим по этим 6 соединениям реальная средняя скорость — 5k. 2+6=8 соединений всего, 100k/8=12.5k лимит скорости, выставляемый обсуждаемым модулем. 2 соединения качают файлы, так что они будут утилизировать этот лимит полностью, а вот остальные соединения — нет. Итого получаем, что общий реальный лимит на соединения от пользователя получился 2*12.5 + 6*5 = 55k, хотя в конфиге вы выставили лимит 100k.
Вот поэтому есть большие сомнения по поводу «правильности» данного подхода.
В любом случае, ограничению скорости по этой формуле очень далеко до «правильного». Скорее всего в nginx ограничения не делали как раз по той причине, что правильно сделать ограничение по сумме не так-то просто (особенно с учетом того, что придется выбирать, какому из соединений пользователя резать скорость в текущий момент).