Сергей Протько

Раньше использовал mysql, и до сих пор все нравилось, как не понадобилась иерархическая структура.

Казалось бы, причем тут mongodb. Мускуль json умеет (хоть и не так удобно), и подозреваю что речь все же идет о графах. В этом случае стоит графовую БД брать (Neo4j например).

Словом уточните свою задачу.

А вот как их получать?! Не смог найти свойства и метода.

Читаем документацию.

https://docs.mongodb.com/manual/reference/method/d...

в английском плоховато смыслю

google translate:

replaceOne () заменяет первую найденную документ в коллекции, которая соответствует фильтру, с помощью замены документа.

Если upsert: истинна и никаких документов соответствуют фильтру, replaceOne () создает новый документ, основанный на замене документа. См Заменить Upsert.

вызов GC вручную

И как это могло бы помочь интересно.

сокет сервер таким образом не справляется с нагрузкой?

если там есть внутри буфер сообщений на отправку - то вполне может просто не успевать отправлять сообщеньки.

индексы вы расставляли? explain запросов делали? Что-то мне кажется что нет.

Для вашей задачи хватит и mysql + подтюнить. В целом же можно еще хранить агрегации готовые вместо того что бы на каждый чих по новой их делать.

уже милион чего перепробвал

map

Может хватит использовать mongodb как основное хранилище? Это весьма скверная затея.

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

сначала изучаем javascript (я как-то подозреваю что вы его не особо знаете)
- потом... углубляемся в javascript
- потом учим express.js, попутно постигая тайный смысл аббривиатуры SOLID, изучая ООП, немного функциональщины полезно будет ну и все такое.
- потом учим angularjs (можно express.js и angularjs поменять местами в принципе, это не столь важно).
- Ну и еще неплохо изучить базы данных (SQL). Причем монгу оставьте на потом, эта штука клево себя ведет как основное хранилище данных только для записи логов, и в редких случаях, когда вам реально нужна документо-ориентированность (очень редкий кейс). Ну и для ускорения выборок из реляционных баз данных за счет хранения аггрегаций, но для этого должна быть необходимость (много джойнов в выборках например, очень сложные запросы, тогда монгу можно использовать как кэш первого уровня для хранения денормализованной копии данных для упрощения этих сложных выборок).

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

Если вас интересует как ускорить запись - можно сначала загонять все в буфер (redis например) и потом пачками заносить все в базу.

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

Решил БД карточной игры перевести на MongoDB

Зачем? Если у вас есть хотя бы 10% вероятность того что между записями появятся отношения/связи, то монга вам не подходит.

Монгу стоит использовать исключительно для хранения денормализованных данных. То есть обычно все хранят в реляционной базе и потом делают агрегации данных в денормализованном виде что бы ускорить выборки. В этом случае у нас может быть одна база данных в нормализованном виде (mysq/postgres/etc) и много инстансов монги из которой данные только читаются, но ничего не пишется (кроме как агрегации инициированные изменением данных в реляционной бд.

И то это нужно только если у вас возникают проблемы с реляционной базой (много джойнов например приходится делать в случае сложных выборок). Если у вас один-два джойна то расставить индексы и не париться.

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

1) я бы помимо ID хранил еще порядковый номер, который бы четко задавал последовательность изображений. В таком случае мы можем хранить рэйнджи не просмотренных изображений. Ну и так как у нас может быть произведен переход только к соседнему изображению - это легко устроить.

2) без разницы. Лучше по дефолту брать sql и nosql для кеширования и агрегации данных в случае необходимости.

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

Да, это более чем нормальный сценарий. Скажем хранить все в postgresql и делать агрегации данных для ускорение выборок в какой нибудь elasticsearch или монгу.

А если вы еще и CQRS будете практиковать, то вообще ништяк. Тогда команды у нас будут работать только с postgresql и инициировать обновление агрегаций а запросы - с эластикой.

Хорошо ли он подружится с React.js?

А в react.js уже есть http клиент? Эта библиотека только для view layer. Так что как приготовите взаимодействие с API так и будет дружить.

А стоит ли тратить время на написание REST API ?

https://parse.com/

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

name,date,user_id

user_id вообще быть не должно.

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

Коллекция в этом случае будет агрегацией данных, эдакий кэш. Можно держать несколько коллекций, как в случае с реляционными базами и формировать часть коллекций динамически через map/reduce при изменении данных. Как оптимизировать обновление этой выборки - это уже ваша задача как программиста.

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

Эм... а почему в реддисе это хранить? Эффективнее прямо в основном потоке, нет? Ну да не суть.

Почему хранить айдишник сокета в монге (как и в любой другой СУБД) дурная затея вы поймете после первого ребута системы, отваливающихся соединений и т.д. То есть вам на каждый чих придется еще и базу дергать, относительно медленную к слову если сравнивать с key=>value в памяти или тем более просто мэпу в памяти.

Кешировать комнаты в реддисе тоже неплохая задумка. Все горячие данные стоит хранить в памяти и минимизировать время доступа. Но есть мнение что у вас не будет таких нагрузок что все будет плохо. Так что решайте по мере возникновения проблем.

Так же как и блог.