Уже на этапе анализа пробелмы: у вас изначально просто нет никаких паттернов, не с чем сравнивать. Более того, две аппаратно идентичные нейронные сети обученные на одном и том же наборе данных, дающие примероно одинаковые результаты, но с разным начальным остоянием (которое обычно инициализируется через RNG), будут иметь совершенно разное распределение ролей нейронов и разные веса связей.
Что касается процедуры отключения: тут очень большая вероятность, что вам придется отключать всю сеть, так как очень часто каждый кусок логики не собран в какой-то локальной подсети, а более-менее «размазан» по всей сети.
Кстати, тоже интересный момент. Вот вы говорите «ИИ без жестких ограничений его логики на аппаратном уровне». А как вы себе представляете ограничение логики ИИ на аппаратном уровне? Будете в нейронах определенные входы спиливать? )
Я это к тому, что по крайней мере сейчас работа нейронной сети — это в определенном смысле черный ящик и у нас нет механизма воздействовать на сеть на уровне абстрактных понятий.
Навскидку там 90% — это проблемы с «экспортом технологий шифрования»: по стути необходимо для каждой отдельной страны индивидуально разбирать, какие вообще алгоритмы/размеры ключей туда можно «ввозить» без дополнительной регистрации/сертификации и т.п. Что для Андроида, как глобального продукта, не очень подходит.
можно настроить дефолтное поведение, а вообще это гибкость, например для логов и комментариев это не обязательно.
Отвечу цитатой своего комментария выше:
Ну и опять же, если начинать крутить настройки Монги, чтобы она стала сопоставима по надежности/доступности с чем-то из обычных реляционных БД, то ВНЕЗАПНО оказывается, что Монга начинает работать во много раз медленнее и эти самые традиционные реляционные БД её обгоняют.
Иногда «табанят» не просто для торможения, а для того чтобы вернуться назад (чтобы выполнить маневр или вернуться к тому, что проскочили). Так что все же корректней «грести в обратную сторону».
монга позиционируется как AP система с eventual consistency
… и, как не трудно догадаться — это типичная маркетинговая чушь :)
По факту MongoDB
1) В каждый момент времени обрабатывает только один запрос (т.е. о параллельности там нет и речи). Как следствие тот же PostgreSQL выигрывает у MongoDB по скорости, если число операций записи высоко по сравнению с числом чтений.
2) По-умолчанию используется поведение, когда клиенту отправляется ответ об успешности операции еще до того, как запрос был хоть в каком-то виде записан на диск (на хоть какой-нибудь из нод).
3) Более того, в конфигурации по-умолчанию клиенту шлется ответ об успешности операции сразу после того, как мастер-нода обработалса запрос. Если получится так, что мастер-нода умерла и так и не вернулась потом обратно — информация о записи будет потеряна безвозвратно, а клиент так и останется уверен, что всё ОК.
Ну и опять же, если начинать крутить настройки Монги, чтобы она стала сопоставима по надежности/доступности с чем-то из обычных реляционных БД, то ВНЕЗАПНО оказывается, что Монга начинает работать во много раз медленнее и эти самые традиционные реляционные БД её обгоняют.
Автор указывает, что у Монги хватает нюансов, о которых обычно на всяких уроках/тренингах/ознакомительной документации обычно не упоминается, но которые делают использование Монги во многих проектах неуместным. И я в этом с автором согласен. В том числе потому, что у самого был проект, где в качестве одной из БД была выбрана MongoDB и впоследствии этот выбор был признан неудачным.
Ну почему же. У Монги целая масса всякой специфики: начиная с глобалных блокировок на запись и заканчивая отсутствием какой-либо компресии хранимых данных и рекомендацией авторов Монги использовать короткие имена полей в объектах (что для меня выглядит глупо и несерьезно).
Т.е. даже если вы были несправедливо обвинены, опровергли все обвинения, доказали свою честность и правоту, то напавший на вас тролль не страдает.
Не совсем верно. Тролль оплачивает своих адвокатов, вы — своих. Поэтому корректней было бы сказать:
Т.е. даже если вы были несправедливо обвинены, опровергли все обвинения, доказали свою честность и правоту, то вы всё равно несете тяжелые финансовые потери из-за расходов на адвокатов.
Про веб-компоненты я читал, представляю как они работают (даже на Хабре уже были стаьи). Но это не отменяет претензии к вам, так как вы подаете заведомо неверную информацию, когда пишете «для подключения нужно лишь добавить в коде» и пишете строчку с единственным «link».
Но ведь не правда же! У вас помимо этого «нужно лишь» будет еще дополнительный код, который подцепит результат импорта в нужное место. И если это делать как в статье выше — никаких дополнительных фич по сравнению с обычным AJAX вы не получите.
Очень многие задачи упираются в IO, а не в CPU. Чаще всего в БД. Для таких задач то, что они реализованы на Python или Ruby, не имеет существенной разницы с точки зрения производительности — от переписывания на Java/C#/C++/asm сильно быстрее не станет. А вот скорость разработки будет различаться в разы.
Что касается процедуры отключения: тут очень большая вероятность, что вам придется отключать всю сеть, так как очень часто каждый кусок логики не собран в какой-то локальной подсети, а более-менее «размазан» по всей сети.
Я это к тому, что по крайней мере сейчас работа нейронной сети — это в определенном смысле черный ящик и у нас нет механизма воздействовать на сеть на уровне абстрактных понятий.
ifиswitch— это сравнения.По факту MongoDB
1) В каждый момент времени обрабатывает только один запрос (т.е. о параллельности там нет и речи). Как следствие тот же PostgreSQL выигрывает у MongoDB по скорости, если число операций записи высоко по сравнению с числом чтений.
2) По-умолчанию используется поведение, когда клиенту отправляется ответ об успешности операции еще до того, как запрос был хоть в каком-то виде записан на диск (на хоть какой-нибудь из нод).
3) Более того, в конфигурации по-умолчанию клиенту шлется ответ об успешности операции сразу после того, как мастер-нода обработалса запрос. Если получится так, что мастер-нода умерла и так и не вернулась потом обратно — информация о записи будет потеряна безвозвратно, а клиент так и останется уверен, что всё ОК.
Ну и опять же, если начинать крутить настройки Монги, чтобы она стала сопоставима по надежности/доступности с чем-то из обычных реляционных БД, то ВНЕЗАПНО оказывается, что Монга начинает работать во много раз медленнее и эти самые традиционные реляционные БД её обгоняют.
А заголовок, конечно, слишком желтый.
Но вообще, если не выискивать специально отличия, то разница не видна.