Redis vs SQLite vs PostgreSQL

Question

[HiltoN]

Решил сравнить производительность указанных БД для нескольких болльших плоских таблиц и простейших запросов (по ключу, по индексу и т.п.). Представил одинаковую предметную область — очередь сообщений: для SQLite и PostgreSQL это одинаковые схемы, для Redis использовались сортированные списки, т.к. другие варианты хранения не подошли для описанной задачи. Запросы: поиск сообщения по ключу, удаление сообщения по ключу из очереди, выборка сообщений старше n минут, выборка и удаление сообщения из начала очереди.

10 млн строк, все базы занимают почти по 2 ГБ (больше к сожалению не было RAM). Результат: если база влазит в память, то скорость выполнения запросов примерна одинакова для разных «СУБД» (простые операции — около 3000 операций в секунду, посложнее — около 600). В чём же тогда прелесть Redis-а? Понимаю, что он подходит для узконаправленных задач, например, только поиск по ключу, т.е. для ограниченных по размеру кешей. В остальном одни минусы: и за памятью следи, чтобы база влезала в RAM (PG же просто замедлиться перейдя к дисковому чтению, Redis же начнёт свопится); и набор команд и типов данных ограничен.

PS: Что вы используете для надёжного перманентного хранения данных и быстрого выполнения простых запросов? Холивар PG vs MySQL можно опустить, разницы между ними практически не будет.

Answer 1

[Maxim Avanov]

1. В Redis лучше представлена работа с коллекциями. Простой пример — инкрементальный счётчик. Вы делаете incrby/hincrby для любого ключа, не заботясь о его наличие в хранилище. В Postgres аналогичная функциональность на основе последовательностей (nextval('foo')) подразумевает, что вы уже создали последовательность 'foo' ранее. Это подталкивает вас на написание процедур, которые перед попыткой изменить счётчик, сначала проверяют его наличие, при необходимости создают его и только потом изменяют. Больше ручной работы.

2. Структуры данных в Redis оптимизированы либо под быстрый поик О(1), либо под компактность и приемлемую произволительность O(N), O(log(N)). Практически всегда получается обходиться простыми или вложенными хеш-таблицами с О(1) или О(n). В Postgres вы практически всегда пользуетесь той или иной разновидностью B/R-tree, GiST/GIN индексов со сложностью O(log(N)(+N)). До версии 8.4, индексы типа HASH в Postgres имели практически схожую с B-tree скорость поиска, поэтому их применение не имело никакого смысла. Сейчас, в версии 9.1, смысла стало больше, но не намного — HASH индексы не поддерживают Write-Ahead Log и при сбоях требуют ручной переиндексации:
"Hash index operations are not presently WAL-logged, so hash indexes might need to be rebuilt with REINDEX after a database crash. They are also not replicated over streaming or file-based replication. For these reasons, hash index use is presently discouraged." http://www.postgresql.org/docs/9.1/static/indexes-types.html

У себя в проектах, я использую и Redis, и Postgres. Первый — как эффективную систему для сбора онлайн-статистики (счетчики-лайки, различные метрики), а второй — как хранилище для пользовательских аккаунтов и контента с его мета-информацией. При этом, наметилась тенденция переносить контент на HBase, оставляя для Postgres только задачи по ACID-обслуживанию операций с пользовательскими аккаунтами.

Answer 2

[CKOPOBAPKuH]

Молоток vs Кувалда vs Отвёртка

Я решил выяснить, какой из инструментов лучше. Представил одинаковую задачу — ударять себя по большому пальцу ноги. Отвёртку решил держать за ручку и ударять наконечником, так как неудобно держать за наконечник и ударять ручкой. Для молотка и кувалды это одинаковые схемы. Запросы: ударить по большому пальцу и измерить время, сколько болит.

Результат: если ударить больно, то палец болит. В чём же тогда прелесть отвёртки? Понимаю, что она подходит для узконаправленных задач, например, только откручивание или закручивание, т.е. для ограниченных задач. В остальном одни минусы: и держать неудобно, и площадь поражения невелика, и по пальцу я попал только с третьего раза.

PS: Что вы используете для надёжного перманентного отбивания пальцев? Холивар классический русский молоток vs молоток из икеи можно опустить, разницы между ними практически не будет.

