Як бази даних працюють внутрішньо? [зачинено]


80

Я працюю з базами даних протягом останніх кількох років, і я хотів би думати, що я став досить компетентним з їх використанням. Однак нещодавно я читав про Закон Джоеля про негерметичні абстракції, і я зрозумів, що, хоча я можу написати запит, щоб отримати майже все, що хочу, з бази даних, я навіть не уявляю, як база даних насправді інтерпретує запит. Хтось знає якісь хороші статті чи книги, які пояснюють, як бази даних працюють внутрішньо?

Деякі конкретні речі, які мене цікавлять:

  • Що насправді робить база даних, щоб з’ясувати, що відповідає оператору select?
  • Як база даних інтерпретує приєднання по-різному до запиту з кількома операторами "де ключ1 = ключ2"?
  • Як база даних зберігає всю свою пам’ять?
  • Як зберігаються індекси?

Якщо це SQL-сервер, то настійно рекомендую Inside Microsoft SQL Server 2005 series (Microsoft press), зокрема, Storage Engine та Querying..Він відповідає на всі ваші запитання та багато іншого. Можливо, вас зацікавлять деякі з цих щоденників: Крейг Фрідман Кален Делані Варто також підписатися на SQLServerCentral ..
Гульзар Назім

Спробуйте цей db.cs.berkeley.edu/papers/fntdb07-architecture.pdf та WikiPedia. Це трохи величезна тема та такі моделі, як RDBMS, FLATFILE тощо. Синтаксичний аналізатор - це дійсно одна з найважливіших складових. Дякую
Saif Khan

2
Станом на 2015 рік є ця стаття, яка видається досить непоганою.
Піовезан

Внутрішня архітектура баз даних ускладнена. ЦЕЙ СТАТТІ пояснює детальну роботу серверів та механізмів зберігання даних mysql.
shashwat srivastava

Відповіді:


83

Що насправді робить база даних, щоб з’ясувати, що відповідає оператору select?

Якщо говорити прямо, це питання грубої сили. Просто, він читає кожен запис кандидата в базі даних і узгоджує вираз із полями. Отже, якщо у вас є "вибрати * з таблиці, де name = 'fred'", він буквально проходить через кожен запис, захоплює поле "name" і порівнює його з "fred".

