powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Модель данных для обмена сообщениями
21 сообщений из 21, страница 1 из 1
Модель данных для обмена сообщениями
    #39010900
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Здравствуйте.
Допустим необходимо спроектировать некоторую модель, основным назначением которой будет обмен сообщениями между пользователями. Первое приближение даст нам два отношения Users и Messages, и соответственно схемы отношения
Users {name v,ID i pk};
Messages {destID i fk, senderID i fk, m v,...};

Для небольших размеров модели(по памяти) данная структура должна работать. Но если размер в разы превышает терабайты, например, то как в таком случае должна выглядеть модель ?
...
Рейтинг: 0 / 0
Модель данных для обмена сообщениями
    #39010909
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercuryЗдравствуйте.
Допустим необходимо спроектировать некоторую модель, основным назначением которой будет обмен сообщениями между пользователями. Первое приближение даст нам два отношения Users и Messages, и соответственно схемы отношения
Users {name v,ID i pk};
Messages {destID i fk, senderID i fk, m v,...};

Для небольших размеров модели(по памяти) данная структура должна работать. Но если размер в разы превышает терабайты, например, то как в таком случае должна выглядеть модель ?

Для данной задачи
Забить на реляционную модель
Использовать любое "no SQL" решение.
В зависимости от этого создавать модель.
...
Рейтинг: 0 / 0
Модель данных для обмена сообщениями
    #39010942
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercury,

Сам по себе размер не является решающим фактором - реляционные СУБД проектировались для того, чтобы легко масштабироваться по размеру. Какую нагрузку Вы планируете на эти терабайты? Какие запросы? Сколько одновременно читающих/пишущих процессов?
...
Рейтинг: 0 / 0
Модель данных для обмена сообщениями
    #39010943
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercuryЗдравствуйте.
Допустим необходимо спроектировать некоторую модель, основным назначением которой будет обмен сообщениями между пользователями. Первое приближение даст нам два отношения Users и Messages, и соответственно схемы отношения
Users {name v,ID i pk};
Messages {destID i fk, senderID i fk, m v,...};

Для небольших размеров модели(по памяти) данная структура должна работать. Но если размер в разы превышает терабайты, например, то как в таком случае должна выглядеть модель ?

размер бд не взять на ее структуру.
Так что очень так же.
...
Рейтинг: 0 / 0
Модель данных для обмена сообщениями
    #39011068
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercuryДопустим необходимо спроектировать некоторую модель, основным
назначением которой будет обмен сообщениями между пользователями.
Для обмена сообщениями между пользователями БД не нужна. Совершенно.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Модель данных для обмена сообщениями
    #39011191
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivSashaMercuryЗдравствуйте.
Допустим необходимо спроектировать некоторую модель, основным назначением которой будет обмен сообщениями между пользователями. Первое приближение даст нам два отношения Users и Messages, и соответственно схемы отношения
Users {name v,ID i pk};
Messages {destID i fk, senderID i fk, m v,...};

Для небольших размеров модели(по памяти) данная структура должна работать. Но если размер в разы превышает терабайты, например, то как в таком случае должна выглядеть модель ?

размер бд не взять на ее структуру.
Так что очень так же.

размер бд не влияет на ее структуру.
Так что точно так же.
...
Рейтинг: 0 / 0
Модель данных для обмена сообщениями
    #39011818
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivMasterZivпропущено...


размер бд не взять на ее структуру.
Так что очень так же.

размер бд не влияет на ее структуру.
Так что точно так же.

Т.е. время выборки, например, всех писем пользователя Adel будет постоянной величиной, или практически не будет меняться, в зависимости от размера БД ? (аналогично к другим CRUD операциям)
...
Рейтинг: 0 / 0
Модель данных для обмена сообщениями
    #39011821
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот МатроскинSashaMercury,

