чятаны, а никто с неведомой ёбанной хуйнёй после апдейта до 3.4.6 не встречался?

надо у @dd_bb спросить :))

чятаны, а никто с неведомой ёбанной хуйнёй после апдейта до 3.4.6 не встречался?

на 3.4.5 падает, а что у 3.4.6 там?

UNCAUGHT EXCEPTION: STACK LEVEL TOO DEEP

на 3.4.5 падает, а что у 3.4.6 там?

а что на 3.4.5?

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

а что на 3.4.5?

оО, ты не в курсе?

ноуп

https://jira.mongodb.org/browse/SERVER-29850

а, ну тут всё понятно

это ёбанная ведомая хуйня!

а у тебя какой лог?

в моём случае кластер просто встаёт раком

опа-опа, мы как раз на 3.4.6 хотим, расскажи по подробнее =)

если бы я знал что ещё рассказывать ваще

а симптомы?

если смотреть в монгу, внутри всё красиво

кроме того факта что в какой-то момент монгосы начинают закрывать соединения с нодами

жестко

там была засада с энтропией, но её починили, энтропии достаточно

собственна энтропия вылезла как симптом

напиши чем в итоге закончится

даунгрейдом ;)

у нас в бою 3.4.6 прикатили не так давно вроде пока полет нормальный

1 мастер и 2 ридонли-реплики

У меня есть подозрение что это бага в монгосе

так что наверное вопрос в первую очередь к операторам sharded clusters

А напомните, плиз - если в репликасете две монги + 1 арбитр, то увод в оффлайн арбитра и Secondary так же поломает и primary, да? оно будет в непонятном состоянии. правильно же помню?

канешна

в смысле поломает?

оставшийся одинокий primary перейдет в нерабочее состояние же

без кворума записи не будет

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

да, знач все правильно помню благодарю.

чтение будет

поэтому арбитр рекомендкют ставить в третьем датацентре или вообще во внешнем интернете

оставшийся одинокий primary перейдет в нерабочее состояние же

он перейдёт в состояние SECONDARY

У меня есть подозрение что это бага в монгосе

похоже так. после отката mongos до 3.4.3 (не спрашивайте даже) отлегло

поже там напортачили с пулом

ребят, а стоит ли использовать MongoDB в качестве хранилища для чат истории? т.е. каждое сообщение как документ?

не наткнусь ли я на подводные камни?

если сообщения маленькие — наткнёшься

если их будет очень (10^9+) много

если не очень маленькие, то не наткнёшься.

а может и наткнёшьяс!

вот я об этом тоже задумался... по сути структура сообщение приблизительно такая: { id datetime to from message }

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

медиа-элементы кодируются в качестве ссылок в message

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

удалять, обрабатывать, искать (по времени)

дефайн «обрабатывать» и «искать»

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

телеграм тоже простенький. там десять полей

дефайн «обрабатывать» и «искать»

change message + find between datetime A and B

или всё-же лучше хранить такую структуру в SQL?

в системе используются как MariaDB так и MongoDB и вопрос в чём лучше реализовать данный, простенький чат 1. удаление по id 2. обработка текста по id 3. поиск по времени (между A и B)

да без разницы совершенно

в монге можно чят считай одиним документом сделать

похоже так. после отката mongos до 3.4.3 (не спрашивайте даже) отлегло

так версии 3.4.4-3.4.6 с проблемой?

я просто предполагаю что Mongo с этим лучше справится в плане производительности, не хочется SQL этим напрягать

я просто предполагаю что Mongo с этим лучше справится в плане производительности, не хочется SQL этим напрягать

у rocketchat mongodb, они не парились что не справится, работает шустро

так версии 3.4.4-3.4.6 с проблемой?

3.4.6 вероятно с проблемой. про 3.4.4 и 3.4.5 ничего сказать не могу, пушо апдейт был с 3.4.3 -> 3.4.6 и откат соотвественно 3.4.6 ->3.4.3

у rocketchat mongodb, они не парились что не справится, работает шустро

а вот дискорд монгу не ослили

3.4.6 вероятно с проблемой. про 3.4.4 и 3.4.5 ничего сказать не могу, пушо апдейт был с 3.4.3 -> 3.4.6 и откат соотвественно 3.4.6 ->3.4.3

ага, понятно.

в монге можно чят считай одиним документом сделать

да но... зачем... если например более 1000 сообщений в нём а нужно лишь от последние 20...

да но... зачем... если например более 1000 сообщений в нём а нужно лишь от последние 20...

разбей на документы по 20 сообщений

а вот дискорд монгу не ослили

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

разбей на документы по 20 сообщений

звучит как костыль

звучит как костыль

тогда монга не для тебя

т.е. монга не справится с множеством маленьких документов?

большим имеется ввиду множеством

я не знаю что такое «справится»

т.е. монга не справится с множеством маленьких документов?

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

хмммм

в прошлой жизни мы, гхм «глубоко рефакторили» фронтенд для аналитки метрик из скад, монга была 0.9 кажется. мы там такого адища натворили, но ничо. там щас 3.0 со snappy пишет и преагрегирует 20k документов в секунду. и индексы в два раза больше данных %)

ничо, живёт

"MongoDB is designed to find indexed entries very quickly. MongoDB is very good at finding a few needles in a large haystack. MongoDB is not very good at finding most of the needles in the haystack." https://stackoverflow.com/questions/3038703/mongodb-schema-design-many-small-documents-or-fewer-large-documents

ох

asked Jun 14 '10 at 15:56

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

не читай гугл по монге, там одна вода и старье

2010 ?

"MongoDB is designed to find indexed entries very quickly. MongoDB is very good at finding a few needles in a large haystack. MongoDB is not very good at finding most of the needles in the haystack." https://stackoverflow.com/questions/3038703/mongodb-schema-design-many-small-documents-or-fewer-large-documents

"<PUT ANY DB NAME HERE> is designed to find indexed entries very quickly. <PUT ANY DB NAME HERE> is very good at finding a few needles in a large haystack. <PUT ANY DB NAME HERE> is not very good at finding most of the needles in the haystack."

соглашусь

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

спасибо

с одной строны хранить чаты как отдельные дискуссии в документах... 4мб это очень грубо говоря ~2048 сообщений если каждое по 2к

не айс, это почти бомба... бомбанёт если беседа затянется))

не надо хранить 4мб

надо хранить так, как ты будешь читать документы

если у тебя 90% трафика открытие чята, в котором показываются последние 20 документов, то зачем дублировать from/to 20 раз, если можно не дублировать

индексы по from/to будут в 20 раз меньше

поиск будет в 20 раз быстрее

а что кстати насчёт embedded documents?

а что с ними?