[чат] websocket + ?

SEREGA1995 сказал(а):↑

ну если тебе надо сделать join на него еще один, и пока в первой табличке, 10000 в второй 100000 и в третьей 1000000 это ок, добавить нолик, привет оптимизациям, редисам, кешам и т.д. монга просто больше сможет сама собой работать, в какой-то момент и ей надо будет кеш слой или еще чего крутить, индексов еще понастроишь, памяти больше сожрешь, можно и на sql прекрасно сделать, просто больше проблем решить придется, большими ресурсами

Нажмите, чтобы раскрыть...

Ну да сложнее, с носкл удобнее и проще такое делать, просто ты немного челов запутаешь словами "sql медленно") 

SEREGA1995 сказал(а):↑

mongo лучше, так как социалка и чатики много древовидных структур содержит, юзер -> друзья -> друзья друзей, юзер -> чаты -> cообщения...

 

в sql это превратится в кучу joinов что будет медленно если взлетит)

 

это если очень коротко)

Нажмите, чтобы раскрыть...

в постгресе/мускуле есть json, с подключением)

Till_Its_Gone сказал(а):↑

Ну да сложнее, с носкл удобнее и проще такое делать, просто ты немного челов запутаешь словами "sql медленно") 

Нажмите, чтобы раскрыть...

есть много разных баз, под разные сферы, реляционные, временные, документоориентированные, key-value, clickhousы всякие и каждая со своими плюсами и минусами, под свои задачи, нужно правильно готовить любую, теоретически можно в любую класть, вопрос будущих проблем, боли и ресурсов) sql базы прекрасны в своем роде для задач которые они решают)

 

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

 

Erace сказал(а):↑

в постгресе/мускуле есть json, с подключением)

Нажмите, чтобы раскрыть...

как ты видишь структуру такой базы с json полями?

 

Till_Its_Gone сказал(а):↑

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

там должны быть пуш нотификации

 

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

Нажмите, чтобы раскрыть...

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

Till_Its_Gone сказал(а):↑

И как ты отправишь сообщение, если у тебя закрыто приложение? Или вообще выключен дивайс?

Нажмите, чтобы раскрыть...

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

Речь шла о приеме

Till_Its_Gone сказал(а):↑

Не понял насчет "погодного веления".

Нажмите, чтобы раскрыть...

 - они не реал тайм (время доставки может варьироваться от 0 до 5 минут)

 - они имеют ограничение на кол. в минуту

SEREGA1995 сказал(а):↑

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

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

Нажмите, чтобы раскрыть...

офс, для групп никак.

Зато p2p подойдет для общения мимо сервака, в данном случае сервер нужен только для первичного коннекта как DHT, а потом уже юзеры сами обмениваются сообщениями, которые хранятся только у них (эдакая секурность для работяг)

saw_tooth сказал(а):↑

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

Речь шла о приеме

 - они не реал тайм (время доставки может варьироваться от 0 до 5 минут)

 - они имеют ограничение на кол. в минуту

Нажмите, чтобы раскрыть...

ты же сам ответил, что службы ожидают нотификаций)

Если закрыто приложение, то ты просто видишь сообщение на телефоне, если открыто - приложение обрабатывает его сразу.

 

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

 

 

Till_Its_Gone сказал(а):↑

ты же сам ответил, что службы ожидают нотификаций)

Если закрыто приложение, то ты просто видишь сообщение на телефоне, если открыто - приложение обрабатывает его сразу.

Нажмите, чтобы раскрыть...

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

Till_Its_Gone сказал(а):↑

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

Нажмите, чтобы раскрыть...

Причем тут поток сообщений? Что ты несешь?

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

Ровно в той же степени и для ЛС: если ты бомбить начнешь сообщениями более чем 120 в мин, то они просто не будут доходить.

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

 

Push-notification придуманы абсолютно для других целей, нежели чаты, и когда не было firebase как сервиса, гугль нещадно карал нарушителей, вплоть до 1 минутный connect-limit, хотя оно и так было....лимит, в плане быстрой доставки.

saw_tooth сказал(а):↑

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

Причем тут поток сообщений? Что ты несешь?

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

Ровно в той же степени и для ЛС: если ты бомбить начнешь сообщениями более чем 120 в мин, то они просто не будут доходить.

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

 

Push-notification придуманы абсолютно для других целей, нежели чаты, и когда не было firebase как сервиса, гугль нещадно карал нарушителей, вплоть до 1 минутный connect-limit, хотя оно и так было....лимит, в плане быстрой доставки.

Нажмите, чтобы раскрыть...

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

Till_Its_Gone сказал(а):↑

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

