Everything_is_not_so_bad

Я расскажу Вам про личный опыт, без претензий на истину в последней инстанции...

Для чего идеальна MongoDb? Примеры приложений, где монга будет лучше mysql?

Для человека который привык работать с реляционными БД, смириться с логикой и вообще с подобными БД - довольно сложно. Для тех, кто работает с реляционными БД профессионально - сделать это ещё сложнее...

Если сравнивать с реляционными БД и с оглядкой на конкретно MySQL - монга идеально вписывается там, где структура данных заранее неизвестна. Тут я хотел привести пример, но не смог придумать ни одного дельного примера, после того как начал плотно работать с PostgreSQL... Давайте попробую из практики. Мы один раз применяли монгу в проекте где есть десятки и сотни тысяч товарных позиций и у каждой из них свой уникальный набор различных свойств. На основе уже имеющихся свойств, "соседних" товаров, контентщику предлагался наиболее вероятный набор параметров, которые нужно заполнить, но в любой момент он мог удалить или добавить любое поле и/или множество значений одного из них, например, "Цвет: черный, серый, фиолетовый". Всё это дело попадало под разные динамические фильтры и далее по цепочке... В то время, насколько я помню ещё не было поддержки JSONB-формата у PostgreSQL, по этому мы остановились на MongoDB. Ну и конечно же, желание "воткнуть ультра новую и модную БД в проект" сыграло свою роль...

Что в монге определённо не нравится (и это не моя "идея", об этом пишут даже в учебниках под монге) - это тотальная денормализация данных. Которая в некоторых случаях может сыграть злую шутку. Например, все комментарии "поста" обычно хранятся прямо в самой сущности поста. Это очень удобно и довольно быстро работает, но... иногда это приводит к полному коллапсу. Особенно, когда у Вас перекрестная ссылочность.

Безусловно, не редко можно встретить проекты в которых даже в реляционных БД не прописаны, например, внешние ключи и контроля целостности данных как такового нет, но обычно это происходит по следующим причинам:
1. Очень низкая квалификация администратора БД проекта
2. В попытке выжать из базы больше производительности, не найдя других методов оптимизации
3. Данных настолько много, что БД/ключи - начинают "сыпаться", не редко это связано с п.1

Так же, последние тесты показывают, что PostgreSQL почти не уступает MongoDB даже в её родной среде (на уровне данных в формате JSON). А в некоторых аспектах даже превосходит её... Подробности Вы можете увидеть на некоторых конференциях по Postgres (да, на конференциях по MongoDB, Вы вряд ли увидите, как кто-то будет рассказывать, что [их любимая] монга "хуже" некоторых других движков...). Кстати, поддержку формата JSON стандартизировали (наконец-то) на уровне SQL-стандарта (если я не ошибаюсь) и в самом ближайшем будущем, думаю стоит ожидать полноценную поддержку оного в SQL-базах, в т.ч. поддержку в бинарном виде с возможностью индексации данных (кстати, некоторые SQL-базы уже такое умеют).

Моё понимание, ответа на вопрос, "когда действительно стоит использовать MogoDB?" звучит примерно так: Исключительно в тех случаях, когда Вы понимаете, что она станет действительно хорошим решением для поставленной задачи и сейчас и в будущем. В моей практике, таких проектов можно было бы насчитать ничтожно мало, а точнее около нуля, особенно с учётом развития некоторых современных SQL-БД и вообще направления "JSON в SQL" в целом. Но, безусловно такие проекты могут быть и есть (в данном случае, не у меня). Но, тут стоит обратить внимание на крайне важный факт - когда всплывает такой проект, что бы адекватно оценить наиболее оптимальную БД под него - нужно знать как минимум пару-тройку SQL-БД, со всеми их особенностями, достоинствами и недостатками... причем не просто "знать", а хорошо знать, "изнутри". А так же знать все характерные черты монги, а так же её особенности, достоинства и т.д. То есть, если Вы задаётесь вопросом, "а хорошо ли впишется монга в проект N?" и не можете найти на него однозначного ответа, вероятнее всего, что в долгосрочной перспективе, в "проект N" она впишется плохо.

P.S. В заключение, хочу ещё раз напомнить, что "JSON в SQL" - активно развивается... Со всеми вытекающими.

Прежде чем удалять /data/2017, мне нужно точно убедиться, что данные берутся именно из /mnt/2017.

1. Отключите в конфиге nginx использование /data/2017 и станет сразу все понятно, откуда будут браться ваши данные.
2. Не удаляйте /data/2017, а просто переименуйте например в /data/2017.old, поживите так N дней, проверьте что все работает корректно.
3. Анализируйте access.log на предмет 404 для файлов которые лежали в /data/2017, а сейчас уже берутся из /mnt/2017
4. Только убедившись, что все хорошо, удаляйте /data/2017

Потому, что "высоко-/низко-уровневый" это просто условная и достаточно относительная классификация языков по одному конкретному качеству - по уровню абстракции, предоставляемой языком его пользователю. А когда всплывает слово "абстракция", обязательно нужно задуматься над тем, что от чего абстрагируется. В данном случае речь идет об абстрагировании конструкций языка от среды выполнения программы, написаной на этом языке. Например, во всех этих ЯВУ есть такие абстракци, как именованная переменная, тип данных, конструкции управления потоком выполнения или вызов функций системы/стандартных библиотек и т.д. Мы просто пишем int а = 3; или while(flag == true)..., а обо всем остальном заботится язык. Для сравнения, в ассемблере (низкий уровень) нам приходится иметь дело с конкретными регистрами, битами, адресами и jump-ами, и никакой среды, которая пришла бы нам на помощь, там тоже нет. В этом смысле уровень абстракции того же С намного выше.

