Фон
Я працюю над додатком для клієнта, який включає деякі функції соціальних мереж. Я спочатку розробляв мобільний фронт-енд, але обставини також залишили мене відповідальним за розробку заднього кінця.
Як загальна інформація, наша система дозволяє користувачам слідкувати за іншими користувачами та отримувати сповіщення про тих, за якими вони стежать, як ви очікували від соціальної мережі. Застереження полягає в тому, що лише невеликий підмножина (щонайбільше декількох сотень) користувачів буде відслідковуватися, сподіваючись, що більша частина користувальницької бази буде стежити принаймні за одним із цих осіб.
З боку користувальницького інтерфейсу у нас з’явиться кнопка сповіщення з номером на ній, і натискання кнопки перенесе вас на екран сповіщень.
Проблема
Я досліджував стратегії впровадження сповіщень та більшість ресурсів, які знайшов сенс створити одну або кілька таблиць сповіщень у базі даних. (Приклад, який мені подобається, - це прийнята відповідь тут: /programming/9735578/building-a-notification-system ).
Те, що мене відкидає, - це те, що більшість стратегій сповіщень, керованих базами даних, вимагають вставляти рядок для кожного сповіщення для кожного підписника. Отже, якщо тисяча людей стежить за Саллі, ми вставляємо тисячу рядків у відповідну таблицю. Це масштабується? Що станеться, якщо ми дійдемо до того, що десятки чи сотні тисяч користувачів слідкують за Саллі, і вона робить кілька десятків публікацій на день?
Моя первісна ідея полягала в тому, щоб обробляти все запитами: номер на кнопці сповіщення буде отримано, запитуючи кількість рядків у вмісті, опублікованому нещодавно, ніж останній раз, коли ви відвідували екран сповіщень, тоді як окремі сповіщення створюватимуться з більш детальних запитів. коли ви відвідали екран сповіщення. Цей підхід не вимагає запису чи додаткового зберігання, але він негнучкий і, ймовірно, забиває сервер досить важко.
НАСТРОЙКА
Резервний сервіс (як встановлено попереднім розробником) використовує CodeIgniter та базу даних MySQL . Зараз він працює на шаленому GoDaddy-акаунті хостингу, але я припускаю (сподіваюсь?) Це буде оновлено до того, як ми розпочнемо виробництво, і пакет хостингу буде масштабуватись із ростом користувачів.
Наразі єдиним нашим мобільним додатком є мобільний додаток, але ми також плануємо згодом створити веб-сайт. Наразі я не переймаюся тим, як отримувати оновлення від натиску в реальному часі від сервера про сповіщення.
ДОБАВЛЕННЯ
Я не спеціалізуюсь на мікстурах, і я перебуваю над головою в цьому відділі. Клієнт це знає, і я зробив усе можливе, щоб спробувати пояснити масштаб проекту такого характеру, але вони дали зрозуміти, що в цей момент вони не будуть довіряти нікому іншим, щоб працювати над проектом. Напевно у нас ще ще місяць роботи, перш ніж ми зможемо додавати тестери, і я можу отримати будь-які показники ефективності. Я дійсно не можу оцінити, скільки користувачів у нас може бути або на якому апаратному забезпеченні ми можемо працювати протягом наступних 5 років, але я думаю, що клієнт сподівається на сотні тисяч користувачів або більше.
Я сподіваюся, що це досить специфічна проблема, яку слід розмістити тут; Я можу вдосконалити це, якщо буде потреба. Будь ласка, запитайте, чи є у вас запитання чи я пропустив важливі деталі.
тл; д-р
- Чи має система управління сповіщеннями, керованими базами даних, негативні наслідки для довгострокової масштабованості, коли всі користувачі лише за деякими кількома сотнями людей?
- Чи є спосіб зробити сповіщення бази даних сповіщень, не потребуючи окремого рядка повідомлень для кожного сповіщення для кожного підписника?
- Чи може система сповіщень, орієнтованих на запити, була масштабованою, чи мали б якісь переваги, крім того, щоб не записувати будь-які дані в БД?
- Невже я занадто рано задумуюся над цим? Чи варто просто побудувати щось, що працює зараз, і ми можемо потурбуватися про його оптимізацію, якщо це стане проблемою, враховуючи, що у клієнта обмежений бюджет, і ми ще не знаємо, чи буде кінцевий продукт популярним?