Мои навыки проектирования баз данных отвратительны. Где искать средство?

У меня есть веб-сайт, который постепенно расширяется как по трафику, так и по сложности дизайна базы данных. Я всегда работал в первую очередь разработчиком и никогда не был администратором БД, кроме того, что мне нужно делать, чтобы мой код работал. Это нужно изменить - мне нужно повысить эффективность работы с базой данных.

Чтобы привести расплывчатый пример, я ищу, как учиться:

  • Оптимизация сложных таблиц/связей для повышения производительности/масштабирования
  • Как эффективно индексировать. (На данный момент кидаю индексы на внешние ключи, и на этом все)
  • Общие принципы проектирования сложных баз данных

Большинство ресурсов, которые я нашел, либо больше ориентированы на основы SQL («это запрос SELECT, JOIN и т. д.»), либо сосредоточены в первую очередь на проблемах производительности вне БД.

Итак, я знаю, что это немного расплывчато, но где я должен искать, чтобы моя база данных была разработана наиболее эффективным и целостным образом?


performance database-design database-performance
person PlankTon    schedule 11.04.2012    source источник

Ответы (3)


arrow_upward
2
arrow_downward

  1. Узнайте о моделировании данных. Выбор правильной структуры данных всегда является важным первым шагом для программирования в целом и для баз данных в частности. Производительность не может быть «прикручена» к плохой структуре данных! ERwin Руководство по методам, вероятно, неплохое начало изучения моделирования данных.
  2. Узнайте, как СУБД организуют данные на физическом уровне. Это очень поможет вам понять, как «формировать» ваши данные для повышения производительности и как эффективно использовать многие механизмы производительности, которые современные СУБД предоставляют в ваше распоряжение. Используйте указатель, Люк! — отличное руководство по этой теме. .
  3. Узнайте, как эффективно получить доступ к базе данных, и убедитесь, что вы действительно понимаете клиентский API, который будет вызываться из вашего кода. Различные API имеют свои особенности, но все они имеют некоторые общие темы, такие как привязка параметров, подготовка запросов и выборка. Даже если вы «защищены» ORM от необходимости, скажем, связывать параметры вручную, это все равно происходит «под прикрытием», и понимание этого повышает вашу способность писать производительный код.
  4. Мерить, мерить, мерить. Современные информационные системы чрезвычайно сложны, и даже эксперты делают неверные предположения, так что не полагайтесь на предположения!
person Branko Dimitrijevic    schedule 11.04.2012

arrow_upward
1
arrow_downward

Я бы посоветовал немного почитать о настройке производительности. Он очень специализирован в зависимости от используемой вами базы данных. НО вот несколько книг для размышления:

Сервер SQl https://rads.stackoverflow.com/amzn/click/com/1590594215

https://rads.stackoverflow.com/amzn/click/com/1906434476

MySQL https://rads.stackoverflow.com/amzn/click/com/B0028N4W7Y

Oracle https://rads.stackoverflow.com/amzn/click/com/0071780262

Общая настройка производительности -Performance-Tuning-Peter-Gulutzan/dp/0201791692/ref=sr_1_18?s=books&ie=UTF8&qid=1334154964&sr=1-18

person HLGEM    schedule 11.04.2012

arrow_upward
1
arrow_downward

Прежде всего, я бы порекомендовал узнать, как использовать EXPLAIN и что означает его вывод. Запустите его на самых распространенных запросах и изучите результат. Используют ли запросы разумные индексы? Они вообще используют индексы? Запросы, которые на первый взгляд кажутся очень простыми, могут оказаться весьма дорогостоящими.

Затем я предлагаю найти ваши самые медленные запросы. Postgres (например) имеет функцию, которая позволяет вам регистрировать источник SQL для всех запросов, выполнение которых занимает больше N секунд. Они медленные, потому что не индексируются, очень сложные или работают с огромным объемом данных?

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

person Alex Howansky    schedule 11.04.2012