САД>>таблица с 100500 колонок? САД>>а потом делать хитрые маппинги плоских сущностей на иэрархию объектов? САД>>но зачем? если можно положить и достать as is hlt>Что такое "as is" в данном случае?
в каком виде документ положили — в таком и достали.
это очень удобно.
Ops>JSON в постгре — это не просто текст, по нему вполне можно запросы делать. Так что это не просто key-value
можно, я в курсе.
но обычно этого не требуется.
впрочем, такое сейчас и сиквел поддерживает.
но нужно сравнивать перфоманс с специализированными решениями, как тот же монго.
САД>>>таблица с 100500 колонок? САД>>>а потом делать хитрые маппинги плоских сущностей на иэрархию объектов? САД>>>но зачем? если можно положить и достать as is hlt>>Что такое "as is" в данном случае? САД>в каком виде документ положили — в таком и достали. САД>это очень удобно.
Что это за вид такой, в котором в Redis можно положить, а в sql нельзя?
Здравствуйте, СвободуАнжелеДевис, Вы писали:
САД>можно, я в курсе. САД>но обычно этого не требуется.
Когда не требуется — тогда и монга не нужна. САД>впрочем, такое сейчас и сиквел поддерживает. САД>но нужно сравнивать перфоманс с специализированными решениями, как тот же монго.
По крайней мере индексы по полям json можно строить. А так — конечно, надо сравнивать.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Джо>Redis is faster than SQL Server for a key/value cache store. About 15x faster for reads and 19x faster for writes according to my tests on a single machine (no clustering or other multi-machine setup).
Здравствуйте, Gattaka, Вы писали:
G> И чем же он так хорош как ditributed cache? G> Как у него с отказоустойчивостью. G> Если значение попало на одну ноду редиса, то как скоро оно доберется до другой ноды? G> В обще зачем нужен distributed cache? Можно конкретный пример?
Боюсь, что на объяснение базовых практик распределенных систем и цитирование документации по redis я потрачу сильно много времени впустую.
P.S. "В КСВ к звёздам надо приходить подготовленными, а не так как вы: вчера — у подворотни, а сегодня — здесь, на втором ряду..."
Здравствуйте, Anton Batenev, Вы писали:
AB>Боюсь, что на объяснение базовых практик распределенных систем и цитирование документации по redis я потрачу сильно много времени впустую. AB>P.S. "В КСВ к звёздам надо приходить подготовленными, а не так как вы: вчера — у подворотни, а сегодня — здесь, на втором ряду..."
За этим высокомерным надменным пафосом скрывается банальное невежество. Проблема в том, сударь, что вы даже не сможете объяснить при всем желании. Потому что сами не знаете. При этом боитесь себе в этом признаться. Типичная история, вас много таких. И именно вы вкручиваете свой медленный редис куда не попадя. Карго культ не более.
А какой тип лучше подошел бы? Выглядит как аналог типа данных Redis:
Strings are the most basic kind of Redis value. Redis Strings are binary safe, this means that a Redis string can contain any kind of data, for instance a JPEG image or a serialized Ruby object.
A String value can be at max 512 Megabytes in length.
Т.е. значение получаемое по ключу, это произвольная строка переменной длины.
На чтение это же не должно влиять, почему операции чтения медленнее? Кроме того, Redis обеспечивает именно такой уровень изоляции по сути, по скольку он однопоточный.
И кстати это может быть ответом на вопрос зачем Redis, из-за специализации там меньше ненужных настроек где можно ошибиться.
Здравствуйте, Джо, Вы писали:
Джо>И кстати это может быть ответом на вопрос зачем Redis, из-за специализации там меньше ненужных настроек где можно ошибиться.
Здравствуйте, Джо, Вы писали:
G>>varchar(max)
Джо>А какой тип лучше подошел бы? Выглядит как аналог типа данных Redis: Джо>
Джо>Strings are the most basic kind of Redis value. Redis Strings are binary safe, this means that a Redis string can contain any kind of data, for instance a JPEG image or a serialized Ruby object.
Джо>A String value can be at max 512 Megabytes in length.
Джо>Т.е. значение получаемое по ключу, это произвольная строка переменной длины.
Нифига не ангалог. В SQL Server в нем можно хранить до 2 Гб. Просьба обеспечить аналогичным типом из Redis. Чувак в тесте пихает в трочку guid.tostring() явно varchar(max) избыточно.
Джо>>Т.е. значение получаемое по ключу, это произвольная строка переменной длины. G>Нифига не ангалог. В SQL Server в нем можно хранить до 2 Гб. Просьба обеспечить аналогичным типом из Redis. Чувак в тесте пихает в трочку guid.tostring() явно varchar(max) избыточно.
512Mb vs 2Gb — это примерно одно и тоже. Я смотрю на эксперимент как ответ на вопрос "можно ли создать сервис Redis на базе MS SQL In-memory OLTP". Функционал redis в том что ты можем положить по ключу строку от 0 до 512Mb, какой тип SQL Server для этого подойдет лучше чем varchar(max)? То что фактически он работает со строками длиной в GUID, это детали теста. То что SQL Server не может предоставить аналогичный функционал без деградации производительности говорит о его недостатках когда его заставляют работать как замену Redis.
G>Распространенные базы данных позволяют тебе не думать об алгоритмах. Ты говоришь что тебе нужно, а они уже сами подбирают алгоритм. И уже сами решают как это сделать.
До первой проблемы. В реальном проде надо знать и алгоритмы, как работают блокировки, как устроены уровни изоляции, итд.
Здравствуйте, Gattaka, Вы писали:
G>За этим высокомерным надменным пафосом скрывается банальное невежество. Проблема в том, сударь, что вы даже не сможете объяснить при всем желании. Потому что сами не знаете. При этом боитесь себе в этом признаться. Типичная история, вас много таких. И именно вы вкручиваете свой медленный редис куда не попадя. Карго культ не более.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, Gattaka, Вы писали:
G>>За этим высокомерным надменным пафосом скрывается банальное невежество. Проблема в том, сударь, что вы даже не сможете объяснить при всем желании. Потому что сами не знаете. При этом боитесь себе в этом признаться. Типичная история, вас много таких. И именно вы вкручиваете свой медленный редис куда не попадя. Карго культ не более.
F>ты просто недостоин этой чести.
Здравствуйте, Джо, Вы писали:
Джо>>>Т.е. значение получаемое по ключу, это произвольная строка переменной длины. G>>Нифига не ангалог. В SQL Server в нем можно хранить до 2 Гб. Просьба обеспечить аналогичным типом из Redis. Чувак в тесте пихает в трочку guid.tostring() явно varchar(max) избыточно.
Джо>512Mb vs 2Gb — это примерно одно и тоже. Я смотрю на эксперимент как ответ на вопрос "можно ли создать сервис Redis на базе MS SQL In-memory OLTP". Функционал redis в том что ты можем положить по ключу строку от 0 до 512Mb, какой тип SQL Server для этого подойдет лучше чем varchar(max)? То что фактически он работает со строками длиной в GUID, это детали теста. То что SQL Server не может предоставить аналогичный функционал без деградации производительности говорит о его недостатках когда его заставляют работать как замену Redis.
А можно ли в редис положить строчку оптимальным образом не более 200 символов, как это можно в Sql Server?
