Принцип хранения (постоянство)
-
Mongo
Данные Mongo будут храниться в базовой файловой системе, поэтому емкость хранилища намного больше, чем у Redis и memcached. Вся информация о коллекциях и индексах в базе данных будет разбросана и храниться в нескольких файлах данных, то есть mongodb не похожа на базу данных SQL, данные и индексы каждой таблицы хранятся отдельно; единицей блока данных является экстент (диапазон, площадь ), то есть файл данных состоит из нескольких экстентов. В экстенте могут храниться данные коллекции или данные индексов. В экстенте могут храниться только одни и те же данные коллекции. соответствующих экстентов.В экстентах, в итоге коллекция состоит из одного или нескольких экстентов, минимальный размер 8К, максимальный размер может быть 2Г, увеличиваясь в свою очередь, они разбросаны по множеству данных файлы. Для файла данных он может содержать данные из нескольких коллекций, то есть смесь экстентов и экстентов индексов из нескольких разных коллекций. Каждый экстент содержит несколько документов (или записей указателя), и размер каждого экстента может быть разным, но экстент не будет охватывать 2 файла данных.
image.png
-
Redis
1. Данные Redis хранятся в памяти, и данные могут сохраняться на диске с помощью двух механизмов хранения.
(1) Работает моментальный снимок: он сначала сохраняет данные в памяти, а затем, когда накопленные данные достигают определенного заданного значения, будет запущена операция DUMP, и измененные данные будут записаны в файл данных (файл RDB) в один раз.)
(2) AOF работает: первое — это данные в памяти, но оно будет исправлено при использовании вызова fsync для завершения операции записи в записи журнала, файл журнала фактически предоставляет интерактивный текстовый файл протокола Redis на основе Интернета. Ситуация AOF вызывает fsync не означает, что все они неблокирующие, блокирующий процесс fsync может возникать на некоторых системах, в этом случае можно настроить изменение, но не изменять значение по умолчанию. AOF является наиболее критической конфигурацией в отношении частоты дополнительного вызова fsync файла журнала, есть две предустановленные частоты, всегда приходят в каждую запись, добавляются каждую секунду, добавляются один раз в секунду. При перезапуске Redis файл будет прочитан AOF «воспроизведение», чтобы восстановить последний момент перед закрытием Redis.
(3) Сравнение двух принципов хранения:
a.性能 Snapshot方式的性能是要明显高于AOF方式的，原因有两点： 采用2进制方式存储数据，数据文件比较小，加载快速。存储的时候是按照配置中的save策略来存储，每次都是聚合很多数据批量存储，写入的效率很好，而AOF则一般都是工作在实时存储或者准实时模式下。相对来说存储的频率高，效率却偏低。 b.数据安全 AOF数据安全性高于Snapshot存储，原因： Snapshot存储是基于累计批量的思想，也就是说在允许的情况下，累计的数据越多那么写入效率也就越高，但数据的累计是靠时间的积累完成的，那么如果在长时间数据不写入RDB，但Redis又遇到了崩溃，那么没有写入的数据就无法恢复了，但是AOF方式偏偏相反，根据AOF配置的存储频率的策略可以做到最少的数据丢失和较高的数据恢复能力。 -
Memcached
1. Memcached не поддерживает постоянные операции с данными в памяти, поэтому все данные хранятся в виде in-memory.
тип данных:
-
Mongo
1. Строка, целое число, логическое значение, двойной прогресс с плавающей запятой... Для конкретной справки:воооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооо
-
Redis
1, в дополнение к простым типам данных о значении клавиш, а также предоставление списка, структуры данных хеш, набора, ZSET и т. Д.
-
Memcached
1. Memcached использует форму ключ-значение для хранения и доступа к данным
Модель сетевого ввода-вывода
-
Mongo
1. Многопоточная синхронная модель ввода-вывода.
image.png
Основной поток принимает соединение, а затем создает поток для обработки каждого соединения, модель «поток на соединение»:
（1）不适合短连接服务，创建/删除线程的开销是巨大的，体现在创建线程时间和至少1MB 内存的使用。
（2）伸缩性受到线程数的限制，200+线程数的调度对 OS 也是不小的负担。另外随着线程数的增加, 由于 mongo 本身业务的特性，对数据处理的并发度并不高，DB锁和全局的原子操作造成的 context-switch 也是急剧上升，性能反而下降，频繁的线程切换对于 cache 也不友好。
-
Redis
1. Redis использует однопоточную модель мультиплексирования ввода-вывода и инкапсулирует простую структуру обработки событий Ae_Event. В основном он реализует epoll, kqueue, kvport и select. Для операций ввода-вывода только с одним хранилищем однопоточность может использовать преимущества скорости. также предоставляет некоторые простые вычислительные функции, такие как сортировка, агрегация и т. д. Для этих операций однопоточная модель не может использовать преимущества многоядерных ЦП, что серьезно повлияет на общую пропускную способность, поскольку в процессе вычислений ЦП Все планирование ввода-вывода заблокировано, поэтому Redis не подходит для вычислений.
-
Memcached
1. Memcached — это многопоточная, неблокирующая сетевая модель с мультиплексированием ввода-вывода.Он разделен на основной поток мониторинга и рабочий подпоток.Поток мониторинга отслеживает сетевое соединение.После принятия запроса он передает слово описания соединения в рабочий поток для чтения и записи IO.Сетевой уровень использует библиотеку событий, инкапсулированную libevent.Многопоточная модель может играть роль многоядерности ЦП, но она вводит проблему когерентности кэша (когерентность кэша) и блокировки , такие как: наиболее часто используемая команда статистики Memcached, для этого фактически требуются все операции Memcached.Глобальные переменные заблокированы, выполняются технические работы и т. д., что приводит к потере производительности. (Консистентность кеша относится к тому, совпадают ли данные в кеше с данными в целевом хранилище, то есть были ли измененные данные в кеше сохранены в физическом хранилище и изменено ли содержимое в физическом хранилище такое же, как и в целевом хранилище. Содержимое кеша такое же. Это концепция когерентности.)
Механизм управления памятью
-
Redis
1. Управление памятью Redis в основном реализуется через два файла zmalloc.h и zmalloc.c в исходном коде. Чтобы облегчить управление памятью, после того, как Redis выделит часть памяти, он сохранит размер этой части памяти в заголовке блока памяти. Как показано на рисунке ниже, real_ptr — это указатель, возвращаемый Redis при вызове функции malloc.Redis сохраняет размер блока памяти в заголовке (размер, занимаемый size, известен и является длиной типа size_t), а затем возвращает ret_ptr. Когда вам нужно освободить память, не передавайте ret_ptr в программу управления памятью.Значение real_ptr можно легко вычислить с помощью ret_ptr, а затем передать real_ptr в free для его освобождения.
image.png
2. В Redis не все массивы всегда хранятся в памяти. Это самая большая разница по сравнению с Memcached. Когда физическая память израсходована, Redis может обменять некоторые значения, которые давно не использовались, на диск (Примечание: здесь используется технология виртуальной памяти Redis, которая устарела после Redis 2.4). Redis будет кэшировать только всю ключевую информацию.Если Redis обнаружит, что использование памяти превышает определенный порог, будет запущена операция подкачки. Операция подкачки вычисляет, какие значения, соответствующие ключам, необходимо подкачать на диск по правилам, а затем сохраняет значения, соответствующие этим ключам, на диск и одновременно очищает их в памяти. Эта функция позволяет Redis хранить данные, которые превышают размер физической памяти его компьютера. Разумеется, память самой машины должна иметь возможность сохранять все ключи, ведь эта часть данных не будет подкачиваться на диск. В то же время, когда Redis подкачивает данные в памяти на диск, основной поток, предоставляющий сервис, и подпоток, выполняющий подкачку, будут совместно использовать эту часть памяти.Если данные подкачки необходимо обновить, Redis заблокирует эту операцию до тех пор, пока подпоток не завершит обмен. Изменения можно будет вносить только после этого. При чтении данных из Redis, если значение ключа чтения отсутствует в памяти, то Redis необходимо загрузить соответствующие данные из файла подкачки, а затем вернуть их клиенту.Здесь возникает проблема с пулом потоков ввода-вывода. . По умолчанию Redis будет блокироваться, то есть соответствующая операция не будет выполняться до тех пор, пока не будут загружены все файлы подкачки. Эта стратегия больше подходит, когда количество клиентов невелико и выполняются пакетные операции. Но если Redis используется в приложении большого веб-сайта, это показывает, что он не может соответствовать ситуации большого параллелизма. Таким образом, Redis позволяет нам устанавливать размер пула потоков ввода-вывода, выполнять параллельные операции над запросами на чтение, которым необходимо загрузить соответствующие данные из файла подкачки, и сокращать время блокировки.
-
Memcached
1. Memcached по умолчанию использует механизм Slab Allocation для управления памятью, основная идея которого состоит в том, чтобы разделить выделенную память на блоки определенной длины в соответствии с заранее заданным размером для хранения записей данных ключ-значение соответствующей длины, чтобы полностью решить проблему фрагментации памяти. Проблема. Механизм Slab Allocation предназначен только для хранения внешних данных, то есть все данные ключ-значение хранятся в системе распределения slab, но другие запросы памяти Memcached применяются через обычный malloc/free, потому что количество этих запросов и частота определяет, что они не повлияют на производительность всей системы.
2. Принцип действия механизма slab-аллокации относительно прост, как показано на рисунке ниже, он сначала обращается к большому блоку памяти из операционной системы, делит его на куски разного размера, а куски одного размера делит на группы класс плиты. Среди них чанк — это наименьшая единица, используемая для хранения ключ-значение. Размер каждого класса плит можно контролировать, устанавливая коэффициент роста при запуске Memcached.
image.png
3. Когда Memcached получает данные, отправленные клиентом, он выбирает наиболее подходящий класс slab в соответствии с размером полученных данных, а затем, запрашивая список свободных чанков в классе slab, сохраненном Memcached, вы можете найти класс slab, который использует блок A для хранения данных. Когда срок действия записи данных истекает или она отбрасывается, фрагмент, занимаемый записью, может быть переработан и снова добавлен в список свободных.
4. Из приведенного выше процесса видно, что Memcached обладает высокой эффективностью управления памятью и не вызывает фрагментации памяти, но его самым большим недостатком является то, что он приводит к пустой трате места. Поскольку каждому блоку выделяется память определенной длины, данные переменной длины не могут использовать это пространство. Как показано на рисунке ниже, кэшируйте 100 байт данных в 128-байтовые фрагменты, а оставшиеся 28 байтов теряются.
Управление кластером
-
Mongo
1、Replica Set：中文翻译叫做副本集，就是集群当中包含了多份数据，保证主节点挂掉了，备节点能继续提供数据服务，提供的前提就是数据需要和主节点一致。 Как показано ниже:
2. Mongodb(M) представляет главный узел, Mongodb(S) представляет резервный узел, а Mongodb(A) представляет арбитражный узел. Активный и резервный узлы хранят данные, а арбитражный узел не хранит данные. Клиент одновременно подключается к основному узлу и резервному узлу и не подключается к арбитражному узлу.
3. По умолчанию главный узел предоставляет все услуги добавления, удаления и изменения, а резервный узел не предоставляет никаких услуг. Однако можно настроить резервный узел для предоставления услуг запросов, что может снизить нагрузку на основной узел.Когда клиент выполняет запрос данных, запрос автоматически передается на резервный узел. Этот параметр называется Read Preference Modes, и клиент Java предоставляет простой метод настройки, который не требует работы непосредственно с базой данных.
4. Арбитражный узел - это особый вид узла. Он не хранит данные сам по себе. Его основная функция заключается в том, чтобы решить, какой резервный узел становится основным узлом после того, как основной узел повесит трубку, поэтому клиенту не нужно подключаться к этот узел. Несмотря на то, что существует только один резервный узел, арбитражный узел по-прежнему требуется для повышения уровня резервного узла (резервный узел повышается до главного узла). Требуется узел кворума. Видеть:blog.CSDN.net/Вторжение Луо Нань/Ах…
-
Redis
1. По сравнению с Memcached, который может реализовать распределенное хранилище только на стороне клиента, Redis предпочитает создавать распределенное хранилище на стороне сервера. Новая версия Redis уже поддерживает функцию распределенного хранилища. Redis Cluster — это расширенная версия Redis, которая распределена и допускает единую точку отказа, не имеет центрального узла и обладает линейной масштабируемостью. В архитектуре распределенного хранилища Redis Cluster узлы взаимодействуют друг с другом через двоичный протокол, а узлы и клиенты — через протокол ascii. С точки зрения стратегии размещения данных Redis Cluster делит все поле значения ключа на 16384 (2^14) хеш-слотов, и каждый узел может хранить один или несколько хеш-слотов, то есть Redis Максимальное количество узлов, поддерживаемых кластером, составляет 16384.
2. Чтобы обеспечить доступность данных в условиях единой точки отказа, Redis Cluster вводит главный узел и подчиненный узел. В кластере Redis каждый главный узел соответствует 2 подчиненным узлам для обеспечения избыточности. Таким образом, во всем кластере время простоя любых двух узлов не приведет к недоступности данных. Когда главный узел отключается, кластер автоматически выбирает подчиненный узел, который становится новым главным узлом.
-
Memcached
1. Memcached — это система буферизации данных с полной памятью.Хотя Redis поддерживает сохранение данных, полный объем памяти является основой его высокой производительности. В качестве системы хранения на основе памяти размер физической памяти машины представляет собой максимальный объем данных, который может хранить система. Если данные превышают размер физической памяти одной машины, необходимо построить кластер для расширения емкости хранилища.
2. Сам Memcached не поддерживает распространение, поэтому распределенное хранилище Memcached может быть реализовано только на стороне клиента с помощью распределенных алгоритмов, таких как последовательное хеширование.
Сценарии применения
-
Memcached и Redis
1. По сравнению с memcached, если вам нужно гарантировать, что данные не будут потеряны, выберите Redis.
2. Конечно, в большинстве случаев лучше выбрать Redis, потому что он мощнее, популярнее и имеет больше сторонников, чем Memcached. Memcached — это лишь малая часть функциональности Redis. Так что для новых проектов выбирайте Redis.
-
Mongo
1. Использование Mongo не противоречит двум вышеупомянутым базам данных.Этот текст является лишь кратким изложением знаний.
2. Журнал, запись сообщений, отсутствие транзакций, отсутствие сложной таблицы соединений, хранилище большой емкости, высокая пропускная способность, отсутствие потери данных, высокая доступность, использование Mongo.
Ссылаться на: