Помогите и посоветуйте. Проблема с оптимизацией.

[duba]

Помогите и посоветуйте. Проблема с оптимизацией.

Задача такая: Есть пользователи и их какие-то события. Один пользователь добавляет что-то (например пишет комментарий к статье). После добавления записи мне нужно проинформировать остальных пользователей о том, что этот пользователь написал новый комментарий. Рассматриваю случай когда при добавлении записи мне нужно проинформировать около 200 других пользователей. Тоесть при добавлении 1 главной записи , мне придёться ещё добавить 200 записей об информировании:


INSERT INTO log_evets (кто_информируе, кого_информировать, текст_информации_или_id_события) VALUES (3, 4, 'Михаил добавил комментарий к статье .... ');

Допустим что у нас 2000 пользователей и каждый добавил 2 комментария, но у каждого по 200 подпищиков которых нужно проинформировать. Тоесть мы получаем на 2000*2*200 = 800 000. (почти миллион записей).

Далее я размышляю так: Что бы всё это более мение быстроо работало, я могу создать VIEW (MySQL 5) view_log_evets в котором буду ограничевать записи например по дате или какому-то количеству. (Что бы старые записи не мешали новым, да и просто что бы выборка была быстрее). Я так же могу создать какую то временную таблицу в которую буду помещать очередь добавления об информировании (Для того что бы мне INSERT делать 1 раз и сразу для большой кучи событий, при этом проверять не сильно ли загруженна база, и вообще не занята ли таблица для записи).

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

Я хотел бы узнать, правильно ли я мыслю по поводу оптимизации ?
Какие ещё методы можно использовать что бы решить данную задачу ?
Возможно есть вариант как то упростить весь подход к этой задаче ?

 

[Bitterman]

А зачем добавлять какие-то записи? Отправки мыла недостаточно?

 

[duba]

Ну несовсем, это же интранет приложение, всё должно быть в одном месте. Да и не я это решаю.

 

[Bitterman]

это же интранет приложение, всё должно быть в одном месте.

А можно разъяснить мне смысл этой фразы?
И что за таблица log_events? Просто лог? С какой целью он ведется? Не проще ли писать в файл тогда?

Да и не я это решаю.

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

 

[duba]

Bitterman - приложение внутреннее, корпоративное, но с большим количеством юзеров. Серверов там тоже несколько, пользователей переваливает за 100 000. Закащики хотят что бы одни из более продвинутых пользователей могли смотреть события других, каких именно пользователей определено уже базе зарание. Тоесть я бы очень хотел вести 1 большой лог просто для всех или для админов, но так нельзя. Мне нужно вести лог выборочно, для определённых задач.

 

[Bitterman]

Добавляй в лог только события. Зачем тебе там поле "кого информировать"? Сделай лог событий + таблица связи каким пользователям о каких пользователях сообщать.

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

Что значит нельзя?

 

[Фанат]

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

 

[Krishna]

Серверов там тоже несколько, пользователей переваливает за 100 000.

А софт для них пишет человек путающийся в трех соснах)
Остаётся только поапплодировать! )

 

[confguru]

INSERT INTO log_evets (таймштамп,кто_информируе,текст_информации_или_id_события) VALUES (now(), 3, 'Михаил добавил комментарий к статье .... ');

Отдельная табличка где user_id подписаны на события кто_информируе
и таймштамп последнего просмотра..

 

[duba]

Ок, всем спасиба. Буду реализовывать как сказал admin. Потом расскажу что получилось.

 

[jonjonson]

И что все упёрлись в http? При более менее быстрых обновлениях и даже с аяксом это бред.
Самое медленное место здесь не момент с работой с БД. Паттерн слушатель - да. Самое медленное обновление пользовательского интерфейса.