nozzy: Автор же написал "это одни и те же строки из таблицы "Контакты", т.е. не будет "раздвоения", да и вообще нет смысла дублировать данные в данном случае, даже вредно.
Проблема может быть в драйвере для монги. В любом случае нужно анализировать кто грабит память, а не гадать на пальцах. Попробуйте перезагрузить скрипт без перезагрузки монги, если память "нормализуется", то проблема точно в скрипте. Так же ещё можете попробовать обновить монгу на всякий пожарный.
Судя по цифрам, монга не использует много памяти.
> как бы мне нарвится AtScript и мне все понятно
AtScript уже давно слит в унитаз, они перешли на TypeScript
> Хотя Роб Эйзенберг мне сказал что
Роб ушел из Ангуляра год назад и начал свой фреймворк
> ng2.0 isn't far enough along in development to actually build anything.
Можно перевести как: ng2 не достаточно далеко ушел в развитии чтобы по настоящему разрабатывать что-то.
PAJCH: Я для одной соц. сети успешно использовал MongoDB.
Сейчас посмотрел у ВК лимит на страницу новостей - поэтому можно выделить по мегабайту на каждого пользователя и хранить ленту - будет быстро работать (т.к. чтений больше чем записей).
Если говорить вообще про сводные "ленты" постов, то тут 2 "полюса": 1) составлять по ленте на каждого пользователя - быстра выборка. но большой расход диска, 2) держать идентификаторы "друзей" и составлять ленту реалтайм - тут большая нагрузка на индексы и диск, но экономия по диску.
В больших проектах обычно используют что-то по середине, в зависимости от задач и нагрузки. И часто используют не один вид БД.
> то 1 человек в среднем написал 10k сообщений,
даже если человек будет сидеть 10 часов на вашем сайте, то выходит он должен постить по 16 сообщений в минуту без отрыва, даже у твитера такой нагрузки нет.
Разделение на базы и коллекции одних данных - это партицирование. Это эффективно в некоторых случаях.
Но все зависит от того как вы будете использовать эти данные. Если нужно просто получать сообщения одного пользователя за день - то это подходит, в добавок можно ещё запаковать сообщения - в итоге будете получать все сообщения одним чанком - быстро и экономия дисков.
Какие запросы у вас будут к данным.
> А монга больше подходит ... до 200к документов на коллекцию
Но и нормально работает при сотнях миллионов. (У меня на проекте были миллиарды, но я не штатно использовал монгу).
Вообще вам нужен обработчик для построения индекса, в монго его нет и не понятно будет ли вообще, (в postgre вроде есть), поэтому нужно подготавливать поле под индекс. Если вы заботитесь о занимаемом месте, тогда нужно сменить метод хранения либо рассмотреть другие инструменты.
Т.к. у вас условия в запросе: { url => $url } и { ts => $start_time }, то вам обязательно нужны индексы по этим полям, иначе монга будет вручную перелопачивать все документы и искать нет ли такого документа с таким url.
Т.е. индексы нужно создать до вставки данных.
col_doc.endureIndex({url: 1})
col_statistic.ensureIndex({ts: 1})
так же можно использовать уникальный индекс, это не даст создать дубль.
Более подробный explan можно сделать так, там есть время выполнения и т.п.: db.user.explain('executionStats').update(...)
Судя по вашему mongostats, монга выполняет 300-400 обновлений в сек (помимо запросов) - а это ~3мс на запрос в среднем.
Это да, но все равно ангуляр лайт не сильно нагружает +16кб, зато можно будет использовать другие крутые фичи, да и работает быстрее чем jQuery - benchmark
Хз, ангуляр дает "плохой" трейс, я бы на вашем месте, добавил бы console.log в $digest цикл - тогда можно будет точно сказать на каком watch-e ошибка, а потом дебагером проверить что не так. - это быстро. (ну или просто дебаггером без console.log, если ватчей не много).
Если сможете сделать jsfiddle, где эта ошибка воспроизводится - смогу быстро найти проблему.