Тепер, якщо поле "ім'я таблиці" індексується, то база даних (ймовірно, але не обов'язково) спочатку використовуватиме індекс, щоб знайти записи кандидатів, до яких застосовуватиметься фактичний фільтр.

Це зменшує кількість записів кандидатів, до яких слід застосувати вираз, інакше він буде просто робити те, що ми називаємо "скануванням таблиці", тобто читати кожен рядок.

Але принципово, однак він знаходить записи кандидатів окремо від того, як застосовується фактичний вираз фільтра, і, очевидно, є кілька розумних оптимізацій, які можна зробити.

Як база даних інтерпретує приєднання по-різному до запиту з кількома операторами "де ключ1 = ключ2"?

Ну, об'єднання використовується для створення нової "псевдо-таблиці", до якої застосовується фільтр. Отже, у вас є критерії фільтрації та критерії об’єднання. Критерії об'єднання використовуються для побудови цієї "псевдо-таблиці", а потім до неї застосовується фільтр. Тепер, при інтерпретації об'єднання, це знову та сама проблема, що і фільтр - порівняння грубих сил та зчитування індексу для побудови підмножини для "псевдо таблиці".

Як база даних зберігає всю свою пам’ять?

Одним із ключів хорошої бази даних є те, як вона управляє своїми буферами вводу-виводу. Але це в основному відповідає блокам оперативної пам'яті блокам диска. Завдяки сучасним менеджерам віртуальної пам'яті простіша база даних майже може покластися на ВМ як менеджер буфера пам'яті. Високоякісні БД все це роблять самі.

Як зберігаються індекси?

B + Дерева, як правило, вам слід це переглянути. Це пряма техніка, яка існує роками. Ця перевага ділиться з більшістю будь-якого збалансованого дерева: послідовний доступ до вузлів, а також всі листові вузли пов'язані, щоб ви могли легко переходити від вузла до вузла в порядку ключів. Отже, за допомогою індексу рядки можна вважати "відсортованими" для певних полів бази даних, і база даних може використовувати цю інформацію для користі для оптимізації. Це відмінне від, скажімо, використання хеш-таблиці для індексу, яка лише дозволяє швидко дістатися до певного запису. У B-Tree ви можете швидко дістатись не просто до певного запису, а до точки у відсортованому списку.

Фактична механіка зберігання та індексування рядків у базі даних насправді є досить прямою і добре зрозумілою. Гра управляє буферами та перетворює SQL на ефективні шляхи запитів, щоб використати ці основні ідіоми зберігання.

Потім, поверх ідіоми зберігання є ціла багатокористувацька, блокування, реєстрація та складність транзакцій.


8
Я просто хотів сказати, що це справді цікава та корисна відповідь. Ви десь більше писали на цю тему?
Натан Лонг

це допоможе мені зрозуміти, як насправді працює база даних
Adzimzf

"тоді база даних (ймовірно, але не обов'язково) спочатку використовуватиме індекс, щоб знайти записи кандидатів, до яких застосовуватиметься фактичний фільтр", у яких випадках індекс не використовується, якщо доступний, і чому?
Сатиендра Кумар

1
@SatyendraKumar це залежить від усього, але врешті-решт, якщо оптимізатор (на основі статистики тощо) вирішить, що результатом запиту з індексу буде велика частина рядків таблиці, дешевше ігнорувати натомість сканування індексу та таблиці. Індекс включає багато випадкових входів / виходів, і це має вартість. Зрештою ця вартість вища, ніж просто сканування таблиці. Керування подібними речами - лише один із аспектів налаштування бази даних та процесу оптимізації запитів.
Will Hartung

4
  • Що насправді робить база даних, щоб з’ясувати, що відповідає оператору select?

    БД використовують індекси (див. Нижче)

  • Як база даних інтерпретує приєднання по-різному до запиту з кількома операторами "де ключ1 = ключ2"? Операції об'єднання можуть бути переведені в двійкові операції з деревами шляхом об'єднання дерев.

  • Як база даних зберігає всю свою пам’ять?

    файли з картою пам'яті для швидшого доступу до їх даних

  • Як зберігаються індекси?

    Внутрішні БД працюють з B-Trees для індексації.

Це слід детальніше пояснити у wikipedia.

http://en.wikipedia.org/wiki/B-tree

http://en.wikipedia.org/wiki/Database


1

На додаток до читання, може бути корисним використання інструментів БД для вивчення плану виконання, який база даних використовує для ваших запитів. На додаток до отримання розуміння того, як це працює, ви можете експериментувати з методами для оптимізації запитів за допомогою кращого циклу зворотного зв'язку.


0

Сайф, відмінне посилання. Огляд з висоти пташиного польоту, який охоплює більшість тем та надає детальну інформацію про конкретні реалізації постачальників.

Я зробив три спроби написати пояснення, але це насправді занадто велика тема. Перегляньте статтю Hellerstein (на сервері берклі, до якої зв’язаний Сайф), а потім запитайте про особливості.

Варто зазначити, що в будь-якій даній СУБД реалізовано лише підмножину "відомих хороших ідей". Наприклад, SQLite навіть не робить хеш-об'єднань, він робить лише вкладені цикли (так !!). Але тоді це DBM, що легко вбудовується, і робить свою роботу дуже добре, тому є щось сказати про відсутність складності.

Дізнатися про те, як СУБД збирає статистику та як вона використовує їх для побудови планів запитів, а також навчитися читати плани запитів, насамперед, є безцінною навичкою - якщо вам потрібно вибрати одну тему "внутрішніх даних бази даних" вчись, вчись цього. Це зробить світ різним (і ви більше ніколи випадково не напишете декартовий продукт ... ;-)).


0

Якщо ви хочете дізнатись детальніше, я рекомендую отримати джерела sqlite і подивитися, як це робиться. Це повно, хоча і не в масштабах більших відкритих джерел та комерційних баз даних. Якщо ви хочете дізнатись детальніше, я рекомендую Остаточне керівництво по SQLite, яке є не тільки чудовим поясненням sqlite, але й однією з найбільш читаваних технічних книг, які я знаю. Що стосується MySQL, ви можете дізнатись у MySQL Performance Blog , а також на передній панелі книги O'Reilly High Performance MySQL (V2), блог якої є одним із авторів.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.