Вертика и кликхаус в основном для олтп

Твой сарказм не уместен

Дело в том, что колоночные СУБД не очень любят изменения данных, а добавления переваривают хорошо в виде огромных пакетов данных для загрузки.

Вертика и кликхаус в основном для олтп

Чего?

Дело в том, что колоночные СУБД не очень любят изменения данных, а добавления переваривают хорошо в виде огромных пакетов данных для загрузки.

Апдейт в вертике, это удаление и вставка

Вертика и кликхаус в основном для олтп

Ты OLTP и OLAP не попутал часом?

Причем удаление не физическое

Ты OLTP и OLAP не попутал часом?

Не попутал

Страно....

Кафка стриминг и вперед

Так вот я тебе скажу — эти СУБД НЕ ДЛЯ OLTP.

Кафка стриминг — это уже не OLTP.

Почему же, те же транзакции

Вшивий магазинчик писать на columnstore — не покатит. Мороки будет больше, чем эффекта.

А колоночные бд не для аппликейшен

Поэтому не надо путать

Все колоночные СУБД работают в режимах "ЗАГРУЗКА ДАННЫХ — ПОДГОТОВКА — РАБОТА С ДАННЫМИ (ВЫБОРКИ)".

Колоночные, это хранилище и аналитика

Никаких транзакций они не приемлят.

Все колоночные СУБД работают в режимах "ЗАГРУЗКА ДАННЫХ — ПОДГОТОВКА — РАБОТА С ДАННЫМИ (ВЫБОРКИ)".

Нет

Колоночные, это хранилище и аналитика

Ты только что утверждал, что "ОНИ ДЛЯ OLTP" ?

Я утверждал, что они могут

И могут хорошо

Они могут, да... Но ХРЕЕЕНООООВОООО!

Тот же кликхаус спокойно собирает поток

Они могут, да... Но ХРЕЕЕНООООВОООО!

Ты не умеешь их просто готовить

Блин, ЭТО НЕ OLTP!

Если у тебя свои понятия, не называй их общеупотребимыми терминами, придумай свои...

О да

Для OLTP-то ДАААААА РУЛЯТ НЕМЕРЯННО!

Мы же уже давно выяснили что ты разбираешся в старой классике бд. Но от слова совсем ничего не понимаешь в данных. С данными у тебя дальше классических схем из книжек дело не идет. И думаю такое будет пока ты не займешься плотно математикой и анализом

Ты неправ. Я в NoSQL не разбираюсь только

Я ещё раз говорю, columnstore не катит для OLTP, потому что операции модификации/удаления данных достаточно дорогие. Нужно брать существующие словари данных и их модифицировать, возможно, уплотнять, и возможно переписывать существующие данные , даже те, что НЕ МЕНЯЛИСЬ (!!!) для оптимизации структуры хранения данных. Это никто не любит делать.

Я ещё раз говорю, columnstore не катит для OLTP, потому что операции модификации/удаления данных достаточно дорогие. Нужно брать существующие словари данных и их модифицировать, возможно, уплотнять, и возможно переписывать существующие данные , даже те, что НЕ МЕНЯЛИСЬ (!!!) для оптимизации структуры хранения данных. Это никто не любит делать.

да не дорогие они, они даже шустрее, чем у реляционок

просто дорогие относительно чтения

если в классике чтение запись это грубые 50/50, то в колоночных это где-то 80/20

И, главное — вся эта оптимизация может быть коту под хвотс следующей порцией добавления данных — НАДО ВСЁ ОБРАТНО СНОВА ДОБАВЛЯТЬ!

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

да да, я про КХ намекаю

просто дорогие относительно чтения

Не относительно чтения, а относительно аналогичных операций в обычных СУБД, ориентированных на OLTP

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

Ощущение такое, что ты говоришь о ДОБАВЛЕНИИ данных, а меня про МОДИФИКАЦИЮ И УДАЛЕНИЕ данных даже не слышишь.

Не относительно чтения, а относительно аналогичных операций в обычных СУБД, ориентированных на OLTP

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

ОК, ты — ГЕРОЙ, маладец!

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

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

Что значит нереляционная? Columnstore — вполне себе реляционные.

колоночные бд в большиснтве своем реляционные

не надо путать метод хранения данных и сами данные

Я кстати не знаю ни одной нереляционной Columnstore СУБД

что-то проскакивало, но какая-то дикая редкость

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

я так понял, что именно этот коммент относился к нереляционным базам)

нее, у нас тут сравнение классические реляционки против колоночных

А, ну наверное ElasticSearch/Solr такие же принципы супернормализации используют, как и Columnstore.

Но как бы сам термин Columnstore подразумевает, что есть колонки, а значит, есть и таблицы ?

я понял суть спора) недостаточно вверх прочитал просто)

Суть в том, что предлагали говнозизайн базы магазина с таблицами из 1000+ колонок залечить, испльзуя columnstore. Почему такая мысль пришла кому-то в голову — неясно.

https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model

Вот это ему надо.

вот и ответ

?

