« Rev
@mongodb_ru   116
Fwd »


Max
да, знач все правильно помню благодарю.
Sergey
чтение будет
Sergey
поэтому арбитр рекомендкют ставить в третьем датацентре или вообще во внешнем интернете
yopp
У меня есть подозрение что это бага в монгосе
похоже так. после отката mongos до 3.4.3 (не спрашивайте даже) отлегло
yopp
поже там напортачили с пулом
Roman
ребят, а стоит ли использовать MongoDB в качестве хранилища для чат истории? т.е. каждое сообщение как документ?
Roman
не наткнусь ли я на подводные камни?
yopp
если сообщения маленькие — наткнёшься
yopp
если их будет очень (10^9+) много
yopp
если не очень маленькие, то не наткнёшься.
yopp
а может и наткнёшьяс!
Roman
вот я об этом тоже задумался... по сути структура сообщение приблизительно такая: { id datetime to from message }
yopp
исходить надо не из структуры, а из того как ты будешь сообщения потом использовать
Roman
медиа-элементы кодируются в качестве ссылок в message
yopp
дефайн «обрабатывать» и «искать»
Roman
там чат довольно простенький, не телеграм пишу))
yopp
телеграм тоже простенький. там десять полей
Roman
дефайн «обрабатывать» и «искать»
change message + find between datetime A and B
Roman
или всё-же лучше хранить такую структуру в SQL?
Roman
в системе используются как MariaDB так и MongoDB и вопрос в чём лучше реализовать данный, простенький чат 1. удаление по id 2. обработка текста по id 3. поиск по времени (между A и B)
yopp
да без разницы совершенно
yopp
в монге можно чят считай одиним документом сделать
Roman
я просто предполагаю что Mongo с этим лучше справится в плане производительности, не хочется SQL этим напрягать
yopp
так версии 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
Roman
в монге можно чят считай одиним документом сделать
да но... зачем... если например более 1000 сообщений в нём а нужно лишь от последние 20...
tenni
а вот дискорд монгу не ослили
дискорд вообще очень своеобразная штука, реверсил как-то не понравилась в плане масштабируемости круто придумали
yopp
звучит как костыль
тогда монга не для тебя
Roman
т.е. монга не справится с множеством маленьких документов?
Roman
большим имеется ввиду множеством
yopp
я не знаю что такое «справится»
tenni
т.е. монга не справится с множеством маленьких документов?
если ты готов шардить через proxysql, а это занятие не самое занятное - вперед, монга в этом плане круче
Roman
хмммм
yopp
в прошлой жизни мы, гхм «глубоко рефакторили» фронтенд для аналитки метрик из скад, монга была 0.9 кажется. мы там такого адища натворили, но ничо. там щас 3.0 со snappy пишет и преагрегирует 20k документов в секунду. и индексы в два раза больше данных %)
yopp
ничо, живёт
Roman
"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
yopp
ох
tenni
asked Jun 14 '10 at 15:56
yopp
ни одна субд не справляется хорошо с маленькими записями
tenni
не читай гугл по монге, там одна вода и старье
Roman
2010 😃
yopp
"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."
Roman
соглашусь
yopp
если это не бесплатная книга, то пожалуйста, кидайтесь пиратчиной в личке
yopp
спасибо
Roman
с одной строны хранить чаты как отдельные дискуссии в документах... 4мб это очень грубо говоря ~2048 сообщений если каждое по 2к
Roman
не айс, это почти бомба... бомбанёт если беседа затянется))
yopp
не надо хранить 4мб
yopp
надо хранить так, как ты будешь читать документы
yopp
если у тебя 90% трафика открытие чята, в котором показываются последние 20 документов, то зачем дублировать from/to 20 раз, если можно не дублировать
yopp
индексы по from/to будут в 20 раз меньше
yopp
поиск будет в 20 раз быстрее
Roman
а что кстати насчёт embedded documents?
yopp
а что с ними?
Roman
если один документ хранит другой то это технически один entity или 2?
Roman
ибо я знаю что документ макс. 4мб весит
yopp
ты где-то не в том месте информацию берёшь
yopp
монга это фронтенд к хранилищу bson документов
yopp
в монге лимит на размер bson — 16 мб
Roman
хмм, окей
yopp
что там внутри этого bson — совершенно пофиг, главное чтоб было поле _id, значение которого меньше 1024 байт
yopp
т.е. если это другая bson структура, то опять-же, сериализированная в bson она должна быть меньше 1024 байт
yopp
к этим документам есть несколько разновидностей индексов
yopp
для того чтоб искать по _значениям_ аттрибутов внутри документа
Roman
угу, это понятно
Roman
хмм, т.е. просто хранить чанки чата в документах с определённым размером?
yopp
я не устану повторять простую вещь: документы надо хранить так, как ты их будешь читать
yopp
понятно что должны быть разумные ограничения
yopp
зачем вытаскивать все 16 мегабайт ради 15 байт?
Roman
типа { members: [<user_id>] first: <datetime> last: <datetime> messages: [ { message: <text> author: <user_id> } ] }
Roman
max 50 message per document, or "page"
yopp
messages: [{t: DateTime, from: Boolean, text: String}]
yopp
хотя если надо по автору искать, то да, дублировать
« Rev
@mongodb_ru   116
Fwd »