Но

Это не значит что она для всего подходит

Очевидно же

Не зная требований проекта глупо убеждать юзать монгу

т.е. твой кейс это терабайтная база к-я работает как часы??

ну, пиздец, достижение

Ясно понятно, тролль

похлопаем

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

все остальное у нее плохо. в продакшене рекомендуют минимум 2 инстанса, на реально больших базах невозможно управлятся с ней без привлечения платного консалтинга от mongo

ты идиот

1) экстремалы могут гонять монгу в solo

попробуйте опровергнуть это приведя какой-от кейс и докажите что нет решения лучше

все просто

2) что значит «реально больших базах невозможно управлятся с ней без привлечения платного консалтинга от mongo»?

но это долго и муторно

но это долго и муторно

что долго и муторно?

разбор кейсов

попробуйте опровергнуть это приведя какой-от кейс и докажите что нет решения лучше

поднять за 15 минут шард из 10 сегментов

c HA, и зонированием

тут спросили, я ответил.

ты не ответил

тебя где-то укуксили на жопу, а ты тут свои комплексы разливаешь

хотя скорее всего никто тебя за жопу не кусал, ты просто не осилил даже курсы

>поднять за 15 минут шард из 10 сегментов да просто заусти 15 инстансов elastic serach или там crate.io

ом

@lig11 дайте мне пожалуйста штуку, которой можно резать неверных

«15 инстансов elastic serach» против монги

окей

Я проста начал изучать mongo ))) изза этого хотел понять. Спасибо.

монга — докуметохранилище, простое в обслуживании, с очень лёгким и мощным маштабированием, с простым языком запросов, множественными различными индексами

подходит, сюрприз, для хранения документов!

при проектировании монги нельзя думать реляционными категориями

монга позволяет очень долго вообще не думать об оптимизации, что скорее плохо, чем хорошо

но с другой стороны, можно заниматься бизнесом, а не кручением ручек, а потом уже нанять людей которые тебе накрутят

в монге нет транзакций (можно наколхозить похожий механизм)

Шард монги на 30 инстансов, 6 лярдов документов. Работает ок

А компрессия помоему все таки должна сокращать время фетча данных мне кажется разжиматься будет быстрее чем чсиквенс рид с хдд

Хотя хер знает

@dd_bb м ?

да, с диска читать меньше

есть правда подъёбка

в кеше WT данные не сжатые

а вот в дисковом кеше уже сжатые

Да

по этому кеш на 90% памяти глупо

Оно потом по сети тоже несжатое гонится

Если только нем ссл с включенным gzip

Сеть быстрее диска обычнр

Который выключен а большинстве дистрибутивов

Оно потом по сети тоже несжатое гонится

в сеть ты уже гонишь найденные документы, их априори меньше чем на диске

Тоже верно

В сети в обоих вариантах обем данных не меняется

Вот, кстати, не особо полезная фича при активной записи. Оплог засирается очень быстро. Если по этому полю не надо фильтровать, то лучше писать уже сжатые данные

ложь

оплог — коллекция

так что она сжимается так-же как и все остальные

ну,ок. если я должен буду хранить 5 лярдов документов, то я поставлю crate.io и буду точно также хранить json+буду иметь sql движок поверх этого+ еще всякие хипстерские примочки типа kibana

так что она сжимается так-же как и все остальные

Да, только его размер устанавливается в несжатом виде

Да, только его размер устанавливается в несжатом виде

и?

чего я не буду иметь, так это сжатия

и?

Если писать большие блобы, он очень быстро может превратиться в тыкву (его будет хватать на минуты)

Или ещё лучше - апдейтить

5% диска на минуты оплога?

вот люди, выпослушали мои аргументы и аргументы yopp. судите уже сами ;0))

5% диска на минуты оплога?

Вполне, я сразу уперся в это при первом деплое

gridfs?

Даже по глупости увеличил его до 60гиг

gridfs?

Нет, обычная коллекция

Терминальные логи на единицы мб. Очень хорошо жмутся х100+

а, логохранилище, окей, да

понимаю твою боль!

но ваще тогда лушче брать жирные cpu и включать не snappy а zlib

писец. пошел флейм. пойду дописывать очередную хуету на монге. всем пока ;))

но ваще тогда лушче брать жирные cpu и включать не snappy а zlib

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

Зато сразу решилась проблема с размером оплога

При всех своих особенностях, монга довольно предсказуемая в своем поведении, при сравнении с тем насколько много тебе нужно знать о ее кишках. Что не скажешь про тот же пг

Зато сразу решилась проблема с размером оплога

можешь им в жиру засабмитить ишшуй на тему размера оплога

точнее размера capped коллекций

я думаю что они могут вркутить опцию, которая будет смотреть не на size а на storageSize для выселения

попробуйте прочитать что я писал выше. мне нечего добавить

У Erlang слишком мала ниша. Как и у mongo. Библиотек мало, постоянно приходится изобретать велосипеды. И , соответственно, язык почти не развивается. Конторы начавшие писать на эрланге мечтают соскочить, так как программистов найти очень тяжело. Это все общеизвестно, же. Если ты жавер, то вариантов работы навалом. а вот если ты эрлангист...

но с другой стороны, можно заниматься бизнесом, а не кручением ручек, а потом уже нанять людей которые тебе накрутят

+