Проектирование реляционной базы данных и нависшая надежду - PullRequest
5 голосов
/ 06 декабря 2011

Я работаю в команде из четырех человек в растущей компании, насчитывающей более 200 пользователей. Пришло время для массивного рефакторинга нашего проприетарного программного обеспечения, и мы очень рады создать идеальную систему, которая, как мы знаем, сможет выдержать рост как минимум 5+ лет. Однако мы используем реляционную базу данных, и, хотя мы создаем довольно неплохие проекты, у меня возникает ощущение, что этот продукт может работать медленнее, на что мы надеемся в будущем.

Мое беспокойство вызывает использование нами отношений с ключевыми словами. Они отлично подходят для обеспечения целостности данных, поэтому мы идем с ними. Если бы мы хотели изменить чье-то имя пользователя, это изменило бы его во всех связанных местах. Замечательно. Проблема в том, что мы не являемся - мы связываемся по их идентификатору, поэтому единственным значительным преимуществом является производительность, получаемая при наличии индекса реляционного ключа.

Все эти накапливающиеся индексы дают мне красный флаг. У нас есть несколько таблиц, которые просто связывают таблицы с тремя реляционными ключами. У них определенно есть свое место, и мы настолько уверены, что это сократит количество запросов, которые мы будем выполнять. Тем не менее, я тогда думаю - у нас есть 10 000 строк в этом, 10 000 в этом, и 10 000 в другом, и мы хотим добавить новый. Бам! Новый индекс * 4.

Это беспокоит. Есть ли какие-нибудь подводные камни, в которые мы попадем, какие-нибудь советы от опытных людей?

Ответы [ 4 ]

3 голосов
/ 06 декабря 2011

Как быстро ваша текущая система? Разработка хорошей схемы базы данных - это основа всего вашего приложения, и если бы мне пришлось выбирать между скоростью и дизайном, я бы выбрал дизайн. Есть несколько способов ускорить работу вашего приложения, которые не имеют ничего общего с самой базой данных.

Если вы выполняете параллельную установку (запускаете старую систему с новой системой), вы можете отслеживать медленные журналы запросов и предотвращать любые начальные проблемы с медлительностью на ранних этапах. Вы также можете идентифицировать часто выполняемые запросы и оптимизировать запросы, добавляя новые или редактируя существующие индексы.

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

Другим методом оптимизации является увеличение (увеличение физической емкости отдельных машин) или масштабирование (добавление большего количества машин в кластер с репликацией). Я видел, как системы работают очень быстро с 10 миллионами записей на машинах с 64 ГБ оперативной памяти. Поэтому убедитесь, что ваш дизайн включает в себя физические возможности.

Существует целый ряд методов оптимизации, которые вы можете использовать для обеспечения быстрой базы данных; держитесь подальше от текстовых столбцов, не используйте операторы OR, избегайте ORDER BY RAND () и ограничивайте использование операторов группировки, таких как group by. Это всего лишь несколько примеров, поэтому сделайте некоторые исследования. Чтобы упростить оптимизацию, вы можете использовать такие инструменты, как объяснение MySQL, которые будут определять, насколько болезненным может быть запрос при запуске через приложение.

Я бы настоятельно рекомендовал использовать MySQL от Percona , поскольку они высоко оптимизированы и предлагают пользовательские функции.

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

3 голосов
/ 06 декабря 2011

Не выбрасывайте Fks, если это не нужно.Если вы сделаете это, вероятность 100% неверных данных близка к 100%.

Fks будет замедлять вставки и удаления, но они должны это делать.Если люди, обладающие триллионами финансовых записей, могут создавать базы данных, которые работают быстро и все еще имеют ограничения, то же самое можно сделать и у вас.

Если вы беспокоитесь о том, как ваша база данных работает, поскольку volumn становится выше, наймите профессионального дизайнера баз данных.ТО, кто знает о реальных рисках исключения ключей и денормализации, а также о проблемах производительности, вызванных плохим дизайном базы данных.

3 голосов
/ 06 декабря 2011

Мое беспокойство связано с использованием нами отношений по ключевым словам. Они отлично подходят для целостность данных, поэтому мы идем с ними. Если бы мы хотели изменить чье-то имя пользователя, это изменит его во всех связанных местах. Замечательно. Проблема в том, что мы не ... мы связываемся по их идентификатору, поэтому единственным главным преимуществом является производительность, полученная благодаря Индекс ключа.

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

Если вы разрешите пользователям вводить "Сан-Франциско, Алабама" в качестве названия города, иметь действительно быструю базу данных не имеет значения. Что бы вы ни писали там, оно не будет доставлено. Сан-Франциско не в Алабаме.

Каждое ограничение целостности данных, которое вы можете обнаружить, должно быть объявлено в dbms. Это экономит время и деньги. Многое из этого.

2 голосов
/ 06 декабря 2011

В этой отрасли есть очень умные и опытные люди, которые намеренно отказываются от ссылочной целостности, транзакций и других «золотых стандартов» проектирования баз данных. eBay является одним из них. Их проектные решения обсуждаются Мартином Фаулером (специалист по разработке программного обеспечения) в этом блоге

Мораль должна быть (ИМХО): не делайте предположений, вместо этого делайте прототипы и тестируйте! Подготовьте количественные тесты, чтобы проверить ваши проектные решения, прежде чем вы совершите. Существует множество платформ для модульного тестирования, которые позволят вам быстро раскрутить прототипы и испытательные стенды.

Видео с теми же героями - здесь и другая презентация здесь

...