Артемий

Стандартная связь многие-ко-многим. Таблица магазинов, таблица производителей, таблица связи магазин-производитель.

MySQL + Sphinx + Memcached

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

MongoDB имеет смысл, если у вас будет ну хотя бы 20 млн композиций, плюс там будет еще куча активности типа прослушиваний, коментов, лайков и прочей ерунды.

MySQL плохо масштабируется при смешанной нагрузке (когда запись/чтение почти поровну), но если у вас только чтение и данные редко обновляются, то можно иметь и миллионы композиций и при миллионной дневной посещаемости. Есть решения вроде Galera, где проблемы масштабирования решены достаточно неплохо.

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

fias.nalog.ru/Updates.aspx

UPD
Дополню: КЛАДР о котором пишут в соседних ответах - это не старый формат, это другой формат, хотя и являющийся предшественником ФИАС. Оба справочника являются пополняемыми и обновляемыми, оба содержат косяки и ошибки причем как общие, так и персонально свои.
На уровне работы с регионами и городами - проблем особых нет (не считая идиотского устройства городов нашей страны, когда город может являться частью другого города находясь в десятке километров, а поселок находящийся в черте города может быть обособленным), а вот на уровне улиц/домов опечатки бывают достаточно часто.

Если самоцель такого выноса - прекратить влияние дампов на доступность чтения с БД, то, при условии, что ваши таблицы в InnoDB и у вас включён binlog, вы можете снимать копии БД с помощью xtrabackup (innobackupex), не останавливая службу и не прерывая доступ к таблицам.
Изменения, произошедшие с момента старта бекапа, "доедут" из бинлога на завершении процесса.
Снимать копии можно как на тот же сервер, так и стримить их (без использования локального диска) на другой.

Если таблицы в MyISAM, можно настроить SLAVE-сервер и снимать дампы с него, не влияя на доступность основного.

Это практика.

Правда из контекста не совсем ясно - это некие регулярные дампы данных для резервирования, или это ручные дампы для разработчиков, которые они могут спонтанно снять в любое время через phpmyadmin?
Если второе, то это не исправить изменением архитектуры. Для чего dev'ы дампят базу с логами? Почему они не могут задампить только нужные мелковесящие таблицы, или даже ограничиться их структурой, чтобы не задевать другие таблицы?
Если для разработки необходим весь снэпшот базы, я бы сделал его снятие регулярным с xtrabackup и публиковал разработчикам для скачивания по сети из одного конкретного места, чтобы никто больше не подключался к продакшену и не делал никаких дампов с продакшена.

Imho:
1) БД 7 гигов как бы не много. Оно должно дампиться за несколько минут.
2)
- Зачем каждому разработчику актуальный дамп продакшена?
- Зачем это все хостить на боевом сервере?
3) Идея писать логи в основную БД весьма порочна. Поднимите под неё какую нибудь монгу, ну или хотя бы отдельный sql сервер.
4) Идея хранить картинки в базе конечно имеет право на жизнь, но для этого нужны веские аргументы.
Мне кажется вполне можно вынести работу с картинками в отдельный сервис (единый для всех) и хранить это все дело в файловой системе.

Таким нудным говорить что час твоей работы стоит 500-1000р пускай даже по консультациям. Консультировать в пустую неизвестно будет ли заказ ты не обязан. Говори прямо как и есть я говорю типо такого:

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

Ты не обязан больше тратить своё время на него без денег. Как правило 95% таких заказчиков нищеброды с 500р в кармане хотящие летающую тарелку и круглосуточную без выходных техническую поддержку, с которых ничего не заработаешь, а если и заработаешь себе дороже встанет не рад этим деньгам будешь.

в строчках 52 и 53 /classes/Article.php

Вторичные индексы InnoDB, как известно, ссылаются на значение первичного ключа, а физически на дисках данные лежат рядом с первичным ключом и отсортированы по по этому самому первичному ключу. Значит, если в индексе написано, что вам нужны id 9, 6, 50, 8 и 7, выгоднее их читать с диска не в таком порядке, а пересортировать и прочитать двумя запросами: 6-9 и 50. Так получаем 2 запроса случайного чтения вместо 5. Это весьма полезно для HDD с медленной механикой, но ещё и приносит свои, хоть и более скромные, дивиденды для SSD - они хоть и на порядки быстрее HDD в случайном чтении, но и им тоже удобнее последовательное, а не случайное чтение.

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

И ещё момент: у вас в запросе нет order by, но есть limit - это значит, что вам всё равно, какие именно строки выбрать. Mysql в таком случае будет возвращать любые подходящие строки в любом порядке на своё усмотрение.