зависит от движка

есть инмемори есть не инмемори

о да, ещё одна путаница - по первой, кроме Mongo многие другие БД (как правило key-value), типо Redis, Memcached и т.д. были in-memory и их так же называли noSQL и некотрые думают, что если in-memory то это noSQL.

зависит от движка

я не знал что у Тарантула несколько движков. Всегда думал про него как про in-memory СУБД.

а PipelineDB это SQL или нет ? :)

а PipelineDB это SQL или нет ? :)

трудно сказать что такое SQL бд, кроме того что эта БД должна подерживать язык запросов SQL. С другой стороны noSQL как правило не подерживает такой язык и при этом не операется на реалиционную теорию. Но сейчас MongoDB вроде имеет SQL адаптер и... по хорошему такую БД можно назвать SQL и одновременно noSQL. Но честно говоря я бы этот термин викинул нафиг. Лучше использовать РСУБД и документо ориентированная и key-value. БД может имееть эти свойства в разных пропорциях и к этому добавляется списко языков запросов. ЗЫ mysql имеет не только SQL интерфейс.

Google BigData имеет почти SQL интерфейс но там нету join...

а тарантул тогда что ? :) оно и не кей велью и не документо ориентированная... так кортежи на диск сложить с индексами

или в память.. это уж как захочется =)

а у тарантула есть WAL?

а тарантул тогда что ? :) оно и не кей велью и не документо ориентированная... так кортежи на диск сложить с индексами

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

есть у них и WAL и репликации и еще всякое

ну это как бы особенность асинхронности, вы делаете много чего паралельно пока ждёте IO, но если у вас 17с это некая числодробилка или чтение всей БД то тут мало, что поможет.

да нет у него асинхронности. и не хранит он ничего на диске, там нет IO. только бесполезный bgsave форком раз в N времени и восстановление из rdb-файла при старте.

SQL нету? нету. один хранит JSONB второй кортежы. кому что удобнее.

nosql - это не no sql, это not only sql

да нет у него асинхронности. и не хранит он ничего на диске, там нет IO. только бесполезный bgsave форком раз в N времени и восстановление из rdb-файла при старте.

IO это не только диск, а ещё и сеть...

nosql - это не no sql, это not only sql

где SQL надо заменить на РСУБД

IO это не только диск, а ещё и сеть...

и по сети он тоже ничего не гоняет

если так всё плохо, то зачем им пользуются?

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

Ну для меня redis это memcached на стероидах

стероиды тут это фичи

А зачем пользуются memcache если есть redis ?

nosql - это не no sql, это not only sql

в разные периоды развития по разному расшифровывали))

Да, интерфейс с точки зрения использования у него вполне приятный, еще бы удалить пересечения ключей по типам, и было бы вообще ок (чтобы я не мог случайно запросить хэш по ключу, по которому валяется инт). Но с точки зрения гарантий, предоставляемых клиенту - он вообще нулевой. Я не вижу для него юзкейсов кроме деревянного kv-кэша с таймаутами на стороне приложения.

А зачем пользуются memcache если есть redis ?

Зачем пользовать редис если есть тарантул ? :)

к слову что написанно на сайте Redis по поводу single-thread: It's very unlikely that CPU becomes your bottleneck with Redis, as usually Redis is either memory or network bound. For instance, using pipelining Redis running on an average Linux system can deliver even 500k requests per second, so if your application mainly uses O(N) or O(log(N)) commands, it is hardly going to use too much CPU.

Зачем пользовать редис если есть тарантул ? :)

Справедливое замечание. Ну во-первых потому что когда тарантула еще не было редис уже был широко распространен. Во-вторых, потому что по редису экспертизы и доков больше. В остальном, если по бенчмаркам будет одинаково или лучше, то не вижу смысла в редисе при наличии тарантула

antirez (автор редиса) очень часто полагается на такие утверждения, не предпринимая попыток продумать ситуацию "от обратного" (i.e. если все-таки процессор почему-то залип - здесь были бы добавлены таймауты операций), в результате чего и имеем то, что имеем. И про 17 секунд - это действительно реальный кейс, хоть и не у меня, а у человека, который запросил помощи. При этом никаких lua-скриптов у него внутри не было.

