Comments 35
Что такое Caché?
Зачем оно нужно?
Почему у него такое мудрёное название?
Чем оно отличается от постгреса, монги, редиса?
Какого чёрта я должен думать о том, как там внутри представляются числа?
Зачем оно нужно?
Почему у него такое мудрёное название?
Чем оно отличается от постгреса, монги, редиса?
Какого чёрта я должен думать о том, как там внутри представляются числа?
Вероятно, статья просто не для вас, такое бывает.
Caché — это СУБД, хотите знать больше, гуглите
Логично, что того же для чего и другие СУБД
чем отличается, тем что он другой, думаю что обсуждение различий Caché не тема для обсуждений в конкретно этой теме
тема выложена в блоге разработчика Caché, и интересна тем кто знает что такое Caché
Логично, что того же для чего и другие СУБД
чем отличается, тем что он другой, думаю что обсуждение различий Caché не тема для обсуждений в конкретно этой теме
тема выложена в блоге разработчика Caché, и интересна тем кто знает что такое Caché
Понимаете, в чём проблема.
Я вот пересмотрел все посты из Хабра на тему Caché.
Подавляющее большинство написано людьми, работающими в InterSystems.
Подавляющее большинство постов никогда не выходило в топ Хабра.
Подавляющее большинство постов выглядит, как копипаста рецептов из вики, за исключением того, что никакой вики про Caché мне найти не удалось.
В комментариях тусит небольшая тусовка людей, которые оказываются в основном сотрудниками того же InterSystems.
Так что, обращаясь к сотрудникам InterSystems: можно _хороший_ пост _для непосвящённых_, в котором _внятно_ будет объяснено, что такое Caché и зачем его нужно иметь где-то, кроме легаси-кода?
Я вот пересмотрел все посты из Хабра на тему Caché.
Подавляющее большинство написано людьми, работающими в InterSystems.
Подавляющее большинство постов никогда не выходило в топ Хабра.
Подавляющее большинство постов выглядит, как копипаста рецептов из вики, за исключением того, что никакой вики про Caché мне найти не удалось.
В комментариях тусит небольшая тусовка людей, которые оказываются в основном сотрудниками того же InterSystems.
Так что, обращаясь к сотрудникам InterSystems: можно _хороший_ пост _для непосвящённых_, в котором _внятно_ будет объяснено, что такое Caché и зачем его нужно иметь где-то, кроме легаси-кода?
Если честно, то здесь нужно быть сотрудником InterSystems, чтобы писать в корпоративный блог.
Насчет того что статьи больше похожи на копипасту, наверно не соглашусь. Большая часть все таки личный опыт. Мои статьи, точно.
Наверно вы действиьельны правы и требуется какая то хорошо развернутая статья по теме, что такое Cache.
К сожалению тусовка людей действительно не очень большая. в большинстве своем это уже опытные люди.
Насчет того что статьи больше похожи на копипасту, наверно не соглашусь. Большая часть все таки личный опыт. Мои статьи, точно.
Наверно вы действиьельны правы и требуется какая то хорошо развернутая статья по теме, что такое Cache.
К сожалению тусовка людей действительно не очень большая. в большинстве своем это уже опытные люди.
Писать посты на тему Caché можно не только в блог InterSystems, и не только силами сотрудников, хабр — социальный проект.
Про «рецепты из вики», это стиль подачи информации в статье. Как яркий пример такой статьи, wiki.openstreetmap.org/wiki/PostGIS/Installation — вся статья — концентрированный личный опыт. Какие команды выполнить, чтобы достичь результата. Ориентировано исключительно на тех, кто знает, что и с помощью чего он собирается делать. Вот только я пока совсем не вижу причин, по которым кому-нибудь вообще стоит использовать Caché. И это проблема не моя, а компании InterSystems, потому что возьму я в зависимости от задачи PostgreSQL или Redis, а не их разработку.
Знаете, показателем полезности ваших статей является, например, то, что они не набирали больше +6 (а это меньше, чем сотрудников InterSystems на хабре!), и то, что в комментариях к ним (в основном «отличная статья! автору респект!») не отметилось никого, кроме сотрудников того же InterSystems.
Если вы хотите увеличивать тусовку людей, то, может быть, стоит задуматься, что и для кого вы пишете на хабре?
Про «рецепты из вики», это стиль подачи информации в статье. Как яркий пример такой статьи, wiki.openstreetmap.org/wiki/PostGIS/Installation — вся статья — концентрированный личный опыт. Какие команды выполнить, чтобы достичь результата. Ориентировано исключительно на тех, кто знает, что и с помощью чего он собирается делать. Вот только я пока совсем не вижу причин, по которым кому-нибудь вообще стоит использовать Caché. И это проблема не моя, а компании InterSystems, потому что возьму я в зависимости от задачи PostgreSQL или Redis, а не их разработку.
Знаете, показателем полезности ваших статей является, например, то, что они не набирали больше +6 (а это меньше, чем сотрудников InterSystems на хабре!), и то, что в комментариях к ним (в основном «отличная статья! автору респект!») не отметилось никого, кроме сотрудников того же InterSystems.
Если вы хотите увеличивать тусовку людей, то, может быть, стоит задуматься, что и для кого вы пишете на хабре?
Есть такой пост! Написан не сотрудником, не в блоге, для новичков, и даже объясняет почему ему это нравится
Представляете, этот пост чуть менее, чем полностью, состоит из скриншотов мастеров, которые я увижу всего один раз, если вообще увижу. За деревьями не видно леса.
И в комментах опять одни сотрудники InterSystems, и потерявшиеся нечаянно попавшие люди, ничего не знающие про Caché, вежливо намекающие, что ничего не поняли, но, может быть, круто. Правда, непонятно, как это может пригодиться в жизни.
Но как пример того, что посты можно писать по-разному, и не обязательно в корпоративный блог — хорошо!
И в комментах опять одни сотрудники InterSystems, и потерявшиеся нечаянно попавшие люди, ничего не знающие про Caché, вежливо намекающие, что ничего не поняли, но, может быть, круто. Правда, непонятно, как это может пригодиться в жизни.
Но как пример того, что посты можно писать по-разному, и не обязательно в корпоративный блог — хорошо!
Вы за скриншотами не увидели главного
Cache'-проектировщик должен всегда мыслить объектами предметной области (Domain Model, DM). Ночь. Улица. Фонарь. Аптека. Кому неймется использовать абстракции — просьба входить с парадного. У нас здесь всё по-простому — всяческие «регистры учета» мы традиционно доводим до жидкого состояния и сливаем в. В качестве компенсации за мучения типа «ну как же это обозвать, чтобы было в DM?» рано или поздно наступает совершенная синергия — система начинает отвечать адекватно на воздействия, к которым проектировщик ее не готовил.
Признак того, что Вы знаете этот шаблон простой: На половину новых запросов заказчика Вам ничего не нужно делать. Система ведет себя точно так же, как и реальный бизнес — процветает.
DM — это главный шаблон. И он же пригодится нам первым.
Еще одна небольшая ремарка:
Cache' предлагает не просто хорошую реализацию модели предметной области. Здесь очень лаконичными и удобными средствами обеспечивается инкапсуляция не только данных, но и поведения объектов предметной области в соответствующие классы.
Простите, но если главное в статье для новичков находится на семнадцатом нажатии PgDn из 48, то к качеству этой статьи у меня есть определённые претензии, которые hivemind хабра выражает проще — рейтинг поста — +1.
Тем более, что из приведённой вами цитаты с зашкаливающим количеством умных слов мне совсем неясно, в чём отличие от Redis и его хранимок на lua.
Тем более, что из приведённой вами цитаты с зашкаливающим количеством умных слов мне совсем неясно, в чём отличие от Redis и его хранимок на lua.
есть информация и по поводу кто-чьей разработкой является, в блоге есть, кхм, перевод, но рекомендую читать в оригинале
Хорошая статья.
Суть: «всё, что угодно, можно представить в виде набора вложенных словарей».
В общем-то, просто, очевидно и понятно.
Непонятно, как этот словарь будет крутиться, когда в него положить пару миллионов значений, а потом достать?
Что будет, когда мы захотим обновить половину значений в половине ключей на втором-третьем уровне вложенности?
С какой стороны к этому прикручена транзакционность?
Как оно будет хранить это всё на нескольких узлах, когда всё место на одном закончится?
Как оно будет балансировать нагрузку на чтение-запись?
В общем-то, самое интересное остаётся за кадром.
А представленное в статье в питоне легко делается через d = json.load(file) / global d / json.dump(file, d), без всякого Caché.
Суть: «всё, что угодно, можно представить в виде набора вложенных словарей».
В общем-то, просто, очевидно и понятно.
Непонятно, как этот словарь будет крутиться, когда в него положить пару миллионов значений, а потом достать?
Что будет, когда мы захотим обновить половину значений в половине ключей на втором-третьем уровне вложенности?
С какой стороны к этому прикручена транзакционность?
Как оно будет хранить это всё на нескольких узлах, когда всё место на одном закончится?
Как оно будет балансировать нагрузку на чтение-запись?
В общем-то, самое интересное остаётся за кадром.
А представленное в статье в питоне легко делается через d = json.load(file) / global d / json.dump(file, d), без всякого Caché.
в чём отличие от Redis и его хранимок на lua… когда в него положить пару миллионов значений, а потом достать… как балансировать нагрузку...Для новичков?
«Для новичков в Caché» — вовсе не то же самое, что «для клинических идиотов», и вовсе не подразумевает отсутствия бекграундовых знаний в других технологиях и проблем, с которыми сталкиваются все, кто так или иначе реализует заявленные InterSystems фичи.
У меня вполне конкретный список вопросов, не рассмотренных в обозримых интернетах, кратко озвученный ещё в самом первом комментарии, на который мне было предложено «пойти погуглить».
У меня вполне конкретный список вопросов, не рассмотренных в обозримых интернетах, кратко озвученный ещё в самом первом комментарии, на который мне было предложено «пойти погуглить».
плохо все будет. У нас полтора года «пилили» это каше, кучу денег на лицензии вбухали. Спецы из москвы приезжали… так и не смогли даже в тесте запустить хотя бы одно рабочее место, не говоря о том сколько было обещано. После тестового запуска положило основную систему /обмен так и не взлетел в промышленных масштабах/. И все затихло.
Приятно, что вы пересмотрели их все (их довольно много, даже только в нашем блоге). Жаль, что не все понравились.
Как и сказал уже Daimor, чтобы писать в корпоративном блоге InterSystems на Хабре, нужно указать галочку «Сотрудник» InterSystems. Хаба по Caché пока нет, но может появится когда-нибудь. Подавляющее большинство статей написано инженерами компаний-партнеров InterSystems и просто заинтересованными в развитии технологии людьми.
В топ хабра статьи редко выходят, да — но что делать, технология не очень распространенная. Действительно, не монго и не редис с постгресом. Про стилистику статей критика принимается: но мы стараемся размещать в нашем блоге такие статьи, которые интересны нашему сообществу. Можете написать лучше — обращайтесь, возможно наймем вас в качестве автора интересной статьи про Caché, которая выйдет в топ.
Пост для непосвященных — хорошая идея, наверное надо такой сделать. Хотя объектной СУБД Caché уже более 10 лет — т.е. все эти статьи, что такое Caché и постреляционные СУБД уже выходили с десяток лет назад.
Пока статьи «Что такое Caché» на Хабре нет, напишу вкратце про Caché здесь:
Caché — проприетарная СУБД, т.е. не свободное ПО. Поэтому возможно вы возьмете Mongo, Redis или Postgres а не Caché, просто потому, что они опенсорс.
Но взамен денег за покупку ПО клиент InterSystems получает круглосуточную поддержку 24/7, что в некоторых проектах, согласитесь, очень критично.
Изначально (30 лет назад) СУБД Caché была тем, что сейчас называют NoSQL key/value системами. Только структура атомарных хранимых данных в Caché — это key/value в многомерных и разреженных массивах (глобалы).
Дальше СУБД развивалась, в на многомерном движке БД появилась поддержка реляционной модели (т.е. данные можно хранить в таблицах как в любой реляционке и манипулировать ими посредством SQL), наряду с ODBC/JDBC. Затем появилась и поддержка объектной работы с данными, реализованная в скриптовом серверном языке Caché Object Script(COS) и в различных bindings: Java, C#, C++.
Транзакции поддерживаются. Есть встроенный сервер приложений. Горизонтальное масштабирование есть. Высокая доступность и репликация есть. Все популярные серверные ОС поддерживаются.
Вот из-за этой своей многомерной природы и серверного языка COS Caché может работать и как Mongo и как Redis и как Postgres, причем на одних и тех же данных, в зависимости от того, как тому или иному приложению удобно с ними работать. А потом можно еще и через объектный интерфейс к этим же данным обратиться. Это уникальная характеристика Caché — где еще такое возможно?
В качестве примера, зачем это может быть нужно в жизни, приведу кейс одного из наших клиентов. У них была база на одном популярном SQL движке. И сделали они ее в стиле EAV: вся схема в 3-х таблицах, есть такой популярный прием. Но они с этим приемом укусили себя за хвост в плане производительности SQL. Процедур написаны тысячи, код менять нереально. А вот можно ли что-то поделать с производительностью? Вот в Caché можно например переписать логику выполнения SQL процедуры вручную, через оптимальный «обход» многомерных key-value структур. Не для всех конечно это нужно делать, а процедуры с «бутылочным горлышком». Вот конкретно для этого заказчика, переход на Caché дал рост производительности почти 4 раза сразу, просто заменой JDBC драйвера и написанием пары серверных процедур на COS, что решило их текущую проблему.
Почему выбирают Caché наши партнеры? Наверное лучше спросить у них, но можем сказать, что оперирование хранимыми сущностями в Caché позволяет быстро писать сложный код и малой кровью решать сложные задачи. Также очень помогает объектная сторона Caché, что позволяет оперировать наследованием в хранимых классах и наследовать бизнес-логику в методах.
В основном сейчас для Caché пишут решения на REST интерфейсе, с передачей JSON между сервером Caché и клиентскими приложениями. Бизнеслогика REST API пишется на COS.
Caché надежная СУБД: об этом могут сказать банки, биржи (EuroStoxx, Ameritrade, Credit Suiss), операторы крупных госсистем в Украине, Казахстане и России, операторы телеком-услуг, авиадиспетчеры.
Вместе с Caché поставляется технология NLP iKnow и технология OLAP DeepSee.
Другие наши заказчики приобретают InterSystems Ensemble — ESB, основанную на Caché и обладающую всем необходимым для реализации полноценной шины для интеграционного ИТ-решения. Но Ensemble это отдельная история, про которую тоже с удовольствием расскажем.
Как и сказал уже Daimor, чтобы писать в корпоративном блоге InterSystems на Хабре, нужно указать галочку «Сотрудник» InterSystems. Хаба по Caché пока нет, но может появится когда-нибудь. Подавляющее большинство статей написано инженерами компаний-партнеров InterSystems и просто заинтересованными в развитии технологии людьми.
В топ хабра статьи редко выходят, да — но что делать, технология не очень распространенная. Действительно, не монго и не редис с постгресом. Про стилистику статей критика принимается: но мы стараемся размещать в нашем блоге такие статьи, которые интересны нашему сообществу. Можете написать лучше — обращайтесь, возможно наймем вас в качестве автора интересной статьи про Caché, которая выйдет в топ.
Пост для непосвященных — хорошая идея, наверное надо такой сделать. Хотя объектной СУБД Caché уже более 10 лет — т.е. все эти статьи, что такое Caché и постреляционные СУБД уже выходили с десяток лет назад.
Пока статьи «Что такое Caché» на Хабре нет, напишу вкратце про Caché здесь:
Caché — проприетарная СУБД, т.е. не свободное ПО. Поэтому возможно вы возьмете Mongo, Redis или Postgres а не Caché, просто потому, что они опенсорс.
Но взамен денег за покупку ПО клиент InterSystems получает круглосуточную поддержку 24/7, что в некоторых проектах, согласитесь, очень критично.
Изначально (30 лет назад) СУБД Caché была тем, что сейчас называют NoSQL key/value системами. Только структура атомарных хранимых данных в Caché — это key/value в многомерных и разреженных массивах (глобалы).
Дальше СУБД развивалась, в на многомерном движке БД появилась поддержка реляционной модели (т.е. данные можно хранить в таблицах как в любой реляционке и манипулировать ими посредством SQL), наряду с ODBC/JDBC. Затем появилась и поддержка объектной работы с данными, реализованная в скриптовом серверном языке Caché Object Script(COS) и в различных bindings: Java, C#, C++.
Транзакции поддерживаются. Есть встроенный сервер приложений. Горизонтальное масштабирование есть. Высокая доступность и репликация есть. Все популярные серверные ОС поддерживаются.
Вот из-за этой своей многомерной природы и серверного языка COS Caché может работать и как Mongo и как Redis и как Postgres, причем на одних и тех же данных, в зависимости от того, как тому или иному приложению удобно с ними работать. А потом можно еще и через объектный интерфейс к этим же данным обратиться. Это уникальная характеристика Caché — где еще такое возможно?
В качестве примера, зачем это может быть нужно в жизни, приведу кейс одного из наших клиентов. У них была база на одном популярном SQL движке. И сделали они ее в стиле EAV: вся схема в 3-х таблицах, есть такой популярный прием. Но они с этим приемом укусили себя за хвост в плане производительности SQL. Процедур написаны тысячи, код менять нереально. А вот можно ли что-то поделать с производительностью? Вот в Caché можно например переписать логику выполнения SQL процедуры вручную, через оптимальный «обход» многомерных key-value структур. Не для всех конечно это нужно делать, а процедуры с «бутылочным горлышком». Вот конкретно для этого заказчика, переход на Caché дал рост производительности почти 4 раза сразу, просто заменой JDBC драйвера и написанием пары серверных процедур на COS, что решило их текущую проблему.
Почему выбирают Caché наши партнеры? Наверное лучше спросить у них, но можем сказать, что оперирование хранимыми сущностями в Caché позволяет быстро писать сложный код и малой кровью решать сложные задачи. Также очень помогает объектная сторона Caché, что позволяет оперировать наследованием в хранимых классах и наследовать бизнес-логику в методах.
В основном сейчас для Caché пишут решения на REST интерфейсе, с передачей JSON между сервером Caché и клиентскими приложениями. Бизнеслогика REST API пишется на COS.
Caché надежная СУБД: об этом могут сказать банки, биржи (EuroStoxx, Ameritrade, Credit Suiss), операторы крупных госсистем в Украине, Казахстане и России, операторы телеком-услуг, авиадиспетчеры.
Вместе с Caché поставляется технология NLP iKnow и технология OLAP DeepSee.
Другие наши заказчики приобретают InterSystems Ensemble — ESB, основанную на Caché и обладающую всем необходимым для реализации полноценной шины для интеграционного ИТ-решения. Но Ensemble это отдельная история, про которую тоже с удовольствием расскажем.
Ура! Развёрнутый ответ!
Как-то так и должен выглядеть вводный пост про то, что такое Caché и как его набирать с клавиатуры :)
За пятнадцать лет успело смениться минимум три поколения программистов. Вы правда думаете, что кто-то читает статьи пятнадцатилетней давности? В лучшем случае — свежие их переводы :)
Вот, когда напишете первый пост (а скелет вы уже написали) — есть сразу несколько вопросов на потом (нет, не нужно отвечать тут сейчас, напишите красивый отдельный пост):
1. если Caché умеет работать, как редис — как это сделать? как писать ин-мемори без транзакций, в стиле r.get() / r.set()? как оно обходится с памятью? что будет, когда память кончится? как рассказать «убивай всё старое и не держи на него зла, ты кеш»? как экспайрить и продлевать время жизни записей?
2. если Caché умеет косить под Postgres / SQL — как это использовать? как отличить Caché-[redis] от Caché-[postgres]? насколько реально взять какой-нибудь несложный движок/ORM и сходу запустить под Caché? Вот чисто ради примера — какой-нибудь простой Django app или Wordpress.
3. если Caché умеет работать, как Mongo — интересно было бы почитать, как оно масштабируется. Не «запустите вот такую команду, чтобы смасштабировать на два сервера», а нормальные схемы, как происходит чтение, запись в репликах, куда пишется WAL и что происходит, когда сеть падает и вдруг Split-brain и merge-brain.
И, ради бога, не используйте никому неизвестных маркетинговых термиров в статьях для новичков. «Вместе с Caché поставляется технология NLP iKnow и технология OLAP DeepSee.» — пустой звук для меня, пока вы не расскажете, что это и почему я его хочу.
И спасибо за ответ! :)
Как-то так и должен выглядеть вводный пост про то, что такое Caché и как его набирать с клавиатуры :)
За пятнадцать лет успело смениться минимум три поколения программистов. Вы правда думаете, что кто-то читает статьи пятнадцатилетней давности? В лучшем случае — свежие их переводы :)
Вот, когда напишете первый пост (а скелет вы уже написали) — есть сразу несколько вопросов на потом (нет, не нужно отвечать тут сейчас, напишите красивый отдельный пост):
1. если Caché умеет работать, как редис — как это сделать? как писать ин-мемори без транзакций, в стиле r.get() / r.set()? как оно обходится с памятью? что будет, когда память кончится? как рассказать «убивай всё старое и не держи на него зла, ты кеш»? как экспайрить и продлевать время жизни записей?
2. если Caché умеет косить под Postgres / SQL — как это использовать? как отличить Caché-[redis] от Caché-[postgres]? насколько реально взять какой-нибудь несложный движок/ORM и сходу запустить под Caché? Вот чисто ради примера — какой-нибудь простой Django app или Wordpress.
3. если Caché умеет работать, как Mongo — интересно было бы почитать, как оно масштабируется. Не «запустите вот такую команду, чтобы смасштабировать на два сервера», а нормальные схемы, как происходит чтение, запись в репликах, куда пишется WAL и что происходит, когда сеть падает и вдруг Split-brain и merge-brain.
И, ради бога, не используйте никому неизвестных маркетинговых термиров в статьях для новичков. «Вместе с Caché поставляется технология NLP iKnow и технология OLAP DeepSee.» — пустой звук для меня, пока вы не расскажете, что это и почему я его хочу.
И спасибо за ответ! :)
Зачастую все эти слова, о том мы что все в подряд поддерживаем — и то и это говорит о том, что разработчики мечутся во всех направлениях, пытаясь спасти продукт.
В жизни всего гораздо печальнее, вместо ACID операций сплошные суррогаты и ручные выкрутасы для поддержки целостности базы.
В жизни всего гораздо печальнее, вместо ACID операций сплошные суррогаты и ручные выкрутасы для поддержки целостности базы.
Пожалуйста)
Подробные ответы в подробной статье, а тут снова вкратце и с конца.
Про неизвестные маркетинговые термины. NLP — Natural Language Processing, например NLP от Яндекса. У нас такая технология называется iKnow, пример.
OLAP — online analytical processing, на Хабре. Наша технология называется DeepSee.
3. ECP — одна из технологий масштабирования решений на Caché, по сути распределенный транзакционно-целостный кэш данных. Если вдруг будете в Санкт-Петербурге 16 октября, приходите на InterSystems Meetup — будет рассказ о практике применения ECP. И кстати про iKnow тоже и без marketing bullshit.
2. Если кратко: все, что ODBC/JDBC сразу будет работать с Caché, как с любой реляционкой. Примеры с django — хорошая идея, сделаем, но я не понимаю, зачем использовать платную СУБД в качестве базы для Wordpress?
1. Красивый отдельный пост :)
Набирать сложно :) Но можно: на маке alt+e и снова e )
Подробные ответы в подробной статье, а тут снова вкратце и с конца.
Про неизвестные маркетинговые термины. NLP — Natural Language Processing, например NLP от Яндекса. У нас такая технология называется iKnow, пример.
OLAP — online analytical processing, на Хабре. Наша технология называется DeepSee.
3. ECP — одна из технологий масштабирования решений на Caché, по сути распределенный транзакционно-целостный кэш данных. Если вдруг будете в Санкт-Петербурге 16 октября, приходите на InterSystems Meetup — будет рассказ о практике применения ECP. И кстати про iKnow тоже и без marketing bullshit.
2. Если кратко: все, что ODBC/JDBC сразу будет работать с Caché, как с любой реляционкой. Примеры с django — хорошая идея, сделаем, но я не понимаю, зачем использовать платную СУБД в качестве базы для Wordpress?
1. Красивый отдельный пост :)
Набирать сложно :) Но можно: на маке alt+e и снова e )
Многомерный движок… Вы живёте в своём замкнутом мирке с нестандартной терминологией. На основании того, что интерфейсом работы с Б-деревом с составным ключём, является многомерный массив (глобал), вы говорите про «многомерный движок», «многомерное структуры данных». Если бы кто-нибудь из вас вылез бы с техническим докладом на какую-нибудь достаточно известную в широких кругах конференцию, тот же Highload++, вас бы там затроллили по самое «не балуйся» за эти ваши «многомерный движок» и «многомерные структуры данных». Любая реляционная СУБД в не меньшей степени «многомерна». Ведь она хранит данные в таблицах, каждая из которых состоит из нескольких атрибутов. Таким образом, таблицу можно представить как множество точек в n-мерном пространстве. Вы можете мне назвать хоть одну распространённую СУБД, которая не была бы «многомерной» в этом смысле? Но хорошо, я даже готов принять вашу терминологию.
Да, EAV является распространённой практикой в многомерных реляционных СУБД. Используется, как правило, тогда, когда число измерений объекта заранее не известно. И заключается в отображении каждого объекта, с неизвестным заранее числом измерений, на множество других объектов с заранее известным числом измерений. Но при этом мощность множества хранимых объектов сильно возрастает, всвязи с чем возникают проблемы с производительностью. Однако, многие многомерные реляционные СУБД могут предложить и другие решения этой проблемы. Например, в многомерной СУБД PostgreSQL поддерживаются многомерные атрибуты. Уже много лет существует многомерный тип hstore, а с версии 9.4 поддерживается многомерный тип произвольной вложенности — jsonb. При этом не просходит увеличения мощности множества хранимых объектов, а ускорении 4 раза по сравнению с EAV — далеко не предел.
Да, EAV является распространённой практикой в многомерных реляционных СУБД. Используется, как правило, тогда, когда число измерений объекта заранее не известно. И заключается в отображении каждого объекта, с неизвестным заранее числом измерений, на множество других объектов с заранее известным числом измерений. Но при этом мощность множества хранимых объектов сильно возрастает, всвязи с чем возникают проблемы с производительностью. Однако, многие многомерные реляционные СУБД могут предложить и другие решения этой проблемы. Например, в многомерной СУБД PostgreSQL поддерживаются многомерные атрибуты. Уже много лет существует многомерный тип hstore, а с версии 9.4 поддерживается многомерный тип произвольной вложенности — jsonb. При этом не просходит увеличения мощности множества хранимых объектов, а ускорении 4 раза по сравнению с EAV — далеко не предел.
Для реляционных СУБД единственный способ хранения информации — таблицы. Столбцы этих таблиц могут быть разных типов, в том числе сложных (XML, JSON), но таблица должна быть. Внутри эти таблицы могут представляться как угодно, но сама СУБД программистов баз данных на уровень ниже таблиц не пускает.
Многие данные ложатся на таблицы естественно. Некоторые (иерархические, например) данные на таблицы естественным образом не отображаются, но есть много способов как их в таблицах моделировать.
Caché хороша в том числе многомодельностью. Если в таблицы что-то ложится плохо, можно использовать другие модели данных — объектную или иерархическую (глобалы). И рассматривать одни и те же данные с разных точек зрения. Или создать на основе глобалов свою модель, если нужно.
«замкнутый мирок», «вылез», «затроллили». Отчего такая неприязнь?
Многие данные ложатся на таблицы естественно. Некоторые (иерархические, например) данные на таблицы естественным образом не отображаются, но есть много способов как их в таблицах моделировать.
Caché хороша в том числе многомодельностью. Если в таблицы что-то ложится плохо, можно использовать другие модели данных — объектную или иерархическую (глобалы). И рассматривать одни и те же данные с разных точек зрения. Или создать на основе глобалов свою модель, если нужно.
«замкнутый мирок», «вылез», «затроллили». Отчего такая неприязнь?
Подавляющее большинство написано людьми, работающими в InterSystems.
Подавляющее большинство постов никогда не выходило в топ Хабра.
Подавляющее большинство постов выглядит, как копипаста рецептов из вики, за исключением того, что никакой вики про Caché мне найти не удалось.
В комментариях тусит небольшая тусовка людей, которые оказываются в основном сотрудниками того же InterSystems.
Т.к. есть опыт использования Caché, объясню вам то, чего сотрудники InterSystems, по идеологическим причинам, объяснить не могут.
Caché основана на системе MUMPS, уходящей корнями ещё в 60-ые годы. Там был весьма специфичный язык программирования, в котором используется очень много псевдографики, и встроенная возможность хранения данных в Б-дереве, которое из этого языка программирования видно как вложенный массив (именно «вложенный», термин «многомерный» добавляется исключительно для понтов). Для своих лет, вероятно, система была довольно продвинутой.
Caché, с свою очередь, является попыткой модернизировать MUMPS до уровня 21ого века. В язык программирования была добавлена объектность и прочие современные возможности, в результате чего он стал странным смешением псевдографики и современного синтаксиса. Для хранения данных были добавлены SQL и объектный доступ, реализованные на базе этих самых вложенных массивов, пресловутых глобалов. При этом оба эти новых способа доступа получились очень отсталыми на фоне тех возможностей, которые предоставляются современными реляционными СУБД и ORM. Об их недостатках можно говорить очень много, я не хочу сейчас распылять на этом внимание. Достаточно сказать, что SQL в Caché застрял на уровне стандарта 92-ого года, самый сильный поддерживаемый уровень изоляции данных там read committed (не настоящий, с нарушениями), планировщик запросов путается в JOIN'ах 3ёх таблиц.
Система релизов Caché очень интересна. Не выходят исправления багов вообще, только новые релизы. Какие либо исправления можно получить только сообщив о баге в поддержку. Т.е., чтобы иметь уверенность в сносной работе Caché, нужно самому оттестировать весь функционал, который собираешься использовать, и запросить с поддержки исправление всех багов, которые нашёл.
Но всё это компенсируется агрессивностью маркетинга. Он не перестаёт кричать, что них круче всё и вся, зачастую выдавая новейшие технологические фишки из 70-ых-80-ых годов прошлого века. На удивление этот дух агрессивного маркетинга заражает даже некоторых технических сотрудников InterSystems, что, казалось бы, должно бы невозможно в силу уровня технической грамотности и кругозора.
Из вышесказанного очевидно, что такая система не может завоевать популярность и признание у широкого круга разработчиков. Её судьба — замкнуться в рамках узкой «секты» и не выходить за её пределы. Отражение этого процесса мы можем видеть и на хабре.
Там был весьма специфичный язык программирования, в котором используется очень много псевдографики
в результате чего он стал странным смешением псевдографики и современного синтаксиса
в самом языке программирования псевдографики не больше чем в любом другом языке программирования, т.е. ее там совершенно нет, кроме что ее можно вывести, как вы правильно упомянули, СУБД уходит глубоко корнями в 60-ые (хотя если быть точнее все таки 70-ые), и для систем того времени, это нормально иметь такой интерфейс, вплоть до середины 90-ых такое было. И то что ее продолжатели так же поддерживают вывод псевдографики так же, в чем собственно проблема.
Да, согласен SQL-92 не самая свежая версия, но скажем так, это можно расценивать как расплату, за возможность разного типа доступа к данным, и возможность гибко управлять выполнением запросов (умение правда доступное не многим). Приведите мне примеры СУБД, где на достаточно высоком уровне реализовано одновременно и SQL и NoSQL.
Почему же это не выпускают исправления багов. за год выпускается обычно две версии, и на каждую по несколько версий с исправлениями. А как система исправления багов работает в других проприетарных и нет системах? или другие СУБД выпускают абсолютно безбажные релизы?
не увидел, как вышесказанное очевидно, что система не может завоевать популярность. Да не сильно популярна, но развивается, и новые проекты создаются и не только на Caché но и на бесплатной GT.M.
и кстати о каких таких фишках 70-ых-80-ых речь?
У меня актуальность сведений примерно 2009-2010 год. Возможно, что с тех пор что-то улучшилось. Во всяком случае, сайт сейчас почистили. Раньше там было написано, что Caché выполняет SQL-запросы «five times faster than relational databases». Может быть специально для маркетологов и придумали такой test case. Но на фоне повисающих из-за корявых планов простых SQL запросов на небольших объёмов данных, это смелое утверждение смотрелось как насмешка. Ещё помню, что были описаны такие уникальные технические фишки, как компактное хранение null'ов (т.е. null map или его аналог). Якобы в реляционных СУБД NULL значения занимают очень много места.
Возможно, что и политика релизов изменилась с тех пор. На момент моей работы с Caché, о том, что не выпускаются баг-фиксы, а только новые релизы, мне рассказал преподаватель Caché. Но тогда, исправления багов мне не удалось добиться вообще. Поддержка лишь разводила руками, предлагали перейти на новый релиз. Инженер по телефону объяснял, что ему некогда заниматься моей ерундой. Я, мол, сам виноват, что использую то, что сам не протестировал. Вот, когда на крупном внедрении транзакции перестают откатываться, он сидит и день и ночь. Пробовал переходить на новый релиз, а в новом релизе были новые баги. Поэтому я просто вставлял костыли, чтобы обойти неработающую функциональность Caché.
Чтобы не быть голословным по поводу уровня поддержки SQL, приведу один пример. Читаю на хабре статью про новинки Caché 2014.1. Оказывается, теперь Caché хранит селективность одного самого частого значения в колонке. Читаю release notes PostgreSQL 7.2 от 2002 года. PostgreSQL начинася с версии 7.2 хранит для колонок гистограмму с распределениям значений (в дополнение к частотам самых частых значений). Я даже не спрашиваю, почему пробелы в критических точках SQL устраняются так чертовки медленно. Интересно, почему если уж взялись за проблему, не сделать по аналогии с проверенными временем решениями из Open Source? Или поискать решение в Google Scholar?
Идея объединения SQL и NoSQL в Caché мне не очень понятна. Понятно, что я могу иметь отдельно глобалы, а отдельно — таблицы, объекты. Но этого же я могу добиться, используя 2 и более разных СУБД. Много проектов используют одновременно реляционную и key-value СУБД, например PostgreSQL и Redis. А вот доступ через SQL и глобалы к одним и тем же данным мне не понятен. Если я захочу что-то поменять через глобалы, я должен буду обновить также все вручную все индексы. А если добавлю индекс к таблице, то мне нужно будет вручную править свой код. Может быть реальный use-case — это писать свой код для обхода глобалов, чтобы компенсировать недостатки планировщика SQL? Из комментария ниже я понял, что это действительно так. Но при настолько отсталом планировщике, вам не кажется это издевательством?
Ещё интересный момент, касающийся сочетания разных способов доступа. Что происходит, когда я в определении класса добавляю индекс? SQL запросы начинают выдавать неверный результат. Видимо, это какое-то инновационное понимание consistency.
Есть и другое понимание объединения SQL и NoSQL. Сейчас всё популярнее хранение слабо-структурированных данных в рамках реляционной модели. Можете посмотреть презентацию на эту тему. Коммерческие реляционные СУБД тоже подтягиваются в этом плане.
Раскрою свою мысль и про объектный доступ. В пресс релизах Caché, он был описан как «мощный объектный доступ». Что там предлагается сейчас, не проверял. Но на тот момент, когда я с Caché работал, получить объект можно было только по id или по связи с другим объектом. Т.е. чтобы сделать выборку, приходилось вначале выбрать id SQL-запросом. В то время, как в любой популярной ORM на тот момент, были удобные объектные интерфейсы для формирования выборок.
Вот такая изнанка была у проекта, который, между прочим, стал «прорывом года» на одном из симпозиумов InterSystems.
Возможно, что и политика релизов изменилась с тех пор. На момент моей работы с Caché, о том, что не выпускаются баг-фиксы, а только новые релизы, мне рассказал преподаватель Caché. Но тогда, исправления багов мне не удалось добиться вообще. Поддержка лишь разводила руками, предлагали перейти на новый релиз. Инженер по телефону объяснял, что ему некогда заниматься моей ерундой. Я, мол, сам виноват, что использую то, что сам не протестировал. Вот, когда на крупном внедрении транзакции перестают откатываться, он сидит и день и ночь. Пробовал переходить на новый релиз, а в новом релизе были новые баги. Поэтому я просто вставлял костыли, чтобы обойти неработающую функциональность Caché.
Чтобы не быть голословным по поводу уровня поддержки SQL, приведу один пример. Читаю на хабре статью про новинки Caché 2014.1. Оказывается, теперь Caché хранит селективность одного самого частого значения в колонке. Читаю release notes PostgreSQL 7.2 от 2002 года. PostgreSQL начинася с версии 7.2 хранит для колонок гистограмму с распределениям значений (в дополнение к частотам самых частых значений). Я даже не спрашиваю, почему пробелы в критических точках SQL устраняются так чертовки медленно. Интересно, почему если уж взялись за проблему, не сделать по аналогии с проверенными временем решениями из Open Source? Или поискать решение в Google Scholar?
Идея объединения SQL и NoSQL в Caché мне не очень понятна. Понятно, что я могу иметь отдельно глобалы, а отдельно — таблицы, объекты. Но этого же я могу добиться, используя 2 и более разных СУБД. Много проектов используют одновременно реляционную и key-value СУБД, например PostgreSQL и Redis. А вот доступ через SQL и глобалы к одним и тем же данным мне не понятен. Если я захочу что-то поменять через глобалы, я должен буду обновить также все вручную все индексы. А если добавлю индекс к таблице, то мне нужно будет вручную править свой код. Может быть реальный use-case — это писать свой код для обхода глобалов, чтобы компенсировать недостатки планировщика SQL? Из комментария ниже я понял, что это действительно так. Но при настолько отсталом планировщике, вам не кажется это издевательством?
Ещё интересный момент, касающийся сочетания разных способов доступа. Что происходит, когда я в определении класса добавляю индекс? SQL запросы начинают выдавать неверный результат. Видимо, это какое-то инновационное понимание consistency.
Есть и другое понимание объединения SQL и NoSQL. Сейчас всё популярнее хранение слабо-структурированных данных в рамках реляционной модели. Можете посмотреть презентацию на эту тему. Коммерческие реляционные СУБД тоже подтягиваются в этом плане.
Раскрою свою мысль и про объектный доступ. В пресс релизах Caché, он был описан как «мощный объектный доступ». Что там предлагается сейчас, не проверял. Но на тот момент, когда я с Caché работал, получить объект можно было только по id или по связи с другим объектом. Т.е. чтобы сделать выборку, приходилось вначале выбрать id SQL-запросом. В то время, как в любой популярной ORM на тот момент, были удобные объектные интерфейсы для формирования выборок.
Вот такая изнанка была у проекта, который, между прочим, стал «прорывом года» на одном из симпозиумов InterSystems.
По поводу SQL ничего мне сказать, если честно, больше потому что использую очень редко, и чаще это достаточно простые запросы, но знаю на своем опыте что SQL в Caché можно оптимизировать самостоятельно, и инструментов для этого к счастью становится все больше с каждым новым релизом.
Насчет разделения SQL и NoSQL, я бы наверно не согласился, наверно просто не понимаю как это могло бы выглядеть и как с этим работать.
Не помню как на старых версиях, но сейчас точно, открыть объект можно по ключу индекса, когда объявлен уникальный индекс по одному или нескольким полям, по ним можно открыть объект одним вызовом, без SQL.
Возможно к сожалению я не знаю, как работают другие СУБД, ни реляционные, ни NoSQL. Моё небольшое знакомство было только с MySQL, еще до Caché. с тех пор и MySQL, уже у Oracle и много других СУБД появилось. Но мне вполне хватает Caché, чего не хватает сами делаем. Для работы над теми проектами где мне приходилось работать и продолжаю работать, достаточно знаний и опыта в Caché, и пока этого хватает.
по поводу планировщика sql, не думаю что в любой другой СУБД, на любым данных запросы будут сразу быстро бегать без оптимизации, и все равно нужно пользоваться определенными инструментами, чтобы оптимизировать индексы, сами запросы и прочее, чтобы запросы забегали с хорошей скоростью. И чем это отличается от Caché?
Насчет разделения SQL и NoSQL, я бы наверно не согласился, наверно просто не понимаю как это могло бы выглядеть и как с этим работать.
Не помню как на старых версиях, но сейчас точно, открыть объект можно по ключу индекса, когда объявлен уникальный индекс по одному или нескольким полям, по ним можно открыть объект одним вызовом, без SQL.
Возможно к сожалению я не знаю, как работают другие СУБД, ни реляционные, ни NoSQL. Моё небольшое знакомство было только с MySQL, еще до Caché. с тех пор и MySQL, уже у Oracle и много других СУБД появилось. Но мне вполне хватает Caché, чего не хватает сами делаем. Для работы над теми проектами где мне приходилось работать и продолжаю работать, достаточно знаний и опыта в Caché, и пока этого хватает.
по поводу планировщика sql, не думаю что в любой другой СУБД, на любым данных запросы будут сразу быстро бегать без оптимизации, и все равно нужно пользоваться определенными инструментами, чтобы оптимизировать индексы, сами запросы и прочее, чтобы запросы забегали с хорошей скоростью. И чем это отличается от Caché?
В PostgreSQL планировщик запросов достаточно умён, чтобы в подавляющем большинстве случаев оптимизировать план запроса под ваши данные на основе статистики по таблицам, развернуть Join в другую сторону, выбрать правильный алгоритм join'а, и вообще «сделать хорошо». Ошибки редки и в большинстве своём чинятся чтением EXPLAIN (ANALYZE) от запроса, хлопаньем себя по лбу и высказыванием «вот я дурак» (обычно 1..10 минут).
Что такое в случае Caché «оптимизировать SQL самостоятельно»? Какие инструменты кроме EXPLAIN / ANALYZE / auto_explain для этого могут быть в принципе нужны? Значит ли это, что при выборе Caché на самом деле у меня нет опции писать на SQL, и всё придётся переписывать на вендор-лоченом собственном языке, с которого просто некуда мигрировать?
По поводу SQL и NoSQL: стандартная нынче архитектура высоконагруженной системы обычно включает в себя:
— frontend, штука, которая очень быстро асинхронно общается с пользователем — пишется самостоятельно, иногда может выродиться в конфиг nginx;
— cache, in-memory key-value хранилище с экспайрингом, обычно redis/memcache, хранящее наиболее популярные read-запросы к фронтенду (используется, когда у приложения большой read);
— mq, брокер очередей сообщений — штука, которая занимается асинхронностью и распределением нагрузки по узлам, в которую фронтенд складирует write-запросы и прочие вызовы долгих процедур (используется, соответственно, при наличии большого потока на write; обычно rabbitmq / rq);
— worker, который разгребает queue и выполняет все долгие записи и рассчёты, а зачастую и заполняющий кеш — пишется самостоятельно;
— persistent storage, база данных-хранилка, в которой надёжно лежат все данные — вот тут уже кто во что горазд, postgresql / mysql / mongodb.
Из комментариев ниже я понял, что Caché претендует на то, чтобы быть frontend и persistent storage. А что у него с кешем в памяти? Может ли Caché удобно и эффективно менеджить очередь сообщений (вообще, есть ли там понятие сообщений?)
«Но мне вполне хватает Caché, чего не хватает сами делаем.» — пугающая фраза.
Значит ли это, что при выборе Caché как базы я обречён становиться её разработчиком?
Идут ли в комплекте с лицензией исходные тексты Caché?
Значит ли это, что при использовании Caché у меня перестанет хватать времени на самообразование и я не смогу эффективно разрабатывать систему, потому что я не смогу брать готовые блоки и мне придётся всё переписывать заново?
В хорошей high-load архитектуре вся фишка как раз в том и состоит — время на оптимизацию не тратится, кроме совсем критических перформанс-проседаний, которые уже считаются багами, «потому что один идиот заселектил всю таблицу и фильтрует её в коде».
Пока что я вижу, что этот самый быдлокодерский кошмарный сон DBA в Caché считается подходом по умолчанию, и это сеет недоверие к продукту.
Что такое в случае Caché «оптимизировать SQL самостоятельно»? Какие инструменты кроме EXPLAIN / ANALYZE / auto_explain для этого могут быть в принципе нужны? Значит ли это, что при выборе Caché на самом деле у меня нет опции писать на SQL, и всё придётся переписывать на вендор-лоченом собственном языке, с которого просто некуда мигрировать?
По поводу SQL и NoSQL: стандартная нынче архитектура высоконагруженной системы обычно включает в себя:
— frontend, штука, которая очень быстро асинхронно общается с пользователем — пишется самостоятельно, иногда может выродиться в конфиг nginx;
— cache, in-memory key-value хранилище с экспайрингом, обычно redis/memcache, хранящее наиболее популярные read-запросы к фронтенду (используется, когда у приложения большой read);
— mq, брокер очередей сообщений — штука, которая занимается асинхронностью и распределением нагрузки по узлам, в которую фронтенд складирует write-запросы и прочие вызовы долгих процедур (используется, соответственно, при наличии большого потока на write; обычно rabbitmq / rq);
— worker, который разгребает queue и выполняет все долгие записи и рассчёты, а зачастую и заполняющий кеш — пишется самостоятельно;
— persistent storage, база данных-хранилка, в которой надёжно лежат все данные — вот тут уже кто во что горазд, postgresql / mysql / mongodb.
Из комментариев ниже я понял, что Caché претендует на то, чтобы быть frontend и persistent storage. А что у него с кешем в памяти? Может ли Caché удобно и эффективно менеджить очередь сообщений (вообще, есть ли там понятие сообщений?)
«Но мне вполне хватает Caché, чего не хватает сами делаем.» — пугающая фраза.
Значит ли это, что при выборе Caché как базы я обречён становиться её разработчиком?
Идут ли в комплекте с лицензией исходные тексты Caché?
Значит ли это, что при использовании Caché у меня перестанет хватать времени на самообразование и я не смогу эффективно разрабатывать систему, потому что я не смогу брать готовые блоки и мне придётся всё переписывать заново?
В хорошей high-load архитектуре вся фишка как раз в том и состоит — время на оптимизацию не тратится, кроме совсем критических перформанс-проседаний, которые уже считаются багами, «потому что один идиот заселектил всю таблицу и фильтрует её в коде».
Пока что я вижу, что этот самый быдлокодерский кошмарный сон DBA в Caché считается подходом по умолчанию, и это сеет недоверие к продукту.
Оптимизация sqlв каше, сводится в большинстве случаев к выбору какие индексы нужно добавить. Неужели в любимой вами пострес, и индексы автоматически подсказывает и добавляет и сразу проиндексирует их?
При наличии достаточно большого объема (в сравнении с вашим объемом бд). Наиболее часто используемые данные будут браться из кеша, и чтение будет достаточно быстрым. Так же естьи была бд CACHETEMP. Данные этой бд хранятся в буфере глобалов насколько это возможно, так же изменения в эту бд никогда не журналируются и естественно не попадают под транзакции, что хорошо влияет на производительность.
если я правильно понял про очередь, это очередь записи, вся запись в бд производится WriteDaemon, специальный процесс который и пишет сам данные в бд, и скорость записи в больширстве случаев не влияет на работу процессов которые эти данные меняли и хотят получить измененные.
Но я не понял про управление очередью сообщений.
Ну не то чтобы многоприходится делать, в основном это про удобные инструменты разработчика, например единственная на данный момент среда для разработки, но сейчас несколько проектов которые хотят изменить это, в том числе и мой.
При наличии достаточно большого объема (в сравнении с вашим объемом бд). Наиболее часто используемые данные будут браться из кеша, и чтение будет достаточно быстрым. Так же естьи была бд CACHETEMP. Данные этой бд хранятся в буфере глобалов насколько это возможно, так же изменения в эту бд никогда не журналируются и естественно не попадают под транзакции, что хорошо влияет на производительность.
если я правильно понял про очередь, это очередь записи, вся запись в бд производится WriteDaemon, специальный процесс который и пишет сам данные в бд, и скорость записи в больширстве случаев не влияет на работу процессов которые эти данные меняли и хотят получить измененные.
Но я не понял про управление очередью сообщений.
Ну не то чтобы многоприходится делать, в основном это про удобные инструменты разработчика, например единственная на данный момент среда для разработки, но сейчас несколько проектов которые хотят изменить это, в том числе и мой.
Advanced Message Queuing Protocol: www.amqp.org/ — международный стандарт для очередей сообщений.
Пользуясь вашей терминологией: хотите знать больше, гуглите.
Пользуясь вашей терминологией: хотите знать больше, гуглите.
Что такое в случае Caché «оптимизировать SQL самостоятельно»? Какие инструменты кроме EXPLAIN / ANALYZE / auto_explain для этого могут быть в принципе нужны? Значит ли это, что при выборе Caché на самом деле у меня нет опции писать на SQL, и всё придётся переписывать на вендор-лоченом собственном языке, с которого просто некуда мигрировать?
Предлагают вручную писать код, который обходит Б-деревья (в терминологии Caché — работает с глобалами). Как самостоятельный способ выполнения запросов, такой подход вполне имеет право на жизнь. Что-то похожее предлагает, например, Tarantool. Но вот только Tarantool — это специализированная СУБД, которая вообще не поддерживает SQL. В то время как Caché позиционируется как СУБД общего назначения, поддерживающая SQL.
Предлагают вручную писать код, который обходит Б-деревья (в терминологии Caché — работает с глобалами).
В Caché B-деревья никто не обходит. Глобалы действительно хранятся в виде B-дерева, но это физический уровень хранения, о котором заботится движок, и не нужно думать, где именно лежат блоки данных в B-дереве.
В Caché при «ручном» выполнении запросов обходятся собственно глобалы, и таких видов обхода ровно два.
Функция $Order- перебор ключей на определенном уровне индексов глобала. Документация.
Вот пример обхода всех записей класса Sample.Person и вывода их на текущее устройство.
set personid=$Order(^Sample.PersonD("")) // берем первый ID человеков
while personid {
set person=##class(Sample.Person).%OpenId(personid) // открываем объект по id
do person.PrintPerson() // выводим данные человека на устройство
set personid=$Order(^Sample.PersonD(personid)) // берем ID следующего человека
}
Структура хранения класса в глобалах описана в исходном коде класса в блоке XData.
Функция $Query — обход всего глобала, учитывая все вложенные индексы. Документация.
Но вот только Tarantool — это специализированная СУБД, которая вообще не поддерживает SQL.Я бы не сказал, что это преимущество Tarantool.
по поводу планировщика sql, не думаю что в любой другой СУБД, на любым данных запросы будут сразу быстро бегать без оптимизации, и все равно нужно пользоваться определенными инструментами, чтобы оптимизировать индексы, сами запросы и прочее, чтобы запросы забегали с хорошей скоростью. И чем это отличается от Caché?
Если смотреть крупным планом, то да, любой планировщик не идеален. Но всегда есть определённый state of art. Если набор техник, которые ведущие производители взяли на вооружение. Для реляционных СУБД таким state of art является MVCC, cost based optimizer и многое другое. А когда ты видишь реализацию SQL в Caché, отстающий от этого state of art на десятилетия, возникает определённый диссонанс. И когды ты видел, как другая база нормально справлялась с запросами по 100 КБ, то тебе не очень хочется переписывать свой запрос из 3-ёх JOIN'ов напрямую через глобалы. Может быть, если смотреть на Caché как на вещь в себе, не зная про другие СУБД, то всё ок. Но я уж буду обходить её стороной.
Caché основана на системе MUMPS, уходящей корнями ещё в 60-ые годы. Там был весьма специфичный язык программирования, в котором используется очень много псевдографики, и встроенная возможность хранения данных в Б-дереве, которое из этого языка программирования видно как вложенный массив (именно «вложенный», термин «многомерный» добавляется исключительно для понтов). Для своих лет, вероятно, система была довольно продвинутой.
Про MUMPS все верно. Действительно в 60-е и 70-е была весьма продвинутой системой. Более того: в 80-х ее даже скопировали в СССР вместе с PDP-11 и создали советский MUMPS — Диамс и распространили на всю страну. Кое где это чудо до сих пор работает(!) еще на тех же СМ-ках (порт в Магадане, колхозы в Беларуси). Подробности можно нагуглить, вот интересный рассказ. В мире осталось несколько инкарнаций MUMPS, самая массовая это GT.M, есть и российская реализация. Есть и апологеты. Термин «вложенный массив» — ваш? Про псевдографику в коде — это про что конкретно?
Caché, с свою очередь, является попыткой модернизировать MUMPS до уровня 21ого века. В язык программирования была добавлена объектность и прочие современные возможности, в результате чего он стал странным смешением псевдографики и современного синтаксиса. Для хранения данных были добавлены SQL и объектный доступ, реализованные на базе этих самых вложенных массивов, пресловутых глобалов. При этом оба эти новых способа доступа получились очень отсталыми на фоне тех возможностей, которые предоставляются современными реляционными СУБД и ORM. Об их недостатках можно говорить очень много, я не хочу сейчас распылять на этом внимание. Достаточно сказать, что SQL в Caché застрял на уровне стандарта 92-ого года, самый сильный поддерживаемый уровень изоляции данных там read committed (не настоящий, с нарушениями), планировщик запросов путается в JOIN'ах 3ёх таблиц.
В Caché тоже можно писать «как в MUMPS». Но зачем? На курсах обучения InterSystems этому не учат — а учат, как эффективно писать приложения на Caché с использованием объектного подхода, SQL и прямого доступа к глобалам, где это необходимо. Вы проходили обучение в InterSystems?
SQL 92 да. Но скажите, какие отличительные возможности SQL 2011 от SQL 92 вы используете в своей работе каждый день? Думаю, если нашим клиентам будет не хватать SQL 2011, такую поддержку сделают. В CachéSQL есть свои удобные расширения тоже.
Оптимизатор SQL возможно не лучший в мире, хотя и постоянно улучшается. Но! В Caché всегда есть возможность написать свою реализацию работы конкретного SQL-запроса, если SQL не справляется.
Про отсталость объектной СУБД по сравнению с ORM — можно подробности? ИМХО в случае с .NET и Java bindings Caché как раз убирает оверхэд на объектно-реляционное преобразование, которое есть в некоторых ORM.
Но всё это компенсируется агрессивностью маркетинга. Он не перестаёт кричать, что них круче всё и вся, зачастую выдавая новейшие технологические фишки из 70-ых-80-ых годов прошлого века.
А где Вы нашли агрессивный маркетинг? Помоему его вообще почти нет в России — я не вижу в аэропортах и на улицах биллбордов о сверхскоростной и надежной СУБД Caché.
Из вышесказанного очевидно, что такая система не может завоевать популярность и признание у широкого круга разработчиков. Её судьба — замкнуться в рамках узкой «секты» и не выходить за её пределы. Отражение этого процесса мы можем видеть и на хабре.
Видимо, у Вас был негативный опыт с СУБД Caché. ИМХО на любой платформе можно писать хорошо и плохо. Примеры «ада» написанного на Caché и MUMPS есть, что справедливо также для любого языка вообще. Но, есть и весьма впечатляющие системы с десятками тысяч одновременных пользователей в том числе в России и СНГ, построенные на технологиях InterSystems.
Для меня Caché — это СУБД, которая весьма эффективно и, что важно, очевидно и поддерживаемо позволяет манипулировать данными произвольной сложности. И продуктивно выдавать их во внешние системы для UI с помощью JSON, вебсервисов, SQL и т.п. Также подкупает легкость администрирования и масштабирования системы.
И да, я работаю в InterSystems.
Псевдографика в коде — это когда в одной строке кода очень много разных знаков $%^& и т.д., причём идут они зачастую подряд. В системных классах Caché, такого можно насмотреться много. На самом деле это не самое большое замечание, я понимаю, что к такому синтаксису тоже можно привыкнуть. Не ставлю это в центр своей критики. Хотя сам Caché Object Script показался сделанным довольно топорно. Например, показалась непродуманной реализация множественного наследования.
Было бы неплохо и сам SQL-92 полноценно поддерживать, включая изоляцию транзакций. Среди всех возражений на мой первоначальный комментарий, никто не спорил с тем, что нет даже честного read committed. А ведь, чтобы собрать сложный отчёт на нагруженный базе, бывает очень нужен repeatable read. Среди не самых критичных замечаний к SQL в Caché, я бы называл отсутствие приоритета операций, отсутствие поддержки выражений в ORDER BY. Функции работы с XML (XMLELEMENT, XMLFOREST, XMLAGG) — это, наверное, изюминка реализации SQL в Caché, единственная фича стандарта SQL-2003, которую мне удалось там найти. Но даже они не работают как надо, сказывается отсутствие типизации: XML елемент, собранный одной функцией и подставленный в другую, воспринимается как строка.
CTE, RECURSIVE CTE, WINDOW FUNCTION, LATERAL JOIN — всё это придумали не ради академических изысканий, а для решения сугубо практических задач. И да, я использую их на практике, хотя и не каждую конструкцию каждый день.
Про то, на каком уровне планировщик и как он развивается, я на наглядном примере объяснил выше. Caché 2014.1 делает маленький шажок в улучшении статистики. Но при этом до уровня PostgreSQL 7.2 от 2002 года ещё как до Китая. На месте сотрудника InterSystems я бы сгорал от стыда. Но нет, вы предлагаете коменсировать это ручным трудом: реализовывать алгоритмы обхода глобалов самостоятельно.
Про объектность и ORM я тоже уже написал выше. Я не пробовал доступ из .NET и Java, но из самой Caché я не мог получить объект, иначе как по значению уникального индекса. Для любых выборок предлагалось использовать SQL. Хотя любой ORM мог похвастаться наличием объектного интерфейса для этого.
Моего опыта работы с Caché хватило, чтобы твёрдо принять решение, ничего общего больше с этим продуктом не иметь. В своих комментариях, я, насколько мог, объяснил это. Я не планирую тратить сейчас много времени на то, чтобы углубляться в проблему сильнее, чем я уже углубился. Надеюсь, что мой опыт будет полезен кому-то в том виде, в котором я его изложил.
Было бы неплохо и сам SQL-92 полноценно поддерживать, включая изоляцию транзакций. Среди всех возражений на мой первоначальный комментарий, никто не спорил с тем, что нет даже честного read committed. А ведь, чтобы собрать сложный отчёт на нагруженный базе, бывает очень нужен repeatable read. Среди не самых критичных замечаний к SQL в Caché, я бы называл отсутствие приоритета операций, отсутствие поддержки выражений в ORDER BY. Функции работы с XML (XMLELEMENT, XMLFOREST, XMLAGG) — это, наверное, изюминка реализации SQL в Caché, единственная фича стандарта SQL-2003, которую мне удалось там найти. Но даже они не работают как надо, сказывается отсутствие типизации: XML елемент, собранный одной функцией и подставленный в другую, воспринимается как строка.
CTE, RECURSIVE CTE, WINDOW FUNCTION, LATERAL JOIN — всё это придумали не ради академических изысканий, а для решения сугубо практических задач. И да, я использую их на практике, хотя и не каждую конструкцию каждый день.
Про то, на каком уровне планировщик и как он развивается, я на наглядном примере объяснил выше. Caché 2014.1 делает маленький шажок в улучшении статистики. Но при этом до уровня PostgreSQL 7.2 от 2002 года ещё как до Китая. На месте сотрудника InterSystems я бы сгорал от стыда. Но нет, вы предлагаете коменсировать это ручным трудом: реализовывать алгоритмы обхода глобалов самостоятельно.
Про объектность и ORM я тоже уже написал выше. Я не пробовал доступ из .NET и Java, но из самой Caché я не мог получить объект, иначе как по значению уникального индекса. Для любых выборок предлагалось использовать SQL. Хотя любой ORM мог похвастаться наличием объектного интерфейса для этого.
Моего опыта работы с Caché хватило, чтобы твёрдо принять решение, ничего общего больше с этим продуктом не иметь. В своих комментариях, я, насколько мог, объяснил это. Я не планирую тратить сейчас много времени на то, чтобы углубляться в проблему сильнее, чем я уже углубился. Надеюсь, что мой опыт будет полезен кому-то в том виде, в котором я его изложил.
Прокомментирую касательно уровня изоляции транзакций.
Если мы возьмём «лидера» индустрии — Oracle — то там наличествуют лишь два уровня:
при этом понятно, что единственным «рабочим» является как раз read committed, и в этом режиме Oracle будет работать эффективнее, чем Caché (Caché в этом случае поставит блокировку и «затормозит» параллельные процессы, ожидающие доступа к разделяемым данным, до тех пор, пока в текущем процессе не будет выполнен commit).
Однако уровень read committed нужен далеко не всегда, и Caché в read uncommitted будет работать эффективнее, чем Oracle в read committed.
Apache Derby, например, поддерживает все 4 уровня изоляции, но при этом для меня она не перестаёт оставаться «игрушечной» СУБД.
Теперь по поводу ANSI SQL 92. Давайте будем различать формальное соответствие и фактическую реализацию. Многие конструкции, входящие в более поздние стандарты, Caché SQL поддерживает уже, недостающие продолжают добавляться. Добавим к этому расширяемую систему типов и возможность вызова функций MUMPS/ObjectScript непосредственно из SQL-выражений — и вы получаете диалект SQL, не уступающий по мощности тому, что предлагают Oracle/DB2/Sybase.
Система релизов Caché несколько сложнее, чем Вы здесь представили. Исправления, для которых можно сделать бэкпорт, портируются назад — иногда на 3-4 релиза назад, т. е. исправления, впервые сделанные в 2014.1, Вы можете наблюдать, скажем, в 2012.2. Для каждой ветки выходит до 8 maintenance-релизов (так, для 2010.2 последний выпущенный — 2010.2.8). Всё познаётся в сравнении. Либо Вы работаете в компании Oracle, либо у Вас не было «приятного» опыта работы с Oracle MetaLink.
Если мы возьмём «лидера» индустрии — Oracle — то там наличествуют лишь два уровня:
- Read committed и
- Serializable,
при этом понятно, что единственным «рабочим» является как раз read committed, и в этом режиме Oracle будет работать эффективнее, чем Caché (Caché в этом случае поставит блокировку и «затормозит» параллельные процессы, ожидающие доступа к разделяемым данным, до тех пор, пока в текущем процессе не будет выполнен commit).
Однако уровень read committed нужен далеко не всегда, и Caché в read uncommitted будет работать эффективнее, чем Oracle в read committed.
Apache Derby, например, поддерживает все 4 уровня изоляции, но при этом для меня она не перестаёт оставаться «игрушечной» СУБД.
Теперь по поводу ANSI SQL 92. Давайте будем различать формальное соответствие и фактическую реализацию. Многие конструкции, входящие в более поздние стандарты, Caché SQL поддерживает уже, недостающие продолжают добавляться. Добавим к этому расширяемую систему типов и возможность вызова функций MUMPS/ObjectScript непосредственно из SQL-выражений — и вы получаете диалект SQL, не уступающий по мощности тому, что предлагают Oracle/DB2/Sybase.
Система релизов Caché несколько сложнее, чем Вы здесь представили. Исправления, для которых можно сделать бэкпорт, портируются назад — иногда на 3-4 релиза назад, т. е. исправления, впервые сделанные в 2014.1, Вы можете наблюдать, скажем, в 2012.2. Для каждой ветки выходит до 8 maintenance-релизов (так, для 2010.2 последний выпущенный — 2010.2.8). Всё познаётся в сравнении. Либо Вы работаете в компании Oracle, либо у Вас не было «приятного» опыта работы с Oracle MetaLink.
Sign up to leave a comment.
Caché Native Access — работаем с нативными библиотеками в Caché