Самый быстрый движок базы данных для кеширования?

Question

Я использую MySQL для своей основной базы данных, где я храню фактические объекты.Когда объект отображается с использованием шаблона, рендеринг занимает много времени.

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

Мне нужна база данных (предпочтительно ключ-значение) для хранения моего кэша. Я не могу использовать прокси-сервер кэширования, потому что мне все еще нужно обрабатыватькэшированный HTML.Есть ли такая база данных с PHP-интерфейсом?

Редактировать: Если я использую memcached и кэширую около миллиона страниц, не исчерпаю ли я ОЗУ?

Редактировать 2: И снова у меня есть много HTML для кеширования (гигабайт).

Answer 1

Если я использую memcached и я кеширую миллион страниц, я не закончу RAM

Memcached

memcached - это также действительно надежный продукт (например, redis more), используемый на всех крупных сайтах для поддержания их в рабочем состоянии. Почти все активные твиты (которые пользователь выбирает) хранятся в memcached для безумной производительности.

Если вы хотите быть быстрым, у вас должен быть активный набор данных в памяти. Но да, если набор данных больше, чем ваша доступная память, вы должны (должны всегда хранить данные в постоянном хранилище данных, потому что memcached является изменчивым) хранить данные в постоянном хранилище данных, например, mysql. Когда он не доступен в памяти, вы попытаетесь извлечь его из хранилища данных и кэшировать его в memcache для дальнейшего использования (с заголовком expire).

Redis

Мне действительно нравится redis , потому что это расширенное хранилище значений ключей с безумной производительностью

Redis - это расширенное хранилище ключей. Это похоже на memcached но набор данных не является изменчивым, а значения могут быть строки, так же, как в memcached, но также списки, наборы и упорядоченные наборы. Все эти типы данных могут манипулировать атомными операциями выдвигать / вставлять элементы, добавлять / удалять элементы, выполняющие объединение на стороне сервера, пересечение, разница между наборами, и так далее. Redis поддерживает разные сортировка способностей.

Redis имеет VM , поэтому вам не нужно отдельное постоянное хранилище данных. Мне очень нравится redis из-за всех доступных команд (power :)?). Этот учебник Саймона Уилсона показывает (много) сырой силы, которой обладает redis.

Скорость

Redis - это довольно быстро! , 110000 SET / сек, 81000 GET / сек для Linux начального уровня. Проверьте контрольные показатели .

Фиксирует

Redis более активно развивается. 8 часов назад antirez (redis) совершил что-то против memcached 12 ноября самое позднее commit .

Установить Redis

Redis безумно прост в установке. У него нет зависимостей. Вам нужно только выполнить:

make
./redis-server redis.conf #start redis

для компиляции redis (Awesome:)?).

Установить Memcached

Memcached имеет зависимость (libevent), что затрудняет установку .

wget http://memcached.org/latest
tar -zxvf memcached-1.x.x.tar.gz
cd memcached-1.x.x
./configure
make && make test
sudo make install

не совсем верно, потому что memcached имеет зависимость libevent и ./configure потерпит неудачу, если libevent отсутствует. Но опять же у них есть пакеты , которые классные, но требуют root для установки.

Answer 2

Redis довольно быстр: 110 000 КОМПЛЕКТЫ / второй

Если скорость имеет значение, зачем использовать сетевой уровень?

Согласно: http://tokutek.com/downloads/mysqluc-2010-fractal-trees.pdf

• InnoDB вставляет .................... 43 000 записей в секунду НА ЕЕ ПИК *;
• TokuDB вставляет ................... 34000 записей в секунду НА ЕЕ ПИК *;
• G-WAN KV вставляет .... 100 000 000 записей в секунду

(*) после нескольких тысяч вставок производительность значительно снижается для InnoDB и TokuDB, которые прекращают запись на диск, когда их кэш, системный кэш и кэш контроллера диска заполнены. См. PDF для интересного обсуждения проблем, вызванных топологией индекса базы данных InnoDB (который сильно нарушает локальность, в то время как топология Fractals масштабируется намного лучше ... но все же не линейно).

Answer 3

Чтобы уточнить ответы на логические представления:

