2. Защо MySQL?
Денормализирането по същество
Нужда от денормализация
Проблеми на денормализацията
Подходи при денормализиране
Materialized views
Добри и лоши практики
3.
4. Вече не е Community driven
Не е точно Open Source
Принципите са приложими не само за
MySQL
Други СУБД имат по добри резултати при
релационния модел
5. Точно заради проблема с натоварването
трябва да оптимизираме
Forks, 99% съвместими с MySQL
Огромна популярност
Множество инструменти
Широко разпространение
13. Обема на данните се увеличава
Сложни и скъпи процеси по обновяване да
данните
Повишаване на сложността на схемата на
базата
Сложни процеси по разработка и
поддържане чист модела на базата
14. Смесване на Нормализирани и
денормализирани данни в една таблица
Дублирани или кеш таблици директно в MySQL
◦ Използване на Trigger-и за опресняване на данните
◦ Периодично опресняване
◦ Инвалидиране на кеш при събитие
◦ Използване на Shadow таблица при опресняване
Atomic rename (RENAME TABLE foo TO foo_old, foo_new To foo;)
Summary таблици
◦ Агрегирани и групирани данни
◦ Толеранс към актуалност на данните
15. Counter tables
◦ Съдържат сумарни данни
◦ Проблем с конкуренция/глобален mutex
UPDATE hit_counter SET cnt = cnt + 1
UPDATE hit_counter SET cnt = cnt + 1 WHERE slot = RAND() * 100;
Периодично увеличаване
Кеш/дублиране на данни извън MySQL
◦ Memcached
◦ NoSQL
◦ BIS
◦ Data warehouses
◦ Аналитични инструменти
16. Materialized views
◦ MySQL не ги подържа
◦ Физически съществуващи данни, не виртуални
◦ Данни акумулирани от различни източници, за
конкретна цел
◦ Въпросът с актуалността в MySQL е въпрос на
разработчика
17. Flexviews - Materialized views и MySQL
Автоматизирано опресняване на данните
Complete
Incremental – (не поддържа всички Select клаузи, union, distinct
avg, distinct sum …)
Flex Change Data Capture (FlexCDC)
Използва Binary логове, а не таблиците в базата
SQL API
Можем да създаваме в runtime view-та