Comments

[HiltoN]

Спасибо, повеселили.
И тем не менее задача не из головы, а реальная и каждый инструмент неплохо стравился с задачей и по-моему все они при примерно равных весовых категориях (я же не сравнивал с ораклом), но с немного отличающимся функционалом (т.е. часть функционала используется для решения задачи, часть нет). По вашему не бывает задач, которые успешно решаются несколькими способами? Или вы думаете что для конкретной задачи есть идеальный инструмент в котором напрочь отсутсвует лишняя функциональность?

[CKOPOBAPKuH]

SQLite — встраиваемая база. её можно скорее всего сравнивать с другими встраиваемыми базами. kyoto/tokio cabinet например.
Postgres/mysql и redis — разные весовые категории, у одних есть транзакции, тьюринг-полный sql, гарантированная консистентность, работа с данными которые значительно превышают объём ram и куча других штук, и redis, то есть простейшие структуры данных лежащие в оперативке + небольшой слой для поддержания персистентности.

вы декларировали цель «сравнить производительность указанных БД для нескольких болльших плоских таблиц и простейших запросов».
ваша задача, даже если бы все меряли правильно, не поможет узнать «производительность больших плоских таблиц и простейших запросов». и к очереди она не имеет никакого отношения, потому что у очереди есть ровно 2 операции: «взять» и «положить».
и это не говоря уже о том, что понятие «производительность» очень широкое и его можно трактовать как угодно. некоторые меряют скорость работы единичных аналитических запросов, которые выполняются десятки минут. некоторые меряют время отклика определенного количества мелких запросов с определенного количества потоков. некоторые меряют максимально возможное количество мелких запросов но чтобы время отклика не превышало пороговое, а количество одновременных запросов подбирают.

а что меряете вы? вы меряете задержки у единичных неконкурентных запросов. померяли. результаты ожидаемы.

[HiltoN]

> «производительность больших плоских таблиц и простейших запросов».
> и к очереди она не имеет никакого отношения, потому что у очереди
> есть ровно 2 операции: «взять» и «положить».
Очередь — очень большая, сотни миллионов строк. Отсюда и слова про большую проскую таблицу. И кроме положить и взять (брать кстати нужно с начала очереди), нужно ещё — взять всё что накопилось за N минут + убрать всё это после обработки. И желательно делать это в нескольких потоках, т.е. быть уверенным что только ты взял этот элемент с очереди. И да, мои тесты примитивные, но отвечают на один из моих вопросов — сколько операций в секунду даст выполнить база когда к ней будут обращаться с одного потока.

[CKOPOBAPKuH]

> сколько операций в секунду даст выполнить база когда к ней будут обращаться с одного потока
> сравнить производительность указанных БД для нескольких болльших плоских таблиц и простейших запросов

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

Answer 3

[Stdit]

Помимо РСУБД, мы используем MongoDB. Замечательная и быстрая штука, которая позволяет хранить коллекции из деревьев любой формы, строить индексы по любым их узлам, легко масштабируется горизонтально, имеет довольно мощную систему запросов на чтение и обновление. Недостаток — отсутствие джойнов, проблемы с агрегацией, они решаются путём предварительной агрегации при изменении данных или переучётом по крону.

Comments

[HiltoN]

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

Про недостаток в виде отсутсвия джойнов — вы ещё наверное с Redis-ом не знакомы, он даже по значениям искать не умеет, лишь по ключам.

[Stdit]

Replica Set очень хороша, можно даже сделать на одной машине на разных портах (хотя я и делал всегда на разных)

[Stdit]

В смысле, машинах

[Stdit]

Да, и вот ещё что подумал: если вам так нужна надёжность, в чём проблема открыть дополнительную вдску?

[cystbear]

Single machine durability резко возрос в MongoDB после версии 1.6. Вот полезная статья на эту тему www.thebuzzmedia.com/mongodb-single-server-data-durability-guide/

[Zelgadis]

Так, во первых join'ы не нужный в mongo, встраиваемые документы и DBRef наше все. А во вторых, в mongo уже давно есть журнал изменений и он включен по-умолчанию. А Replica Set имеет смысл только если 3 разных машины иначе это не Replica Set.