• Плоские файлы так же быстры, как используемый носитель данных (DISK или RAM)
• Среда, которая кэширует в оперативной памяти элементы MRU (наиболее часто используемые)
• Решение имеет интеллектуальный / быстрый хэш-индекс для всех местоположений (на что опираются системы SQL)

Эта комбинация даст вам лучшее решение, которое вы ищете.

В качестве аргумента, плоский файл или нет - исключая решение ТОЛЬКО ДЛЯ ПАМЯТИ - все движки используют некоторую форму плоского файла. Волшебство заключается в том, чтобы знать, где находятся ваши данные, и при настройке чтения считывать данные наиболее оптимально. В 80-х годах в IBM мы использовали дизайн плоских файлов с фиксированной длиной записи - который не был оптимизирован для дискового пространства, он был оптимизирован для ввода-вывода. Индексы тогда основывались на длине записи * ROWID.

Теперь, когда вам нужно, ваша максимальная производительность при масштабировании - это разумная комбинация - у нас более 1 миллиона компаний, более 10 страниц на компанию - 10 миллионов файлов, а также файлы js, css и изображения.

Теория 1) - Вы знаете, что ограничением является ОЗУ - по возможности размещайте динамическое содержимое на диске и удаляйте такие функции, как счетчики посещений. Используйте NGINX или HIGHLY Tune APACHE (или, как мы это делали, создавали наши собственные веб-серверы с 2001 года) - вся концепция заключается в использовании оперативной памяти для наиболее часто используемых и очень интеллектуальном поиске дискового контента - обычно URI - это хорошо. 1017 *

Теория 2) - Анализ трендов и ожидание пользователей - я потратил годы на исследование и разработку систем, которые отслеживают тренды. Если я знаю, что пользователь пойдет по пути A, B, C, D - тогда, когда он нажмет B, я уже предварительно выбрал C и D. Если я знаю, что пользователь пойдет A, B, но может перейти E, то D. У вас есть выбор предварительного кэширования C и E, или для оперативной памяти ради предварительного извлечения D. и ручного извлечения C или E, когда пользователь выбирает это.

Веб-сервер, который мы разработали вместе с некоторыми системами бухгалтерского учета, которые я разрабатывал в течение многих лет, интегрирует Теорию 2 для предварительной выборки с комбинациями Smart Caching. Мы также сохраняем контент на диск в deflate - поэтому транспортный уровень просто закачивает контент в стек, так как 99% браузеров поддерживают дефлированные потоки. (Перед отправкой на этот 1% быстрее перекачивать, чем в 99% случаев)

Согласно мысли о MEMCACHED и SWAP - скорость диска - ваш враг, однако связать ядро ​​для управления этим врагом - эпическая ошибка! Если вы хотите побить производительность MEMCACHED, узнайте, как настроить RAM-диск и сохранить там свои дефлированные элементы HOT HOT!

** ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Все это предполагает, что у вас достаточно пропускной способности, чтобы пропускная способность вашей инфраструктуры / пользователей была не вашим узким местом, а вашими серверами. @ 3FINC

Answer 4

Плоские файлы "технически" самые быстрые - но если вы ищете что-то с интерфейсом PHP и просто кричите - взгляните на postgres.

http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL#Raw_Speed

Для кэширования памяти посмотрите memcached

http://memcached.org/

* Редактировать: из вашего редактирования ... (избыточно да) ... если вы кэшируете этот том в памяти, у вас будут проблемы.Изучите запросы столбцовых таблиц postgres или квази-нестандартное решение для плоских файлов.

Answer 5

http://memcached.org/ + http://php.net/manual/en/book.memcache.php

Answer 6

На самом деле хранение кеша в файлах - действительно самый быстрый способ сделать это.Но, если вы действительно хотите поместить их в базу данных, вы можете проверить MongoDB .MongoDB - это документно-ориентированная база данных, поэтому здесь нет соединений на стороне сервера, поэтому она быстрее, чем mysql (1. с php 2. в интернете много тестов).

Answer 7

Я бы использовал memcached или APC .В зависимости от того, требуется ли вам кэширование, разделяемое между серверами.Memcached - это демон, к которому вы подключаетесь, где APC фактически находится внутри экземпляра PHP (немного быстрее).Они оба хранят кэш в памяти, поэтому он быстро работает.

Answer 8

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