Комментарии 9
Статьи по Cache на хабре всегда интересны, но складывается такое впечатление – требуется весьма низкоуровневое понимание этой технологии, чтобы эффективно с ней работать. Может быть я не так понимаю нишу этой технологии?
+1
Не так. Низкоуровневое понимание ненужно. Обращение к данным элементарно, как к индексированному массиву. Администрирование эпизодическое. Установка и настройка необходимого уровня архивирования. За много лет работы с CACHE мне ни разу не пришлось ремонтировать блоки. Есть архивы, журнал.
-2
Для начинающего в Caché такие знания не особо нужны, чтобы не забивать голову такими подробностями, на самом деле большинство разработчиков думаю о блоках знают, то что они есть, не особо вникая в сами процессы там возникающие. Все видели что есть буфер глобалов 8кБ, есть БД с 8кБ блоком, и большинству этого будет достаточно.
Что касается этой статьи, то это уже уверенный уровень владения Caché. И такие знания могут быть полезны, когда проекты становятся большими, и требуется выжать максимум из всего. Когда размеры БД становятся довольно большими, а диски перестают справляться с нагрузкой, тогда может стать полезным узнать а как можно ускорить чтение БД, как его можно оптимизировать.
И я почти уверен что такое возможно не только для Caché, наверняка в других СУБД есть порой необходимость выйти на низкий уровень, чтобы достичь поставленных целей.
Например, одна из задач которая у меня возникала, это узнать подробно сколько места занимает глобал, вес глобала нужно было знать на разных его уровнях. чтобы определить именно ту ветку которая занимает места больше всего, по той или иной причине. Это было распухание временного глобала. Таких инструментов не было в ранних версиях, и делал такой расчет обходя блоки, и вытаскивая из них нужную информацию.
Что касается этой статьи, то это уже уверенный уровень владения Caché. И такие знания могут быть полезны, когда проекты становятся большими, и требуется выжать максимум из всего. Когда размеры БД становятся довольно большими, а диски перестают справляться с нагрузкой, тогда может стать полезным узнать а как можно ускорить чтение БД, как его можно оптимизировать.
И я почти уверен что такое возможно не только для Caché, наверняка в других СУБД есть порой необходимость выйти на низкий уровень, чтобы достичь поставленных целей.
Например, одна из задач которая у меня возникала, это узнать подробно сколько места занимает глобал, вес глобала нужно было знать на разных его уровнях. чтобы определить именно ту ветку которая занимает места больше всего, по той или иной причине. Это было распухание временного глобала. Таких инструментов не было в ранних версиях, и делал такой расчет обходя блоки, и вытаскивая из них нужную информацию.
+3
Вход в технологию на самом деле ниже, чем кажется.
Нашим партнерам, которые начинают первый проект на технологиях InterSystems, часто достаточно одного двух спецкурсов чтобы уже через пару недель полноценно включиться в разработку проекта на Caché или Ensemble. Учитывая, что в большинстве проектов наших новых заказчиков мы помогаем сделать Proof-of-Concept, эффективность выбора технологии становится видимой очень быстро.
Если говорить о нишах: мы очень успешно делали и делаем интеграционные проекты с помощью платформы Ensemble.
Все случаи, где сейчас успешен NoSQL — там также будет успешна Caché, потому как по природе управления хранимыми данными Caché есть то, что сейчас называют NoSQL.
Традиционно Caché сильна в медицинских решениях со сложными и разреженными структурами данных, сложной логикой работы с данными, а также в высоконагруженных транзакционных системах — биржи, брокеры, банки.
Если есть сложная бизнес-логика, которую трудно распахивать с помощью SQL процедур — это тоже наше поле, т.к. Caché Object Script (COS) может в некоторых случаях намного эффективнее, быстрее и очевиднее управляться с данными, чем это делают хранимые процедуры в SQL серверах (это не критика SQL хранимых процедур — они эффективны, и у нас они тоже есть. Но существует много случаев, когда эффективнее COS). И, что немаловажно, такое решение легко поддерживаемо.
Наши партнеры и клиенты также могут сказать о низкой стоимости владения, о работе службе поддержки — но это уже наверно не релевантно хабру.
Нашим партнерам, которые начинают первый проект на технологиях InterSystems, часто достаточно одного двух спецкурсов чтобы уже через пару недель полноценно включиться в разработку проекта на Caché или Ensemble. Учитывая, что в большинстве проектов наших новых заказчиков мы помогаем сделать Proof-of-Concept, эффективность выбора технологии становится видимой очень быстро.
Если говорить о нишах: мы очень успешно делали и делаем интеграционные проекты с помощью платформы Ensemble.
Все случаи, где сейчас успешен NoSQL — там также будет успешна Caché, потому как по природе управления хранимыми данными Caché есть то, что сейчас называют NoSQL.
Традиционно Caché сильна в медицинских решениях со сложными и разреженными структурами данных, сложной логикой работы с данными, а также в высоконагруженных транзакционных системах — биржи, брокеры, банки.
Если есть сложная бизнес-логика, которую трудно распахивать с помощью SQL процедур — это тоже наше поле, т.к. Caché Object Script (COS) может в некоторых случаях намного эффективнее, быстрее и очевиднее управляться с данными, чем это делают хранимые процедуры в SQL серверах (это не критика SQL хранимых процедур — они эффективны, и у нас они тоже есть. Но существует много случаев, когда эффективнее COS). И, что немаловажно, такое решение легко поддерживаемо.
Наши партнеры и клиенты также могут сказать о низкой стоимости владения, о работе службе поддержки — но это уже наверно не релевантно хабру.
+1
Автору респект: подобные статьи особенно нужны, т.к. документация скупа на эту тему. Большинству из нас пришлось изучать структуру блоков с помощью REPAIR, пусть новичкам будет чуть полегче.
+3
Данная статья – очень большой прогресс во всём блоге. Но для тех, кто пользовался реляционными СУБД с MVCC, серьёзный подводный камень глобалов – это их модель конкурентности. Без понимания этих особенностей, от использования глобалов можно сильно проиграть в производительсности, вместо того, чтобы что-то выиграть. Надеюсь, в будущих постах, эта тема будет раскрыта.
+1
Хотелось бы подчеркнуть, что Дима DAiMor не является сотрудником InterSystems и, реализовав отличный инструмент просмотра структуры глобалов и карты распределения блоков, он пишет о том как можно изучать внутренности текущей реализации с использованием его внешнего инструмента. Ни больше и не меньше.
В следующих двух его постах он покажет (в картинках! :) ) как использовать его просмотрщик, и, боюсь там ни слова не будет про MVCC.
В следующих двух его постах он покажет (в картинках! :) ) как использовать его просмотрщик, и, боюсь там ни слова не будет про MVCC.
+1
С другой стороны, отходя от ткущего топика, да «блокировщики против версионщиков» важная тема, и её при случае надо рассмотреть. И, конечно же, над уметь правильно использовать глобалы и CacheSQL реализацию на оных.
А давайте Вы, Александр smagen попытаетесь написать такую статью, с Вашим пересечением экспертизы и в Caché и PostgreSQL?
А давайте Вы, Александр smagen попытаетесь написать такую статью, с Вашим пересечением экспертизы и в Caché и PostgreSQL?
+1
Экспертизы в Caché у меня нет. В 2008-2009 годах был печальный опыт использования объектного доступа и SQL в Caché. Никаких преимуществ от использования этих двух инструментов я на тот момент не заметил (возможно, сейчас, ситуация несколько изменилась). Дальше мой интерес к Caché двигался в основном ощущением несоответствия между тем, что я увидел на собственном опыте, и тем, что у продукта, есть клиенты, успешно выполненные проекты, коммерческий успех. До какой-то степени этот пробел я восполнил, но на экспертизу мои познания явно не тянут.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Блоки. Внутреннее устройство файла базы данных Caché