Какие алгоритмы я могу реализовать для улучшения общего дизайна и производительности базы данных?

Question

Я работаю над проектом для университета. Знаете ли вы, какие алгоритмы я мог бы реализовать, чтобы помочь с правильным дизайном и общей производительностью базы данных? До сих пор я придумал алгоритм, который может помочь пользователю выбрать ключи-кандидаты, а также алгоритм для нормализации до 3NF. У вас есть другие идеи или предложения? Спасибо.

Answer 1

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

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

Answer 2

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

Как только вы узнаете, для чего предназначена ваша база данных, вы можете начать применять некоторые «Лучшие практики», но даже здесь есть много места для интерпретации, и, что еще хуже, одни и те же принципы могут быть хорошими в одном месте, но очень плохими в другом. Я просто собираюсь предоставить вам пример своего реального опыта

8 лет a go Я начал проект, и мы должны разработать базу данных для финансового приложения. После некоторого анализа мы решили использовать стартовую модель или модель измерения-факта. Мы решили создать индексы (в том числе растровые) для некоторых таблиц, хотя мы перестраивали их во время пакетной обработки, чтобы избежать снижения производительности. пользователи выполняли запросы, которые обращались ко всем данным, в основном к аналитике и агрегированию. Последствия: я отбрасываю все индексы.

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

Резюме, как мой старый друг, который работал Oracle Служба поддержки говорила мне: «Перформанс - это искусство, мой друг, а не наука»

Answer 3

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

Анализ алгоритмов - полезный способ категоризации и размышления о многих проблемах производительности базы данных . Хотя большинство проблем с производительностью решается с помощью передовых методов и методом проб и ошибок, мы никогда по-настоящему не поймем, почему одно решение лучше другого, не понимая лежащих в его основе алгоритмов. Ниже приведен список функций, описывающих алгоритмическую c сложность различных операций с базой данных в порядке от самого быстрого к самому медленному.

1. O (1 / N) - Пакетная обработка для уменьшения накладные расходы для группового сбора, последовательностей, выборки строк
2. O (1) - Хеширование для ha sh секционирование, ha sh кластеры, ha sh соединения
3. O (LOG (N)) - Доступ к индексу для b-деревьев
4. 1 / ((1-P) + P / N) - Закон Амдала и его значение для распараллеливания рабочих нагрузок больших хранилищ данных
5. O (N) - Полное сканирование таблицы, ha sh объединяется (теоретически)
6. O (N * LOG (N)) - полное сканирование таблицы в сравнении с повторным чтением индекса, сортировка, глобальные и локальные индексы, сбор статистики (различные приближения и проблемы с датой рождения разделов)
7. O (N ^ 2) - перекрестные соединения, вложенные циклы, синтаксический анализ
8. O (N!) - порядок объединения
9. O (∞) - оптимизатор (удовлетворение и избегание h alting)

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

Приведенный выше список основан на главе 16 моей книги Pro Oracle SQL Разработка . Вы можете бесплатно прочитать раннюю версию всей главы здесь . Хотя эта глава в основном стоит особняком, она требует глубокого понимания Oracle. Но каждая из тем может стать основой для изучения академических c всю жизнь, поэтому вам нужно выбрать только одну.