модель БД для обсуждения высокой доступности - mysql - PullRequest
Новая
       50

модель БД для обсуждения высокой доступности - mysql

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

Не могли бы вы поделиться своим пониманием масштабируемости?

Допустим, у меня есть простая следующая база данных MySQL / RDBMS для древовидного обсуждения:

Таблицы:

  • обсуждение (идентификатор, URL)
  • комментарий (идентификатор, обсуждение ID, parentCommentId, слаг)
  • comment_vote (обсуждение, идентификатор комментария, идентификатор пользователя, значение)

TheИдея состоит в том, чтобы выполнять менее частые записи (в отличие от более частых чтений) в эту структуру РСУБД и после перезаписи кэша записи для всего обсуждения в некоторый кэш чтения (вероятно, документ БД), где хранится формат, который можно обслуживать без дальнейшей обработки вклиент.

  • Давайте ожидать 250 МБ новых данных каждый день или 1000 запросов в минуту (чтение 90%).
  • В comment_vote мы должны как-то убедиться, что для конкретного комментария существуетмакс. 1 голос за каждого пользователя.
  • БД защищена ключом DiscussionId, и у нас есть кластер БД с произвольным числом узлов

1.Мы идем в реальность с этим макетом?Я имею в виду, у нас есть только 3 таблицы здесь.Есть ли очевидное узкое место?Как и при перестроении индексов, при некоторой блокировке на уровне таблиц ... при каждой вставке в таблицы, которые должны иметь сотни гигабайт и более?

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

3. / Есть ли другие идеи / лучшие решения?

Большое спасибо.

1 Ответ

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

Что ж, управление высокой нагрузкой - очень сложная задача, поэтому вы можете попытать счастья на https://dba.stackexchange.com/, например

Начальные мысли

  1. Вы можете попробовать PostgreSQL какболее мощная альтернатива для MySQL
  2. Для записей, подобных форумам, может быть хорошим решением построить PARTITIONING на основе значений DATE комментариев / обсуждений.Таким образом, вам нужно добавить поля DATE - например, последнее обновление, последнее чтение и т. Д. Эти значения также помогут вам логически решить, есть ли необходимость в архивировании
  3. Если вам нужно реализовать быстрый полнотекстовый поискMySQL не лучший способ
...