Комментарии 81
APIs and other access methods: proprietary protocol (RESP — REdis Serialization Protocol)
А не надо ему верить. RESP не проприетарный, и, как весь остальной Redis, идет под BSD. Вот описание протокола прямо на сайте: https://redis.io/topics/protocol
Боже мой.
Ваши тарантуло — редисы — эластксерчи и прочее НЕ ЯВЛЯЮТСЯ БД и/или СУБД это key/val хранилища данных. Что бы там они не умели они не удовлетворяют acid критериям.
OLTP — относится к реляционным субд. Ключевое слово Transaction. Какие, боже упаси транзакции в редисе? Те костыли, которые клепаются не являются полноценными транзакциями.
Что это за понятие такое "первичные" и "втоичные" индексы? Первичными бывают потенциальные ключи. Ключ — это не индекс. Ключ это ограничение целостности которое может быть связано с индексом.
Вторичных, третичных, четвертичных ключей и индексов не бывает.
Бывают кластерные, плотные и разряженные индексы. Быают первичные ключи, внешние ключи.
Это, если в терминах рсубд.
Поддержка lua это еще не хранимая процедура. В терминах рсубд. Это просто скрипт. Он отсутствует в метаданных и запускается как простой скрипт.
Итого по п 1
Вот это вы "разобрались"… Намешали в кучу всего что можно и нельзя.
п 2 тест…
Этапять… Вы попробуйте не циферки загружать, а нлрмальные объемы текстовых данных. И пусть тарантуло по ним ещё ваши индексы построит.
Репликация это не "если упал один узел"… Это называется stand-by в полноценных системах
Репликация это к распределенности системы.
Повышение стабильности и независимость узлов субд.
Что такое шардирование, почему и от чего — разбирайтесь сами, говорит нам автор.
Автор. Вторичных ключей, как и индексов тоже не бывает.
Redis и Tarantool — однопоточные базы данных, что не позволяет распараллелить аналитические запросы.
Полный привет. Каким боком вы определяете многопоточность с аналитическими запросами?
Итого. Что редис что тараниул это хранилища с натягиванием совы на глобус в виде неких транзакций.
Никаким боком они не могут заменить и быть конкурентом любой рсубд.
Однопоточность — основная причина быстродействия и невохможности обработки множества параллельных запросов.
Если начнут в многопоточность — превратятся в тыкву.
А уж in-memory таблицы есть у всех практически рсубд.
Как инструмент вспомогательный — удобно.
Как основа для хранения… боже уапаси.
Я только про одно утверждение спрошу: откуда такая категоричность, что "Вторичных… индексов не бывает."?
Кажется, вполне взрослый и понятный термин, разве нет? Я сперва хотел отправить в гугл с фразами "вторичный индекс" и "secondary index", но решил просто спросить: можно какие-нить ссылки, где про это же мнение (что их не бывает) почитать можно? Мне правда интересно.
Ответьте для себя на вопрос.
Что такое индекс. Каков его физический смысл.
И что такое "потенциальный ключ".
И вы поймёте, почему он не можеи быть первичным, а ключ — может.
А вообще в комменте моем написано отчего и почему
Если что то гуглится, то это не означает, что информация верна.
Ну я потому и попросил какие-то ссылки, чтобы это мнение еще где-то почитать.
Пока ваша позиция выглядит менее убедительно, чем у остальных комментаторов.
Если что то гуглится, то это не означает, что информация верна.
Может быть. Но может и не быть.
Какие ссылки? Открываем книгу. Напимер, Дейта — введение в Системы баз данных или Ульмана и вперед.
Параллельно изучаем документацию на уже существующие.
Послушайте. Позиции других комментаторов заключается в следующем: вот, я нагуглил, что кто-то где-то упомянул. Значит я прав. "
Простая копипаста. Это считается сейчас "весомым аргументом".
По тексту уже видно смешение терминов, которые нельзя заменять…
То индекс первичный, то ключ… Это вообще разные по смыслу, стрктуре и назначению вещи.
Такое их употребление говорит о непонимании этого. И так — многое.
Ваши тарантуло — редисы — эластксерчи и прочее НЕ ЯВЛЯЮТСЯ БД и/или СУБД
Даже Эксель вполне себе может являться СУБД, а экселевский файл — БД. Система алфавитного хранения книжек в школьной библиотеке — СУБД. Вы путаете СУБД и РСУБД.
Вторичных, третичных, четвертичных ключей и индексов не бывает.
dev.mysql.com/doc/refman/5.6/en/innodb-index-types.html
Вторичный индекс — вполне себе нормальный термин. Если вы привыкли к терминологии кластерных / некластерный индекс, то это вообще говоря ваша проблема.
Не может.
Изучите вопрос, что такое субд. Из чего состоит и как хранит информацию о БД.
К сожалению. Это проблема не моя. Это проблема того, кто не понимает физического смысла индексной структуры.
Так расскажите. Чем по вашему отличается "первичный" индекс от "вторичного".
Мне прямо интересно послушать именно вашу интерпретацию. Не ссылки на сайты, а ваше мнение.
dev.mysql.com/doc/refman/5.6/en/innodb-index-types.html
Вторичный индекс — вполне себе нормальный термин. Если вы привыкли к терминологии кластерных / некластерный индекс, то это вообще говоря ваша проблема.
Вообще, печально, что понятия смазываются и перепутываются, лет 15-20 назад были четкие и однозначные понятия и за такое запутывание, как в статье, автора бы долго били канделябром по голове. Решил погуглить, так в рунете теперь даже вторичные ключи с foreign ключами путают, которые, кстати, могут быть по полям вообще без индексов. В общем грустно ото всего этого.
По хорошему, индексы и ключи — это разные сущности, хотя да, как правило ключ это поле, или поля по которым построен индекс. Однако у них разные области применения.
И праймари кей не всегда обязан быть кластерным, например в Оракле его можно сделать некластерным, правда кластерный индекс все равно будет построен.
Индекс это отдельная структура, построенная по данным из таблицы. Индексов можно нафигачить сколько угодно, больше чем полей у таблицы и все они будут просто индексами.
Однако для того, чтоб мы могли однозначно идентифицировать запись в таблице, мы выбираем какое-то поле, или группу полей таблицы и говорим — это первичный ключ. В таком случае индекс по этому полю, или по этой группе полей, обязан содержать уникальные значения. То есть ключ это не физическая сущность, не отдельная структура, а больше логическая сущность, метка в нашей таблице. Вторичный ключ, это какое-то другое поле, или группа полей, которая тоже может использоваться для однозначного идентифицирования записей. Например, автоинкрекментное поле-идентификатор в таблице товаров это первичный ключ, а наименование товара — вторичный, у нас не должны быть разные товары с одинаковыми названиями.
А foreign ключи, это связи нашей таблицы с какими-то первичными ключами другой таблицы и в нашей таблице по полю foreign ключа может и не быть индекса вовсе.
Зачем путать понятия ключей и индексов, какой в этом смысл?
Вы все правильно написали.
Ммешались в кучу кони, люди…
"Redis поддерживает первичные индексы, не поддерживает вторичные"
И ниже
"В Tarantool можно строить произвольное количество вторичных индексов для данных:
Вторичные ключи могут состоять из нескольких полей."
И ниже
"Вывод
Вторичные ключи и удобные итераторы позволяют строить в Tarantool реляционные модели хранения данных. В Redis такую модель построить невозможно."
Я уж не говорю о" реляционной модели" без fk и каскадных операций.
Да там вообще все прекрасно
Про терминологию наверно ответа нет: и те и другие термины гугляться, у некоторых терминов контекст пересекается.
А уж in-memory таблицы есть у всех практически рсубд.
Как инструмент вспомогательный — удобно.
Как основа для хранения… боже уапаси.
Вот здесь, мне кажется, вы себя ограничиваете. И в redis и в tarantool выполнено надежное хранение in-memory таблиц, в redis чуть похуже архитектурно, в tarantool получше.
Вы не понимаете, почему их нельзя назвать субд?
Все дело не в какой то там "надежности" хранения в ОЗУ. Данные там живут ровно до момента выключения питания.
На этом вся "надежность" заканчивается. Чтобы обеспечить восстанавливаемость, нужно прибегать к чему? Правильно. К некоему энергонезависимому хранилищу.
Дамп же!
В субд для этого используется транзакционный лог. Чувствуете разницу?
Надежность в рамках субд это непротиворечивость данных. Понимаете? Каждый момент вркмени, сложно организованные данные в БД находятся в непротиворечивом сострянии.
Для этого и был создан механизм двухфазной фиксации транзакций.
Который умеет обрабатывать параллельно многие тысячи запросов в секунду… Разруливая все изменения, сохраняя целостность данных.
Что же могу предложить редис с тарантулом? Дамп? Если его сохранять часто при больших объемах данных и однопоточной архитектуре, то от производительности останется пшик. Так как дисковая система — та же, что и для обычной субд. Все запросы выстроятся в очередь, пока база скинет дамп… При большой входящей нагрузке и низких таймингах дампа кратно повышается риск потери целого или части данных. Исходя из практик эмуляции структур. В одном месте поменяли в 3 других не успели. Все. Превед медвед. Образовался артефакт. Данные находятся в противоречивом состоянии. Это я не говорю о том, что никаких ограничений на изменение данных в любом виде нет. От слова вообще. Что такое типы данных… Одна лишь строка.
Попробуй добавь кортеж в отношение произвольными данными в субд. Получится? Нет. А тут — на раз два.
Так что. Key value
В принципе — ничего нового. Именно это же есть в ораклине точно.
Кэш индексных структур? Он и так есть в любой субд. Или вы считаете, что каждый раз субд читает файлы?
Кэш таблиц в память? Тоже есть.
Брать терминологию рсубд и пытаться выдать связанные списки за полноценную субд — глупость.
Это очень нишевые инструменты. Да, они хорошо заточены для определенных целей. Но только для них.
Пытаться микроскопом гвозди забивать — глупо.
Спасибо за разъяснения, но их сложно соотнести конкретно с Redis и Tarantool.
Данные там живут ровно до момента выключения питания.
- И Redis и Tarantool имеют механизм записи всех транзакций в журнал прежде чем сгенерировать ответ клиентскому приложению.
Если его сохранять часто при больших объемах данных и однопоточной архитектуре, то от производительности останется пшик.
- И Redis и Tarantool периодически неблокирующе сохраняют снапшот in-memory данных. Redis с помощью fork, Tarantool с помощью read view.
in-memory архитектура хранит (не кеширует) сразу все данные и индексы в памяти, тем самым избавляясь от механизма кеширования/вытеснения страниц данных с диска/на диск. Какие именно данные уже зависит от архитектуры хранения конкретной БД.
Например, вы можете установить Tarantool и воспользоваться SQL, и соответствующими структурами как в традиционных РСУБД.
https://www.tarantool.io/en/doc/latest/reference/reference_sql/sql_beginners_guide/
Вы старательно обошли основную проблему — неротиворечивость данных.
Без ее решения все, о чем вы говорите не имеет весомого значения.
Хоть сколько сохраняйте дампы, если семантика данных нарушена, то считай данных и нет.
К слову. Как реализована модель бэкапа и можно ли восстановить данные на некий определенный момент.
Эх, жаль потерли эпичный тред на sql.ru про FVMas… Прям повеяло…
Redis fork механизм выполняет консистентный снапшот, потому что используется механизм OS copy-on-write.
Tarantool механизм также выполняет консистентный снапшот, потому что используется внутренний механизм read view.
При чем тут снапшот? Вопрос не о механической целостности, а о том, что в одинаковых структурах могут хранится разные по смыслу данные… Какой механизм предотвращения случайного или специального нарушения правил хранения?
В обычных, реляционных бд это само опреденюление отношения с предикатами и доменами, + ограничения целостности с внешними ключами, каскадированием и тд и тп
Такие механизмы в redis, tarantool решаются способами: или денормализацией, или логикой на аппсервере, или хранимыми процедурами
Вы опять говорите о другом.
Денормализация (опять какой то ацкий термин). Прямо как в школе. Честное слово.
Существует термин "нормалищация" это набор рекомендаций и правил позволяющий редуцировать объем данных и привести их в состояние логического непротиворечия (устранить неконтролируемую избыточность).
Для этого используется "декомпозиция" с участием семантического моделирования. Выделяются сущьности и связи. Определяются первичные и внешние ключи и прочие ограничения целостности, формируются домены и тд и тп.
Итогом этого процесса является набор отношений (сущностей) носителей строго определенных данных и никаких других с исключением артефактов (дублирований, отсутствия связанных значений и тд и тп).
И в идеале, при выполнени естесственного соединения (по естественным первисным ключам… о таком в ваших структурах даже и не мечтать… там все они суррогатные) получается исходный набор данных.
Так как этих механизмов в редисе и тарантуле и эластиксерче и тд нет…
То там просто нечего нормализовывать.
Все данные являются строками. Возможно в тарантуле встроена некое подобие хранения структур, но обеспечения их логической защишенности нет.
Вы поймите. Выполнение проверок внешней логикой это пролная провал. Субд отличается от этого тем, что хранит все металанные о базах данных в себе. Хранимые процедуры и функции, ограничения, сбор статистики, определение доменов, последовательностей, представления, триггеры описание отношений, самое важное — права доступа к операциям мутатораи и DDL… тд и тп…
В предлагаемых системах любой сторонний клиент моджет модифицировать любой блок данны как ему будет угодно и ни одна внешняя процедура не узнает об этом
А потом вы успешно сохраните ваш дамп. Ведь физически то он цел.
Думаем насчёт поддержки WSL2. Не буду прям обещать когда будет, но думаем.
Приходите в чат, у нескольких человек уже получалось запустить (под WSL), в том числе из наших разработчиков, так что это не очень сложно.
Можно использовать чужие решения, например https://github.com/igorcoding/tarantool-spacer как наиболее проработанное из мне известных.
Развивается инструмент миграций для Tarantool Cartridge: https://github.com/tarantool/migrations/
Как уже ответили: https://github.com/igorcoding/tarantool-spacer
И мигратор с интеграцией с Tarantool Cartridge со схожей семантикой: https://github.com/tarantool/migrations
В ентпрз решении используется авросхема с автоматической миграцией соответственно изменениям.
Если новый формат спэйса совместим с текущим, то его можно применить при инициализации приложения в space:format(). Например, добавить nullable поле в конец или поменять тип поля на совместимый.
Вторичные индексы можно добавлять так же при инициализации приложения с space::create_index(name, {if_not_exists = true}). Создание индекса не блокирует процесс, т.ч. под нагрузкой должно быть ок. Удалять индексы можно там же с index = space.index[name]; if index then index:drop() end. Вместо изменения индекса можно добавить новый, а старый удалить.
Надо подумать. Если я правильно помню Memcached с точки зрения k-v совсем скальпель: положил/забрал данные по ключу и всё. А вот сейчас заглянув в архитектурные доки увидел там мультипоточность и аллокаторы. Архитектурные сравнения это посложнее.
Начнём с того, что мемкэш — это кэш. А тарантул — надёжная персистентная бд
История тарантула как раз и начиналась с Memcached. Первым подходом было прикрутить к мемкешеду снапшоты, чтобы не стартовать с пустым кэшем. Потом был сильвербокс — уже полностью свое решение с транзакциями, снапшотами и wal. И уже на замену ему вырос тарантул.
Интересно было бы сравнить с производительностью ArangoDB на том же железе.
Дело в том что в ArangoDB первых версий были коллекции in memory от которых они в более поздних версиях отказались после очередной смены файлового хранилища так как обеспечивалась высокая скорость с исковой персистентностью.
Вы имеете ввиду сравнение дисковых движков тарантула и арангодб?
Поскольку arangodb отказалась от хранения в памяти то хотелось бы сравнить то что в памяти с у тарантула и релиса с тем что в файлах у arangodb. В известном смысле у редиса ведь тоже файловый стор есть. Но у него нет 100% надежности. Я даже столкнулся с тем что файловый стор редиса привел к отказам от обслуживания именно по диску. Так как в режиме были заданы умолчательные значения на сохранение на диск после обновления определенного количества ключей и какой то процесс начал слишком часто писать в редис. В результате сброс памяти в файл проходил несколько ко раз в секунду чем гьушил и процессор и диск.
У и arangodb в свою очередь память также существенного скол зуется так как есть отдельная операция загрузитььколлекцию в память. И до недавнего времени до версии 3.7 кажется при превышении коллекцией объема доступной памяти сервер просто останавливался
Ну и современного сравнения с Аэроспайк точно не помешало бы)
Или поставить базы на одинаковые машины с одинаковым количеством оперативки и начать пихать одинаковые данные и посмотреть в какую больше запихается.
выглядит так, что можно сделать:
set ip_str 0
expire ip_str 60потом на каждый приход ип адреса:
incr ip_strколичество обращений:
get ip_strне попал
Прямо как там в лоб и реализуем. Пишум в ключ ip+toSecond(время) плюс один при каждом обращении. ттл минута + небольшой запас на всякий случай.
Читаем все 60 ключей начиная от текущего времени. Суммируем и получаем результат.
Оптимизация: уменьшение детализации. Можно писать блоками секунд по пять десять.
В Redis используется однозадачность: задачи выполняются по одной и целиком.
Не совсем так, для IO другие треды юзаются:
Redis is, mostly, a single-threaded server from the POV of commands execution (actually modern versions of Redis use threads for different things)
redis.io/topics/benchmarks
И Redis, и Tarantool поддерживают асинхронную репликацию. Только Tarantool умеет в синхронную репликацию.Разве команда WAIT в Redis не является способом достижения синхронной репликации?
Претензия только в том что способ репликации определяется на стороне клиента, а не в конфигах сервера?
Команда wait в Redis и аналог в Tarantool — это «частично» синхронная репликация.
Представим:
- транзакция пришла
- лидер сохранил
- лидер ждёт реплику
- в это время кто-то пришел и уже транзакцию на лидере увидел
В этой ситуации у нас появляются грязные чтения. Синхронная репликация в этом плане работает лучше.
Титанически практический, на мой взгляд, труд об этом можно прочитать в этой статье:
Так лидер же однопоточный, пока не завершится wait, он другие команды выполнять не будет.
Кстати да.
Но есть ещё ограничение: нет ролбека в случае, если реплик мы не дождались. Ролбек можно конечно делать на апп уровне, но тогда может быть уже проще искать хранилище с полностью синхронной репликацией.
А для чего вообще ролбэк? Дальше, если реплики не доступные мы уже работать не можем, нужно вмешательство админа для разбора текущей ситуации. А если мы предполагаем, что все же можем работать далее через таймаут, то для чего нам синхронная репликация, RPO=0 значит не нужно, используем асинхронную репликацию и слежение за отставанием реплик.
Ролбек нужен, чтобы откатить данные, которые на лидере закомитились.
ИМХО, нужно восстанавливать репликацию (восстанавливать хост, сеть, или что там ещё мешает получить ответ лидеру), если нам нужно RPO=0. В момент не получения ответа от реплики нам не известно изменения применились ли на реплике, или применились, но ответ мы не получили. Данные между репликами становятся не согласованы, требуется полное восстановление данных с лидера на реплику если мы воспользуемся ролбэком, вместо ожидания подтверждения транзакции на реплике устраняя причину задержки.
1. Key-value — можно использовать и так, но гораздо чаще key используется для доступа к более сложным структурам данных внутри value, про которых тут написано мало: стеки, хэши, хэш + индекс, stream,… Redis действительно хранилище структур, а не значений.
2. Забыт stream — крайне полезная и эффективная структура, может т.ч. использоваться для логов и гарантированной доставки сообщений — готовая основа для оркестровки групп воркеров с балансировкой нагрузки из коробки, например.
3. Несколько open source плагинов от той же команды, фактически части Redis:
Search — вторичное индексирование и мощный поиск по содержимому хэшей а-ля эластик — c агрегацией, лексикой и т.д.
JSON — хранит бинарно, поддерживает Path и вторичное индексирование с поиском по множеству ключей.
И ещё time series, графы, гео,…
Да, типы данных в статье представлены куце. В Redis и Tarantool они немного ортогональны друг другу. В плагины залазить тоже пока что сложно. Надо подумоть над какими-то пересекающимися кейсами и правильным их сравнением.
Кстати, ещё момент — все 3 модуля, указанные в статье как Redis Enterprise, доступны и в виде open source — собираются и подключаются.
Единственный минус тут — нет готового докера со всеми батарейками сразу, или качаешь докер с редисом плюс один из них, либо голый редис и собирать и включать плагины.
Tarantool поддерживает: Создание брокера очередей
не очень корректно используется, посколько Redis тоже поддерживает как минимум 3 механизма (pub/sub, streams, sorted set (zadd/zpopmin) или rpoplpush)
Что Тарантул, что КокроучДБ — пример крайне неудачных с точки зрения маркетинга названий, которые не дают проектам нормально развиваться во всем остальном мире, к сожалению, как бы круты они ни были. Увы. Но ничего уже не сделать. Как бы ни была смешна эта причина, по моим наблюдениям, она работает очень сильно.
Более того (оффтопик), есть мнение, что Микрософт не смогла полностью захватить серверный мир и отъесть у Линукса бОльшую долю тоже во многом из-за названия своей ОС (Windows Server). Ну какие на сервере окна? Это же для бородатых сисадминов, которые господствовали в 90-х и 2000-х (помните, в те времена серверные ребята еще тоже назывались сисадминами, а не DevOps, как сейчас модно?) — так вот, это для них было как соль на рану: «я человек-командная-строка, мне окна противны». «Как вы яхту назовете, так она и поплывет», на удивление сильный стереотип.
Согласен, хотя facebook выстрелил (но оно скорее нейтральное).
У Тарантула есть «Cartridge» для построение приложений. Это название может оказаться более подходящим.
А Микрософт исправлились и выпустили XboX )
100%. Другой пример: мне кажется, существенная причина, по которая сейчас очень популярна TimescaleDB — название. Тут тебе и тайм, тут тебе скейл. Звучит круто. "Еще никого не уволили за то что потянул таймскейл в продакшен".
Я в таких случаях всегда вспоминаю Elba, менеджер пакетов для Idris
Гугл по "idris elba" не оставляет никаких шансов)
Есть пара миллиардов уникальных хэшей как первичный ключ, значения могут быть от 1 до 1000 других интовых id. Процессы — искать нужный хэш (тут нет проблем), добавлять id к существующей записи. Вот тут уже хочется волшебства, ибо доставать запись, если есть — добавлять новый id, обратно записывать — так себе КПД.
Без вытеснения, in-memory и с записью на диск.
И Redis и Tarantool такое умеют из коробки. Синтаксис Redis попроще, Tarantool более общий
redis-server # запуститьtarantool # запустить и сконфигурироватьtarantool>
box.cfg{listen='127.0.0.1:3301', wal_mode='none', memtx_memory=2*1024*1024*1024} box.schema.user.grant('guest', 'super', nil, nil, {if_not_exists=true,}) box.schema.space.create('kv', {if_not_exists=true,}) box.space.kv:create_index('pkey', {type='TREE', parts={{field=1, type='str'}}, if_not_exists=true,})
redis_test.go
package main import ( "context" "fmt" "log" "math/rand" "testing" "github.com/go-redis/redis" ) func BenchmarkSetRandomRedisParallel(b *testing.B) { client := redis.NewClient(&redis.Options{Addr: "127.0.0.1:6379", Password: "", DB: 0}) if _, err := client.Ping(context.Background()).Result(); err != nil { log.Fatal(err) } b.RunParallel(func(pb *testing.PB) { for pb.Next() { key := fmt.Sprintf("bench-%d", rand.Int31n(1000)) value := rand.Int31() _, err := client.RPush(context.Background(), key, value, 0).Result() if err != nil { b.Fatal(err) } } }) }
tarantool_test.go
package main import ( "fmt" "math/rand" "testing" "github.com/tarantool/go-tarantool" ) func BenchmarkSetRandomTntParallel(b *testing.B) { opts := tarantool.Opts{ User: "guest", } pconn, err := tarantool.Connect("127.0.0.1:3301", opts) if err != nil { b.Fatal(err) } b.RunParallel(func(pb *testing.PB) { for pb.Next() { key := fmt.Sprintf("bench-%d", rand.Int31n(1000)) value := rand.Int31() _, err = pconn.Upsert("kv", []interface{}{key, value}, []interface{}{[]interface{}{"!", 2, value}}) if err != nil { b.Fatal(err) } } }) }
Запуск на 10 секунд на 12 потоков
go test -cpu 12 -test.bench . -test.benchtime 10s
Результаты примерно равны
goos: darwin goarch: amd64 BenchmarkSetRandomRedisParallel-12 965875 14028 ns/op BenchmarkSetRandomTntParallel-12 955849 13928 ns/op PASS
У Redis для того, чтобы не доставать запись, существуют разные операции для таких вот структур данных
У Tarantool, чтобы не доставать данные, есть операции update,upsert. А если их не хватит то хранимки на LuaJIT.
Добавим хотелок по полной, а если надо хранить два инта
hash-a={111{11}},{222{22}},{333{33}}
hash-b={111{44}},{222{55}}
Первый int неуникальный, хочется иметь на него индекс и искать по нему. Это возможно?
Второй вопрос — в редисе/тарантуле можно сделать а ля мускуль select * если вдруг надо будет пройтись по всем записям?
unique = false. www.tarantool.io/ru/doc/latest/reference/reference_lua/box_space/create_indexВ тарантуле для прохода по всем записям можно сделать
box.space.space_name:pairs()box.space.space_name:select()box.space.space_name:pairs():totable()selectfiber.yield()Такой вид задачи и в Redis и в Tarantool удобнее решать через две таблицы:
- первая hash-a={ids}
- вторая id={values}
То есть суть сведётся к предыдущему тесту
В тарантуле есть multikey индексы — одна запись может быть проиндексирована по нескольким значениям. Документации не могу точной найти, но вот тут что-то есть https://www.tarantool.io/en/doc/latest/reference/reference_lua/box_space/create_index/#box-space-path-multikey. Судя по примеру, можно указать сразу json-path до поля c несколькими значениями.
Я в лоб накидал схему на Redis и Tarantool:
Два insert-а в Redis
Один insert в Tarantool
redis_test.go
package main import ( "context" "fmt" "log" "math/rand" "testing" "github.com/go-redis/redis" ) func BenchmarkSetRandomRedisParallel(b *testing.B) { client := redis.NewClient(&redis.Options{Addr: "127.0.0.1:6379", Password: "", DB: 0}) if _, err := client.Ping(context.Background()).Result(); err != nil { log.Fatal(err) } b.RunParallel(func(pb *testing.PB) { for pb.Next() { key := fmt.Sprintf("bench-%d", rand.Int31n(1000)) id := rand.Int31() value := rand.Int31() idstr := fmt.Sprintf("%d", id) valstr := fmt.Sprintf("%d", value) // INSERT _, err := client.HSet(context.Background(), key, idstr, valstr).Result() if err != nil { b.Fatal(err) } _, err = client.SAdd(context.Background(), idstr, key, 0).Result() if err != nil { b.Fatal(err) } } }) } func BenchmarkGetRandomRedisParallel(b *testing.B) { client := redis.NewClient(&redis.Options{Addr: "127.0.0.1:6379", Password: "", DB: 0}) if _, err := client.Ping(context.Background()).Result(); err != nil { log.Fatal(err) } b.RunParallel(func(pb *testing.PB) { for pb.Next() { id := rand.Int31() idstr := fmt.Sprintf("%d", id) _, err := client.SMembers(context.Background(), idstr).Result() if err != nil { b.Fatal(err) } } }) }
tarantool
tarantool>
box.cfg{listen='127.0.0.1:3301', wal_mode='none', memtx_memory=2*1024*1024*1024, readahead=1024*1024*16} box.schema.user.grant('guest', 'super', nil, nil, {if_not_exists=true,}) box.schema.space.create('kv', {if_not_exists=true,}) box.space.kv:create_index('pkey', {type='TREE', parts={{field=1, type='str'}, {field=2, type='unsigned'}}, if_not_exists=true,}) box.space.kv:create_index('skey', {type='TREE', parts={{field=2, type='unsigned'}}, unique=false, if_not_exists=true,})
tarantool_test.go
package main import ( "fmt" "math/rand" "testing" "github.com/tarantool/go-tarantool" ) func BenchmarkSetRandomTntParallel(b *testing.B) { opts := tarantool.Opts{ User: "guest", } pconn, err := tarantool.Connect("127.0.0.1:3301", opts) if err != nil { b.Fatal(err) } b.RunParallel(func(pb *testing.PB) { for pb.Next() { key := fmt.Sprintf("bench-%d", rand.Int31n(1000)) id := rand.Int31() value := rand.Int31() _, err = pconn.Replace("kv", []interface{}{key, id, value}) if err != nil { b.Fatal(err) } } }) } func BenchmarkGetRandomTntParallel(b *testing.B) { opts := tarantool.Opts{ User: "guest", } pconn, err := tarantool.Connect("127.0.0.1:3301", opts) if err != nil { b.Fatal(err) } b.RunParallel(func(pb *testing.PB) { for pb.Next() { id := rand.Int31() _, err = pconn.Select("kv", "skey", 0, 10000, tarantool.IterEq, []interface{}{id}) if err != nil { b.Fatal(err) } } }) }
Тесты
go test -cpu 12 -test.bench . -test.benchtime 10s
goos: darwin
goarch: amd64
BenchmarkSetRandomRedisParallel-12 409393 39018 ns/op
BenchmarkGetRandomRedisParallel-12 768824 15063 ns/op
BenchmarkSetRandomTntParallel-12 781621 16820 ns/op
BenchmarkGetRandomTntParallel-12 858226 13462 ns/op
PASS
ok _/Users/michael.filonenko/course/tmp 53.643sВывод:
В Redis приходится делать два инсерта.
В Tarantool один, и Tarantool поэтому быстрее.
А еще такой вопрос, а какой оверхед у них на хранение? Если в моем случае будет 2 миллиарда хешей по 8 байт и внутри, ну пусть по 10 интов, сколько все это будет реально занимать памяти?
1млн хешей (миллиарды долго ждать)
redis_test.go
package main import ( "context" "log" "math/rand" "strconv" "testing" "github.com/go-redis/redis" ) func lpad(s string, pad string, plength int) string { for i := len(s); i < plength; i++ { s = pad + s } return s } func BenchmarkSetRandomRedis(b *testing.B) { client := redis.NewClient(&redis.Options{Addr: "127.0.0.1:6379", Password: "", DB: 0}) if _, err := client.Ping(context.Background()).Result(); err != nil { log.Fatal(err) } for n := uint64(1); n < 1e6; n++ { key := strconv.FormatUint(n, 16) key = lpad(key, "0", 8) pipe := client.Pipeline() for i := 1; i < 11; i++ { id := rand.Int31() pipe.LPush(context.Background(), key, id) } _, err := pipe.Exec(context.Background()) if err != nil { log.Fatal(err) } } }
tarantool
tarantool>
box.cfg{listen='127.0.0.1:3301', wal_mode='none', memtx_memory=2*1024*1024*1024, readahead=1024*1024*16} box.schema.user.grant('guest', 'super', nil, nil, {if_not_exists=true,}) box.schema.space.create('kv', {if_not_exists=true,}) box.space.kv:create_index('pkey', {type='TREE', parts={{field=1, type='str'}, {field=2, type='unsigned'}}, if_not_exists=true,}) box.space.kv:create_index('skey', {type='TREE', parts={{field=2, type='unsigned'}}, unique=false, if_not_exists=true,})
tarantool_test.go
package main import ( "math/rand" "strconv" "testing" "github.com/tarantool/go-tarantool" ) func BenchmarkSetRandomTarantool(b *testing.B) { opts := tarantool.Opts{ User: "guest", } pconn, err := tarantool.Connect("127.0.0.1:3301", opts) if err != nil { b.Fatal(err) } for n := uint64(1); n < 1e6; n++ { key := strconv.FormatUint(n, 16) key = lpad(key, "0", 8) for i := 1; i < 11; i++ { id := rand.Int31() _, err = pconn.Replace("kv", []interface{}{key, id}) if err != nil { b.Fatal(err) } } } }
Тесты
go test -cpu 12 -test.bench .
redis
- info
# Memory used_memory:233454512 used_memory_human:222.64M used_memory_rss:169279488 used_memory_rss_human:161.44M used_memory_peak:233469968 used_memory_peak_human:222.65M used_memory_peak_perc:99.99% used_memory_overhead:49407608 used_memory_startup:1001600 used_memory_dataset:184046904 used_memory_dataset_perc:79.18%
- info
tarantool вместе со вторичными индексами
- box.slab.info()
items_size: 357184240 items_used_ratio: 99.86% quota_size: 2147483648 quota_used_ratio: 35.16% arena_used_ratio: 96.9% items_used: 356685848 quota_used: 754974720 arena_size: 754974720 arena_used: 731944984 ... - box.slab.info().arena_used/1024/1024
782
- box.slab.info()
Вывод:
- redis used_memory_human:222.64M
- tarantool: 782
- Tarantool занимает побольше в том числе за счёт вторичного индекса
- В Tarantool можно (нужно) отключить индекс хинты, которые снизят потребление памяти
Tarantool vs Redis: что умеют in-memory технологии