Классификация эта (как и любая другая) - условная, т.к. если по этому признаку сравнить, например, те же Яву или Шарп с теми же C++ или Паскаль, то можно бы было сказать, что уровень абстракции первых "несколько выше" - между программой на первых языках и "средой" есть еще промежуточный уровень (байткод/IL), а программы на вторых компилируются прямо в инструкции конкретного процессора. Только смысла в таком утверждении уже не так много, и для указания на эти качества языков проще и полезнее классифицировать их как "компилируемые в инструкции виртуальной машины" и "компилируемые в инстрикции процессора".

И, наконец, сортировка массива - это уже совсем из другой оперы. К языку тут (если вообще!) относится только абстракция "массив". В большинстве языков есть такое понятие, как стандартная библиотека (JDK, stl, те же модули в пыхе и т.д.). Функции вроде сортировки массива, предоставляются не языком, а именно этой библиотекой (как правило, написанной на этом же языке и/или на более низкоуровневых). А, собственно, языком называется очень-очень маленький набор универсальных семантически однозначных конструкций, типа операторов сравнения, циклов или вызовов функций. Фактически, любой современный язык можно "выучить" за день... остаток жизни уйдет на то, чтоб научиться правильно пользоваться им и его библиотеками для написания нужных программ ))

SELECT 
     SUM(CASE WHEN `last_sign_in_at` <= DATE_SUB(NOW(), INTERVAL 3 DAY) THEN 1 ELSE 0 END) AS '> 3 days',
     SUM(CASE WHEN `last_sign_in_at` <= DATE_SUB(NOW(), INTERVAL 90 MINUTE) AND `last_sign_in_at` >= DATE_SUB(NOW(), INTERVAL 3 DAY) THEN 1 ELSE 0 END) AS '> 90 min',
     SUM(CASE WHEN `last_sign_in_at` <= DATE_SUB(NOW(), INTERVAL 30 MINUTE) AND `last_sign_in_at` >= DATE_SUB(NOW(), INTERVAL 90 MINUTE) THEN 1 ELSE 0 END) AS '> 30 min'
FROM `table`

Какая бы не была организация, не верю что ВСЕМ компам нужно связываться со ВСЕМИ компами.
Ставите адекватные маршрутизаторы, разбиваете сеть на VLAN-ы, лечите их отдельно.

Старые ОС можно запускать в виртуалках, с отключенной сетью. А на самом железе - нормальная, современная ОС.
Во многих случаях комп с диагностическим оборудованием может быть совсем отключен от сети.

Архив без сжатия.

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

Блин ответ нашел в одном из похожих вопросов:
копируешь ~/.ssh/id_rsa.pub у себя на локалке и отдаешь его в ~/.ssh/authorized_key о уже на своем vps

Докер - виртуализация приложения. Приведу пример.

Вы разрабатываете некое веб-приложение на java, и вам его нужно тестировать под java7, java8 и под tomcat 7, tomcat 8.

Вы можете купить 4 компьютера, поставить на них 4 варианта, протестировать. Затем все поставить заново для следующего теста. Неудобно, долго, дорого.

На помощь приходит виртуальная машина - вы можете купить 1 компьютер, на нем завести 4 виртуалки, каждую из них настроить, сохранить образы. После тестирования просто восстанавливаете исходное состояние из образов.
Гораздо дешевле, чем раньше. Но каждая виртуальная машина требует процессоры, память, кучу места на диске под операционку. А ведь отличается по сути всего 2 компонента.

На помощь приходит докер. Один комп, одна операционная система. 4 докер контейнера с нужной версией java и томкат. После тестирования контейнер можно удалить и развернуть заранее подготовленный.
Дешевле и быстрее, чем все вышеперечисленное. Потому что операционка одна, нет лишних расходов на CPU и память. Ужиматься дальше практически некуда.

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

Виртуализация приложений через докер позволяет избежать dll-hell, изоляция дисковой системы и окружения.

P.S. Пример очень простой и надуманный, так как конкретно java и tomcat можно и без докера просто запустить несколько разных версий на разных портах, но суть вы должны уловить. Докер - виртуализация на уровне файловой системы, самая дешевая виртуализация.

Странный вопрос. Ответы:
1) ASP.NET Core
2) Любой
3) Любой из мейнстримных

Я использую для локальной разработки docker. Это значительно удобнее, чем держать полноценное окружение из зоопарка разных версий php и прочих штук.
Если сайт старый, под какие-нибудь древние версии apache, php и mysql. Не проблема, - смотрю на hub, если нет, то собираю свой.
При этом спокойно можно переключить на другой проект, более современный. Например с nginx, php7 и postgresql. Предварительно выключив предыдущий контейнер.

Далее в перспективе можно спокойно кинуть контейнер на сервер и за пару минут развернуть сервис.

В общем настоятельно рекомендую попробовать docker при локальной разработке.