После года разработки увидел свет (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...
Новость: https://www.opennet.ru/opennews/art.shtml?num=38522
Кто в курсе, не возьму в толк, почему всё так сконцентрировалось вокруг баз с функционалом ключ/значение? Для чего они?
До сих пор имел дело только с реляционными.
> Для чего они?для удобного хранения пар ключ/значение.
а пара "SQL запрос" -> "результат" чем не пара ключ-значение. Видишь ли это просто другая форма мышления.
> а пара «SQL запрос» -> «результат» чем не пара ключ-значение.тем, что в этом случае вклинивается как минимум один промежуточный слой — sql vm (и парзер, если это не precompiled statement). а на самом деле — больше слоёв. и всё только для того, чтобы в конце концов добраться до какого-нибудь b+ дерева. «nosql» (не люблю этот термин, ну да ладно) как раз промежуточные слои исключают.
всё вышесказаное, конечно, не означает «выкидываем sql, он не нужен!» каждому инструменту — своя ниша и своё применение.
а пара "SQL запрос" -> "результат" тем не пара ключ-значение, что в общем случае одному ключу соответствует много значений
большинство бизнес процессов сложно/невозможно (без допущений и костылей) вписать в реляционную схему...
переменное число характеристик порождает доп. сущности в РСУБД
для отчетов, РСУБД - самое оно
В ключ-значение "бизнес" процессы вообще с такими костылями ложатся, что почти никто не пытается, а вот во всяких личных страничках на сайтах ( большие соц. сети ), где за неверную ссылку голову никто не оторвёт, а время загрузки критично, можно хоть всю личную страницу пользователя в один отвязанный от окружающего мира объект запихивать, и загружать только его, а потом уже после отработки "показали клиенту его страничку" проверять валидность данных и их доступность по ссылкам.
одной из первых БД документооборота была Lotus Notes, кот. (вопщем) и является БД ключ/значение (при условии, что понятие "значение" несколько более расширено ;) )
и воркфло - прекрасно строится на этой платформе
попытка же ИБМ прикрутить DB2 (РСУБД) к домине, не увенчалась успехом и именно по причине костыльности реализации http://forum.codeby.net/topic22892.html?view=findpost&p=109606
т.е. реализовать-то можно - но это будет не реляционная схема;)
> одной из первых БД документооборота была Lotus Notes, кот. (вопщем) и является
> БД ключ/значение (при условии, что понятие "значение" несколько более расширено ;)
> )
> и воркфло - прекрасно строится на этой платформе
> попытка же ИБМ прикрутить DB2 (РСУБД) к домине, не увенчалась успехом и
> именно по причине костыльности реализации http://forum.codeby.net/topic22892.html?view=findpost&p=109606
> т.е. реализовать-то можно - но это будет не реляционная схема;)Логика была запихана в клиентский модуль. С зависимостями, актуальностью, достоверностью данных и атомарностью операций проблемы.
1C Тоже с dbf начинало и что?По поводу ссылки, высосанная из пальца задача, данные которые не нужно обрабатывать, нет смысла хранить, если это результирующий отчёт, то его нужно формировать, и возможно фиксировать в те же blob поля (любой тип туда влазит, аналог не типизированного value).
>Логика была запихана в клиентский модуль. С зависимостями, актуальностью, достоверностью >данных и атомарностью операций проблемы.
>1C Тоже с dbf начинало и что?и то - 1С не стала РСУБД (несмотря на использование "их" как подложки), у неё есть аппсервер, кот. и есть "костыль" к БД
атомарность в вокфло на каком уровне нужна и какими средствами, у сущ. в РСУБД, многозначные поля и разнотипные данные реализуются, в рамках одного документа?и наборчик ёрпов:
САП - надстройка над РСУБД
Ахапта - тожсамое
...
"логика запихана в клиентский модуль";)
>[оверквотинг удален]
> и то - 1С не стала РСУБД (несмотря на использование "их" как
> подложки), у неё есть аппсервер, кот. и есть "костыль" к БД
> атомарность в вокфло на каком уровне нужна и какими средствами, у сущ.
> в РСУБД, многозначные поля и разнотипные данные реализуются, в рамках одного
> документа?
> и наборчик ёрпов:
> САП - надстройка над РСУБД
> Ахапта - тожсамое
> ...
> "логика запихана в клиентский модуль";)"многозначные поля и разнотипные данные реализуются" это какие данные? про те которые не нужны для обработки - реализация blob, если с первого раза не понятно. Если данные надо обрабатывать, искать, сортировать ( выбирать подборку документов по вложениям, характеристикам, то это вполне себе данные с конкретными типами ).
А так выберете из универсального key-value в котором контракты, все те которые в ценах на 13 июля имели добавленную стоимость более n-руб, в разрезе удалённых филиалов и которые были заключены менеджерами нанятыми начиная с 2009 года.
Трёхзвенная архитектура нужна по причине необходимости синхронизации между процессами, т.к. РСУБД не для этого, если это не нужно достаточно двухзвенки, а вот реализовывать в каждом приложении ( конкретной епр-ке ) механизмы дублирующие функционал БД ( всё те же транзакции, каскадные зависимости данных, типизированные справочники ) ещё то извращение.
для чего я буду выбирать в диапазоне? - для отчета - дык про них и было сказано - там и нужны РСУБД
потому как отчет имеет четкую структуру - и это повод для интеграции, а не противопоставления
> для чего я буду выбирать в диапазоне? - для отчета - дык
> про них и было сказано - там и нужны РСУБД
> потому как отчет имеет четкую структуру - и это повод для интеграции,
> а не противопоставленияДля формирования заказа, для расчёта остатков для чего угодно, именно в документообороте, а не в хранении и показе html-к с картинками ( записи трека gps, и вывода на карту )
>Для формирования заказа, для расчёта остатков для чего угодно, именно в документооборотену очень абстрактно
для этого есть аппсервер (в любом раскладе), а уж как там реализовано...
даты и цифры - полюбасу м.б. ключамиа документооборот - это часто согласование, подписание, уведомления, рассылки, запуск порожденных "процессов" (циклов согласования)..., в этой области РСУБД ну никак "не видна"
а именно в таких процессах поля и документы могут динамически создаваться/наследоваться и быть различного типа
> а именно в таких процессах поля и документы могут динамически создаваться/наследоваться
> и быть различного типаНе может ( в реальности не должно ), если может то это уже не документооборот, а отсебятина, без нормальной логики, без модели поведения и без гарантии правильной обработки.
+добавлено+ хотя в жизни конечно бывает.Это как в поле комментарий к заказу писать скидку, потому что её в начальной модели небыло, потом писать обработку скидки и т.д.
> для этого есть аппсервер (в любом раскладе), а уж как там реализовано...
Когда система падает ( да хоть таракан в сервер, хоть дефект производства кристалла процессора ) то в системе в которой целостность данных обеспечивается App. сервером часто наступают большие проблемы, а использование нормальной базы данных позволяет получить последнюю валидную копию рабочей системы.
>даты и цифры - полюбасу м.б. ключами
если у вас набор не связанных между собой ключей, это вам мало поможет, так как контролировать набор параметров которые должны быть заданы определённым образом для допустимости перехода в следующее состояние документа это фактически городить базу данных внутри App сервера.
> большинство бизнес процессов сложно/невозможно (без допущений и костылей) вписать в реляционную
> схему...
> переменное число характеристик порождает доп. сущности в РСУБД
> для отчетов, РСУБД - самое оноАффтар, ты в глаза видал такую книгу, как Ричард Баркер - "ER-modeling"?
У меня впечатление, что ты ни о бизнес-процессах, ни о реляционном моделировании ничего не слышал, ну, кроме названия, конечно.
>> большинство бизнес процессов сложно/невозможно (без допущений и костылей) вписать в реляционную
>> схему...
>> переменное число характеристик порождает доп. сущности в РСУБД
>> для отчетов, РСУБД - самое оно
> Аффтар, ты в глаза видал такую книгу, как Ричард Баркер - "ER-modeling"?
> У меня впечатление, что ты ни о бизнес-процессах, ни о реляционном моделировании
> ничего не слышал, ну, кроме названия, конечно.а ты вживую видал документооборот (именно воркфло) в больших компаниях со сложной структурой, постоянно меняющейся?
я полагаю ты только и слышал о чем-то, но ничего реального не видел ;)
Это кстати вот как раз какое-то стильно-модно-молодёжное предубеждение, скажу я вам)Если свалить все поля ваших классов кучей в редис - там вообще чёрт ногу сломит...
есть ещё и такой секрет же (прямо тут о нём и писали, кажется): для key/value можно «сесть и кодить», не надо заморачиваться разработкой схемы хранения данных и взаимосвязей. ну и что, что оно потом так аукнется, что мало не покажется? это потом будет, а код рубить уже сейчас можно!
бизнес-процессов
спасибокстати, интересную статью тему баз ключ/значение нашел:
http://habrahabr.ru/post/103021/
потому что хипсторы не осиливают теорию множеств и транзакции
Хыхы. Все написавшие выше не правы!
Ключ значение работает тупо на несколько порядков быстрее и хорошо маштабируется. Что сейчас очень востребовано.
Если бы реляционнки работали на уровне мемкеша, то ничего бы больше нужно бы небыло.
> Ключ значение работает тупо на несколько порядков быстрее…чего? ну вперёд, велосипедь сложные структуры данных со связями. посмотрю, за сколько ты навелосипедишь rdbms поверх key/value, и насколько оно в итоге будет тормозить.
>> Ключ значение работает тупо на несколько порядков быстрее
> …чего? ну вперёд, велосипедь сложные структуры данных со связями. посмотрю, за сколько
> ты навелосипедишь rdbms поверх key/value, и насколько оно в итоге будет
> тормозить.Это не задача key store хранилищ.
Что касается обозначенной Вами задачи .... РСУБД хороший инструмент с наработанными шаблонами. Но не единственный - если выйти за рамки реляционной модели - много вкусных плюшек ждут Вас. К примеру работа со сложными структурами ....
Подобного рода задачи решаются другими инструментами - таким классом решений как документ ориентированные БД. К примеру - MongoDB. Там есть на что посмотреть ...
> Хыхы. Все написавшие выше не правы!
> Ключ значение работает тупо на несколько порядков быстрее и хорошо маштабируется. Что
> сейчас очень востребовано.
> Если бы реляционнки работали на уровне мемкеша, то ничего бы больше нужно
> бы небыло.Эти ключ/значение базы для кеширования в памяти запросов к 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()
КЭП? Интерактивные данные в кешить не вариант, тригерами будете их обновлять. Ваш вариан годится когда чтение сильно превышает запись и когда не важно время реального обновления данных у клиента.
> КЭП? Интерактивные данные в кешить не вариант, тригерами будете их обновлять. Ваш
> вариан годится когда чтение сильно превышает запись и когда не важно
> время реального обновления данных у клиента.Может имелось в виду типа App сервера что-то, если мы точно знаем что и где мы обновляем, ничто не мешает нам организовать кэш, правда такой же кэш может быть организован и в БД, так что геморрой с реализацией может перекрыть выигрыш во времени отклика.
> Может имелось в виду типа App сервераСтандартное MVC с ORM на java/python/ruby
> что и где мы обновляемКаждая модель имеет уникальный символьный идентификактор и в СУБД и в кеше.
> правда такой же кэш может быть организован и в БД,Есть возможности в фреймворках делать кеши в БД, но сохранение и извлечение
данных организовано тоже по принципу ключ/значение.
> что геморрой с реализациейДополнительные н несколько строчек кода.
>когда чтение сильно превышает записьИменно, когда читают куча клиентов, а пишут один два специализированных бекенда наполнителя
контента.
Хорошо, намажу толще.
В современном мире интерактива подход беспонтовый.
Ключ-значение
масштабируется
бы не было
а я вот часто имею дело с данными, которым на роду написано ключ/значение. И очень печально, когда разработчики запихивают это в sql.
Конкретные примеры, что у Вас отлично ложится в "ключ-значение"
> Конкретные примеры, что у Вас отлично ложится в "ключ-значение"Добрый день.
Зачем Вы так категоричны ? Вы ведь никогда не ездите в Камазе в магазин ?
Примеров - вагон. Для иллюстрации - хранение данных http сессий в key store хранилище.
РСУБД тут никаким боком не упала - не ее это уровень.
> Конкретные примеры, что у Вас отлично ложится в "ключ-значение"SIP сессии например
> почему всё так сконцентрировалось вокруг баз с функционалом ключ/значение?Потому что
1) Быстрые.
2) Большинство реализаций не боится Бобби Тэйблса.
Кластер так и не осилили? По сути самое важное что ожидалось от 2.8
no-SQL начинает рулить
обычный инструмент, вообще-то.
Опять споры уровня, что лучше: рубить лес лопатой или копать ямы топором.
> Опять споры уровня, что лучше: рубить лес лопатой или копать ямы топором.Это опеннет, детка. Здесь любят летать на боинге в магазин и пытаться лететь на самокате через океан.
Sentinel - ИМХО один из ключевых моментов этой версии ... как по мне - стало стабильнее.
"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