Евгений Вольф

Он же Вам чёрным по бирюзовому говорит:

the requested PHP extension mongodb is missing from your system

Что в переводе на русский означает "в вашем ПХП не установлено расширение по имени mongodb". Установите его и будет Вам счастье (или новая ошибка :)

Обычно решается как-то так: apt install php7.2-mongodb (для Debian/Ubuntu)

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

Для чего идеальна 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" - активно развивается... Со всеми вытекающими.

Можно ли использовать текстовые предложения как идентификатор в базе?

Удалять запись/строку/документ не по ID, а по значению одного из полей (Вы же это спрашиваете?) - вполне себе можно и иногда даже нужно. Другой вопрос, что ID - это уникальная запись, однозначно идентифицирующая некоторую строку/запись/документ, как в MongoDB, так и в SQL-базах. Иначе говоря, при удалении по ID Вы однозначно удаляете конкретную запись, в случае же удаления по какому-то иному параметру, данный параметр может совпадать с другой записью/документом, и далеко не факт, что Вы удалите то, что хотели.

В Mongo есть длинные _id из случайных символов с автоматической генерацией, но я не хочу их использовать для этих целей

Вы главное саму логику генерации и положения ID не трогайте, она ещё не однократно может пригодится в будущем, а удалять записи/документы, при желании, можете по любому из удобных для Вас полей. Можете например, добавлять к документу собственное поле с именем "id", вписывать туда что Вам угодно/удобно, и идентифицировать и удалять документы по этому полю.

Или все же только по хардкору crontab? =)

Это не хардкор, а одна из практик (один из подходов).

Например если завести дополнительное поле с временем последнего обнуления поля count и при обновлении, изменении документа проверять поле и обнулять его?

Можете завести дополнительное поле с датой, и если счётчик != 0 и дата == сегодня, и время обновления >= "уже пора", сбрасываете счётчик на 0 и увеличиваете дату на 1 день. Но по моему, каждый раз дёргать документ, что бы проверить дату и вообще так извращаться, как-то не серьёзно, особенно если таких проверок в день у вас будет не 10 и не 20... (если мало, то особо не принципиально)

P.S. В MySQL есть планироващик свой, на уровне БД. В Монге я такого не припоминаю...

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

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

Первое что приходит на ум это назначить свой _id рендомом.

Я не великий спец по монге, но по моему, идея довольно хреновая, в общей сложности.

Второе это делать хэш на _id, тогда смысл _id пропадает, а его мне хотелось бы оставить для связей т.к в нем насколько мне понимается шифруется служебная информация, которая нужна при распределении бд (на перспективу).

Я бы всё-таки оставил ID в покое и не пытался бы сделать "из палки пистолет". Добавьте новое поле в качестве URL'а документа и записывайте туда хэшированный ID, не думаю, что увеличение объёма документа на 20-40 байт данных, может привести к тотальному краху системы (это как минимум, было бы странно). Ну или, если очень хочется и... и того и другого, используйте механизм "обратимого шифрования", т.е. хэширование - это по сути своей "односторонее шифрование" (если выражаться по простому), хэш нельзя превратить обратно в данные. Используйте обратимое шифрование, например такое. Идею с обратимым шифрованием можно развить и придумать какие-то дополнительные ключи или соль, если хочется прям "совсем страшно зашифроваться"...

P.S. Библиотека для шифрования в примере, - первая что попалась в поиске. Судя по тегам, Вы используете Node.JS, уверен для нее подобных библиотек и алгоритмов должно быть в избытке.

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

Тут про индексы PostgreSQL, но аналогичным же образом, индексы работают во всех БД, с которыми приходилось работать мне.

После того, как поймете общее назначение индексов, можно будет легко найти интересующую Вас информацию по конкретному типу индексов в конкретной БД.

что происходит, когда мы их объявляем

Происходит чтение коллекции и построения индекса. Обычно, в физическом виде, это файл (или несколько файлов) на жестком диске.

Можно ли объявлять много индексов в коллекции?

Можно, но чем больше индексов - тем больше данные будут занимать на диске.

В идеале, под индекс попадают те данные, с которыми Вы работаете непосредственно, например, "логин" пользователя в таблице/коллекции пользователей, т.к. именно по нему происходит поиск. Все остальные данные, за пределами индекса, например, имя_пользователя, пароль, его телефон и т.д. - просто прилагаются "до кучи", в виде не индексированных данных, т.к. по ним либо не осуществляется поиск, либо, осуществляется довольно редко.

Robomongo?