[Stdit]

Join нужны, например, когда надо запросить все документы, у которых во вложенном документе (через DBRef) значение поля удовлетворяет какому-то условию. В Mongo это можно сделать только запросив сначала все вложенные через DBRef документы по условию, а потом запросив $in-ом родителей по получившимся DBRef-ам. Это может быть весьма затратно при большом количестве связей.

[Zelgadis]

Все же большая часть проблем решает встраиванием и индексом на DBRef. Если все же нужен Join — а тут ли инструмент вы используете? или а правильно ли вы сделали дизаин приложения? Нельзя же реляционую модель мышление на монгу накладывать.

[Stdit]

Никто не говорит о том, правильно ли сделан выбор. Невозможность джойнов — это особенность Mongo, которую нужно иметь в виду при выборе субд, вот и всё.

Answer 4

[Алексей Сундуков]

>В чём же тогда прелесть Redis-а?
Данные всегда в ОЗУ, когда как в РСУБД индекс может быть вытесняться на диск, данные при этом на больших объемах почти всегда на диске. Поэтому и получаем просадку производительности из-за I/O на диске. В Redis это в принципе нет, они сейчас на сколько я помню от виртуальной памяти отказались. Про О(1) Ghostwriter уже сказал. ACID таки вносит свой оверхед.

Ну и из подобной группы ПО его выделяет условная персистентность.

Comments

[HiltoN]

alekciy, поясните почему условная. Разве включение AOF + fsync = always не делает её полностью персистентной?

[Алексей Сундуков]

Поэтому и условная. Что есть несколько вариантов синхронизации на диск и только один из них данные на диск пишет гарантированно. Но фишка в том, что его как раз использовать и не нужно ибо пропадает весь смысл, т.к. подскочит I/O по диску и просят по скорости. Благо в вебе потеря некоторых данных не критична, либо же копия данных есть гарантированно на диске через СУБД.

Answer 5

[HiltoN]

Если можно перефразирую вопрос: подскажите быструю персистентную базу, которая, желательно, целиком может мапиться в память, обеспечивать высокую надёжность в случае краха системы, работать на одной машине, поддерживать мультипоточность, желательна поддержка транзакционности. Остальные фишки не важны.

На мой взгляд все три описанные в сабже системы подходят под определение (если нет — исправляйте). Что ещё можете посоветовать?

Comments

[Maxim Avanov]

VoltDB (Wiki) Полноценный ACID, но тем не менее, в ней тоже рекомендуется иметь несколько физических машин. Из простого соображения, что без избыточности (версионности) данные не могут считаться надёжно сохраненными, поэтому их нужно физически размещать на нескольких нодах.

Answer 6

[gro]

где тесты?
параллельные запросы тестировали?

Comments

[HiltoN]

Тесты простейшие, без параллельных запросов, такого плана:

#!/usr/bin/python
import sqlite3
import random
from datetime import datetime

conn = sqlite3.connect('sqlite.db')
cur = conn.cursor()
startTime = datetime.now()
for i in range(1,1000):
	x = random.randint(1,10000000)
	cur.execute('SELECT * FROM t WHERE id=?', (x,))
	cur.fetchall()

print(datetime.now()-startTime)

#!/usr/bin/python
import redis
import random
from datetime import datetime

r = redis.StrictRedis(host='127.0.0.1', port=6379, db=0)
startTime = datetime.now()

for i in range(1,1000):
	x = random.randint(1,10000000)
	r.zscore('queue',x)

print(datetime.now()-startTime)

Answer 7

[Begetan]

1. О каких 3000 запросах в секунду идет речь? На тестовом Intel Atom 1,6 ГГц в скрипте на PHP я получил 12000 запросов в секунду GET/SET

2. Непонятно почему вы не использовали списки (Lists), которые по сути есть готовая реализация очереди?

Comments

[HiltoN]

2. Я использовал как раз списки, причём сортированные (ключ сортировки — timestamp), можно было конечно и простые списки, но по задаче нужны именно сортированные.
1. Наверное именно поэтому я и получил 3К вместо 12К, т.к. это не GET/SET, а ZRANGEBYSCORE и проч.