Назад | Перейти на главную страницу

Что это значит, когда Twitter сообщает, что вся их база данных находится в оперативной памяти?

Мне интересно, с чего начать со стратегиями масштабирования / оптимизации базы данных. После прочтения статей вроде Статья об архитектуре facebook на highscalability.com, и эта статья об архитектуре твиттера, Я не уверен, что под RAM они подразумевают только memcached или что-то еще.

Мои вопросы:

Просто ищу точку в правильном направлении.

Проблема с хранением базы данных в ОЗУ заключается в том, что ОЗУ имеет неприятную привычку забывать все, когда отключается питание, т.е. стойкий. Тем не менее, правильное использование памяти для сайтов с высоким трафиком абсолютно необходимо для получения достойной производительности, потому что вы получаете от этого очень хорошую скорость ввода-вывода, а это очень полезная вещь, если у вас высокая нагрузка.

В памяти MySQL имелся тип таблицы MEMORY, в которой данные хранились в ОЗУ, а не на диске (как в InnoDB и MyISAM). Творческое использование RAMdisk также позволит любой базе данных использовать RAM в качестве резервной копии диска, но, как указано выше, это, вероятно, не то, что вы хотели бы делать. Как вы уже догадались, более полезным приложением было бы использование ОЗУ в качестве высокопроизводительного кеша с использованием чего-то вроде Memcached. Как я уверен, вы знаете, это дает быстрое хранилище ключей / значений, но требует, чтобы приложение знало, что сначала нужно посмотреть туда, а затем вернуться к постоянной базе данных, если ничего не найдено. Сайты, требующие высокой скорости ввода-вывода для всей реляционной БД, имеют возможность сбросить всю БД на что-то вроде Привод Fusion IO. Это не будет так быстро, как ОЗУ, но может быть постоянным, поэтому может быть полезным компромиссом. Я считаю, что SO запускает свою базу данных на диске Fusion IO (см. это сообщение в блоге об их выводах.

Таким образом, на сайте большого объема данные будут храниться в постоянном хранилище (вращающийся диск, SSD и т. Д.), А затем настроен ряд уровней высокопроизводительных кешей, чтобы снизить (обычно чтение) нагрузку на база данных. Записи обычно идут прямо в базу данных, но вы можете использовать локализованный кеш записи, если у вас много записей.

В ответ на ваши конкретные вопросы:

  • Целые базы данных SQL могут храниться в ОЗУ, но это не обязательно встроено или то, что вы ищете. Если вам нужна база данных на основе RAM, вероятно, есть лучший вариант.
  • Индексами SQL будет управлять используемый вами механизм SQL. Различные SQL-серверы (MSSQL, MySQL, Postgres и т. Д.) Могут иметь разные стратегии и параметры настройки для определения, когда выгружать индексы в оперативную память, в зависимости от ряда факторов, таких как их размер, частота попаданий, RAM у вас есть.
  • Я не эксперт по NOSQL, поэтому отвечу здесь. Однако можно ли сказать, что memcached - это база данных NOSQL на основе памяти? Может быть.
  • Memcached довольно широко используется и имеет большую поддержку со стороны различных библиотек и программных стеков.

Twitter использует Redis для своих операций с БД. Это форма базы данных NoSql. Он также находится в памяти, поэтому очень быстро выполняет операции чтения / записи. Twitter принял его для хранения всех своих данных в форме «ключ-значение» для всех своих пользовательских данных. Хотя это требует, чтобы вы реализовали свои собственные алгоритмы управления серверами Redis, как реализовать сегментирование, а также настроить свои собственные конфигурации Master-Slave. Вы можете посмотреть здесь подробнее https://www.youtube.com/watch?v=rP9EKvWt0zo

  1. Да, хотя я думаю, что в твиттере используются различные технологии, а не только СУБД. Существуют механизмы для MySQL, которые работают ТОЛЬКО в памяти, например (кластер NDB, если память обслуживает).

  2. Часто да.

  3. Не по определению, но некоторые могут быть. Часто для любой базы данных лучше всего максимально использовать оперативную память и минимизировать медленный доступ к диску.

  4. Memcached - это, безусловно, один из распространенных кешей внешнего интерфейса для многих серверных частей баз данных. Я дал презентация об использовании memcached с Amazon simpleDB пару лет назад, что может быть полезно, а может и нет.

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

Я не знаю, как твиттер делает это конкретно, но отвечу на ваши общие вопросы:

Может ли X храниться в ОЗУ вопросы: Да, если структуры еще не кэшированы в ОЗУ самой системой базы данных, представьте себе RAM-диск в качестве файловой системы. Все, что есть в памяти. У этих систем огромная пропускная способность. Их недостаток: угадайте, что происходит, когда кто-то вытаскивает вилку ... вся ваша память теряется. Конечно, есть решения для этого, например, делать регулярные снимки / записывать данные на реальные жесткие диски, или вы можете использовать постоянную память (не флеш-память, которая слишком медленная и ограниченная, но есть (действительно дорогие) решения, такие как MRAM.

Да, все базы данных SQL можно хранить в ОЗУ, и это довольно стандартный метод для таких высокопроизводительных сайтов.

Да, индексы SQL, скорее всего, тоже хранятся в ОЗУ.

В ОЗУ можно хранить все, что угодно, это просто место для хранения. Что вы должны принять во внимание, так это размер хранилища, а что еще требует доступа к ОЗУ, чтобы убедиться, что у вас достаточно.