Сам по себе размер не является решающим фактором - реляционные СУБД проектировались для того, чтобы легко масштабироваться по размеру. Какую нагрузку Вы планируете на эти терабайты? Какие запросы? Сколько одновременно читающих/пишущих процессов?

Допустим у нас 10^8 пользователей, 1/10 часть из которых(10^7) каждую минуту отправляют по 1 сообщению(размером в 100 Байт) в любой адрес, и 1/10 часть пользователей проверяет/читает входящие сообщения. Допустим каждый 1/1000 пользователь каждую минуту читает предыдущие сообщения за последнюю неделю/месяц/год.
...
Рейтинг: 0 / 0
Модель данных для обмена сообщениями
    #39011867
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercuryКот МатроскинSashaMercury,

Сам по себе размер не является решающим фактором - реляционные СУБД проектировались для того, чтобы легко масштабироваться по размеру. Какую нагрузку Вы планируете на эти терабайты? Какие запросы? Сколько одновременно читающих/пишущих процессов?

Допустим у нас 10^8 пользователей, 1/10 часть из которых(10^7) каждую минуту отправляют по 1 сообщению(размером в 100 Байт) в любой адрес, и 1/10 часть пользователей проверяет/читает входящие сообщения. Допустим каждый 1/1000 пользователь каждую минуту читает предыдущие сообщения за последнюю неделю/месяц/год.
Отмеченное - это сотни тысяч транзакций в секунду, вряд ли у Вас это потянет одна железка. Т.е. Вам придется делать sharding, или как-то по другому параллелить нагрузку.
Вообще, систему в 100К транзакций в секунду Вам вряд ли помогут спроектировать на форуме ;)
...
Рейтинг: 0 / 0
Модель данных для обмена сообщениями
    #39011877
Serguei
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот МатроскинВообще, систему в 100К транзакций в секунду Вам вряд ли помогут спроектировать на форуме ;)

А чего тут еще придумать можно? Ход мыслей у ТС верный. Как то по другому , что это более производительнее будет работать тут не придумаешь. Надо пробовать и там уже видно будет по производительности.
...
Рейтинг: 0 / 0
Модель данных для обмена сообщениями
    #39011891
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот Матроскин Отмеченное - это сотни тысяч транзакций в секунду, вряд ли у Вас это потянет одна железка. Т.е. Вам придется делать sharding, или как-то по другому параллелить нагрузку.
Вообще, систему в 100К транзакций в секунду Вам вряд ли помогут спроектировать на форуме ;)

Такие системы есть, это факт. Ничего нового в смысле того что требуется реализовать я, очевидно, не спрашиваю. Мне интересно как специалисты проектируют такие системы(уже сейчас), возможно общее направление с небольшими элементами конкретики. Not only SQL(о нем говорили выше) слишком обширное направление(и на мой взгляд неоднозначное, в контексте хотя бы терминологии)
...
Рейтинг: 0 / 0
Модель данных для обмена сообщениями
    #39011978
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercuryТакие системы есть, это факт. Ничего нового в смысле того что требуется реализовать я, очевидно, не спрашиваю. Мне интересно как специалисты проектируют такие системы(уже сейчас), возможно общее направление с небольшими элементами конкретики. Not only SQL(о нем говорили выше) слишком обширное направление(и на мой взгляд неоднозначное, в контексте хотя бы терминологии)

Для обмена сообщений преимущества РСУБД не очевидны, а недостатки явны.
Грубо говоря для мессенджера ACID не нужен, от слова совсем.
Зато нужно быстрая выборка значений "key-value".
Быстрая работа с памятью и отложенная серилизация данных.
Очень ленивая репликация.
Все это позволяют сделать все современные NoSQL решения.
Даже тот же MySQL с отключенными транзакциями и мемкешем вполне подойдет.
А, например, PostgreSQL скорее принесет больше проблем, чем удобства в использовании.
...
Рейтинг: 0 / 0
Модель данных для обмена сообщениями
    #39012626
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercuryПервое приближение...
...не позволит оптимально сделать ничего из того, что ожидают от системы обмена сообщениями.