Справедливое замечание. Ну во-первых потому что когда тарантула еще не было редис уже был широко распространен. Во-вторых, потому что по редису экспертизы и доков больше. В остальном, если по бенчмаркам будет одинаково или лучше, то не вижу смысла в редисе при наличии тарантула

+1, а так у меня уже кода много на redis заточенного.

antirez (автор редиса) очень часто полагается на такие утверждения, не предпринимая попыток продумать ситуацию "от обратного" (i.e. если все-таки процессор почему-то залип - здесь были бы добавлены таймауты операций), в результате чего и имеем то, что имеем. И про 17 секунд - это действительно реальный кейс, хоть и не у меня, а у человека, который запросил помощи. При этом никаких lua-скриптов у него внутри не было.

но у него был запрос не O(N)?

А мы так и не выяснили тогда причину (лол). Он действительно мог самостоятельно набедокурить в объеме данных, другое дело, что ни одно другое хранилище не позволяет одному запросу устроить DOS.

ой да ладно

постгрес складывается на ура

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

select ab from (select a.* from table a) ?

Наверное я не тем путем пошел. Похоже курсор в процедуре решит проблему.

мсье склонен выражаться понятными ему только фразами

На самом деле, я тут недавно спрашивал про создание дочерней базы из основной базы с коском данных из нее, мне тут подсказали ETL. Все хорошо, но получилось что сам ETL оверкил для меня

А это все куски той же истории. Сейчас у меня есть 2 таблицы, и при выборке (T) из двух таблиц объединенных мне надо ререшить из какого поля брать данные. Очевидно что в SELECT всю ее не описать, и надо писать хранимку какую то

CASE ?

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

которые в те таблицы могут добавить*

SQL хорошо развивает структурное мышление

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

постарайся ещё раз выразить, что тебе надо, человеческим языком :)

Т.е. если провести параллель с каким-нибудь ЯП, то мне надо в функции получить ссылку на строку.

зачем?

Чтобы работать с ее полями.

По имени

Это функция будет некий "геттер"

тип RECORD ?

я понял, это такая викторина телепатическая для погресистов )

Возвращаемый? Нет. Зависит от того, с каким полем работаю.

Дмитрий. По-моему, вы всё усложняете. Похоже, что проблема на самом деле в архитектуре.

Не совсем понятно, при чем здесь архитектура

что мешает написать этот геттер прямо в запросе?

зачем там функция?

Потому что там логики на 100 строк будет

Никто не сможет это поддерживать

Если оно прямо в запросе будет

помоему человек искренне хочет Entity Attribute Value модель, но не знает что это такое

Нет. Это не EAV.

Представьте, что вы можете наследовать строки в базе.

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

может тогда яснее выражаться ? :)

Представьте, что вы можете наследовать строки в базе.

наследовать от чего? :)

Вообще было бы нелохо, если бы вы поподробнее описали суть задачи. На более высоком уровне.

ERROR: S client not available

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

это coalesce в чистом виде

это coalesce в чистом виде

+1

Обычный coalesce сюда не впихнуть, к сожалению.

почему?

WITH RECURSIVE ?

Я там выше написал, что логики в функции будет строк на 100

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

Там не только нал не нал

окей, а что ещё?

а призы будут ? :)

Решения надо принимать на основе наличия записей в других таблицах, и их значениях

И на основе них решать откуда в итоге брать значение. Из родителя или из чилда

Что-то мне подсказывает, что в таком виде это всё будет не очень быстро работать.

а если сделать вью по тем данным на которым делать выборку и сджойнить ?

Это не имеет значения

Операция для запуска в фоне для восстановления

и в чем проблема написать 100 строк логики ?

Так вопрос то был не как написать 100 строк логики ) А как обращаться к строке по имени поля в процедуре

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

^

Может, динамический SQL?

Т.е. я пишу SELECT al FROM table al и оно возвращает мне что то типа {1, foobar}

ну ты же строку откуда то получаешь ?

сложи в RECORD

Т.е. здесь видно, что имена полей потеряны. И если кто-то вставит колонку то все

и обращайся к ним

нет ?

То, что вы хотите, можно на plpython написать )

Типа сделать type cast в RECORD?

Такое возможно?

я так не пробовал.

Щас попоробую этот вариант.