Комментарии 46
А почему примеры не используют lock? Если другой пользователь одновременно изменит состав заказа? Ведь транзакции вы тоже там не применили.
Понятно, что вопрос к Робу, как автору, но может вы поясните.
Понятно, что вопрос к Робу, как автору, но может вы поясните.
Я думаю Роб не хотел перегружать вводную обучающую статью. Её перевод итак занял 3 огромных части.
Безусловно, в реальной серьёзной системе будут использоваться блокировки по конкретным заказам с вложенными транзакциями.
Безусловно, в реальной серьёзной системе будут использоваться блокировки по конкретным заказам с вложенными транзакциями.
Собственно multik обещал про транзакции и блокировки в своей серии статей рассказать. Мне кажется, будет отличное дополнение.
Рекомендую из оригинала заменять такие кавычки ”” на обычные "" — это никак не влияет на синтаксис но делает более удобной читабельность и подсветку.
А какие сейчас перспективы использования MUMPS? Ведь все больше систем появляется — где например все данные лежат в наитупейших SQL таблицах типа ID, VALUE, а VALUE представляет собой упакованную в XML сущность произвольной структуры и наполнения.
В таких системах все соединения, поиски, маш-апы делаются на сервере приложений — который строго говоря можно сделать как угодно умным, с параллелизмом, с многонодовостью и даже с тонким оптимизатором (например хранить индексы не в виде B-tree, а T-tree — что гораздо интереснее в случае хранения данных в оперативной памяти) и денормализатором данных
Скорость получается фееричная — даже на весьма средненькой технике мы получали 15-20 тыс. бизнес-транзакций в секунду на тысячах пользователей…
В таких системах все соединения, поиски, маш-апы делаются на сервере приложений — который строго говоря можно сделать как угодно умным, с параллелизмом, с многонодовостью и даже с тонким оптимизатором (например хранить индексы не в виде B-tree, а T-tree — что гораздо интереснее в случае хранения данных в оперативной памяти) и денормализатором данных
Скорость получается фееричная — даже на весьма средненькой технике мы получали 15-20 тыс. бизнес-транзакций в секунду на тысячах пользователей…
Кам мне кажется, самое главное — то, что MUMPS позволяет делать перечисленно вами не на 2 уровне трёхзвенки ( сервере приложений) а на 1 уровне двухзвенки (СУБД). И делать это нормально. И, если верить статьям, с ещё большей скоростью.
Ну если это сервер БД такой умный — то думаю все равно влетим в ограничение «железной» архитектуры. Тот же IRQ delay — и скажем в Intel архитектуре на 8000 пользователях хваленый Oracle уже будет помирать. Выход — уйти от одного процессорного ядра — в несколько нод — не сотен, а тысяч легких связанных в сеть вычислителей (ну типа MapReduce) схем
p.s. Бизнес транзакция — это законченная, имеющая физический смысл — операция. Например — проведение платежа по счету клиента — которая «цепляет» проверку прав операциониста, проверку остатка, запись в документы дня, расчет комиссии, проводки по корреспондирующим счетам и полную запись в аудит операций и безопасности…
В общем — да.
да — вобщем ничего. Просто каждому решению — свое время. Мы например активно занимаемся интеграционными ИС — когда архитектура составляется из множеств компонент различных производителей по принципу «best of breed». И сквозными бизнес-процессами — которые все стягивают. Понятно — что это все делается на серверах приложений — где роль СУБД уже не главная. Поэтому реализовать непростой data transformation нам проще на том же языке, что и все остальное (J2EE). Т.е. критерии чисто экономические — наличие рынка специалистов и унификация инструментария.
Для интеграционных ИС существует отдельный продукт Ensemble, но который базируется опять же на Caché.
Основной мой посыл был в том, что покупая один продукт, вы в рамках предоставляемых им технологий получаете сразу и СУБД, и сервер приложений, и real-time BI, и технологию/фреймворк для разработки веб-приложений.
В подавляющем большинстве случаев предоставляемых Caché возможностей мне хватает, а если нет, то: #comment_5894797
Основной мой посыл был в том, что покупая один продукт, вы в рамках предоставляемых им технологий получаете сразу и СУБД, и сервер приложений, и real-time BI, и технологию/фреймворк для разработки веб-приложений.
В подавляющем большинстве случаев предоставляемых Caché возможностей мне хватает, а если нет, то: #comment_5894797
А смысл — идя покупать в магазин шнурки, брать впридачу еще и костюм? ;-) Часто мои заказчики работают в модели «best of breed» — т.е. выбирают для решения задачи самые лучшие компоненты из нужных сфер. Вполне понятно, что это будут разные вендоры, поэтому хочется гибкости, компонентности и открытости
Но ведь после того, как заказчики выбрали «best of breed» Вы все это объединяете интеграционной шиной? И какую шину используете? Почему например не выбрать Ensemble в качестве шины — ведь по сравнению со стеками технологий от IBM и Microsoft, InterSystems Ensemble — действительно «все в одном», что ИМХО упрощает решение, а также удешевляет и упрощает эксплуатацию.
Ну потому что интеграционная платформа (вернее Application Server) тоже выбирается по принципу «best of breed». Если мы посмотрим Garthner Magic Quadrant (правда нашел 2009 года — но видимо есть и поновее)
itaas.ru/wp-content/uploads/2009/11/jboss-gartner1.jpg
Вы там Ensemble видите !??
itaas.ru/wp-content/uploads/2009/11/jboss-gartner1.jpg
Вы там Ensemble видите !??
Напоминает про «Какой шампунь №1 в мире? А №2?»
Вы всегда пользуетесь только самым-самым и друзья у вас исключительно из списка Forbes?
А насчёт Gartner: так ведь и отчёты по разным темам бывают. Из вашей картинки непонятна тема отчёта.
Странно, что вы не нашли:
Вы всегда пользуетесь только самым-самым и друзья у вас исключительно из списка Forbes?
А насчёт Gartner: так ведь и отчёты по разным темам бывают. Из вашей картинки непонятна тема отчёта.
Странно, что вы не нашли:
- Gartner поместила InterSystems Ensemble в квадрант «Лидеры» в аналитическом отчете «Magic Quadrant For Application Infrastructure For Composite-Application Projects» (2007)
- Magic Quadrant for Application Infrastructure for Systematic Application Integration Projects (June 2012)
- Gartner's Magic Quadrant for Global Enterprise EHR Systems (October 2012)
Моя компания сама в Gartner MQ есть ;-) Да, бренд — дело сильное. Если ты не 1-2 — то тебя может и не быть. Так даже в зеленом горошке — если не Бюндюэль, то кто?
С точки зрения бизнеса — называется сохранность инвестиций.
С точки зрения бизнеса — называется сохранность инвестиций.
Первый отчет — явно устаревший, последний относится к медицине — но тут вопрос — что надо оценивать несомненную долю рынка прикладного решения TrackCare Intersystems или возможности системного инструментария.
Второй да — крайне интересно. Не знал
Второй да — крайне интересно. Не знал
К слову говоря подобная структура на MUMPS будет работать быстрее, чем на SQL. Смотря что, конечно считать транзакцией. Они могут очень отличаться по сложности. Я когда делал тесты с GT.M (бесплатный MUMPS) достигал результатов в 660 000 insert-ов в секунду (база данных на диске, а не в памяти) на 4х3.6GHz Phenom, 8gb, RAID5. Вставлял для теста 10 миллионов записей.
А такой способ хранения очень не оптимален, если приходится производить поиск по полям, какие-то хитрые делать связи между таблицами.
Вычислять аггрегатные функции.
Да и XML не самый быстрый способ сериализации структур.
А такой способ хранения очень не оптимален, если приходится производить поиск по полям, какие-то хитрые делать связи между таблицами.
Вычислять аггрегатные функции.
Да и XML не самый быстрый способ сериализации структур.
Так на 3-tier архитектуре (вернее как подмножество N-tier) можно делать чертовски прикольные вещи — например read ahead чтение с построением декартова произведения любых нужных таблиц с их векторным умножением/пересечением и пр. И это все асинхронно — т.е. клиент даже не догадается как его данные в кубы заворачиваются, меняя физическое представление — совершенно не связанное с их хранением на диске.
А по поводу insert — так по-моему batch insert (bcp) на MS SQL и так дает такую скорость, особенно если есть мощный write cache — с размером более объема вставляемых данных
А по поводу insert — так по-моему batch insert (bcp) на MS SQL и так дает такую скорость, особенно если есть мощный write cache — с размером более объема вставляемых данных
С миллионов (энерго/газо/водо/др.)-счётчиков приходят по сети данные (сокеты/веб-сервисы/http/etc.), которые нужно быстро вставить в БД, предварительно ещё обработав перед и после вставки. И всё это в непрерывном режиме.
Как в этом случае поможет программа bcp?
Подробнее о ETL на лету можно прочитать в этой cтатье.
Поскольку СУБД Caché может выступать и в роли сервера приложений, то осуществление этого в рамках её технологий вполне возможно.
Как в этом случае поможет программа bcp?
Подробнее о ETL на лету можно прочитать в этой cтатье.
Поскольку СУБД Caché может выступать и в роли сервера приложений, то осуществление этого в рамках её технологий вполне возможно.
Прошу прощения — мы как то перешли от философии MUMPS к продуктовой линейке Caché. Лучше это обсудить в отдельном топике в сравнении с аналогичными технологиями. Просто думаю идет конвергенция решений и технологий на фоне жестокой конкуренции — 99,9% инфраструктурных ИТ решений — как и лекарства имеют аналоги, (дженерики). InterSystems Corp была основана практически в том же году что и Oracle — но обороты ( $450 млн. против $37 млрд) даже меньше чем у Sybase — и отстраивание одного продукта от другого начинает носить уже малоразличимый, скорее маркетинговый характер. Мы же не будем холиварить? Caché — отличный _нишевый_ продукт.
p.s. Мы используем для интеграции данных в реальном времени и постоянную доступность данных для критически важных систем решение Oracle GoldenGate. Оно имеет задержку не сотни, как в обычном ETL- а единицы миллисекунд.
p.s. Мы используем для интеграции данных в реальном времени и постоянную доступность данных для критически важных систем решение Oracle GoldenGate. Оно имеет задержку не сотни, как в обычном ETL- а единицы миллисекунд.
Я правильно понимаю, что в таком случае помимо Oracle Database Enterprise Edition и, возможно, какого-то из Application Server, необходимо будет дополнительно покупать ещё Oracle GoldenGate, GoldenGate for Non Oracle Database и GoldenGate Application Adapters?
Да. А разве где-то иначе? Прайс-лист глобальных компаний уже давно представляет собой томик «Война и мир». Я бы тоже предпочел видеть все одной суммой и unlimited, но вероятно их «эффективные менеджеры» привязали каждую позицию к доходам отдельного подразделения — чтобы не было перекрестного финансирования и можно было развивать каждое направление, не делясь прибылью с другими.
Ничего не мешает на MUMPS писать сервер приложений, и не зацикливаясь на Каше. У GT.M всего одно неудобство(может уже устранили) по передаче сокетов в дочерние процессы. Просто в Каше вокруг голого MUMPS уже накрутили то, что может облегчить труд программистов.
У GT.M всего одно неудобство(может уже устранили)GT.M уже официально поддерживает Windows?
Насколько я знаю Windows существует, но она с закрытым кодом и платная.
Я знаю, что какая-то версия GT.M под Windows вообще существует.
Вопрос был про официальную поддержку платформы Windows самим производителем.
Вопрос был про официальную поддержку платформы Windows самим производителем.
И поддержка есть. И тоже платная.
Это вообще не пруфы. Доказательства нужно искать на сайте производителя, а не среди трёпа на стековерфлов.
Как бесплатное решение (FOSS — Free and open-source software) действительно GT.M есть только под Unix-подобныи ОС.
Тут указан емейл, где ты можешь заказать версию под другие платформы, чем Unix-подобные:
tinco.pair.com/bhaskar/gtm/doc/books/ao/UNIX_manual/ch02s01.html
А тут указан емейл по которому ты можешь заказать платную поддержку
www.fisglobal.com/products-technologyplatforms-gtm-faq
Как бесплатное решение (FOSS — Free and open-source software) действительно GT.M есть только под Unix-подобныи ОС.
Тут указан емейл, где ты можешь заказать версию под другие платформы, чем Unix-подобные:
tinco.pair.com/bhaskar/gtm/doc/books/ao/UNIX_manual/ch02s01.html
А тут указан емейл по которому ты можешь заказать платную поддержку
www.fisglobal.com/products-technologyplatforms-gtm-faq
Я попросил ссылку, где чётко указано, что уже есть поддержка GT.M под Windows, а не «сейчас нет, но вы нас попросите и мы вам сделаем всё что угодно за ваши деньги».
Если такой дистрибутив есть, то какой смысл его скрывать или хотя бы указать в документации информацию о том, что он существует?
С таким же успехом я могу заказать СУБД Caché под Raspberry Pi или Android, которых сейчас тоже нет.
PS: упоминание платности (special for Windows) как для заказа дистрибутива, так и для техподдержки вообще снимает всякие дополнительные вопросы.
Если такой дистрибутив есть, то какой смысл его скрывать или хотя бы указать в документации информацию о том, что он существует?
С таким же успехом я могу заказать СУБД Caché под Raspberry Pi или Android, которых сейчас тоже нет.
PS: упоминание платности (special for Windows) как для заказа дистрибутива, так и для техподдержки вообще снимает всякие дополнительные вопросы.
Там не указано, что нет версии под Windows, так что не нужно фантазировать. Поскольку данный вопрос интересен тебе, а не мне, то напиши и спроси.
Не имею привычки что-то домысливать за документацию:
GT.M V6.0-002 Release Notes: Platforms
«А что сверх этого, то от лукавого» (Матфей 5,37)
GT.M V6.0-002 Release Notes: Platforms
«А что сверх этого, то от лукавого» (Матфей 5,37)
Я у же говорил:
Мне не нужно подтверждение моих слов ссылкой из документации к бесплатной версии GT.M ))
Как бесплатное решение (FOSS — Free and open-source software) действительно GT.M есть только под Unix-подобныи ОС.
Мне не нужно подтверждение моих слов ссылкой из документации к бесплатной версии GT.M ))
Разработчикам тяжело было сделать два раздела:
Я пока так и не увидел подтверждения на основе открытых официальных источников ваших слов:
Кулуарная информация меня не интересует.
А специально куда-то писать, чтобы узнать эту информацию, как вы мне советуете, я не собираюсь. И не только поэтому.
- Платформы для бесплатной версии
- Платформы для платных версий?
Я пока так и не увидел подтверждения на основе открытых официальных источников ваших слов:
Насколько я знаю Windows существует, но она с закрытым кодом и платная.
Кулуарная информация меня не интересует.
А специально куда-то писать, чтобы узнать эту информацию, как вы мне советуете, я не собираюсь. И не только поэтому.
Это кому нибудь может мешать?
Кстати, я повторил тест на таком объёме, который гарантированно не влезет в write-cache, поскольку он у меня имеется.
Взял объём данных, который в 10 раз больше моего кеша. Винты шуршали как бешеные.
Получилось 293 544 инсертов в секунду.
Причём тест проводился в виртуальной машине (Vmware Player), что значит на реальном железе будет ещё быстрее.
Взял объём данных, который в 10 раз больше моего кеша. Винты шуршали как бешеные.
Получилось 293 544 инсертов в секунду.
Причём тест проводился в виртуальной машине (Vmware Player), что значит на реальном железе будет ещё быстрее.
Вот видите — мы уже холиварим ;-) Ну не актуален для меня тест insert, поскольку есть такие системы — которые нормально включаются в режим pass thru — напрямую прокачивая данные от датчиков сразу на HDD. И даже CPU не задействуют — потому как в DMA режиме живут.
Понятно что самая быстрая скорость будет на записи в текстовые файлы фиксированного блока данных, кратного пакету DMA/Ethernet/IP и пр. Так работает кстати процессинг VISA — там нет SQL движка.
По поводу виртуалки — «падеж скорости» у меня был не более 15-20% относительно натуральной машины. В основном это опять же зависит от дефрагментации виртуального/реального диска и их отображения.
Подытоживая — в нишевых продуктах можно добиться сколь угодно большого перфоманса. Особенно если они анизотропные — т.е. системы только пишут данные или только читают. Самый геморрой — это когда идет мешанина читающего и пишущего кода — и вот тут поле битвы современных СУБД. Есть даже такие — которые еще на этапе компиляции отделяют один код от другого и запускают с соответствующей оптимизацией на разных нодах в асинхронном режиме с семафорами. Мне такой подход сильно нравится.
Понятно что самая быстрая скорость будет на записи в текстовые файлы фиксированного блока данных, кратного пакету DMA/Ethernet/IP и пр. Так работает кстати процессинг VISA — там нет SQL движка.
По поводу виртуалки — «падеж скорости» у меня был не более 15-20% относительно натуральной машины. В основном это опять же зависит от дефрагментации виртуального/реального диска и их отображения.
Подытоживая — в нишевых продуктах можно добиться сколь угодно большого перфоманса. Особенно если они анизотропные — т.е. системы только пишут данные или только читают. Самый геморрой — это когда идет мешанина читающего и пишущего кода — и вот тут поле битвы современных СУБД. Есть даже такие — которые еще на этапе компиляции отделяют один код от другого и запускают с соответствующей оптимизацией на разных нодах в асинхронном режиме с семафорами. Мне такой подход сильно нравится.
Я вообще не холиварю. И ваш коммент мне нравится и я с ним согласен. Однако, хочу заметить, что в моём тесте попутно со вставкой производилась ещё и индексация по главному глючу.
Ради интереса провёл ещё тест на случайный селект с использованием главного ключа:
833 селекта в секунду. Естественно на таких объёмах данных, где кеширование не работает.
Всё упирается в iops hdd.
И ради интереса провёл тесты на селект на таком объёме, который может влезть в кеш с использованием read ahead:
1 066 666 селектов в секунду.
Ради интереса провёл ещё тест на случайный селект с использованием главного ключа:
833 селекта в секунду. Естественно на таких объёмах данных, где кеширование не работает.
Всё упирается в iops hdd.
И ради интереса провёл тесты на селект на таком объёме, который может влезть в кеш с использованием read ahead:
1 066 666 селектов в секунду.
Поправка: часто бывает так, что в виртуалках диски работают быстрее, чем реальное железо из-за writeback'а на хосте, игнорирующего мольбы о fsync'е из гостя.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Глобалы MUMPS: Экстремальное программирование баз данных. Часть 3