1. Дата отправки
2. Факт прочтения
3. Дата прочтения
4. Групповые сообщения
5. Возможность "удалять" сообщения с любой из сторон с сохранением его у остальных участников
...
Рейтинг: 0 / 0
Модель данных для обмена сообщениями
    #39012657
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mad_nazgulГрубо говоря для мессенджера ACID не нужен, от слова совсем.
Хм. Это что же за такой хреновый мессенджер и кому такой может понадобиться?
...
Рейтинг: 0 / 0
Модель данных для обмена сообщениями
    #39012679
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Всем:
я полагаю, это учебная задача, поэтому споры о нужности субд неуместны.
...
Рейтинг: 0 / 0
Модель данных для обмена сообщениями
    #39012685
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercury


Т.е. время выборки, например, всех писем пользователя Adel будет постоянной величиной, или практически не будет меняться, в зависимости от размера БД ? (аналогично к другим CRUD операциям)


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


выборка по индексу O ( log N)

все CUD тоже O ( log N) в худшем из нормальных случаев. Потому что по индексам.
к тому же сообщения данного пользователя и не нужны никому. фильтры, умный поиск...
...
Рейтинг: 0 / 0
Модель данных для обмена сообщениями
    #39012686
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercuryMasterZivпропущено...


размер бд не влияет на ее структуру.
Так что точно так же.

Т.е. время выборки, например, всех писем пользователя Adel будет постоянной величиной, или практически не будет меняться, в зависимости от размера БД ? (аналогично к другим CRUD операциям)
...
Рейтинг: 0 / 0
Модель данных для обмена сообщениями
    #39012914
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivпри правильной реализации нет, не будет практически меняться

при правильной, это РМД с классическими отношениями для такой модели ?

MasterZivвыборка по индексу O ( log N)

все CUD тоже O ( log N) в худшем из нормальных случаев. Потому что по индексам.

Подскажите пожалуйста где сказано что сложность CRUD операций lg(n) ?
...
Рейтинг: 0 / 0
Модель данных для обмена сообщениями
    #39012917
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[t SashaMercury]MasterZivпри правильной реализации нет, не будет практически меняться

при правильной, это РМД с классическими отношениями для такой модели ?

Нет дело не в отношениях а в индексах.
правильная ..-- это просто без ошибок спроектированная бд и правильно сделанные индексы. Правила все элементарные, в любой книжке. ..

MasterZivвыборка по индексу O ( log N)

все CUD тоже O ( log N) в худшем из нормальных случаев. Потому что по индексам.

Подскажите пожалуйста где сказано что сложность CRUD операций lg(n) ?[/quot]

поиск по индексу O (log N) вот отсюда и следует. ..
...
Рейтинг: 0 / 0
Модель данных для обмена сообщениями
    #39012925
Фотография SashaMercury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Понятно, т.о. индексы панацея для решения такого рода задач ?
PS
Насколько я знаю у них существуют некоторые ограничения, и всякая ли СУБД будет поддерживать множество необходимых индексов по различным элементам ?
...
Рейтинг: 0 / 0
Модель данных для обмена сообщениями
    #39012954
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SashaMercuryПонятно, т.о. индексы панацея для решения такого рода задач ?
PS
Насколько я знаю у них существуют некоторые ограничения, и всякая ли СУБД будет поддерживать множество необходимых индексов по различным элементам ?

индексы вообще панацея для решения любых задач.
Отрасль РСУБД вообще строится на двух
технологиях : кэширование и индексация.

кэширование дает доступ к данным в миллион раз быстрее, а индексы рост сложности по логарифму, те почти линейно и с пологом углом наклона.
...
Рейтинг: 0 / 0
21 сообщений из 21, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Модель данных для обмена сообщениями
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]