Использование внешних ключей в дизайне социальной сети - хорошо / плохо?

Question

В моей схеме я нормализовал свою БД и повсюду есть ФК, потому что в социальной сети очень много взаимосвязанных связей, особенно когда пользователи связываются со всем.

Очевидно, что в социальных сетях производительность будетсломать это.Это означает, что время «чтения» более важно, чем время «записи».Моя БД - MySQL с InnoDB для всех таблиц.Итак, вопрос таков:
1) я предполагаю, что мое предположение «лучше читать, чем писать» - это то, что нужно социальным сетям?
2) иметь много FK (я бы оценил, что почти 30% столбцов в каждой таблице имеют FK)Повлияет ли это на производительность чтения или записи, или на то, и другое, или нет?
3) Лучше иметь 2 набора таблиц для каждой таблицы - одну для операций выбора (чтения) и одну для вставок (записи) с другой схемой, чтобы они моглибыть соответствующим образом спроектированы для лучшей производительности?
4) Будет ли вред, если я скажу 80% моих колонм как fks?(имейте в виду, что это социальная сеть, которая может иметь или не иметь много трафика позже)

Answer 1

1) Полагаю, что мое мнение о том, что лучше читать, чем писать, нужно социальным сетям?

Обычно контент читается чаще, чем пишется.Но это звучит так, как будто вы делаете преждевременную оптимизацию.

2) с большим количеством FK (я бы оценил, что почти 30% столбцов в каждой таблице имеют FK), это повлияет на производительность чтенияили записать производительность или и то, и другое или ничего?

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

Либо ваша база данных нормализована, либо нет.Не пытайтесь нарушить нормализацию, пока не узнаете, что у вас есть проблема с производительностью.

3) Лучше иметь 2 набора таблиц для каждой таблицы - по одной для выбора (чтения) иодин для вставок (записей) с другой схемой, чтобы они могли быть спроектированы соответственно для лучшей производительности?

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

4) Будет ли вред, если я скажу, что 80% моих колонн как fks?(имейте в виду, что это социальная сеть, которая может иметь или не иметь много трафика позже)

Нет - те же ответы, что и выше - нормализовать ваши данные.Объявите свои FK, подождите, пока у вас не возникнет проблема с производительностью, прежде чем пытаться ее исправить.

Answer 2

Вы можете использовать конструкцию MASTERS / SLAVE.

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

Таким образом, ваше промежуточное ПО должно знать, что ВЫБОРЫ сделаны из РАБОВ, а в основном все остальное - в МАСТЕРЕ.Но это зависит от того, что вы используете для бэк-энда.

Answer 3

1) Возможно.Но используйте кеширование, это повышает производительность чтения БД.

2) Оба.Подразумеваемые индексы FK и индексы обычно положительно влияют на производительность чтения, но увеличивают время, необходимое для записи.

3) Нет, и я не совсем понимаю, как это сделать.В какой-то момент данные должны быть записаны в таблицу выбора ... Опять же, используйте кеширование.

4) Не вредно, если именно так структурирована ваша информация.

Если вы беспокоитесьо производительности базы данных, подумайте о кэшировании данных из вашей базы данных и о том, что ваши кэшированные данные не устареют.

Кроме того, планируете ли вы масштабировать на несколько серверов баз данных?Затем вам нужно подумать о том, как синхронизировать базы данных, как распространять изменения.