URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 92834
[ Назад ]

Исходное сообщение
"Выпуск БД Redis 2.8"

Отправлено opennews , 26-Ноя-13 12:54 
После года разработки увидел свет (https://groups.google.com/forum/#!msg/redis-db/37xgI268Nh8/G...) релиз новой стабильной ветки БД Redis 2.8 (http://redis.io/), относящейся к классу NoSQL-систем и развиваемой при содействии компании VMware (следом за первым выпуском 2.8.0 оперативно сформирован корректирующий выпуск 2.8.1). Redis предоставляет похожие на Memcached функции для хранения данных в формате ключ/значение, расширенные поддержкой структурированных форматов данных, таких как списки, хэши и множества, а также возможностью выполнения на стороне сервера скриптов-обработчиков на языке Lua. В отличие от Memcached, Redis обеспечивает постоянное хранение данных на диске и гарантирует сохранность БД в случае аварийного завершения работы.  Исходные тексты проекта распространяются в рамках лицензии BSD. Клиентские библиотеки доступны для большинства популярных языков, включая Perl, Python, PHP, Java, Ruby и Tcl.

Имеется поддержка транзакций, позволяющих выполнить за один шаг группу команд, гарантируя непротиворечивость и последовательность (команды от других запросов не могут вклиниться) выполнения заданного набора команд, а в случае проблем позволяя откатить изменения. Все данные в полном объёме кэшируются в оперативной памяти. Хранение всех данных в оперативной памяти позволяет добиться значительной производительности: при тестировании Redis на сервере с CPU Xeon X3320 2.5 ГГц удалось обеспечить (http://redis.io/topics/benchmarks) 100 тысяч операций записи и чтения в секунду.

Для управления данными поддерживаются такие команды, как инкремент/декремент, стандартные операции над списками и множествами (объединение, пересечение), переименование ключей, множественные выборки и функции сортировки. Поддерживается два режима хранения: периодическая синхронизация данных на диск и ведение на диске лога изменений. Во втором случае гарантируется полная сохранность всех изменений. Возможна организация master-slave репликации данных на несколько серверов, осуществляемая в неблокирующем режиме. Доступен также режим обмена сообщениями "публикация/подписка", при котором создаётся канал, сообщения из которого распространяются клиентам по подписке.

Ключевые улучшения (https://raw.github.com/antirez/redis/2.8/00-RELEASENOTES), добавленные в Redis 2.8:


-  Режим частичной ресинхронизации сo slave-серверами (PSYNC (http://antirez.com/news/47)), позволяющий избежать передачи полного набора данных от master-сервера к slave-системе после кратковременного прерывания связи;
-  Новые команды: SCAN, HSCAN, SSCAN и ZSCAN (http://redis.io/commands/scan)  для перебора элементов в коллекциях, хэшах, множествах и отсортированных множествах. Формат команд:  "SCAN cursor [MATCH pattern] [COUNT count]", через параметр MATCH возможна выборка по маске (например, "scan 52 MATCH key:1*");
-  Переписана (http://antirez.com/news/54) система конфигурации  Redis. Добавлена команда "CONFIG REWRITE", позволяющая сохранить в конфигурационном файле изменения, внесённые на лету в процессе использования команды "CONFIG SET";
-  Поддержка IPv6;
-  Улучшена поддержка скриптинга на стороне сервера. Добавлена команда  EVALSHA, аналогичная EVAL за исключением того, что производится выполнение прокэшированных на сервере скриптов  по связанному с ними хэшу SHA1 (для помещения скрипта в кэш следует использовать команду SCRIPT LOAD);
-  Улучшен алгоритм расчёта времени истечения жизни ключей;
-  В режиме обмена сообщениями "публикация/подписка" обеспечена (http://redis.io/topics/notifications) поддержка уведомления о поступлении событий об изменениях в пространстве ключей. Например, можно подписаться на события о выполнении команд с определённым ключом, истечении жизни ключей или выполнении над ключами операции LPUSH;


-  Улучшение средств по обеспечению непротиворечивости хранимых данных за счёт возможности приостановить операции записи в случае, если не удалось выявить достаточного числа slave-серверов, укладывающихся в установленные лимиты отзывчивости;

-  Полностью переписан код  Redis Sentinel (http://redis.io/topics/sentinel), системы для управления, мониторинга и обеспечена отказоустойчивости БД Redis.

URL: https://groups.google.com/forum/#!msg/redis-db/37xgI268Nh8/G...
Новость: http://www.opennet.me/opennews/art.shtml?num=38522


Содержание

Сообщения в этом обсуждении
"Выпуск БД Redis 2.8"
Отправлено Guest , 26-Ноя-13 12:54 
Кто в курсе, не возьму в толк, почему всё так сконцентрировалось вокруг баз с функционалом ключ/значение? Для чего они?
До сих пор имел дело только с реляционными.

"Выпуск БД Redis 2.8"
Отправлено arisu , 26-Ноя-13 12:55 
> Для чего они?

для удобного хранения пар ключ/значение.


"Выпуск БД Redis 2.8"
Отправлено qqqqq , 27-Ноя-13 14:59 
а пара "SQL запрос" -> "результат" чем не пара ключ-значение. Видишь ли это просто другая форма мышления.

"Выпуск БД Redis 2.8"
Отправлено arisu , 28-Ноя-13 01:50 
> а пара «SQL запрос» -> «результат» чем не пара ключ-значение.

тем, что в этом случае вклинивается как минимум один промежуточный слой — sql vm (и парзер, если это не precompiled statement). а на самом деле — больше слоёв. и всё только для того, чтобы в конце концов добраться до какого-нибудь b+ дерева. «nosql» (не люблю этот термин, ну да ладно) как раз промежуточные слои исключают.

всё вышесказаное, конечно, не означает «выкидываем sql, он не нужен!» каждому инструменту — своя ниша и своё применение.


"Выпуск БД Redis 2.8"
Отправлено badger , 28-Ноя-13 02:12 
а пара "SQL запрос" -> "результат" тем не пара ключ-значение, что в общем случае одному ключу соответствует много значений

"Выпуск БД Redis 2.8"
Отправлено none_first , 26-Ноя-13 12:57 
большинство бизнес процессов сложно/невозможно (без допущений и костылей) вписать в реляционную схему...
переменное число характеристик порождает доп. сущности в РСУБД
для отчетов, РСУБД - самое оно

"Выпуск БД Redis 2.8"
Отправлено NikolayV81 , 26-Ноя-13 13:51 
В ключ-значение "бизнес" процессы вообще с такими костылями ложатся, что почти никто не пытается, а вот во всяких личных страничках на сайтах ( большие соц. сети ), где за неверную ссылку голову никто не оторвёт, а время загрузки критично, можно хоть всю личную страницу пользователя в один отвязанный от окружающего мира объект запихивать, и загружать только его, а потом уже после отработки "показали клиенту его страничку" проверять валидность данных и их доступность по ссылкам.

"Выпуск БД Redis 2.8"
Отправлено none_first , 26-Ноя-13 14:07 
одной из первых БД документооборота была Lotus Notes, кот. (вопщем) и является БД ключ/значение (при условии, что понятие "значение" несколько более расширено ;) )
и воркфло - прекрасно строится на этой платформе
попытка же ИБМ прикрутить DB2 (РСУБД) к домине, не увенчалась успехом и именно по причине костыльности реализации http://forum.codeby.net/topic22892.html?view=findpost&p=109606
т.е. реализовать-то можно - но это будет не реляционная схема;)

"Выпуск БД Redis 2.8"
Отправлено NikolayV81 , 26-Ноя-13 14:57 
> одной из первых БД документооборота была Lotus Notes, кот. (вопщем) и является
> БД ключ/значение (при условии, что понятие "значение" несколько более расширено ;)
> )
> и воркфло - прекрасно строится на этой платформе
> попытка же ИБМ прикрутить DB2 (РСУБД) к домине, не увенчалась успехом и
> именно по причине костыльности реализации http://forum.codeby.net/topic22892.html?view=findpost&p=109606
> т.е. реализовать-то можно - но это будет не реляционная схема;)

Логика была запихана в клиентский модуль. С зависимостями, актуальностью, достоверностью данных и атомарностью операций проблемы.
1C Тоже с dbf начинало и что?

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


"Выпуск БД Redis 2.8"
Отправлено none_first , 26-Ноя-13 15:27 
>Логика была запихана в клиентский модуль. С зависимостями, актуальностью, достоверностью >данных и атомарностью операций проблемы.
>1C Тоже с dbf начинало и что?

и то - 1С не стала РСУБД (несмотря на использование "их" как подложки), у неё есть аппсервер, кот. и есть "костыль" к БД
атомарность в вокфло на каком уровне нужна и какими средствами, у сущ. в РСУБД, многозначные поля и разнотипные данные реализуются, в рамках одного документа?

и наборчик ёрпов:
САП - надстройка над РСУБД
Ахапта - тожсамое
...
"логика запихана в клиентский модуль";)


"Выпуск БД Redis 2.8"
Отправлено NikolayV81 , 26-Ноя-13 15:55 
>[оверквотинг удален]
> и то - 1С не стала РСУБД (несмотря на использование "их" как
> подложки), у неё есть аппсервер, кот. и есть "костыль" к БД
> атомарность в вокфло на каком уровне нужна и какими средствами, у сущ.
> в РСУБД, многозначные поля и разнотипные данные реализуются, в рамках одного
> документа?
> и наборчик ёрпов:
> САП - надстройка над РСУБД
> Ахапта - тожсамое
> ...
> "логика запихана в клиентский модуль";)

"многозначные поля и разнотипные данные реализуются" это какие данные? про те которые не нужны для обработки - реализация blob, если с первого раза не понятно. Если данные надо обрабатывать, искать, сортировать ( выбирать подборку документов по вложениям, характеристикам, то это вполне себе данные с конкретными типами ).

А так выберете из универсального key-value в котором контракты, все те которые в ценах на 13 июля имели добавленную стоимость более n-руб, в разрезе удалённых филиалов и которые были заключены менеджерами нанятыми начиная с 2009 года.

Трёхзвенная архитектура нужна по причине необходимости синхронизации между процессами, т.к. РСУБД не для этого, если это не нужно достаточно двухзвенки, а вот реализовывать в каждом приложении ( конкретной епр-ке ) механизмы дублирующие функционал БД ( всё те же транзакции, каскадные зависимости данных, типизированные справочники ) ещё то извращение.


"Выпуск БД Redis 2.8"
Отправлено none_first , 26-Ноя-13 16:55 
для чего я буду выбирать в диапазоне? - для отчета - дык про них и было сказано - там и нужны РСУБД
потому как отчет имеет четкую структуру - и это повод для интеграции, а не противопоставления

"Выпуск БД Redis 2.8"
Отправлено NikolayV81 , 26-Ноя-13 17:11 
> для чего я буду выбирать в диапазоне? - для отчета - дык
> про них и было сказано - там и нужны РСУБД
> потому как отчет имеет четкую структуру - и это повод для интеграции,
> а не противопоставления

Для формирования заказа, для расчёта остатков для чего угодно, именно в документообороте, а не в хранении и показе html-к с картинками ( записи трека gps, и вывода на карту )


"Выпуск БД Redis 2.8"
Отправлено none_first , 26-Ноя-13 19:46 
>Для формирования заказа, для расчёта остатков для чего угодно, именно в документообороте

ну очень абстрактно
для этого есть аппсервер (в любом раскладе), а уж как там реализовано...
даты и цифры - полюбасу м.б. ключами

а документооборот - это часто согласование, подписание, уведомления, рассылки, запуск порожденных "процессов" (циклов согласования)..., в этой области РСУБД ну никак "не видна"

а именно в таких процессах поля и документы могут динамически создаваться/наследоваться и быть различного типа


"Выпуск БД Redis 2.8"
Отправлено NikolayV81 , 27-Ноя-13 09:56 
> а именно в таких процессах поля и документы могут динамически создаваться/наследоваться
> и быть различного типа

Не может ( в реальности не должно ), если может то это уже не документооборот, а отсебятина, без нормальной логики, без модели поведения и без гарантии правильной обработки.
+добавлено+ хотя в жизни конечно бывает.

Это как в поле комментарий к заказу писать скидку, потому что её в начальной модели небыло, потом писать обработку скидки и т.д.

> для этого есть аппсервер (в любом раскладе), а уж как там реализовано...

Когда система падает ( да хоть таракан в сервер, хоть дефект производства кристалла процессора ) то в системе в которой целостность данных обеспечивается App. сервером часто наступают большие проблемы, а использование нормальной базы данных позволяет получить последнюю валидную копию рабочей системы.

>даты и цифры - полюбасу м.б. ключами

если у вас набор не связанных между собой ключей, это вам мало поможет, так как контролировать набор параметров которые должны быть заданы определённым образом для допустимости перехода в следующее состояние документа это фактически городить базу данных внутри App сервера.


"Выпуск БД Redis 2.8"
Отправлено Аноним , 26-Ноя-13 17:51 
> большинство бизнес процессов сложно/невозможно (без допущений и костылей) вписать в реляционную
> схему...
> переменное число характеристик порождает доп. сущности в РСУБД
> для отчетов, РСУБД - самое оно

Аффтар, ты в глаза видал такую книгу, как Ричард Баркер - "ER-modeling"?

У меня впечатление, что ты ни о бизнес-процессах, ни о реляционном моделировании ничего не слышал, ну, кроме названия, конечно.


"Выпуск БД Redis 2.8"
Отправлено none_first , 26-Ноя-13 19:48 
>> большинство бизнес процессов сложно/невозможно (без допущений и костылей) вписать в реляционную
>> схему...
>> переменное число характеристик порождает доп. сущности в РСУБД
>> для отчетов, РСУБД - самое оно
> Аффтар, ты в глаза видал такую книгу, как Ричард Баркер - "ER-modeling"?
> У меня впечатление, что ты ни о бизнес-процессах, ни о реляционном моделировании
> ничего не слышал, ну, кроме названия, конечно.

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


"Выпуск БД Redis 2.8"
Отправлено vitalif , 27-Ноя-13 19:51 
Это кстати вот как раз какое-то стильно-модно-молодёжное предубеждение, скажу я вам)

Если свалить все поля ваших классов кучей в редис - там вообще чёрт ногу сломит...


"Выпуск БД Redis 2.8"
Отправлено arisu , 28-Ноя-13 01:52 
есть ещё и такой секрет же (прямо тут о нём и писали, кажется): для key/value можно «сесть и кодить», не надо заморачиваться разработкой схемы хранения данных и взаимосвязей. ну и что, что оно потом так аукнется, что мало не покажется? это потом будет, а код рубить уже сейчас можно!

"Выпуск БД Redis 2.8"
Отправлено Grammar Nazi , 27-Ноя-13 19:54 
бизнес-процессов

"Выпуск БД Redis 2.8"
Отправлено Guest , 26-Ноя-13 13:01 
спасибо

кстати, интересную статью тему баз ключ/значение нашел:
http://habrahabr.ru/post/103021/


"Выпуск БД Redis 2.8"
Отправлено Аноним , 26-Ноя-13 13:17 
потому что хипсторы не осиливают теорию множеств и транзакции

"Выпуск БД Redis 2.8"
Отправлено Аноним , 26-Ноя-13 13:31 
Хыхы. Все написавшие выше не правы!
Ключ значение работает тупо на несколько порядков быстрее и хорошо маштабируется. Что сейчас очень востребовано.
Если бы реляционнки работали на уровне мемкеша, то ничего бы больше нужно бы небыло.

"Выпуск БД Redis 2.8"
Отправлено arisu , 26-Ноя-13 13:55 
> Ключ значение работает тупо на несколько порядков быстрее

…чего? ну вперёд, велосипедь сложные структуры данных со связями. посмотрю, за сколько ты навелосипедишь rdbms поверх key/value, и насколько оно в итоге будет тормозить.


"Выпуск БД Redis 2.8"
Отправлено edwin , 26-Ноя-13 19:54 
>> Ключ значение работает тупо на несколько порядков быстрее
> …чего? ну вперёд, велосипедь сложные структуры данных со связями. посмотрю, за сколько
> ты навелосипедишь rdbms поверх key/value, и насколько оно в итоге будет
> тормозить.

Это не задача key store хранилищ.
Что касается обозначенной Вами задачи .... РСУБД хороший инструмент с наработанными шаблонами. Но не единственный - если выйти за рамки реляционной модели - много вкусных плюшек ждут Вас. К примеру работа со сложными структурами ....
Подобного рода задачи решаются другими инструментами - таким классом решений как документ ориентированные БД. К примеру - MongoDB. Там есть на что посмотреть ...


"Выпуск БД Redis 2.8"
Отправлено metallica , 26-Ноя-13 23:17 
> Хыхы. Все написавшие выше не правы!
> Ключ значение работает тупо на несколько порядков быстрее и хорошо маштабируется. Что
> сейчас очень востребовано.
> Если бы реляционнки работали на уровне мемкеша, то ничего бы больше нужно
> бы небыло.

Эти ключ/значение базы для кеширования в памяти запросов к RDBMS backend обработчиками.
Чтоб не делать повторных запросов к sql базам.Если для какого-то представления
какой-то системы имеется модель данных в sql базе, и с разных клиентов поступают
запросы на получение этого представления, то бекенды его формируют, извлекая один и тот же
набор данных, относящиеся к соответствующей модели.Результат запроса к RDBMS сохраняется в
redis/memcached  под каким-то ключом, а backend обработчик сначала проверяет
наличие данных той или иной модели в redis/memcached и только при их отстутствии лезет
в RDBMS.  list=cache.get('MODEL_XXX','No')
          if list=='No':
           list = Model_XXX.objects.all()


"Выпуск БД Redis 2.8"
Отправлено Аноним , 27-Ноя-13 08:48 
КЭП? Интерактивные данные в кешить не вариант, тригерами будете их обновлять. Ваш вариан годится когда чтение сильно превышает запись и когда не важно время реального обновления данных у клиента.

"Выпуск БД Redis 2.8"
Отправлено NikolayV81 , 27-Ноя-13 10:03 
> КЭП? Интерактивные данные в кешить не вариант, тригерами будете их обновлять. Ваш
> вариан годится когда чтение сильно превышает запись и когда не важно
> время реального обновления данных у клиента.

Может имелось в виду типа App сервера что-то, если мы точно знаем что и где мы обновляем, ничто не мешает нам организовать кэш, правда такой же кэш может быть организован и в БД, так что геморрой с реализацией может перекрыть выигрыш во времени отклика.


"Выпуск БД Redis 2.8"
Отправлено metallica , 27-Ноя-13 11:11 

> Может имелось в виду типа App сервера

Стандартное MVC с ORM на java/python/ruby
> что и где мы обновляем

Каждая модель имеет уникальный символьный идентификактор и в СУБД и в кеше.
> правда такой же кэш может быть организован и в БД,

Есть возможности в фреймворках делать кеши в БД, но сохранение и извлечение
данных организовано тоже по принципу ключ/значение.
> что геморрой с реализацией

Дополнительные н несколько строчек кода.


"Выпуск БД Redis 2.8"
Отправлено metallica , 27-Ноя-13 11:03 
>когда чтение сильно превышает запись

Именно, когда читают куча клиентов, а пишут один два специализированных бекенда наполнителя
контента.


"Выпуск БД Redis 2.8"
Отправлено Аноним , 27-Ноя-13 16:59 
Хорошо, намажу толще.
В современном мире интерактива подход беспонтовый.

"Выпуск БД Redis 2.8"
Отправлено Grammar Nazi , 27-Ноя-13 19:56 
Ключ-значение
масштабируется
бы не было

"Выпуск БД Redis 2.8"
Отправлено Клыкастый , 26-Ноя-13 13:45 
а я вот часто имею дело с данными, которым на роду написано ключ/значение. И очень печально, когда разработчики запихивают это в sql.

"Выпуск БД Redis 2.8"
Отправлено Аноним , 26-Ноя-13 18:15 
Конкретные примеры, что у Вас отлично ложится в "ключ-значение"

"Выпуск БД Redis 2.8"
Отправлено edwin , 26-Ноя-13 19:34 
> Конкретные примеры, что у Вас отлично ложится в "ключ-значение"

Добрый день.
Зачем Вы так категоричны ? Вы ведь никогда не ездите в Камазе в магазин ?
Примеров - вагон. Для иллюстрации - хранение данных http сессий в key store хранилище.
РСУБД тут никаким боком не упала - не ее это уровень.


"Выпуск БД Redis 2.8"
Отправлено Клыкастый , 27-Ноя-13 10:55 
> Конкретные примеры, что у Вас отлично ложится в "ключ-значение"

SIP сессии например


"Выпуск БД Redis 2.8"
Отправлено Аноним , 26-Ноя-13 19:56 
> почему всё так сконцентрировалось вокруг баз с функционалом ключ/значение?

Потому что
1) Быстрые.
2) Большинство реализаций не боится Бобби Тэйблса.


