Суть проблемы: есть группа сайтов с достаточно большими базами данных. Данные это довольно большие статьи, их много. Трафика на сайте тоже много. Как в таком случае наиболее успешно определить структуру баз данных? Что поместить в основную таблицу с постами? Что вынести в отдельные?
Используется MySQL.
P.S. Вопрос ставится для того чтобы узнать не типовое решение, а решение для больших объёмов данных при большом объёме посешений.
Так, хорошо. У статьи же по стандарту имеется заголовок, символьный код, дата, сам контент. И выборка из многомиллионной таблицы по символьному коду становится довольно проблематичной. Хотя во многом требуется доставать только код/заголовок/айдиху для виджетов и списка. Тогда получается что в выборке учавствует тяжеленная (из-за самих статей) таблица.
Вопрос ставится для того чтобы узнать не типовое решение, а решение для больших объёмов данных при большом объёме посешений.
очевидно, перенести сам контент в отдельную таблицу?
вообще, решение для больших объемов данных (в зависимости от того, насколько "больших") – шардинг или распределенные kv-стораджи. в зависимости от того, сколько запросов в секунду хотите обрабатывать. для действительно масштабных случаев это обычно делается так: полные объекты статьи хранятся в некоем готовом к масштабированию сторадже (это может быть любой k-v или шардированные mysql), для быстрых выборок строим нужные таблички (обновляем при сохранении статьи), для "виджетов" держим кэш в redis/memcache. если хочется обойтись одной базой, и дело именно в размере таблиц, а не в правильно построенных индексах, то могут помочь materialized views. ну и еще посмотреть на ресурсы сервера, в которые упираются запросы, если диск, то можно заменить диск на побыстрее.
