а что у вас там такое в монге хранится?

клики

ну и rps под 50k

и всё в одной реплике?

с пиками под 100 :/

и всё в одной реплике?

Срамота, да. Над шардингом товарищи чешут репу сейчас

50к рпс тянет монга на моём стареньком mba 2013 года без каких либо кручений ручек :)

вы можете почесать репу об нас.

за деньги естественно

50к рпс тянет монга на моём стареньком mba 2013 года без каких либо кручений ручек :)

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

за деньги естественно

ну, это очевидно :) А вы кто?

В настоящий момент, мы — я и мой COO. Но мы от модели продавать меня, приходим к модели продавать услугу «сделать так, чтоб монга не болела»

Всё никак, гхм, лендинг не соберём.

30 в час?

Вообще 120е :)

или я попутал чатики?

значит попутал :)

Но я думаю что мы в самое ближайшее времени отойдём от практики продавать время и перейдём к практике продавать решение проблемы.

по сути - просто спрячете часы от клиента. что, зачастую, очень разумно ?

Не, просто спрятать часы не работает. Нужно иначе систему отношений строить.

Так что если тебе интересно, ты можешь написать @semakovskaya, она тебе всё расскажет. Если уже болит, но пока не бьёт по лицу и почкам, то что-то поправить сейчас, будет сильно дешевле чем править когда уже бьёт :)

Где-то раза в два-три

а код правите?)

а код правите?)

Пока нет, но есть такое на роадмапе

Запросы конечно правим :)

Так что если тебе интересно, ты можешь написать @semakovskaya, она тебе всё расскажет. Если уже болит, но пока не бьёт по лицу и почкам, то что-то поправить сейчас, будет сильно дешевле чем править когда уже бьёт :)

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

т.е. пока только рекомендациями относительно данных ограничиваетесь и подкруткой монги под конкретный текущий кейс?

т.е. пока только рекомендациями относительно данных ограничиваетесь и подкруткой монги под конкретный текущий кейс?

Анализ запросов, схемы, топологии и деплоймента. И рекомендации что с этим делать

Где-то ближе к середине лета, надеюсь, запустим DBaaS для монги.

Это вторая боль после самих данных :(

Только 3 часа пытался установить это.

Уже хочу умереть

Дальше только хуже, да?

Хм, с виду всё не очень плохо, похоже на жс.

Ууу.

Только 3 часа пытался установить это.

Дальше лучше не пытаться.

Все из-за ебаной мышки, которой я не выделил букву o в расширении .repo для файла yum

Я пиздец тупой, блять.

Объект может хранить коллекцию?

Хотя, коллекция это просто массив, так что, по логике - да.

Во, бля.

Моё говно подходит идеально

Дублируете ли вы важные данные (тьфу), или используете ссылки и делаете джоины в коде приложения (дважды тьфу), если вам нужны ссылки между документами, то вы переросли MongoDB. Когда апологеты MongoDB говорят «документы», то они имеют ввиду вещи, которые вы можете напечатать на бумаге и работать таким образом. Документы имеют внутреннюю структуру — заголовки и подзаголовки, параграфы и футеры, но не имеют ссылок на другие документы. Самодостаточный элемент слабоструктурированных данных. Если ваши данные выглядят как набор бумажных документов — поздравляю! Это хороший кейс для Mongo. Но если у вас есть ссылки между документами, то у вас на самом деле нет документов. MongoDB в этом случае — плохое решение. Для социальных данных это действительно плохое решение, так как самая важная часть — связи между документами.

ааа, монгари

Помогайте с $slice

Как заставить это работать?

Или эта штука только для массивов в документе?

Хотя, коллекция это просто массив, так что, по логике - да.

документ не может быть больше 16 мб

а коллекция может

народ, такой вопрос, есть 60+ Гб данных, около 3 миллионов записей, периодически нужно это все экспортировать в определенном виде, в общем упираюсь в IO диска. Если настроить шардинг оно реально будет лучше или за счет сети станет медленнее так как данные все-равно нужно читать все раз в сутки? Ну и еще, не криворукий ли я, если на 3 млн записей уперся в IO?

народ, такой вопрос, есть 60+ Гб данных, около 3 миллионов записей, периодически нужно это все экспортировать в определенном виде, в общем упираюсь в IO диска. Если настроить шардинг оно реально будет лучше или за счет сети станет медленнее так как данные все-равно нужно читать все раз в сутки? Ну и еще, не криворукий ли я, если на 3 млн записей уперся в IO?

Смотря как упираешься и как на долго.

Вариант завести hidden или просто реплику и с неё синхронизироваться.

Смотря как упираешься и как на долго.

ну каждый день, load average поднимается до 30 :-/

Второй вариант сделать читалку оплога и перейти на реалтайм синхронизацию

иногда сервак загибается

Это всё субъективизмы

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

да, сейчас пробуем закупить IOPS у амазона, вот думаю насколько опрадано

На магнитных дисках небось?

Ой. Амазон

не, SSD

EBS

но почитал

там столько ограничений ппц

Да, я понял. Лучше уж на магнитных дисках. ;)

изначально как оказалось у нас было 10% от максимального IO

короче я спрашиваю потому что думаю что лучше: тупо закидать деньгами и купить IO, или заморачиваться с кластером - что лень :)

Посчитай экономику и реши

и + шардинг надо сапортить

Шардинг тебе тут не поможет

Точнее поможет, но на 60гб это оверкилл

ну оно будет расти думаю до 200 гб легко

скоро может и до 500 гб

начинали со 100 мб :)

Скоро это когда?

ну в рамках 3-4 месяцев

Вот у ребят 7гб в час, вот это я понимаю динамика.

3-4 месяца простоя шарда — дорого

ну мы пока растем и все больше в тестовом режиме

подвязан ES еще к монге для поиска

тоже на AWS лол

Ну деньги раз на это есть, значит всё хорошо развивается

короче все очень зыбко и не понятно, каждый день может быть что-то новое, сегодня 60гб завтра 500 :)

ок, ясно, попробуем докупить IO

просто хочется понимать что это не я сильно налажал с кодом или структурой данных :)

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

ну то есть может это детский лепет и я так криво написал что IO должно быть в 10 раз меньше

Ну ты дай больше объективных показателей, будет понятно есть ли смысл что-то крутить

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

подумаем, думаю так и сделаем...получается IO уходит на вторую ноду?

Да

Ну ты дай больше объективных показателей, будет понятно есть ли смысл что-то крутить

например IO или средний размер документа?

просто чтобы знать на что смотреть

Ты говоришь что упираешься в IO. Покажи объективные данные по IO, чтоб было видно как именно и как долго.

Afair, на обычном ebs при всех раскладах больше 2-3к ипос вроде как не выжать

Который ssd

Но я могу ошибаться, этих облаков как грязи.

да, 3к максимум

но сейчас докупим посмотрим, 3к это кажется 10% от максимума