Comments 12
Мне кажется или "в реальном времени", "мгновенный отклик" никак не связаны с понятием OLTP?
Понятно, что всем хочется быстрее, но скорость принципом OLTP никак не постулируется. Да, и на практике время ожидания завершения транзакции бывает весьма ощутимым.
В 1980-х годах идея получила коммерческое воплощение. Компании, такие как Relational Database Systems (RDS), выпустили одну из первых реляционных СУБД Informix...
Ну, до 80-х уже были РСУБД. INGRES, System R в 74 вышли. Знаменитая Oracle в 79 появилась. Informix, поддерживающий SQL, вообще в 86 появился --- совсем не одним из первых. До него уже появилась "великая и ужасная" DB2 в 82-м году.
Нормализация делается не для повышения производительности, а для целостности данных. Для повышения производительности, как раз, частенько ДЕнормализацию делают. Ибо в сложном запросе столько JOIN-ов может быть, что ваша СУБД тихо "забудет" про вас, а вы отправитесь на перекур.
Впечатление, что автор смешал сам принцип транзакции онлайновой и особенности промышленных систем в практическом применении, где скорости реально важны.
Грубо говоря, есть сама суть и глубинный смысл OLTP, как теоретического принципа, и есть особенности практических реализаций, где скорости достигаются методами, к самому OLTP отношения не имеющими.
Дальше пока не читал... Позже допишу.
Мне кажется или "в реальном времени", "мгновенный отклик"
Для себя я понял, что в годы возникновения OLTP скорость казалась мгновенной, поэтому так и указал. Могу быть и не прав
Ну, до 80-х уже были РСУБД. INGRES, System R в 74 вышли. Знаменитая Oracle в 79 появилась. Informix, поддерживающий SQL, вообще в 86 появился --- совсем не одним из первых
В источниках часто писали именно про Informix. Поэтому и указал её.
Грубо говоря, есть сама суть и глубинный смысл OLTP, как теоретического принципа, и есть особенности практических реализаций, где скорости достигаются методами, к самому OLTP отношения не имеющими.
Интересная мысль. Вы считаете чистого OLTP и сейчас нет? Или кто-то всё же смог приблизиться к нему?
Да, не. OLTP --- это совершить транзакцию, т. е. группу операций, представляющих логически единое действие, по изменению данных в БД так, чтобы сохранилась целостность. Это программист делает --- пишет SQL-скрипт. Вы так и написали. А, как это сделать с приемлемой скоростью в реальной системе -- это уже задача инженеров и админов.
Программист может разрабатывать скрипт на однопользовательской СУБД, крутящейся на его рабочей станции, с небольшой тестовой БД. Инженеры же развернут систему на кластере серверов аппаратных с балансировщиком нагрузки, проиндексируют нужные таблицы, разобьют их на части, поколдуют с настройками, чтобы добиться нужной производительности. К самому скрипту, реализующему логику работы системы по принципам OLTP, это отношения не имеет.
Вот, о чём я.
На практике, конечно, бывает нужно и денормализацию провести с дублированием данных, чтобы повысить производительность. Тогда инженеры и программисты вместе решают эти вопросы, т. к. скрипт придётся переписывать.
OLTP --- это про логику обработки данных: запись, изменение, удаление, как правило, в плоские таблицы. Так же, как и OLAP --- про логику обработки, но уже в виде анализа какого-нибудь гиперкуба.
А скорость --- это уже особенности конкретной реализации.
Никто не запрещает построить OLTP-систему на базе бумажных журналов, человеков-операторов и телефонной или голубиной связи. Логика системы от такой реализации не пострадает. Быстродействие и надёжность --- да. Но, как говорит Каневский, "это уже совсем другая история".
Я бы еще сказал что ни OLTP ни OLAP не являются атрибутами той или иной СУБД. Любая СУБД допускает и то и другое. Это скорее атрибуты приложений использующих СУБД. И вот тут могут появиться разные подходы к удовлетворению разных требований OLTP и OLAP приложений.
Самый простой подход это создать две БД и связать их репликацией. Source БД используется OLTP приложением, target БД соответственно OLAP. Различаться эти БД могут наборами индесков и физическими параметрами хранилища данных. Могут различаться и структурами. Например уровнем нормализации.
Обычно делают так: к боевой базе делают стендбай (идентичный по всем параметрам), и с него уже грузят данные в хранилище для OLAP. В случае неполадок с боевой БД, её нагрузка переключается на стендбай, чтобы бизнес не простаивал.
Ну и да, стандартная реляционка может быть как OLTP, так и OLAP-системой
Стендбай это и есть репликация строго говоря с возможностью делать fail-over и fail-back. У нас так устрена инфра c Оракл того приложения что раньше крутилось на МФ без стендбая. А знаете почему без? Потому что у МФ не может быть "неполадок" ни в железе не в софте кроме конечно дизастера Дата Центра где он стоит.
Хорошая идея прозвучала у Вас про репликацию в OLAP cо стендбая. Наши ДБА Оракл почему то решили что это должно делаться с боевой базы. Я как раз и занимаюсь этой репликацией, но не Ораклом как таковым. И эта конфигурация с боевой базы переодически рушит репликацию из-за высокой загрузки боевой базы. Буду сегодня говорить с ДБА об этом. Интересно чем они обяснят такой решение.
Вообще говоря проблема высокой загрузки боевой базы не должна влиять не репликацию если есть нормальный механизм приоритов в системе, в данном случае Линукс РедХат. Но, как сказали наши ДБА, они приоритетами не занимаются. Но впрочем я далеко ушел от темы статьи. Заканчиваю. Иду купаться в Lake Simcoe.
...До него уже появилась "великая и ужасная" DB2 в 82-м году.
Точнее DB2 for MVS. На персоналках DB2 появилась в форме DB2/2 под OS/2 в середине 90-х, позже была полностью переработана в DB2 for LUW. Переработка главным образом коснулась оптимизатора, в котором были имплементированы многие идеи из оптимизатора DB2 for MVS (presently DB2 for z/OS).
Я проработал с DB2 for z/OS 25+ лет. Это великолепная БД с непревзойденными возможностями, но она требует ИБМ мэйнфрэйм и z/OS. Оракл одно время пытался конкурировать с ИБМ на мэйнфрэймах, но потерпел неудачу и ушел на Линукс.
Автор начал за здравие, а под конец налил кучу воды не относящейся к теме. Ну транзакции, они и есть транзакции. Примеры примитивные приведены, а текста зато - читать не перечитать. Куча общих фраз, ничего интересного.
Ощущение, что статья написана ИИ: куча повторений и переливание из пустого в порожнее
Всякий раз как на Хабр-е появляется статья с ретроспективным анализом то получается что либо компьютеры вооще только появились в начале 1980-х и это были персональные компьютеры, либо как в этой статье, истоия прослеживается только до появления технологии используемой и известной автору. В данном случае это Реляционные БД. Кстати принцип транзакционной обработки данных появился прилично раньше Кодда и реляционных баз данных.
Из статьи:
Революция произошла в 1970 году, когда британский ученый из IBM Эдгар Кодд опубликовал свою работу о реляционной модели данных. Он предложил представлять данные в виде простых таблиц со строками и столбцами, связанных между собой. Это заложило теоретическую основу для современных баз данных и, в частности, для OLTP.
Никакой революции в 1970 году не произошло. Edgar F. Codd никаких таблиц со строками и столбцами не предлагал. Его реляционная теория использует совсем иные термины (domains, for example) и описывает вещи гораздо более сложные (integrities: data, and referential, normal forms, etc...) чем просто таблицы. И, о ужас, Кодд начинает свою знаменитую статью с анализа существующих на тот момент БД с иными чем реляционная модель данных. Это модели с иерархическими и сетевыми связями. Представителем первой модели была IBM IMS (1968 год), сетевая модель была имплементирована в GE IDS (Integrated Data Store (IDS), developed at General Electric, 1964 год) ныне известная как IDMS от Broadcom. Также ADABAS(1971).
Вот эти БД тогда и представляли инструментарий для OLTP, сам Кодд больше говорил в свете своей реляционной модели об OLAP (online analytical processing. OLTP и OLAP вовсе не противоположности как утверждается в статье, а два вида транзакций отличающиеся только характерисками выполнения, но не программирования и не требованиями к БД. Одна и та же БД может выполнять как приложения для OLTP так и OLAP.
Тем не менее изначально реляционные базы данных не позиционировались для OLTP. Просто потому что тогдашние компьютеры не предоставляли достаточных мощностей чтобы выполнять все требования реляционной модели. И в первых релизах РБД далеко не все механизмы реляционной модели Кодда были имплементированны.
В 70-е и 80-е в ИТ превалировали иерархические и сетевые модели в комерческих БД. Они и до сих пор существуют и используются. В приобретающих моду последнее время none-SQL если покапаться можно найти и то и другое.
Я, проработав с РБД с начала 90-х (более 30 лет), недавно волею судьбы окунулся в IDMS и нашел много интересного в ней. По производительности на OLTP эта БД победит любую реляционную БД.
Автор, вы в конце определитесь, вы на OpenSource переходите или на облака (сплошь и рядом проприетарная и недешевая технология). Можно, конечно, и Постгрес в Azure использовать, но зачем?
Ну и не надо забывать, что среднестатистический банк в контексте своей АБС (т.е. классической OLTP) как жил на Оракле, так и продолжает жить. Даже в России. Ибо бизнес-логику переписывать на что-то другое - ну, успехов.
Что такое OLTP: просто о сложном