временная мера, заебался далеко смотреть :D

сокет изи 10к выдержит с норм серваком

Даже не пукнет, максимум пару раз

по идее, нормальный сервер - нормальная скорость

Ну в память лазить вроде как быстрее чем на диск

Ну в память лазить вроде как быстрее чем на диск

а ты возьми хороший диск :)

Памяти много понадобится, раз уж на то пошло

Да ну для каких-то там юзеров ещё и диск хороший

Из говна и палок норм

я кстати думал над схемой работы "отправлено" сообщения

Типа, ты шлёшь сообщение собеседнику и сразу пушишь в список сообщение, но с пометкой "отправляется"

Типа, ты шлёшь сообщение собеседнику и сразу пушишь в список сообщение, но с пометкой "отправляется"

отправлено, ты хотел сказать

Думаю как пиздато запилить получение статуса "отправлено"

Памяти много понадобится, раз уж на то пошло

Не думаю что больше гигабайта

отправлено, ты хотел сказать

Часы

Типа, сервер ещё в БД не записал

Sent, but not read

Или у тебя ебать какой хайлоад?

У телеги 3 стэйта сообщения: Отправляется, отправлено и прочтено

Или у тебя ебать какой хайлоад?

у меня сложная ситуация, но как говориться, надейся на лучшее, готовьтесь к худшему

Ладно, не буду свои тупые советы раздавать

у меня друг трафик перегонит, если коротко

и надо быть во все оружия

да и не хочется делать тяп-ляп

чтобы не было стыдно кому-то показать

А он не давал оценок на ожидаемый поток? Мб из этого лучше исходить

от 50к юзеров

у него порно сайт

иногда 100к, иногда 500к хостов в день

но полагаюсь на минимум

У телеги 3 стэйта сообщения: Отправляется, отправлено и прочтено

Отправляется - не достигло собеседника Отправлено - достигло но не прочитано Прочитано - доставлено и прочитано

Сложно

Отправляется - не достигло собеседника Отправлено - достигло но не прочитано Прочитано - доставлено и прочитано

да не, я думаю о системе, типа как всё работать будет

можно каждому сообщению генерить айдишник

можно каждому сообщению генерить айдишник

Вааау!

Точно!

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

И нигде так ещё не делали?

Отправляется - не достигло собеседника Отправлено - достигло но не прочитано Прочитано - доставлено и прочитано

Не думаю, что "отправлено" это достигнуто. Разве что достигнуто самого сервера

И нигде так ещё не делали?

все так делают

Не думаю, что "отправлено" это достигнуто. Разве что достигнуто самого сервера

Нудыа

И нигде так ещё не делали?

_id присваивается же после записи в бд

_id присваивается же после записи в бд

Нутак

а я должен ловить до бд

А ты ебашь id

так что, костыль, но по другому никак

в телеге в том числе

или __id

_id_

или __id

Или _____id_____

короче, оказалось чтобы решить проблему, надо её расписать :D

Хуле мелочиться?

или __id

в одном сообщении пиши, 1000 флуда от тебя каждый день

в одном сообщении пиши, 1000 флуда от тебя каждый день

я быстро думаю просто ?

перед тем как думать почитал бы книжки

перед тем как думать почитал бы книжки

Слишком долго

Да и вряд ли там будет обьясняться принцип работы этого :)

хоть одну книжку про паттерны проектирования и архитектуры приложений на нод прочти

хоть одну книжку про паттерны проектирования и архитектуры приложений на нод прочти

Опыт нужно кровью и потом зарабатывать, а не читая чужие мнения. А паттерны, в официальной документации разработчиков прочитаю

удачи

удачи

Спасибо)

Читал, мне понравилось

этот хуяк хуяк, чёто долго слишком идёт у меня)

"Хуяк хуяк, в длиною в жизнь"

нельзя просто взять и редиску заюзать

Таки лучше редис для статуса. Банальный вариант key username, value last ping timestamp from front. И на запрос user-status читать оттуда. Заводишь отдельным кластером. Читаешь оттуда со всем микросервисов статуса. Можно и в монго конечно, но память приоритетнее. Эти данные не критичны к потере

Таки лучше редис для статуса. Банальный вариант key username, value last ping timestamp from front. И на запрос user-status читать оттуда. Заводишь отдельным кластером. Читаешь оттуда со всем микросервисов статуса. Можно и в монго конечно, но память приоритетнее. Эти данные не критичны к потере

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

Привет, ребят, у кого-нибудь есть возможность уделить минут 5-10 и помочь со скриптом? напишу в лс

Чтобы найти юзеров нужно сделать: Client -> Users -> Auth -> Users -> Socket -> Users -> Client, Это если хранить статус в редисе, на socket service и выдавать юзеров с user-status'oм при запросе клиента

