Struchkov Mark
c8bcf584e1
All checks were successful
continuous-integration/drone/push Build is passing
3.9 KiB
3.9 KiB
tags | parents | aliases | linked | |||||||
---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
- Журнал БД
- Репликация БД
- Резервные копии БД
- ../../../../_inbox/Транзакция БД
- ../../dev/database/Индекс базы данных
СуБД:
Улучшение производительности
-
Выбирать правильный тип для колонки
-
Денормализация
-
Меньше индексов - лучше
-
Меньше джойнов - лучше
Приложение работает неограниченное количество времени, с каждым днем количество данных в БД увеличивается. При возрастании объема запросы начинают отрабатывать медленнее, в таком случае возникает необходимость в применении партиционирования и шардирования.
Заметки
- Классические СУБД хранят данные в двух местах: на диске и в памяти.
- ../../dev/database/DB page модифицируется сначала в оперативной памяти, потом попадает на диск.
- Часто думают, что реляционная таблица — это массив. Некоторые даже думают, что это двумерный массив. На самом деле, это гораздо более сложная штука. Это мультимножество – набор определенного сорта кортежей, над которым не задано порядка. В SQL-таблице нет порядка. Это важно. И, как результат, когда вы делаете SELECT* из БД (просканировать все записи), результат выполнения запроса может меняться – строчки могут быть в одном порядке, а могут и в другом. Про это нужно помнить.
- Профиль нагрузки на реляционную базу данных выглядит следующим образом: 80% запросов это чтение, 20% запросов это запись. Если запросов на запись больше, то возможно реляционная база данных вам не подходит.
- Обычно в БД имеется планировщик выполнения запроса и executor. Планировщик обычно опирается на ранее собранную статистику выполнения запросов.