Комментарии 13
Я бы хотел знать другое:
1. В Mongo нет нормальных бэкапов, вам предложат либо тормозной mongodump/mongorestore либо делать снапшоты дисков. Уже после этого пункта вам вряд ли захочется работать с mongo.
2. В Mongo очень томозные курсоры. Если вы хотите пробежать по всей коллекции размеров в несколько сот гигабайт, то это будет очень долго. Так что в связке Mongo + Elastic переидексировать ваши гигабайты будет долгой задачей.
3. У Mongo нет нормального бесплатного GUI, самое лучшее — это NoSQLBooster, но он стоит денег.
4. У Mongo много ограничений, на размер документа, на блокировки и т.д. в cosmos лимиты ещё меньше.
5. Mongo очень тяжело администрировать. В отличии от, например, Elasticsearch. Знакомые devops'ы при словах «конфигурировать mongo» как-то быстро сливались.
6. Если вы думаете, что сейчас закините монгу в кубер и будет у вас сверхбыстрое хранилище документов на 10TB, то вы очень ошибаетесь.
7. Mongo и Cosmos — это разные системы. Не стоит разрабатывать под Mongo в надежде, что оно потом легко заведётся на Cosmos.
Обычно путь миграци на mongo проекта выглядит так:
1. Решили перейти с Oracle/MS SQL/MySQL на mongo
2. MVP выглядит отлично всё работает.
3. Залили реальные данные, начали разворачивать кластер и погрустнели.
4. Захотелось построить репорт.
5. Внезапно кто-то из вспомнил про блокировки и ACID. Которые, в Mongo 4, конечно, есть, только вся ваша транзакция должна помещаться в один монго-документ размером в 16MB.
6…
7. Перешли на PostgreSQL.
Моё ИМХО, что позиционирование mongo, как no-sql системы общего назначения крайне неправильно.
Да, когда вы пишете MVP, то всё быстро.
Да, там много фичей, но очень много подводных камней при работе с большими базами.
И надо очень хорошо понимать, что у вас за данные, как проект будет развиваться и сможете ли вы найти достаточно компетентных devops'ов под Mongo.
Иначе берите PostgreSQL и используйте json-поля. Если очень хочется no-sql, то присмотритесь к Elastic (в 2020ом он уже вполне себе no-sql база, а не временный индекс: снапшотить, админить и использовать его удобнее, чем Mongo).
Либо сразу затачивайтесь на конкретное облако: cosmos или aws documentdb. Я не использовал MongoDB Atlas, но говорят, проблемы администрирования он лечит.
1. В Mongo нет нормальных бэкапов, вам предложат либо тормозной mongodump/mongorestore либо делать снапшоты дисков. Уже после этого пункта вам вряд ли захочется работать с mongo.
2. В Mongo очень томозные курсоры. Если вы хотите пробежать по всей коллекции размеров в несколько сот гигабайт, то это будет очень долго. Так что в связке Mongo + Elastic переидексировать ваши гигабайты будет долгой задачей.
3. У Mongo нет нормального бесплатного GUI, самое лучшее — это NoSQLBooster, но он стоит денег.
4. У Mongo много ограничений, на размер документа, на блокировки и т.д. в cosmos лимиты ещё меньше.
5. Mongo очень тяжело администрировать. В отличии от, например, Elasticsearch. Знакомые devops'ы при словах «конфигурировать mongo» как-то быстро сливались.
6. Если вы думаете, что сейчас закините монгу в кубер и будет у вас сверхбыстрое хранилище документов на 10TB, то вы очень ошибаетесь.
7. Mongo и Cosmos — это разные системы. Не стоит разрабатывать под Mongo в надежде, что оно потом легко заведётся на Cosmos.
Обычно путь миграци на mongo проекта выглядит так:
1. Решили перейти с Oracle/MS SQL/MySQL на mongo
2. MVP выглядит отлично всё работает.
3. Залили реальные данные, начали разворачивать кластер и погрустнели.
4. Захотелось построить репорт.
5. Внезапно кто-то из вспомнил про блокировки и ACID. Которые, в Mongo 4, конечно, есть, только вся ваша транзакция должна помещаться в один монго-документ размером в 16MB.
6…
7. Перешли на PostgreSQL.
Моё ИМХО, что позиционирование mongo, как no-sql системы общего назначения крайне неправильно.
Да, когда вы пишете MVP, то всё быстро.
Да, там много фичей, но очень много подводных камней при работе с большими базами.
И надо очень хорошо понимать, что у вас за данные, как проект будет развиваться и сможете ли вы найти достаточно компетентных devops'ов под Mongo.
Иначе берите PostgreSQL и используйте json-поля. Если очень хочется no-sql, то присмотритесь к Elastic (в 2020ом он уже вполне себе no-sql база, а не временный индекс: снапшотить, админить и использовать его удобнее, чем Mongo).
Либо сразу затачивайтесь на конкретное облако: cosmos или aws documentdb. Я не использовал MongoDB Atlas, но говорят, проблемы администрирования он лечит.
5+ лет полета, терабайты данных, монга — всё хорошо. Так что надо понимать, что и как готовить. Эластик не панацея, там другие проблемы, другие данные и другие сценарии использования.
Я в 2012-2013 плотно работал с монгой в качестве быстрого кэша перед MS SQL, на тот момент в среднем раз в неделю один из 12 шардов умирал без явных причин. Т.к. это был кэш, не было проблемы его переинициализировать, но как единственную базу данных я бы монгу не стал использовать.
У вас бывали подобные проблемы? Как решили?
Как вы бэкапили ваши терабайты Mongo-данных?
Например, Elastic легко умеет заливать терабайтные снапшоты в S3 из коробки, причем делает это очень быстро.
Например, Elastic легко умеет заливать терабайтные снапшоты в S3 из коробки, причем делает это очень быстро.
Я несколько лет назад делал тест производительности mongo vs postgres в режиме key<>jsonb value. При тех настройках, которые у меня были postgres был быстрее.
Мне показалась привлекательной возможность шардинга в mongo но знакомые девопсы меня отговорили.
Так что похоже, лучшая no-sql документ ориентированная БД это Postgres
Мне показалась привлекательной возможность шардинга в mongo но знакомые девопсы меня отговорили.
Так что похоже, лучшая no-sql документ ориентированная БД это Postgres
К обучению ваша школа подходит также ответственно, как к переводу статей? То есть тяп-ляп гуглопереводчиком даже без исправления терминологии?
Нужно сузить площадь атаки на MongoDB, а звать к себе на огонёк всем мамкиных хакеров.
Полный доступ к файлам сервера? У него должен быть доступ только к базе данных.
Куда вы слова про аутентификацию дели?
Суть «сначала поставьте пароль, а потом думайте, нужен ли вам модный LDAP» не передана.
Да мы о ней уже второй абзац говорим, вы чего?
А. ещё. можно. после. каждого. слова. точку. ставить. Да, в английском это звучит нормально, но тут у нас русский должен быть.
Это не поиск, а операция соединения ($lookup) в одном из шагов конвейера аггрегации.
Команда астронавтов с Марса у вас возвращается что ли? Команда сообщает об успешной записи.
НовоязЪ вы знаете, молодцы, чО.
Первое здесь — контрольный список, второе — конвейер, третье — журналирование.
Автор предлагает настраивать не порядок сортировки, а правила сортировки (текста/символов).
И тут не культура, а, скорее, диалект.
Монга, я сравню тебя с тобой же и разочаруюсь! Монга тоже СУБД, а с 4-й или даже 3-й версии её можно даже в РСУБД записать.
Не забудьте привязать поверхность атаки к MongoDB
Нужно сузить площадь атаки на MongoDB, а звать к себе на огонёк всем мамкиных хакеров.
с Dedicated User, у которого есть полный доступ к файлам
Run MongoDB with a Dedicated User with full access to the data files
Полный доступ к файлам сервера? У него должен быть доступ только к базе данных.
Установка на сервер через порт по умолчанию может оказаться проблемной
To install it on a server on the default port without authentication is asking for trouble
Куда вы слова про аутентификацию дели?
Воспользуйтесь этой идеей, пока будете думать над причудливой аутентификацией на основе LDAP.
Do that method while you think about your fancy LDAP-based authentication
Суть «сначала поставьте пароль, а потом думайте, нужен ли вам модный LDAP» не передана.
Если говорить о безопасности
While we’re talking about security
Да мы о ней уже второй абзац говорим, вы чего?
MongoDB не использует схему. Но это не значит, что схема не нужна.
А. ещё. можно. после. каждого. слова. точку. ставить. Да, в английском это звучит нормально, но тут у нас русский должен быть.
Поиск без поддержки индексов
Это не поиск, а операция соединения ($lookup) в одном из шагов конвейера аггрегации.
команда возвращается до того, как осуществляется запись.
Команда астронавтов с Марса у вас возвращается что ли? Команда сообщает об успешной записи.
Чек-лист
пайплайн
логирование
НовоязЪ вы знаете, молодцы, чО.
Первое здесь — контрольный список, второе — конвейер, третье — журналирование.
Забыв о порядке сортировки…
Автор предлагает настраивать не порядок сортировки, а правила сортировки (текста/символов).
которые соответствуют языку и культуре пользователей системы
И тут не культура, а, скорее, диалект.
с другим типом баз данных, таким как СУБД
Монга, я сравню тебя с тобой же и разочаруюсь! Монга тоже СУБД, а с 4-й или даже 3-й версии её можно даже в РСУБД записать.
А. ещё. можно. после. каждого. слова. точку. ставить. Да, в английском это звучит нормально, но тут у нас русский должен быть.
Ну вот тут вы уже по мелочам придираетесь, нормально те два предложения читаются, если поставить там простую запятую — предложение потеряет структуру, прямо как то предложение, которое вы прямо сейчас читаете, хотя лично я бы там поставил не запятую, а точку с запятой, но, как я считаю, там можно и просто точку поставить, ведь русский язык этого не запрещает.
НовоязЪ вы знаете, молодцы, чО.
Первое здесь — контрольный список, второе — конвейер, третье — журналирование.
Самое забавное тут, что логирование и журналирование — это совершенно разные термины, и в оригинале было именно journaling.
Шел 2020 год, люди почему-то все еще ждали действительно полезных и интересных статей на хабре от бизнес-аккаунтов
Так интересные и полезные статьи таки бывают, например от Milfgard. Postgres Professional, ТуТу тоже ахинею не пишут, хоть и не для всех тема интересна, у КРОКа вроде что-то хорошее проскакивало, уверен есть много примеров хороших статей от бизнес учёток.
Ну и как бы, если достаточно долго говорить людям, что они делают плохо, то до них дойдёт, что нужно исправляться или закрыться нафиг.
Ну и как бы, если достаточно долго говорить людям, что они делают плохо, то до них дойдёт, что нужно исправляться или закрыться нафиг.
Сталкивался с MondoDB на двух проектах.
На одном MondoDB использовался как хранилище логов — все ок.
На другом MongoDB использовался как основная бд — и с ней было куча мороки. Например, просят доработать сортировку элементов, смотрю — а она в одних местах работает, в других нет. Иду в базу — там параметр, отвечающий за сортировку где-то есть, где-то нет, где-то он int, где-то string. Конечно, можно поправить, и поправил, но, в нормально спроектированной SQL-базе таких ошибок бы даже не появилось.
На одном MondoDB использовался как хранилище логов — все ок.
На другом MongoDB использовался как основная бд — и с ней было куча мороки. Например, просят доработать сортировку элементов, смотрю — а она в одних местах работает, в других нет. Иду в базу — там параметр, отвечающий за сортировку где-то есть, где-то нет, где-то он int, где-то string. Конечно, можно поправить, и поправил, но, в нормально спроектированной SQL-базе таких ошибок бы даже не появилось.
В SQL базах тоже проблем хватает. Вот мы настроили версионирование через миграции, даже вроде внимательно пишем Down миграции и вот налили что-то в прод и поняли, что не то и надо откатить… В 90% случаев такая история заканчивается восстановлением из бекапа и кучей ночной работы :(
В нашем случае даже для журнала изменений объектов перешли с Монги на Постгрес:
Для нас скорость поиска была критична, так что аривидерчилёва Монга.
- Скорость одиночной вставки — равная.
- Скорость пакетной вставки — постгрес с транзакциями существенно быстрее монги, даже если у неё отрубить журналирование. Нам для этой задачи было без разницы.
- Потребление памяти — постгрес 9.6 скромно кушал 15 — 100 метров оперативки, а монга v3.2 жрала 1,5 гига так как всю базу и индексы тащила в оперативку. Серверу наплевать, а вот в компах тогда было по 8 гиг, ситуация «на грани свопа».
- Скорость поиска — тут монга сливалась в унитаз. Без индексов по всем фильтруемым полям искать отказывалась, так как наша пара миллионов записей была > 150 000 (или 127к, точную цифру не вспомню), но даже обвешанная индексами монга сравнима только с постгресом без индексов. В основных сценариях «дай список изменений такого-то объекта» (int) и «дай мне все объекты у которых изменилось это поле» (json ключ -> значение) Постгрес с правильными индексами (jsonb_path_ops) укладывался в 0,05 секунды, монга же думала от 1 до 20 секунд.
- Место на диске — монге нужно было на треть меньше места. Не критичный параметр.
Для нас скорость поиска была критична, так что аривидерчи
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
14 вещей, которые я хотел бы знать перед началом работы с MongoDB