Который имеет лучшую производительность? - PullRequest
1 голос
/ 27 декабря 2010

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

Я храню комментарии к записи в «Комментарии» Таблица и сообщения в «Сообщения» Таблица.Теперь моя схема для таблицы комментариев выглядит следующим образом:

postId commentId postsBy Date CommentBody

Since, чтобы получить комментарии к сообщениюЯ должен был бы искать все посты, чей postId соответствует postId этого конкретного поста, и даже мой postId не может стать первичным ключом, поскольку postId будет не уникальным в столбце (так как несколько комментариев для одного поста), поэтому Iдумал, что если бы я мог объединить postId и commentId в один комментарий (это становится первичным ключом) , используя который postId также можно получить .Вот как я думаю:

CommentId будет сгенерирован как postId * 100 + i (где i - i-й комментарий к сообщению)

, таким образом, чтобыизвлекать комментарии для поста (скажем, с postId = 8452) Я бы искал все посты с commentId (это был бы первичный ключ), лежащий между 845200 и 845299 .. вместо поиска всех комментариев с postId = 8452 .. (конечно это ограничиваетмаксимальное количество комментариев до 100).Но приведет ли это к повышению производительности?

Ответы [ 6 ]

4 голосов
/ 27 декабря 2010

Вот что вы делаете. Загрузите базу данных с репрезентативными данными, например, в два раза превышающими ожидаемый размер.

Затем запустите ваши запросы и проверьте их по обеим версиям схемы.

Затем, и это хороший момент, повторяйте это каждые X недель с новыми актуальными данными, чтобы убедиться, что ситуация не изменилась.

Вот что значит быть администратором. Если ваши данные никогда не изменятся, оптимизация базы данных не является операцией «забей и забудь». И единственный способ убедиться в этом - это провести испытания в репрезентативных условиях.

Все остальное - догадки. Образованные догадки, не поймите меня неправильно, но я предпочел бы иметь детерминистический ответ, предпочтение кому-либо еще, тем более, что первое приспособится к изменениям.

Моя любимая мантра оптимизации - «Мера, не угадай!»

1 голос
/ 27 декабря 2010

Я бы порекомендовал:

  • Использовать двухкомпонентную структуру с составным ключом в комментариях для лучшей уникальности индекса.

  • 100 комментариевдля каждой статьи это плохое ограничение, которое может ударить вас в спину.

  • Не используйте разные таблицы для комментариев относительно видео / изображений и т. д.

  • Если огромное количество комментариев, добавьте таблицу с архивом комментариев и переместите туда старые комментарии.Самые запрашиваемые комментарии (самые новые) будут иметь меньшую и более эффективную таблицу.

  • Сохраняйте BLOB-объекты (изображения и видео) на другом разделе, а не в БД.БД будет меньше и менее фрагментирован на уровне файлов.

regards, / t

0 голосов
/ 27 декабря 2010

CommentId будет сгенерирован как postId * 100 + i (где i - i-й комментарий к сообщению)

, таким образом, для получения комментариев к сообщению (скажем, с postId = 8452) я буду искать все сообщения с комментарием (это был бы первичный ключ), лежащий между 845200 и 845299 .. вместо поиска всех комментариев с postId = 8452. . (конечно, это ограничивает максимальное количество комментариев до 100). Но приведет ли это к какому-либо приросту производительности ??

Это, скорее всего, даст худшую производительность, чем запрос, основанный на столбце внешнего ключа postId, но единственный способ убедиться в этом - попробовать оба метода (как предложено paxdiablo) и измерить производительность.

0 голосов
/ 27 декабря 2010

Используйте составной ключ.Или, если вы используете какую-то инфраструктуру, которая допускает только ключи с одним столбцом, вторичный индекс для postId

0 голосов
/ 27 декабря 2010

Если CommendId не уникален, вы можете создать составной PRIMARY KEY для (postId, CommentID):

CREATE TABLE Comment
        (
        postId INT NOT NULL,
        commentId INT NOT NULL,
        …,
        PRIMARY KEY (postId, commentId)
        )

Если ваша таблица MyISAM, вы можете пометить commentId как AUTO_INCREMENT, который присваивает ему значение UNIQUE для каждого поста.

Если оно уникально, вы можете создать PRIMARY KEY для CommentId и вторичный индекс для (PostId, CommentId):

CREATE TABLE Comment
        (
        commentId INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
        postId INT NOT NULL,
        …,
        KEY (postId, commentId)
        )
0 голосов
/ 27 декабря 2010

Если вы хотите получить большой объем, вы должны создать таблицу Post и таблицу Comments, чтобы иметь меньшую таблицу :).И не забудьте использовать индекс и разделы на них.

...