Мне интересно, с чего начать со стратегиями масштабирования / оптимизации базы данных. После прочтения статей вроде Статья об архитектуре facebook на highscalability.com, и эта статья об архитектуре твиттера, Я не уверен, что под RAM они подразумевают только memcached или что-то еще.
Мои вопросы:
Просто ищу точку в правильном направлении.
Проблема с хранением базы данных в ОЗУ заключается в том, что ОЗУ имеет неприятную привычку забывать все, когда отключается питание, т.е. стойкий. Тем не менее, правильное использование памяти для сайтов с высоким трафиком абсолютно необходимо для получения достойной производительности, потому что вы получаете от этого очень хорошую скорость ввода-вывода, а это очень полезная вещь, если у вас высокая нагрузка.
В памяти MySQL имелся тип таблицы MEMORY, в которой данные хранились в ОЗУ, а не на диске (как в InnoDB и MyISAM). Творческое использование RAMdisk также позволит любой базе данных использовать RAM в качестве резервной копии диска, но, как указано выше, это, вероятно, не то, что вы хотели бы делать. Как вы уже догадались, более полезным приложением было бы использование ОЗУ в качестве высокопроизводительного кеша с использованием чего-то вроде Memcached. Как я уверен, вы знаете, это дает быстрое хранилище ключей / значений, но требует, чтобы приложение знало, что сначала нужно посмотреть туда, а затем вернуться к постоянной базе данных, если ничего не найдено. Сайты, требующие высокой скорости ввода-вывода для всей реляционной БД, имеют возможность сбросить всю БД на что-то вроде Привод Fusion IO. Это не будет так быстро, как ОЗУ, но может быть постоянным, поэтому может быть полезным компромиссом. Я считаю, что SO запускает свою базу данных на диске Fusion IO (см. это сообщение в блоге об их выводах.
Таким образом, на сайте большого объема данные будут храниться в постоянном хранилище (вращающийся диск, SSD и т. Д.), А затем настроен ряд уровней высокопроизводительных кешей, чтобы снизить (обычно чтение) нагрузку на база данных. Записи обычно идут прямо в базу данных, но вы можете использовать локализованный кеш записи, если у вас много записей.
В ответ на ваши конкретные вопросы:
Twitter использует Redis для своих операций с БД. Это форма базы данных NoSql. Он также находится в памяти, поэтому очень быстро выполняет операции чтения / записи. Twitter принял его для хранения всех своих данных в форме «ключ-значение» для всех своих пользовательских данных. Хотя это требует, чтобы вы реализовали свои собственные алгоритмы управления серверами Redis, как реализовать сегментирование, а также настроить свои собственные конфигурации Master-Slave. Вы можете посмотреть здесь подробнее https://www.youtube.com/watch?v=rP9EKvWt0zo
Да, хотя я думаю, что в твиттере используются различные технологии, а не только СУБД. Существуют механизмы для MySQL, которые работают ТОЛЬКО в памяти, например (кластер NDB, если память обслуживает).
Часто да.
Не по определению, но некоторые могут быть. Часто для любой базы данных лучше всего максимально использовать оперативную память и минимизировать медленный доступ к диску.
Memcached - это, безусловно, один из распространенных кешей внешнего интерфейса для многих серверных частей баз данных. Я дал презентация об использовании memcached с Amazon simpleDB пару лет назад, что может быть полезно, а может и нет.
Мудрая стратегия memcached перед базой данных может быть очень полезной, но вы можете использовать кластеризацию и совместимые с протоколами решения, такие как мембаза слишком.
Я не знаю, как твиттер делает это конкретно, но отвечу на ваши общие вопросы:
Может ли X храниться в ОЗУ вопросы: Да, если структуры еще не кэшированы в ОЗУ самой системой базы данных, представьте себе RAM-диск в качестве файловой системы. Все, что есть в памяти. У этих систем огромная пропускная способность. Их недостаток: угадайте, что происходит, когда кто-то вытаскивает вилку ... вся ваша память теряется. Конечно, есть решения для этого, например, делать регулярные снимки / записывать данные на реальные жесткие диски, или вы можете использовать постоянную память (не флеш-память, которая слишком медленная и ограниченная, но есть (действительно дорогие) решения, такие как MRAM.
Да, все базы данных SQL можно хранить в ОЗУ, и это довольно стандартный метод для таких высокопроизводительных сайтов.
Да, индексы SQL, скорее всего, тоже хранятся в ОЗУ.
В ОЗУ можно хранить все, что угодно, это просто место для хранения. Что вы должны принять во внимание, так это размер хранилища, а что еще требует доступа к ОЗУ, чтобы убедиться, что у вас достаточно.