Нажмите, чтобы раскрыть...

Я еще в первом сообщении сказал, что реал-тайм чатов, никто никогда не юзает пуши для передачи сообщений, потому что:

 - есть ограничения

 - отсутствие реалтайма (нормального)

 - они придуманы были для других целей

 

Максимум что можно 3-х уровневый конвеер делать с 2-мя службами, одна из которых системная, на пуши гугловые, ее вотчит юзер служба, которая сама обращается на сервер пока девайс не захолджен (юзер службы помеченные как системные, могут и в холде работать в целом, но это слабая гарантия, и управление питанием может такие службы клозать) - перехватывает пуши до истечения тайм-аута работы (принято что бы юзер службы не юзали дохера модем), которой собственно управляет приложение:

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

2 ----проходит первый тайм аут (нет входящих/исходящих), служба засыпает, передавая управление на пуши, в случае если юзер холдит девайс - делается это принудительно.

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

4. по запуску месенджера, прием пушей останавливается встроенной службой, и управление передается слубже юзерской

 

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

saw_tooth сказал(а):↑

Я еще в первом сообщении сказал, что реал-тайм чатов, никто никогда не юзает пуши для передачи сообщений, потому что:

 - есть ограничения

 - отсутствие реалтайма (нормального)

 - они придуманы были для других целей

 

Максимум что можно 3-х уровневый конвеер делать с 2-мя службами, одна из которых системная, на пуши гугловые, ее вотчит юзер служба, которая сама обращается на сервер пока девайс не захолджен (юзер службы помеченные как системные, могут и в холде работать в целом, но это слабая гарантия, и управление питанием может такие службы клозать) - перехватывает пуши до истечения тайм-аута работы (принято что бы юзер службы не юзали дохера модем), которой собственно управляет приложение:

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

2 ----проходит первый тайм аут (нет входящих/исходящих), служба засыпает, передавая управление на пуши, в случае если юзер холдит девайс - делается это принудительно.

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

4. по запуску месенджера, прием пушей останавливается встроенной службой, и управление передается слубже юзерской

 

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

Нажмите, чтобы раскрыть...

ну сори, я писал как понимаю, мне не приходилось пока читать доку файрзбейза(для моей задачи хватало доки как моя IDE подключается к их сервисам xD) и писать месенджеры)

Siller__ сказал(а):↑

захотелось сделать веб версию мессенжера

Спойлер: "линк на макет"

https://www.figma.com/file/Yu7E9cvS1nTJ7vYtj4haXYKc/ReactJS-Chat?node-id=0%3A1

 

морда на реакте

бек на ноде(т.к. с ней немножко уже работал в связке с psql)

возник вопрос в хранении данных - с ws всё и так понятно, но где можно хранить остальной контент?

выбор между psql и mongodb

 

кто знает - посоветуйте: что подходит лучше к данной апликухе - реляционка/нереляционка(желательно с пояснением выбора той или иной технологии)?

 

p.s. тем, кто узнал этот макет -> чела, который его сделал - нет, копировать его кодяру я не буду, просто понравился макет

p.s.2 не пытаюсь сделать конкурента условной телеге т.к. бессмысленно - делаю для себя/попрактиковаться  

 

upd: возможно есть смысл использования и SQL/noSQL вместе(если есть конечно)

Нажмите, чтобы раскрыть...

челик ты делаешь просто для себя что-то бери любую БД и юзай 

Siller__ сказал(а):↑

захотелось сделать веб версию мессенжера

Спойлер: "линк на макет"

https://www.figma.com/file/Yu7E9cvS1nTJ7vYtj4haXYKc/ReactJS-Chat?node-id=0%3A1

 

морда на реакте

бек на ноде(т.к. с ней немножко уже работал в связке с psql)

возник вопрос в хранении данных - с ws всё и так понятно, но где можно хранить остальной контент?

выбор между psql и mongodb

 

кто знает - посоветуйте: что подходит лучше к данной апликухе - реляционка/нереляционка(желательно с пояснением выбора той или иной технологии)?

 

p.s. тем, кто узнал этот макет -> чела, который его сделал - нет, копировать его кодяру я не буду, просто понравился макет

p.s.2 не пытаюсь сделать конкурента условной телеге т.к. бессмысленно - делаю для себя/попрактиковаться  

 

upd: возможно есть смысл использования и SQL/noSQL вместе(если есть конечно)

Нажмите, чтобы раскрыть...

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

Точно не помню почему, но для себя я выбрал postgresql. Я обычно работаю с очень большим объемом данных и у этой бд были свои плюсы. Но как говорят выше, по сути да, тут возьми просто что больше нравится.