"Выпуск БД Redis 2.8"
Отправлено Аноним , 26-Ноя-13 13:33 
Кластер так и не осилили? По сути самое важное что ожидалось от 2.8

"Выпуск БД Redis 2.8"
Отправлено Аноним , 26-Ноя-13 15:04 
no-SQL начинает рулить

"Выпуск БД Redis 2.8"
Отправлено arisu , 27-Ноя-13 01:30 
обычный инструмент, вообще-то.

"Выпуск БД Redis 2.8"
Отправлено Аноним , 26-Ноя-13 15:09 
Опять споры уровня, что лучше: рубить лес лопатой или копать ямы топором.

"Выпуск БД Redis 2.8"
Отправлено Аноним , 26-Ноя-13 19:58 
> Опять споры уровня, что лучше: рубить лес лопатой или копать ямы топором.

Это опеннет, детка. Здесь любят летать на боинге в магазин и пытаться лететь на самокате через океан.


"Выпуск БД Redis 2.8"
Отправлено edwin , 26-Ноя-13 19:24 
Sentinel - ИМХО один из ключевых моментов этой версии ... как по мне - стало стабильнее.

"Выпуск БД Redis 2.8"
Отправлено waf , 28-Ноя-13 18:27 
"Why you should never use MongoDB"
http://www.sarahmei.com/blog/2013/11/11/why-you-should-never.../
и то же в тезисном виде:
http://java.dzone.com/articles/you-definitely-shouldnt-use