Я наткнулся на несколько утверждений о том, что использование CacheDB вместо проверенных RDBMS. Но я не мог понять, как это лучше, чем РСУБД? если да, то почему они префикс кэша?
Это RDBMS или сервер Caché? Не могли бы вы написать краткие заметки о прецеденте в вашем проекте?
Кэш - это уникальный зверь, в зависимости от того, как вы его используете, тогда его можно охарактеризовать как базу данных без SQL, RDBMS или объектно-ориентированную базу данных. Конечно, это не все вещи для всех людей, поэтому знание того, каким образом каждому из них нужно какое-то объяснение.
Все это построено на основе предреляционного процедурного языка под названием MUMPS (ужасное маркетинговое название, которое ужасно для Googling, поэтому теперь они просто используют Кэш, который ужасен только для Googling). Этот язык включает операции по сохранению данных в качестве собственных команд, поэтому механизм персистентности можно оптимизировать, не затрагивая код приложения.
Этот язык имеет один тип коллекции, словарь ключей/значений с 0 или более отсортированными ключами и один тип данных, в котором операторы выполняют строгие вещи и другие, чтобы делать несколько вещей. Все ключи и значения являются экземплярами этого типа данных.
Это было в течение долгого времени, а приложения, написанные на протяжении всего этого времени, еще не выполнялись.
Этот язык предшествует первой СУБД, но позже разработчики добавленной RDBMS поддержки языка. Кэш компилирует SQL (статически или динамически) в более современную версию MUMPS, которая затем управляет движком хранения. Если это звучит странно, на самом деле это не так - каждая РСУБД компилирует или интерпретирует SQL в направлениях для этого механизма хранения.
Кэш превратился в объектно-ориентированный язык (как и многие другие языки со временем), что означает, что теперь есть 2 типа данных, исходный и тип объекта. Объекты не могут быть сохранены как ключи или значения на диске напрямую, но могут наследовать или применять методы сохранения.
Поэтому люди, использующие Cache, могут использовать объектно-ориентированный код, SQL или процедурный код или комбинировать их по своему усмотрению.
Каковы преимущества и недостатки?
Для пользователей, работающих с устаревшими приложениями MUMPS, у них практически нет выбора, поэтому я сосредоточусь на всех остальных.
Большой недостаток заключается в том, что он имеет небольшую долю на рынке (по сравнению с другими РСУБД, хотя вместо этого его можно сравнить с другими продуктами) и оценивается в одном и том же рабочем месте как коммерческая СУБД (хотя, вероятно, намного легче работать для индивидуальной сделки для какого-то конкретного своеобразного использования), поэтому для его покупки должна быть какая-то веская причина.
Кроме того, небольшая доля рынка означает меньший рынок для разработчиков. Кроме того, различные способы его использования означают, что не все разработчики кэша подходят для всех проектов: кто-то, кто поддерживает предыдущее приложение (от ранее организованного программирования) в течение последних 20 лет, может не очень хорошо использовать Cache для объектно-ориентированной сети приложения.
Другая проблема заключается в том, что библиотек кода практически не существует вне того, что предлагает Intersystems (поставщик), и они не могут конкурировать с чем-то вроде .NET или Java в размере.
Большим преимуществом является то, что объект Cache Script (современный язык MUMPS) намного больше, чем обычно, в базе данных. Это скорее преимущество, чем больше бизнес-логики в базе данных.
На самом деле, IMHO большинство преимуществ кеша приходят, если вы используете его для своей бизнес-логики. Сочетание базы данных и бизнес-логики намного проще, проще получить высокую производительность и не особенно приводит к долгосрочным проблемам обслуживания, когда среда так сильно его поддерживает.
Недостатком комбинирования базы данных и бизнес-логики в кэше является то, что перенос либо будет довольно сложным, и, как правило, ваша бизнес-логика написана на свободном языке, и вам не нужна лицензия любого вида для ее запуска. Здесь вы в значительной степени находитесь в одной лодке, как если бы ваша бизнес-логика находилась в TSQL, за исключением того, что еще труднее порт.
Если вы O.K. с этим, однако, многие вещи прекрасны. Нет ORM - коммерческий или ручной код. SQL скомпилирован в код, на который вы можете смотреть (он сгенерирован таким образом, что он оптимизирован для скорости чтения, а имена переменных могут быть такими же, как "T32", но они все еще доступны для чтения, если вам нужно), даже шаг за шагом или точка останова. Стоимость написания курсоров SQL очень низкая. Вы можете написать объектно-ориентированный код. Он интерпретировался, так что легче развиваться быстро. Если вы хотите скорость, вы можете отключить транзакции и пойти без SQL.
Я также нашел, что это очень легко администрировать. В большинстве моих опытов с ним нет такой вещи, как DBA - вам просто не нужен.
Межсистемный кэш может быть определен как объектно-ориентированная база данных.
Я думаю, что это обычная база данных RDBMS с объектно-ориентированным сценарием. Oracle хранит procs, Cache имеет объект script.
Мы переходим к кэшу Intersystems, чтобы использовать их инструменты BI и отчетности. Я до сих пор не столкнулся с ситуацией, которая не может быть решена с помощью хранимой процедуры MySQL или Oracle. Я предпочитаю писать все в процедурах SQL, чтобы избежать будущих головных болей миграции.
Люди с сильным объектно-ориентированным фоном могут предпочесть использование ObjectScript.
На всякий случай вы его не видели, вот их документация
Это не RDBMS по дизайну. Это объектная база данных. вы можете использовать интерфейс sql и просматривать данные, например, исходящие из традиционных RDBMS.
Я пытался это сделать несколько лет назад, просто для хобби проекта, в основном обучения.
Примечательно то, что перед "всем этим облачным материалом" у них уже была система, где вы можете хранить данные через один node, и он будет реплицировать его для нескольких других узлов. Поэтому, если вам нужно масштабирование, это можно сделать. Примерно 10 лет назад, когда тиражирование данных между базами данных осуществлялось в домашних инструментах, afaik. Они заявляют, что есть система с 50 КБ плюс люди, работающие онлайн с одной базой. Репликация может выполняться несколькими способами.
Данные хранятся в деревьях, они называются глобальными. И все, что вы храните, - это дерево. У них есть доступ к объектам, на самом деле объект в базе данных - это объекты на вашем языке (Objectcript, я думаю, что они поддерживали java). Существует реальное наследование в данных (глобальные переменные, вызов его таблицы будет неправильным). Таким образом, нет необходимости в hibernate/orm/jpa/... stuff.
Однако язык их хмм. Если вам нравится Perl один лайнер, вы в порядке. В противном случае это происходит.