Ну, это нестандартный SQL, а СУБД названа не была... и что они там проверяют?

почему не стандартный?

Ну так вот, не все СУБД оконные функции поддерживают...

oracle же вроде, нет?

а про как можно меньше строк

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

Количество кода на SQL минимизировать — вообще бредятина.

От количества кода ничего не зависит

ERROR: S client not available

ну не скажи

oracle же вроде, нет?

Там Postgres написано...

ну не скажи

Ну, скажу...

я всегда стараюсь написать короче, по возможности не городить миллион текста в одной процедуре

а выносить в функции к примеру что-то

или дробить как то

дело в том, что потом другому человеку придется это читать и там будет слишком много буковок

Ключевое слов "ПО ВОЗМОЖНОСТИ". Я тоже стараюсь не писать лишнее, если это не нужно

я всегда стараюсь написать короче, по возможности не городить миллион текста в одной процедуре

sql - это не ЯП, от писанины полностью зависит производительность и логика

а выносить в функции к примеру что-то

Как ты часть запроса SELECT вынесешь в функцию ?

Расскажи, я поржу...

поэтому когда спрашивают, как можно минимизировать sql, можно отвечать "так же, как и головной мозг"

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

поэтому когда спрашивают, как можно минимизировать sql, можно отвечать "так же, как и головной мозг"

СОгласен.

Поэтому я и написал — идиотизм.

возможно в контексте данного задания необходимо было сделать вывод одной таблицей, при этом организовав периоды

может не про код вообще говоря вопрос?))

дело в том, что потом другому человеку придется это читать и там будет слишком много буковок

Вот как раз беда многих кто приходит с императивных языков и начинает писать на SQL в том, что они ПЫТАЮТСЯ МИНИМИЗИРОВАТЬ ОБЪЁМ КОДА, и устранить дублирование, там, где это не то, что не нужно, а ПРОСТО НЕЛЬЗЯ ДЕЛАТЬ.

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

на вкус и цвет товарищей нет)

И что? Я прочитаю запросто

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

и в чем проблема?

если человек не умеет читать 500 строчные листинги, значит это не его

ну а чистота кода? ка кбез нее?

вот я открываю функцию был тут человек которых это сделал

ща

я приведу пример

или хотите сказать, что вот я написал программу через ООП, а следующий разраб умеет только в фукнциональное программирование и теперь это моя проблема?

Опять-таки, начинающие часто смотрят на здоровый запрос и ОФИГЕВАЮТ, а он очень простой, в нём просто 30 полей в списке вывода...

set [version] = CASE WHEN (CASE WHEN len(REPLACE(REPLACE(REPLACE(REPLACE(i.caption,CHAR(13),' '),CHAR(9),' '),CHAR(10),' '),CHAR(160),' '))<30 THEN REPLACE(REPLACE(REPLACE(REPLACE(i.caption,CHAR(13),' '),CHAR(9),' '),CHAR(10),' '),CHAR(160),' ') ELSE SUBSTRING(REPLACE(REPLACE(REPLACE(REPLACE(i.caption,CHAR(13),' '),CHAR(9),' '),CHAR(10),' '),CHAR(160),' '),charindex('/',REPLACE(REPLACE(REPLACE(REPLACE(i.caption,CHAR(13),' '),CHAR(9),' '),CHAR(10),' '),CHAR(160),' '),0)+1,charindex(' ',REPLACE(REPLACE(REPLACE(REPLACE(i.caption,CHAR(13),' '),CHAR(9),' '),CHAR(10),' '),CHAR(160),' '))-charindex('/',REPLACE(REPLACE(REPLACE(REPLACE(i.caption,CHAR(13),' '),CHAR(9),' '),CHAR(10),' '),CHAR(160),' '),0)-1) END) like 'ksrv%' THEN '-' ELSE CASE WHEN len(REPLACE(REPLACE(REPLACE(REPLACE(i.caption,CHAR(13),' '),CHAR(9),' '),CHAR(10),' '),CHAR(160),' '))<30 THEN REPLACE(REPLACE(REPLACE(REPLACE(i.caption,CHAR(13),' '),CHAR(9),' '),CHAR(10),' '),CHAR(160),' ') ELSE SUBSTRING(REPLACE(REPLACE(REPLACE(REPLACE(i.caption,CHAR(13),' '),CHAR(9),' '),CHAR(10),' '),CHAR(160),' '),charindex('/',REPLACE(REPLACE(REPLACE(REPLACE(i.caption,CHAR(13),' '),CHAR(9),' '),CHAR(10),' '),CHAR(160),' '),0)+1,charindex(' ',REPLACE(REPLACE(REPLACE(REPLACE(i.caption,CHAR(13),' '),CHAR(9),' '),CHAR(10),' '),CHAR(160),' '))-charindex('/',REPLACE(REPLACE(REPLACE(REPLACE(i.caption,CHAR(13),' '),CHAR(9),' '),CHAR(10),' '),CHAR(160),' '),0)-1) END END,

то есть каждый раз всплывал какой то костыль в строке

и каждый раз его заменяли