Redis vs Aerospike Чемоданы?

Question

Пройдя через несколько ресурсов в Google и переполнение стека (упомянуто ниже), я получил общее представление о том, когда использовать что, но также получил пару вопросов

Мое понимание:

1. При использовании в качестве чистых баз данных в оперативной памяти обе имеют сопоставимую производительность.Но для больших данных, где полный полный набор данных не может быть помещен в память или даже если он может быть помещен (но это увеличивает стоимость), AS (аэроспайк) может быть хорошим выбором, поскольку он обеспечивает режим, в котором индексы могут храниться в памятии данные в SSD.Я полагаю, что производительность будет немного снижена (по сравнению с полностью в памяти БД, хотя способ, которым AS обрабатывает чтение / запись с SSD, делает его более быстрым, чем традиционный дисковый ввод / вывод), но экономит стоимость и обеспечивает производительность, а затем заполняет данные на диске.Поэтому, когда полные данные могут быть помещены в память, оба могут быть одинаково хороши, но когда память ограничена, AS может быть хорошим случаем.Это верно?

2. Также сказано, что AS предоставил богатую и простую в настройке функцию кластеризации, в то время как некоторые функции кластеризации в redis должны обрабатываться в приложении.Это все еще остается в силе, или это было правдой до тех пор, пока пару лет назад (я так думаю, как я вижу, redis также предоставляет функцию кластеризации)?

Чем аэроспайк отличается от других ключей-значение баз данных nosql?

В каких случаях используется Redis вместо Aerospike?

Answer 1

Ваше предположение в (1) неверно, поскольку оно относится (в основном) к синтетическим ситуациям, когда все данные помещаются в память. Что происходит, когда у вас есть система, которая увеличивается до многих терабайт или даже петабайт данных? Хотели бы вы попытаться разместить эти данные в очень дорогой, сложной для управления системе в памяти, содержащей много узлов? Современная машина может хранить гораздо больше SSD / NVMe дисков, чем памяти. Если вы посмотрите на новый тип семейства экземпляров i3en из Amazon EC2, у i3en.24xl есть 768 ГБ ОЗУ и 60 ТБ памяти NVMe (8 x 7,5 ТБ). Этот тип машин очень хорошо работает с Aerospike, так как он хранит только индексы в памяти. Очень маленький объем данных может храниться в небольшом кластере таких плотных узлов и работать исключительно хорошо.

Aerospike используется в реальном мире в кластерах, которые выросли до сотен терабайт или даже петабайт данных (от десятков до сотен миллиардов объектов), обслуживая миллионы операций в секунду и по-прежнему обрабатывая от миллисекунд до единичных цифры в миллисекундах. См. https://www.aerospike.com/summit/ для нескольких выступлений на эту тему.

Другим аспектом, влияющим на (1), является тот факт, что производительность одного экземпляра Redis вводит в заблуждение, если в действительности вы будете развернуты на нескольких серверах, каждый с несколькими экземплярами Redis на них. Redis не является распределенной базой данных, как Aerospike - она ​​требует шардинга на стороне приложения (который становится чем-то вроде кошмара кластеризации и горизонтального масштабирования) или отдельного прокси, который часто оказывается узким местом. Замечательно, что один осколок может выполнять миллион операций в секунду, но если прокси-сервер не может справиться с объединенной пропускной способностью и конкурирует с осколками за процессор и память, производительность при масштабировании изображения больше, чем просто в оперативной памяти по сравнению с данные на SSD.

Если вы не смотрите на небольшое количество объектов или небольшое количество данных, которые вряд ли будут расти, вам, вероятно, следует сравнить их для себя с проверкой концепции.