Лучшие практики для денормализации данных из реляционных в нереляционные БД

Question

У меня есть веб-сайт, который начинает расти за пределы простой производительности и Tunning. Это PHP-приложение с MySQL в качестве бэкэнда. MySQL правильно настроен, а код оптимизирован.

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

Предположим, у вас есть сайт, похожий на ebay или Amazon. У вас есть продукты в вашей базе данных с некоторой связанной информацией (продавец, клиенты, которые купили продукт, город, штат и т. Д.). Это было бы несколько таблиц в реляционной базе данных, и было бы неплохо сохранить этот способ для создания хороших запросов. Но, например, для домашней страницы вы можете иметь один денормализованный документ (например, в MongoDB). Может быть коллекция с последними денормализованными продуктами, подобными этой:

products = {
   {
      id:13,
      name:"Some product",
      city:"aCity",
      state:"aState",
      price:"10"
   },
   {
      id:123,
      name:"another product",
      city:"aCity",
      state:"aState",
      price:"10"
   }
}

Таким образом, я мог бы запросить эту коллекцию вместо базы данных MySQL (со всеми включенными объединениями), и все могло бы быть очень быстрым.

Теперь вот вопрос. Когда и как бы вы денормализовали эти данные? Например, я могу решить, что хочу денормализовать данные при их вставке.

Итак, в моем "create-product.php" (проще говоря). Я мог сделать все «вставки в» для mysql, и после этого я мог сделать сохранение в коллекцию Mongo.

Или я могу просто запустить программу на сервере. Или сделайте немного cron, чтобы искать последние продукты.

Все это возможности. Чем ты занимаешься? Какой у вас опыт?

Большое спасибо.

Answer 1

Концептуально вы создаете какой-то кэш и ожидаете, что его заполнение будет дорогостоящим, поэтому вы хотите, чтобы он был постоянным, исходя из разумного предположения, что загрузка из вашего постоянного кеша будет быстрее, чем возвращаться к настоящей БД.

Существуют некоторые варианты вашей идеи: кэширование фрагментов HTML-страниц или строк JSON и использование распределенного кэша в памяти - не постоянного, но отказоустойчивого.

Большой вопрос со всеми решениями для кэширования: «Насколько устаревшим я могу быть?». Для некоторых данных устаревание на 24 часа не имеет большого значения. Например: Топ 10 самых популярных книг? Последние обзоры, для тех, которые только некоторые пакетное обновление сделают. Для более срочной работы вам может потребоваться более быстрое обновление, но вы действительно хотите избежать чрезмерной дополнительной обработки в основном потоке. Например, было бы стыдно давать покупателю медленный опыт покупки, потому что он ждет обновления кеша. В этих случаях вы можете просто отправить сообщение «Вот обновление» в очередь или даже сообщение «Ваша запись nunber 23 устарела», пусть кэш выберет это как свое свободное время и, если потребуется, обновит само.