Лучший подход для реализации системы комментариев и лайков, таких как Instagram или Twitter - PullRequest
Новая
       44

Лучший подход для реализации системы комментариев и лайков, таких как Instagram или Twitter

0 голосов
/ 16 октября 2018

Мы разрабатываем базу данных (MySQL) для курсового проекта.Это именно то, в чем мы застряли: система комментариев и лайков.Итак, мы нашли этот вопрос: Реализация комментариев и лайков в базе данных

Это красиво и точно объяснено.Но каждый лайк или комментарий должен быть новым рядом.Кнопка «Нравится» в Instagram в среднем нажимается ~ 4,5 миллиарда раз в день.Это слишком велико для likes стола.4.5bx30 дней = 135 трлн в месяц!Я не верю, что они так проектируют.

  • Главный вопрос, который мы имеем в виду: как мы можем разработать наиболее подходящую структуру дизайна, используемую крупными компаниями?(Twitter, Instagram и т. Д.) (Минимальное выполнение запросов, наиболее оптимизированные и т. Д.)JSON будет обновлен в колонке комментариев.Является ли этот метод более эффективным, чем добавление новой строки для каждого комментария или подобного?

database_struct

  • Мы нашли следующую диаграмму классов: https://stackoverflow.com/a/1120491/5685796 Этот дизайн был опубликован в 2009 году. Если мы делаем большие проекты, создаст ли реализация этой схемы проблему оптимизации для нас в будущем?(Предположим, что каждая акция содержит 1 миллион лайков и 1 миллион комментариев.:))

Редактировать: Мы проектируем как реляционную базу данных.

1 Ответ

0 голосов
/ 18 октября 2018

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

Помещение объектов в JSON затрудняет их поиск, поиск, фильтрацию и т. Д. То же самое относится к массивам любого типа.Вы делаете и то и другое - помещаете массив объектов JSON в одну ячейку.

Узнайте о JOIN для повторного соединения вещей, о которых я вам говорю, для разделения.

Чтобы попасть втриллионы, вам также понадобится «осколок».Но давайте не будем обсуждать это до тех пор, пока вы не наберете миллионы.

(Дополнительные советы)

У "крупных компаний" есть набор данных, который "отбрасывается" на сотни серверов.Comments очень вероятно, будет в обычной таблице.JSON вряд ли будет использоваться;особенно не для поиска или сортировки.JSON хорош для разного круфта, который нужно сохранить, но не искать / сортировать.

Для вас действительно лучше

  1. спроектировать и реализовать что-то (даже если он включает JSON);
  2. Запущен в производство;
  3. Изучите проблемы, которые возникают;
  4. Через несколько месяцев измените дизайн - будьте готовы выбросить большую частьОригинальный дизайн.
  5. «Промыть и повторить».Слишком много препятствий, чтобы прыгнуть, чтобы добраться туда, куда попали крупные компании за десятилетие и десятки инженеров.

Я могу помочь вам сделать только одну итерацию за раз.

Likes ... Если вы держите счетчик, делайте это в «параллельной» таблице.Это снизит конкуренцию на главном столе.Если вы ведете список того, кому что понравилось, то это таблица сама по себе.

идентификаторы ... Не используйте AUTO_INCREMENT на столе с очень хорошим ПК.Основной пример - таблица «многие: многие» - используйте совокупность двух идентификаторов.

Нормализуйте, но не чрезмерно нормализуйте.Это то, что вы начнете понимать в моем «шаге 3» выше.

Делайте не используйте схему схемы EAV (Entity-Attribute-Value). не хорошо масштабируется.

Подклассы часто становятся неуклюжими.В этой ссылке у них есть Photo / Article / Place "is" Entity.Photos должна быть своей собственной таблицей с собственными столбцами, причудами, индексами и т. Д.

Не не использовать любое стороннее программное обеспечение.Хорошо, вы можете использовать его для первой итерации моих шагов выше.Но на шаге 4 выбросьте его полностью.К тому времени вы были вынуждены изучать детали MySQL (поскольку программное обеспечение не сможет полностью вам помешать узнать подробности).

...