import express from 'express'; import jwt from 'jsonwebtoken'; import mongoose from "mongoose"; import bcrypt from 'bcrypt'; import {registerValidation} from "./validations/auth.js"; import {validationResult} from "express-validator"; import UserModel from "./models/User.js"; mongoose.connect('mongodb+srv://name:pass@cluster0.zesdawo.mongodb.net/blog?retryWrites=true&w=majority') .then(() => console.log('ok')) .catch(err => console.log(err)); const app = express(); app.use(express.json()); app.post('/signup', registerValidation, async (req, res) => { const errors = validationResult(req); if (!(errors.isEmpty())) { return res.status(400).json(errors.array()); } const password = req.body.password; const salt = await bcrypt.genSalt(10); const passwordHash = await bcrypt.hash(password, salt); const doc = new UserModel({ email: req.body.email, fullName: req.body.fullName, avatar: req.body.avatar, passwordHash: passwordHash }); const user= await doc.save(); res.json(user); }); app.listen(3333, () => { console.log('ok'); });

Ребзя, всем привет! Ситуация такая, есть кластер с PSA архитектурой, 5.0.15 версия, находится в Германии, есть новые 3 сервака в Москве, также монго 5.0.15 установлены, не добавляются в набор реплик, на московских серваках 2 сетевых интерфейса, 101 и 103 подсети, для подключения с монгой москвы есть внешний айпи с портом 47017, на серваке 27017 в conf файле, с немецких серваков через монгош могу зайти на московские через внешний айпи и порт 47017, но в реплику не загоняется, как думаете в чем проблема?

Что вы бы выбрали, express или nuxt?

из этого ничего

Что вы бы выбрали, express или nuxt?

выбирай то с чем больше работаешь

Ребзя, всем привет! Ситуация такая, есть кластер с PSA архитектурой, 5.0.15 версия, находится в Германии, есть новые 3 сервака в Москве, также монго 5.0.15 установлены, не добавляются в набор реплик, на московских серваках 2 сетевых интерфейса, 101 и 103 подсети, для подключения с монгой москвы есть внешний айпи с портом 47017, на серваке 27017 в conf файле, с немецких серваков через монгош могу зайти на московские через внешний айпи и порт 47017, но в реплику не загоняется, как думаете в чем проблема?

сами фреймы неплохие но есть технологии получше

А в конфиге реплики у вас какие адреса указаны? Отмечу что в кластере все ноды должны иметь возможность подключаться ко всем другим нодам. По этому вам нужно у существующего кластера в Германии все ноды сделать доступными из Москвы

0.0.0.0

я имюе ввиду в rs.config()

Внешка

порт указан как 47017?

если тебе именно на джс нужно бек писать то советую посмотреть в сторону express

Но все же, когда в компанию в какую-то пойдешь, там то реакт требуют, то чет другое

а вообще какой в компании стек на том ты и будешь писать

Что вы бы выбрали, express или nuxt?

nuxt, если на фронте используется vue, nest или чистый express, если не имеет значение

Всем привет, подскажите в чем может быть проблема, в базе всего около 40к документов, а каждый запрос find занимает по 6s, так же не должно быть? В базе будет десятки миллионов записей и весить она будет 300гб, тогда каждый запрос будет занимать 1 день? Может у кого есть идеи что с этим делать?

.lean() попробуй

Это в mongoose или в mongodb можно?

Всем привет, подскажите в чем может быть проблема, в базе всего около 40к документов, а каждый запрос find занимает по 6s, так же не должно быть? В базе будет десятки миллионов записей и весить она будет 300гб, тогда каждый запрос будет занимать 1 день? Может у кого есть идеи что с этим делать?

для начала замерить время исполнения через explain c executionStats. Там же глянуть на что тратится время. Параллельно мониторить цпу/диски/память на сервере под монгой

Всем привет, подскажите в чем может быть проблема, в базе всего около 40к документов, а каждый запрос find занимает по 6s, так же не должно быть? В базе будет десятки миллионов записей и весить она будет 300гб, тогда каждый запрос будет занимать 1 день? Может у кого есть идеи что с этим делать?

Индексы хоть есть?)

Похоже что нет, сейчас делаю, я просто дописываю после другого человека, вот изучаю)

Проведите explain, если есть COLLSCAN, то нужно вешать индекс, если заранее знаете что запрос такого типа будет очень частым, есть смысл создать индекс, если в запросе условия по нескольких ключам и используется сортировка и т.д., то лучше создать композитный индекс по правилу ESR. Но не стоит плодить индексы лишний раз, так как падает скорость записи да и увеличивается объем хранимых данных

Кто-нибудь может помочь с установкой nodejs чата на Windows VPS? За небольшую плату?)

Подвернулась базёнка весом в 5G, в которую напхали 3.5к+ коллекций. Это барахло в линухе ресторится только на сервере с 40G рамы и на любые параметры ему плевать. На серверах похилее рестор фэйлится, СУБД отстреливается. Воспроизводится абсолютно на всех версиях. error running create command: connection(localhost:27017[-5]) socket was unexpectedly closed: EOF В винде ресторится успешно, но тоже выжирает прилично рамы - 10G почти. Это фэйспалм какой-то 🤦.

Проверил. Похоже MongoDB таки больна на рестор множества коллекций. Нагенерил несколько тысяч "одноклеточных" доков и раскопировал это на 3.5к коллекций. 3G на диске заняло. При ресторе сжираются десятки ГБ рамы и валится с той же ошибкой: Failed: mytestdb.mytestcol_copy_666: error creating collection mytestdb.mytestcol_copy_666: error running create command: connection(localhost:27057[-5]) socket was unexpectedly closed: EOF.

Как там тикет оформить? В bug Core Server (SERVER)?

Проверил. Похоже MongoDB таки больна на рестор множества коллекций. Нагенерил несколько тысяч "одноклеточных" доков и раскопировал это на 3.5к коллекций. 3G на диске заняло. При ресторе сжираются десятки ГБ рамы и валится с той же ошибкой: Failed: mytestdb.mytestcol_copy_666: error creating collection mytestdb.mytestcol_copy_666: error running create command: connection(localhost:27057[-5]) socket was unexpectedly closed: EOF.

а какие ошибки в логе самой монги? возможно она упирается в лимит файловых дескрипторов?

Тонны насыпает всякого. Гляну, конечно, возможно и есть по открытым файлам сообщения. Но память льётся неистово в любом случае. Дамп тоже ест гигами при ничтожном датасете по объёму. Количество файлов - одно, а то, что СУБД за собой не чистит по уже отработанным таскам (коллекциям) - другое по идее 🤨

я написал небольшой стресс-тест, нагенерировал 4000 коллекций и через mongorestore восстановил

Мне этот скрин ни о чём не говорит к сожалению. Что за трэды, что за 801МБ.

у вас 4гб это все коллекции или каждая?

заняло минут 5

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