Чтобы найти юзеров нужно сделать: Client -> Users -> Auth -> Users -> Socket -> Users -> Client, Это если хранить статус в редисе, на socket service и выдавать юзеров с user-status'oм при запросе клиента

Нихуясебе ты наворотил

А если хранить у юзера в БД то получиться: Client -> Users -> Auth -> Users -> Client,

Нихуясебе ты наворотил

Микросервисы братан, микросервисы

То есть, на 2 запроса меньше. Хз, существенно это или нет, но вроде да

Чтобы найти юзеров нужно сделать: Client -> Users -> Auth -> Users -> Socket -> Users -> Client, Это если хранить статус в редисе, на socket service и выдавать юзеров с user-status'oм при запросе клиента

Ты можешь вставить в выдачу userinfo статус так же. Плюс отдельный сервис когда просто по юзеру статус надо. Плюс в ws когда статус меняется - рассылать всем кто в чате статус

Ты можешь вставить в выдачу userinfo статус так же. Плюс отдельный сервис когда просто по юзеру статус надо. Плюс в ws когда статус меняется - рассылать всем кто в чате статус

Так, а если хранить у юзера, то никаких запросов не потребуется делать. Послал акк нужного юзера и там уже вся user-status инфа

Нихуясебе ты наворотил

Оставь его, пациент всё еще уверен, что микросервисы вылечат его от всех бед :)) ждём...

Микросервис создавать, имея возможность избежать этого. Стоит ли?

Так, а если хранить у юзера, то никаких запросов не потребуется делать. Послал акк нужного юзера и там уже вся user-status инфа

Тебе в таким варианте прийдется на смене статуса менять запись юзера. Что не особо хорошо в случае с монго - дополнительные write включая диск

Тебе в таким варианте прийдется на смене статуса менять запись юзера. Что не особо хорошо в случае с монго - дополнительные write включая диск

Я согласен, этот вариант будет тяжелее для монго, но стоит ли ради этой тяжести создавать микросервис и делать дополнительные запросы?

Хотя это выглядит как перераспределение нагрузки на всю систему, но хз если честно

Я согласен, этот вариант будет тяжелее для монго, но стоит ли ради этой тяжести создавать микросервис и делать дополнительные запросы?

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

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

А при каких нагрузках это ощутимо повлияет?

хотя сложный вопрос :D

Ага. У меня есть сервис что льёт данные под 5мб/сек и вроде норм. Но там выборка по timestamp и чтение большого блока данных достаточно быстро

Но диски nvme (были ssd) что впрочем близко к работе с памятью. Ну если не считать циклы самого ssd, и платить за замену не тебе

Но диски nvme (были ssd) что впрочем близко к работе с памятью. Ну если не считать циклы самого ssd, и платить за замену не тебе

Твой вариант конечно производительнее, вглядит как перераспределние нагрузки, что в случае микросервисов будет более правильным решением. Но в моём случае, хранить user-status у юзера в записи, в качестве временной меры более рациональнее. Но в будущем обязательно исправлю этот момент

Твой вариант конечно производительнее, вглядит как перераспределние нагрузки, что в случае микросервисов будет более правильным решением. Но в моём случае, хранить user-status у юзера в записи, в качестве временной меры более рациональнее. Но в будущем обязательно исправлю этот момент

Так быстрее сделать, да.

Спасибо, тогда пойду пилить)

Ага. У меня есть сервис что льёт данные под 5мб/сек и вроде норм. Но там выборка по timestamp и чтение большого блока данных достаточно быстро

выборка по datetime быстрее будет, ( я про sql )

выборка по datetime быстрее будет, ( я про sql )

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

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

экономия на sort

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

т.е. в монге все документы хранятся по возрастающей? и на findOne() оно выдаст самый новый документ посути?

т.е. в монге все документы хранятся по возрастающей? и на findOne() оно выдаст самый новый документ посути?

во всех sql базах так же

т.е. в монге все документы хранятся по возрастающей? и на findOne() оно выдаст самый новый документ посути?

по порядку записи. грубо говоря сортировка по умолчанию - это id. он, хранит в себе уже timestamp. Вот прикольный сервис https://steveridout.github.io/mongo-object-time/

по порядку записи. грубо говоря сортировка по умолчанию - это id. он, хранит в себе уже timestamp. Вот прикольный сервис https://steveridout.github.io/mongo-object-time/

А api есть?

во всех sql базах так же

нет

выборка по datetime быстрее будет, ( я про sql )

зависит от индексов

fs поддерживает относительный путь? У меня модуль лежит в отдельной папке. И я записываю документ с помощью fs.writeFile(__dirname + `/history.txt А как сделать, что бы документ был записан на один уровень выше? типа ../history.txt Или нужно прописывать абсолютный путь?