Представлен проект DBOS (DBMS-oriented Operating System), развивающий новую операционную систему для выполнения масштабируемых распределённых приложений. Особенностью проекта является использование СУБД для хранения приложений и состояния системы, а также организация доступа к состоянию только через транзакции. Проект развивается исследователями из Массачусетского технологического института, Висконсинского и Стэнфордского университетов, университета Карнеги-Меллона и компаний Google и VMware. Наработки распространяются под лицензией MIT...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=57735
Ну, к тому шло... Когда "что-то" работает на множестве узлов, и надо как-то координировать работу этого "чего-то" на этих узлах, то почему бы не использовать обкатанные технологии распределённых БД. Это напрашивается само собой.
Врачу, исцелися сам!Проблема распределенных БД - что они в общем и целом- г-но, все до единой.
Либо не тру-распределенные (а master-sl...follower), либо жеппа с целостностью, либо с восстановлением, а чаще всего все и сразу.Тут же речь об in-memory их разновидностях - которые г-но совершенно фееричнейшее даже на локалхосте.
чем плох MySQL NDB?
Те, кто его всерьёз готовил, в цирке не смеются.
Так и не надо смеяться над акробатами.
а можно технические подробности?
Конкретно это счастье плохо тем, что малейшая задержка со сбросом состояния на диск, и нода крашится, а состояние бывает здоровым.
мускул который умудряется исчерпать всю память от простого запроса? кек
Как вам это удаётся? Тут нужен особый талант.
ну вот, раньше такого не было:)
какая из нод у тебя исчерпала память? SQL node? coordinator? data node?
сколько всего было памяти на это ноде?
какой объем данных был в базе?
какой запрос и какой объем выборки?
а все ли там было хорошо с настройками?
> сколько всего было памяти на это ноде?
> какой объем данных был в базе?
> какой запрос и какой объем выборки?
> а все ли там было хорошо с настройками?кек, стандалон мускул 8.0 со стандартными настройками, память 32 ГБ + столько же свопа, одна база не превышающая размер в 50 Мб данных и таблиц не больше 30, тестовый стенд. Вот и свалилось к херам исчерпав память + своп, и процесс собственно прибился киллером, запросы обычные с несколькими джойнами, точно не скажу ибо нах мне это надо разгребать, конечно баг мускула именно этой версии. К чему все это, мускул стал хуже!!!
> какой запрос и какой объем выборки?вот похоже на это, пофиксили на 8.0.27, а исполоьзовалась 8.0.26
Changes in MySQL 8.0.27 (2021-10-19, General Availability)
Concurrent insert operations on multiple tables with full-text indexes caused a large number of full-text index synchronization requests, resulting in an out of memory condition. (Bug #32831765, Bug #103523)
есть и такие фиксы
Some of the functions defined in mbr_utils.cc threw heap-allocated exceptions in some situations. Memory allocated for the exception object in these cases was never freed, which meant that a small amount of memory leaked each time an exception was thrown.
This is fixed by allocating the exception on the stack in such cases, instead. (Bug #104214, Bug #33086286)
>[оверквотинг удален]
> Concurrent insert operations on multiple tables with full-text indexes caused a large
> number of full-text index synchronization requests, resulting in an out of
> memory condition. (Bug #32831765, Bug #103523)
> есть и такие фиксы
> Some of the functions defined in mbr_utils.cc threw heap-allocated exceptions in some
> situations. Memory allocated for the exception object in these cases was
> never freed, which meant that a small amount of memory leaked
> each time an exception was thrown.
> This is fixed by allocating the exception on the stack in such
> cases, instead. (Bug #104214, Bug #33086286)ну так это тупо баг, есть еще Maria и Percona и другие форки со своим саппортом, но какое это все имеет отношение к NDB? ответ - никакого
> ну так это тупо баг, есть еще Maria и Percona и другие
> форки со своим саппортом, но какое это все имеет отношение к
> NDB? ответ - никакогода тупо баг, обычное ведь дело в каждом релизе мемлик баги пускать
> но какое это все имеет отношение к
> NDB? ответ - никакогоконкретно тот баг нет не имеет, ибо ндб фултекста не имеет.
пс: и смех и грех
Linux: On Linux systems, NDB interpreted memory sizes obtained from /proc/meminfo as being supplied in bytes rather than kilobytes. (Bug #102505, Bug #32474829)
Ну и конечно отдельный цирк с дедлоками. Транзакции ж конвертируются в key-value, row-based locks превращаются в block-based locks, со всеми вытекающими.
можно подробнее?какие транзакции? на каких запросах?
P.S. ссылки приветствуются
https://dev.mysql.com/doc/mysql-cluster-excerpt/8.0/en/mysql...Думаю, для самого начала достаточно.
Ну и вот сюда можно поглядеть. В старой дооракловой документации было доходчивое объяснение процессов LCP-GCP, в этой при беглом осмотре не нашёл.
https://dev.mysql.com/doc/refman/8.0/en/mysql-cluster-basics...
> https://dev.mysql.com/doc/mysql-cluster-excerpt/8.0/en/mysql...
> Думаю, для самого начала достаточно.
> Ну и вот сюда можно поглядеть. В старой дооракловой документации было доходчивое
> объяснение процессов LCP-GCP, в этой при беглом осмотре не нашёл.и где там нечто именуемое "block-based locks"?
там есть только:
To ensure that a given transaction reads only before or after values, you can impose row locks using SELECT ... LOCK IN SHARE MODE. In such cases, the lock is held until the owning transaction is committed.И это нужно для эмуляции уровня изоляции Repeatable Read, что выше и написано по сути.
Но никто не мешает использовать Read Commited стандартный почти для 99% приложений (написаннных без такого говна как Entity Framework или еще какого ORM, переопределяющего дефолтовый уровень изоляции).
Там даже хуже чем блочные блокировки, да, прошу прощения, блочных блокировок в NDB нет, только строчные, перепутал с TokuDB.Начнём с того, что READ COMMITTED - это единственное, что может NDB. Больше ничего не может в принципе.
Причём не просто READ COMMITTED, а per row, что дополнительно доставляет.Как только появляются уникальные индексы - у тебя начинаются дополнительные приключения - чтение, не использующее никакой индекс (full scan / ALL), начинает брать блокировки на всю таблицу целиком. Эти же приключения есть при других условиях. Это SHARED READ LOCK, то есть любая модификация попавших в чтение строк в этот момент идёт курить бамбук. Если скан занимает сколь-либо длительное время - всё, приплыли.
чем плох обычный мускул или постгресс??
кактус одним словом :)
> Тут же речь об in-memory их разновидностях - которые г-но совершенно фееричнейшее даже на локалхосте.Это до момента, когда у тебя большая географически распределенная сеть точек почти во всех регионах, десятки/сотни тысяч позиций с пересчетом цен один-два раза в день с поправкой для каждого региона и офиглиард заказов ежедневно. Как наплачешься с инвалидацией многокилометрового кэша — приходи.
Ну а чо делать-то? Времена smp шкафов прошли, нужно исполняться на кучах куч тазиков. У гуглов вроде что-то получается.
Ты переносишь на БД, которая используется "для хранения приложений и состояния системы" те проблемы, которые имеют место в других областях использования БД. У БД объявлений Авито своя специфика, у БД постов и каментов ВК - своя, у БД документооборота Госуслуг своя, у Росреестра своя, здесь тоже своя специфика. Вот лежит у нас бинарник программы в БД в виде блоба. Мы скомпиляли новую версию и с помощью средств, которые предоставляет распределённая БД, распихали его по нодам. Логи тоже кидаются в БД, вроде бы единую, но логи от разных нод не пересекаются. Конфликту взяться неоткуда, при этом в любой момент можно прогрепать логи по всей сети. И так далее. Имхо, вещь очень перспективная.
> в любой момент можно прогрепать логи по всей сетиИ все они лежат в памяти...
Благословенна компьютера с бесконечной оперативной памятью... способной вместить все непересекающиеся логи в сети...
Давно уже к похожей картине пришли в кишках облаков вроде Амазона и Яндекса. Только готовые СУБД для решения задачи не подходят. Уходят годы на разработку специальных оптимизированных СУБД и всё равно получается большой оверхед по ресурсам и прочая куча проблем. Красиво выглядит только на словах.
Ещё один "аспирант-теоретик"! :)) Увидел какую-то чушь, да ещё и защищает.
В реале этот павлиноуткаёж не взлетит. Это чисто экспериментальный проект, рождённый, чтобы загнуться. Это не будущее ни разу.
Не взлетит, не взлетит, можешь не волноваться. Там игорей нет, и медиаплеера нет, и торентокачалки нет, и мессенджеров нет, и браузер не портировали, и офиса тоже нет, и нвидии они палец не показали, чтобы дрова сделала.
А какой палец они должны показать Нвидии чтобы та сделала под них дрова?
> А какой палец они должны показать Нвидии чтобы та сделала под них
> дрова?Тот же, какой показал Линус.
От шоб я следил за пальцами какого-то поца...
Короче ничего нет. Дрочение ради самого процесса)))
Распределенных баз данных не бывает. База данных тогда только база данных, когда она ACID. Все остальное -- файлопомойка.
С данными на множестве узлов работают только нищeбpoды. Нормальные пацаны для этого используют мэйнфреймы. Один 19" блок Z имеет одной оперативки до 40 Тбайт, а в шкафу с ним и в шкафу рядом десятки петабайт дисковой памяти. Одним словом, https://www.redbooks.ibm.com/redbooks/pdfs/sg248851.pdf. Таким образом, на территории, занимаемой парой 19" шкафов (~ 5 квадратных метров с учетом распахнутых дверок и выезда блоков на салазках) располагается любая нынешняя распределенная база данных, какогj бы объема она не была. При этом она даже не ACID, а ACIZ. Z -- zero access time 24/7... Z здесь вместо D -- durability.
Спросите, а почему гуглы не используют мэйнфреймы? Ответ лежит в плоскости рейдерского наезда жидoрептилоидов из конгреса под предводительством гейтсов на IBM в конце 90-х -- IBM просто не желает с алиенами иметь дело. Пейсбук сюда же.
> База данных тогда только база данных, когда она ACIDА если юзкейс этого не требует?
>> База данных тогда только база данных, когда она ACID
> А если юзкейс этого не требует?Значит то, что он использует, -- это не база данных, а свалка данных, в лучшем случае файлопомойка.
Юзекейсы -- это термин, не имеющий никакого отношения к базам данных. Это вообще термин из UML -- абстрактного языка, который не предназначен описывать организацию данных, а только использовать уже готовую, причем исключительно статическую организацию, чтобы поверх нее создавать т.н. бизнесалгоритмы, которым будут следовать биороботы, нанятые данным бизнесом.
Юзеркейсы определяют подмножество допустимых действий пользователей над доступными им (в виде static view) данными, при этом они никак не могут влиять на схему данных в базе, поскольку сугубо вторичны и подчинены.
Юзекейс -- это действия, а database никаких действий вообще не определяет -- это просто набор описаний данных и связей между ними (отношений). Эти описания исключительно декларативны и не предполают никаких конкретных действий с ними. Действия -- это задача другого уровня (прикладного). Юзеркейсы -- это методы, а dataase -- это данные, никаких методов доступа к ним не устнавливающие. Юзеркейсы в связи с данными придуманы это лишь для того, чтобы стричь бабки с ООП-лохов, котороые пкупают тысячкстраничные книжки, набитые на 10% банальностями полувековой давности, а на остальные дибильными выдумками крайне ангажированных авторов.
> биороботы, нанятые данным бизнесом.А, ну, всё понятно.
> Юзекейс -- это действия, а database никаких действий вообще не определяет --
> это просто набор описаний данных и связей между ними (отношений).И? Как быть в случае, если для выполнения действий, требуемых юзкейсом, необходима система с такими данными и отношениями между ними, чтобы в любой географической точке данные были доступны мгновенно, а небольшое отставание актуальности некритично? Например, пользователь, чей кредит исчерпан, будет несколько минут пользоваться неким сервисом при отрицательном балансе лицевого счёта? При том, что более строгий подход (допуск к пользованию сервисом только при наличии денег на счету, подтверждённом ответом только от центральной БД) приведёт к недоступности сервиса для абонентов на какой-то территории из-за отвала центральной БД.
(1)
>необходима система с такими данными и отношениями между ними, чтобы в любой географической точке данные были доступны мгновенно, а небольшое отставание актуальности некритично?То есть такая система - Хорошая система
(2)
>Например, пользователь, чей кредит исчерпан, будет несколько минут пользоваться неким сервисом при отрицательном балансе лицевого счёта?То есть такая система - плохая система
(3)
>При том, что более строгий подход (допуск к пользованию сервисом только при наличии денег на счету, подтверждённом ответом только от центральной БД) приведёт к недоступности сервиса для абонентов на какой-то территории из-за отвала центральной БД.От щото я уже запутался в мысли... то есть такая система - плохая система или хорошая?
> То есть такая система - плохая системаНо с этим иногда можно смириться.
> "чтобы в любой географической точке данные были доступны мгновенно"Ну мгновенно - не получится - скорость света/интернета ограничена.
И разве это не реализовать на одном Z-series с толстыми каналами ?
> с толстыми каналами ?В мире, где строители могут воткнуть сваю в идущий по тоннелю вагон метро, никакой канал не может считаться абсолютно надёжным. После первого же порванного левым экскаватором кабеля начинаешь иначе смотреть на всё, и проектировать инфраструктуру с учётом возможного разрыва соединения. В одних случаях единственный возможный вариант - выдать ошибку и ждать восстановления линка. В другом можно пользоваться локальной репликой, а синхронизацию провести после восстановления связи.
> Один 19" блок Z имеет одной оперативки до 40 ТбайтОдин 4Э16С умеет до 16 Тб.
Не ломайте человеку манямирок, в котором уровень технологического лидерства Межделмаша недостижим для соперников, а СУБД могут быть только кислотными и никак иначе.
>Распределенных баз данных не бывает. База данных тогда только база данных, когда она ACID. Все остальное -- файлопомойка.А в каком месте шардинг противоречит ACID?
Боян [:|||||||:]IBM System i
Будет интересно увидеть, когда допилят, сильно ли упадёт производительность. Что-то не верится, что лишь слегка.
Поверх эфира запустят?
Эфир с своим POS уже таки в фрод скатывается, при том буквально вот-вот, на днях. Просто офигенная схема, и совсем не фрод, когда узкая клика создателей узурпирует все коины сгенереные системой по сути, а потом их раздает, дескать. А такое "платежное средство" с самозваными рокфеллерами изниоткуда - точно нужно? Да и все эти смартконтракты и проч интересны узкой группе лиц. Обычным смертным вообще сложно объяснить что это такое и как работает, при всей забавности идеи. К тому же с учетом того что там произвольная логика - всегда есть риск что вас немного лоханут, вкрутив там что-нибудь с заподвыподвертом, и если вы не махровый кодер и реверсер, можно на раз пролететь.
Ух, как горит у майнераста! Красота!
Цена как была так и держится. А вот ненужные фермы - это да, в труху, и уже не продашь что б хоть половину отбить)))
Не совсем на "поверх эфира", но, уже есть проект unix поверх блокчейна:
https://github.com/tonlabs/tonix
> ОС поверх распределённой СУБД.Интересно…
Чем из 3 составляющих САР они пожертвовали?
Там упомянуты СУБД, а у СУБД в документации эти моменты довольно подробно расписаны.
#НаконецТоПрекратитсяГеморройСВыборомОСДляСУБД #Нет
Надеюсь вы когда-нибудь поймете зачем нужны хэштэги.
Для комментариев ?
Очевидно же - для контрольных сумм
> в экспериментах пока используется VoltDBкоторая усё-у-памяти, актив-актив, синхронная репликация?
для сколько-нибудь живого перформанса потребуется много-памяти, потребуется лишняя пара интерфейсов для replnet (астанавитесь рогатые твари это уже минимум семь шнуров на каждый корпус)... отличная идея, что может пойти не так...
> Members of our team are currently researching:
> Better tradeoffs between local and distributed transactions in a distributed databaseбегать перформанс критикал задачи на одной ноде, фигня вопрос
> Better ways to support multiple data stores and data models in the DBOS backend, enabling operations like analytics and file I/O for which traditional databases are inefficient.
тут быренько drbd прикрутим
> New infrastructure leveraging data provenance to make debugging distributed applications easier
ооо на етом месте ижевский концерн калашникова по производству многоствольных автоматов для стрельбы в ноги, геклер-кох и кольт (ой извините ныне ческа збройовка) заплакали и пошли нервно курить в углу от зависти
в общем, для аспирантов - поле непаханое. одна хрень не сработала - yopt, можно тут же, не сходя с кафедры, попросить грант на исследование следующей. движуха!
А что, вот, распределенный сервис по расшариванию оперативки. Конечно д@рьмово и тормозно.
Осталось в блокчейн Ethereum еще и ось засунуть.
> операционная система ... поверх СУБДДо чего дошли ... Круто
операционная система ... поверх git
операционная система ... поверх email
операционная система ... поверх fax
операционная система ... поверх скринсейвера
операционная система ... поверх ...Имхо товарищам надо почитать для чего нужна операционная система, а то что они лепят- должно называться как-то иначе...
Имхо ты вообще вкурсе что такое прогресс и как он работает? Почитай на досуге узнаешь хоть что-то новое.
Так и запишем. Прогресс - это попытка грантососов забивать гвозди микроскопом. Нуачо, вдруг прокатит?
К порванному шаблону прикладывайте подорожник, зуд скоро пройдет.
Ты где слово "шаблон" узнал, убогий? Или вам в школе его кто-то неосторожно сказал?
Узнаю тупых 2К-детей - им какую пое6ень ни покажи - им всё прогресс! :))) что биткойны, что ИИ, что венда-10... дети - чо с них взять!
Ахаха, старичок, тебе что не скажи всё уже изобрели «великие» советские ученые, которые так ничего и не сделали.
Были такие на заре IT. Только не распределённые.
Такую чушь "придумывали" когда тебя даже в проекте не было. И всё это благополучно похерилось в пыли времён. И что "крутого" ты тут нашёл, мальчик?!
То есть файловая система у них поверх СУБД, которая в памяти...
Ок.
А о существовании внешней памяти она вообще в курсе? Где и какими средствами оно сохраняет состояние между запусками?
Это все в микроядре?
Ну похоже там как у Оракла для БД Oracle (чтобы не бодаться с файловой системой ОС, с её кэшированиями, "неБДшными" оптимизациями и т.п.) может использоваться ASM (Automatic Storage Management) - свой аналог ФС и управлялки дисками/томами, который работает напрямую с raw devices и специализирован под нужды БД. Т.е. в DBOS реализуют своё казино с блэкджеком и поэтессами, аналог ZFS/BTRFS, но попроще и с упором на нужды БД, как ASM. А DBOS-ная пользовательская ФС уже будет (если будет) поверх БД реализована, может даже с какими-нибудь необычными для традиционной ФС идеями, ну типа как MS для Longhorn'а в WinFS хотели реализовать. Ну т.е. ФС в таком случае может быть не только тупой иерархией каталогов и файлов с правами.
Сколько пользовал такие RAW хранилища - один гемор с ними ... что с бакапом/восстановлением, что с работой... Вроде как уже в 9ке они не рекомендовались к использованию.
Совершенно верно. Орацл похоронил эту глупость давным-давно. Она тех времен, когда были "настоящие" block devices, и все они были +- одинаковыми (поскольку ничего кроме scsi диска под ними не могло быть по определению).Внезапно, оказалось что проще выпороть индуса, не умеющего работать с файловой системой, чем поддерживать эти поделки самоучек без мотора, костыльно-уникальные для каждой ос и для каждой комбинации устройств хранения.
Проблема в том, что "своя управлялка томами" априори ограничена и неуклюжа.
Практически для ВСЕХ ВОЗМОЖНЫХ ВИДОВ сториджа ты ОБЯЗАН иметь в своей "странной" СУБД поддержку. Скажем, запилил ты с горем пополам HDD. А потом раз - и у людей SSD! С абсолютно другими принципами. Другой захотел СУБД на стриммере - ОПЯТЬ ПИЛИТЬ! Причём даже харды могут быть разными архитектурно, что тебе ТОЖЕ надо учитывать в своей... гм... "управлялке томами".
Короче, всё это доморощеное г0вн0 из разряда "сами всё напишем".
> Проблема в том, что "своя управлялка томами" априори ограничена и неуклюжа.Ну так всякие ZFS и иже с ними - это всё тоже "доморощеное г0вн0 из разряда "сами всё напишем". Кто-то (Sun) "для себя любимого" и начинал писАть. Не марсиане же прилетали и дарили людям какие-то ныне устоявшиеся, популярные, "стандарт де-факто" системы. И так по любой любимой Вами технологии. Как-то опрометчиво утверждать, что компания уровня Оракла с ASM - доморощенное, а сановский ZFS для солярки - не доморощенное. Просто удачные решения ("удачные" - не обязательно технологически лучшие, см. OS/2 vs Win) выжили, а менее удачные - теперь для Вас г0вн0. Так же и здесь - вдруг это сборище университетов и компаний родило бы что-то мегаполезное, этакую "MegaZFS 2.0 bez kosyakov!", которое бы Вы через 10 лет всем ставили в пример как образец космических технологий, а всё остальное - "оно самое, коричневое".
Причин в хотении своей управлялки - море. Это и лицензирование готового продукта. Или чужие патентованные технологии. Или желание контролировать развитие продукта в нужном тебе направлении...
> То есть файловая система у них поверх СУБДСверху СУБД файловая система официальная - для пользователей/программистов/программ.
А снизу СУБД файловая-то система поди тоже водится, но не официальная, а как служебная часть этой операционной системы.
Распределенная система без запусков. Она вообще не выключается - только перетекает от узла к узлу. Ее невозможно остановить, запустивши единожды. И смысла в состоянии между запусками нет.
Когда перепишут на Rust ?
Не перепишут, будут писать на Карбоне.
С сетевым стеком на Go и микросервисами на Dart.
Ну и конечно же пользовательскими приложениями на Хаскеле.
А на эрланге, эрланге, залитом эликсиром, тоже что-нибудь напишут? Например JDK? Хотя не, JDK на прологе надо переписывать...
Звучит как то что надо было делать сразу в области операционных систем, а не то что получилось сейчас.
Один вопрос - зачем лезть в СУБД если можно использовать тот-же сервер LDAP. Эффективнее будет.
Странно что они не лезут в карман…
LDAP это протокол доступа к СУБД.
> LDAP это протокол доступа к СУБД.Применительно к LDAP средства хранения данных вообще не обсуждаются. Но, конечно есть особо отмороженные индивиды которые посредством костылей тянут ключ/значение в SQL, значительно теряя в производительности.
Но суть решения в SQL абстракции, которую с большей эффективностью можно заменить на LDAP. SQL изначально был предназначен для работы с таблицами описывающими конечное количество столбцов. Попытки расширить возможности SQL - рождают уродов вроде 1С.
LDAP предназначен для работы с обьектами, не имеющими по факту строгой структуры. Поэтому более применим для ОС.
>рождают уродов вроде 1С.Не могли бы вы привести пример "не урода" DSL в той же области что 1С?
TDS ... например
Тфу букаффка выпала - TDMS же !
>Особенностью проекта является использование СУБД для хранения приложений и состояния системы, а также организация доступа к состоянию только через транзакции
>и компаний GoogleТак вот ты какая, фуксия!
очень ждём операционной системы работающей поверх гибридной облачной среды (для начала AWS + GCP + on prem)
"... но процессор эмулировать в виртуальной памяти... Такого ещё не было!"
Эмулировать на sql запросах... :)
Не wasm уже хорошо.
Кажется кто-то переизобрёл AS/400 только в кластерном варианте. Осталось только добавить объектную модель.
Ага ... Ещё MUMPS вспоминается :-)
> кто-то переизобрёл AS/4000_0
каким боком, можно узнать?
OS/400 использовала единое адресное пространство памяти для RAM и HDD, а в качестве хранилища данных (точнее объектов) - DB2.
Первый релиз - 1988й год если не шибаюсь.
Ах да - там ещё использовался интерпретатор байт-кода, а-ля Java. Посему она пережила три смены архитектуры CPU без перекомпиляции программ.
Ты забыл уточнить что перекомпилировать в любом случае было особо нечего.Под нее существовал только очень странный околобанковский софт (около - потому что процессинг по каким-то кто-бы-мог-подумать причинам в эти ящики запихивался плохо и все попытки такое в длительной перспективе использовать кончались уходом на более вменяемые архитектуры. А коробка оставалась сбоку, выбросить ее было невозможно, да и жаба давила.)
ух-хух, только околобанковский софт. то-то я эти коробки вывозил с предприятий, у которых в названиях были "сталь" и "прокат".какой нахер процессинг, as/400 делалась чуть ли не под soho.
> какой нахер процессинг, as/400 делалась чуть ли не под soho.при ее цене это должен быть soho образца "сталь и прокат". Где денег немеряно, офисные задачки совершенно примитивные (бухгалтерия для всей толпы рабов, разумеется, 1С). Что они там на ней считали и где брали этих странных разработчиков (а главное - ну зачем это было делать) - уму непостижимо все равно.
А вот в банчках понятно зачем ее любили - только оно не работало, поэтому любовь была чисто платонической.
заколоти свою копипасту себе в трухляк и иди куда-нибудь.я бы сказал куда, но модераторы считают, что опеннет - безопасная территория для анацефалов, поэтому я не скажу куда тебе идти.
> там ещё использовался интерпретатор байт-кода, а-ля Java. Посему она пережила три смены архитектуры CPU без перекомпиляции программ.
это просто сказка какая-то. товарищ солтис небось икает не переставая.
Ну вот, а где лекция, трищ профессор?
Только перо расписал...
Те же ассоциации.
AS/400 не видел. Некоторое время работал на https://en.wikipedia.org/wiki/Pick_operating_system Это из 60х годов. Примерно похоже, только там даже не РСУБД была. MultiValue. В современных терминах, наверное, больше всего похоже на JSON/NoSQL. Очень гибкая организация: Виртуальная машина -> Счет -> Файл -> Запись -> Значение -> Подзначение... Любой сущностью можно было удобно управлять как единым куском.Если память не изменяет - основная причина почему они в итоге стали всё-таки выносить свою БД поверх ОС общего назначения и перестали быть самостоятельной ОС - сетевой стэк.
да уж, времена. блакноты на попаскрипте, системы на базах данных, будущее которое заслужили
Ну чем, чорт побери, МЫ -то такое заслужили?Думаешь, тем что надо было не багрепорты писать, которые все равно закрывали не читая, а просто отстреливать эту публику? Так патрон же ж не напаслись бы...
Ну Вы же не пошли в РВСН.
Боже... Люди совсем разучились переводить тексты!
Прочтите оригинал и долго думайте!Это Операционная Система упрощенная для использования в базах данных.
Т.е. не ОС поверх DB, а ровно наоборот.
Позорище...
P.S. Оригинальное название - A Database-Oriented Operating System
А теперь сами дальше заголовка оригинал прочитайте.Например "For example, a cluster scheduler could store information on tasks and workers in database tables and implement scheduling operations as database transactions that mix imperative code and SQL".
Или просто на картинку взгляните. Ниже DBMS - Microkernel services, а выше - OS services.
Да, и что?Ядро ОС НЕ использует DB для работы. Это очевидно.
разные службы могут использовать DB для хранения данных.
Для этого DB и делают...
Unix был написан на C. И тот же самый C используется для написания приложений для
Unix. Тоже самое как говорится.Есть условно стандартная для этой OS база данных. И она используется в инфрасткрутуре
самой OS.Это абсолютно НЕ означает, что OS работает поверх Базы данных!!!!
И НИКТО из авторов об этом не говорит! Может лучше слушать авторов, а не местных идиотов?
CSV файлы можно использовать в качестве бекенда для хранения данных?
Это пять!