LINUX.ORG.RU

О внешних и встраиваемых в приложение серверах баз данных

 


0

2

Собственно вот что я хочу сказать, меня недавно уверяли что встраиваемые сервера баз данных это очень хорошо и просто,
но во что выливается эта простота?

А выливается она на примере Firefox вот в это:
При посещении ЛОРа и всяких сайтов с мангой по каждому удобному случаю генерирующих новый URL у меня в истории накопилось куча ссылок, это не тормозило браузер, но искать нужные ссылке среди всех этих мусорных ссылок было не удобно.

И так, самое главное недовольство это то, что процесс по удалению около 12~14 тысяч ссылок длился около двух часов и всё это время встроенная БД тормозила браузер настолько, что по сути делала его неработоспособным.

При этом браузер при удалении пакета из более чем 5000 ссылок занял всё свободное ОЗУ в 3.65 ГБ и е6щё примерно столько же в свопе, после чего процесс удаления упал оставив недоудалёнными около/более полуторатысяч ссылок.

Дале, было бы хорошо выделять ссылки по сложным условиям, например remanga.org AND /ch[digest], но формы для задания нескольких условий в диалоге истории нет.

Далее было бы хорошо сделать скрипт, в который были бы внесены шаблоны удаляемых ссылок и поставив этот скрипт на ночь уйти спать, но БД то встроенная и мне пришлось все два часа сидеть за компом и вбивать новые запросы, сортировать ссылки и выделять их блоки в ручную.

Вывод

Внутренняя БД не упрощает программирования, но при этом создаёт кучу неудобств при дальнейшей эксплуатации приложения, не давая при этом пользователю самому решать и автоматизировать не типичные и мало распространённые задачи.
При этом само приложение выступает узким местом в работе с этой БД, затрудняя и ограничивая действия пользователя.

★★★★★

Последнее исправление: torvn77 (всего исправлений: 2)

Ответ на: комментарий от anonymous

теперь пофантазируем на тему, как мог бы выглядеть на такой вот персистентной ООСУБД «правильный гипертекст»:

  • вместо DOM, хранимого в памяти, трудно сериализуемого, жрущего память оперативную – внутреннее представление хранимое в глобалях MUMPSа низкоуровнево, снаружи видное как ООСУБД API наподобие метаобъектного протокола с мультиметодами из Common Lisp

** собственно, в каком-то «встроенном браузерном движке» ЕМНИП, GOODS ООСУБД К. Книжника прикрутили. на С++. ну почему бы не взять вот нормальную полноценную ООСУБД.

  • вместо парсера, который жрёт память и строит полный DOM – потоковое представление

  • вместо текстового и AST представления – типизированные деревья

  • JavaScript не нужен

  • средства публикации контента типа Literate Programming, написанные на MUMPS. работающие непосредственно с ООСУБД объектами напрямую (*).

  • простой текстовый протокол типа Gopher.

  • простой формат гипертекстовых документов типа PDF. с возможным ООСУБД реплицируемым представлением

** прокси, полноценно кеширующий объекты.

  • ну или не гофер а этот как там его новомодный Gemini.

(*) кстати, если посмотреть из архивов с примерами на EsiObjects в .opc/.opl файлы.

то там видно сериализованное представление этих самых объектов (с частично LitProg документацией в RTF) – которое по сути очень напоминает WEB литературный.

у документов есть метаданные: время создания, юзер, связи, отношения, события.

в общем: есть мнение что на этом вот всём можно было бы запилить ГОРАЗДО более удобный и правильный гипертекст – чем сейчас мы наблюдаем в браузере.

многомерный, на базе MUMPS, OLAP. и ООСУБД интерфейса к нему поверх. который делает ненужными всякие там CMS-ки.

anonymous
()

в хромиуме кстати история и поиск в ней сделаны отвратительно. гораздо хуже и не удобнее даже той же Opera Presto. там сложно что-то найти.

а по идее нужно бы что-то типа облака тегов с произвольными метаданными, и какие-то правила для автоматической классификации по таким тегам.

anonymous
()
Ответ на: комментарий от anonymous

при этом на MUMPS-ах встраиваемый движок прикрутить всяко не сложнее того же ООСУБД GOODS К. Книжника.

существуют MiniMono (проприетарный, бесплатный, все основные ОС), YottaDB (С API доступа к глобалам, бесплатный, открытые исходники, современный форк GT.M).

почему все так упарываются то по SQL-ям, то по ещё более простым неиерархическим NoSQL ключ-значение в браузерах (получая потом GIL и проблемы с масштабируемостью таких недобазок), а не используют нормальную СУБД – тайна сия велика есть

anonymous
()
Ответ на: комментарий от bhfq

cool story, bro.

ну прям «24 cpu, а я не могу двинуть курсор». «почему проводник запускается по 30 секунд и жрёт CPU, когда иконок на рабочем столе больше 100» – во всём виноваты квадратичные алгоритмы и «тяп-ляп и в продакшн»

остаётся только гадать сколько в таких недобазках ещё всяких GIL осталось.

anonymous
()
Ответ на: комментарий от byko3y

Кому, как не мне, хардкорщику с «You are about to close 6648 tabs. Are you sure you want to continue?»

не, именно столько вкладок у меня не было. было примерно 3500 в хроме и примерно 3500..4000, максимум 5500+ в файрфоксе.

при запуске браузера – ожидаемые тормоза секунд на 20-30.

из-за подгрузки вкладок в файрфоксе «по требованию» напихать туда можно было поболее вкладок.

и он даже почти не тормозил и не падал, корёжа профиль и накрывая всю историю и сессию медным тазом.

потом профиль переехал на рамдиск, вокруг него добавились костыли-обёртки для бекапа образа рамдиска и профиля пофайлово через rsync для истории Last Known Good Profile, и бекапы понедельно.

но всё равно же блин. хранили бы те же кеши, историю, сессию – как нормальные ООСУБД персистентные объекты. или лучше как мумпсовые глобали.

и проблемы с битым профилем не существовало бы по определению.

anonymous
()
Ответ на: комментарий от anonymous

ещё существует MSH – переосмысленное ОО развитие идей MUMPS.

открытые исходники, реализация интерпретатора под Linux.

в целом, здравые идеи есть. например, если классический M сервер это «кеширующий сервер глобалов и рутин» где рутины = сопрограммы на языке вроде ФОКАЛа, то далее в Cache Object скрипт добавили объекты написав свой диалект (частично на макросах M), а в EsiObjects – запилили свой ОО язык с транслятором через EsiParser на ANTLR в базовый M.

далее в GT.M как и в O’Kane’s MUMPS на С++ реализовали трансляцию из M в C++. то есть GT.M это по сути современный компилируемый M, который транслируется в *.o, расширяется на *.so.

ещё там более-менее нормальная поддержка UTF8 в GT.M.

потом возник форк от основных разработчиков GT.M : YottaDB где выпилили кроссплатформенность и пытаются избавиться от самого языка M.

там и пытаются реализовать эту вот идею «библиотека доступа к глобалам» без языка M на разных API: C API, Go, Rust, Python, и т.п.

например, где-то в VISTA был пример доступа к GT.M на питоне. через pexpect. фактически expect’ом автомагически бот на питоне общается через телнет с мумпсом.

ну то есть, сейчас имхо для реализации чего-то в духе MSH не обязательно костылить свой недоинтерпретатор на коленке (и недоделанную СУБД). можно взять YottaDB, C API и ковырять его. реализовав свой ОО недоязычок вместо канонiчного M.

и стремиться куда-то в направлении EsiObjects / Cache Object Script как полноценной CASE IDE к ООСУБД поверх мумпсов.

anonymous
()
Ответ на: комментарий от anonymous

в хромиуме накостылили ещё один свой велосипед

«Велосипед» из хрома используется в Riak и Bitcoin Core. NoSQL, вроде Беркли DB, ближе по духу к данным, которые хранятся в БД браузера. FF перешли на SQLite не от хорошей жизни, а из-за того, что не могли толком поддерживать свое собственное решение.

byko3y ★★★★
()
Ответ на: комментарий от anonymous

вместо DOM, хранимого в памяти, трудно сериализуемого, жрущего память оперативную – внутреннее представление хранимое в глобалях MUMPSа низкоуровнево, снаружи видное как ООСУБД API наподобие метаобъектного протокола с мультиметодами из Common Lisp
JavaScript не нужен
многомерный, на базе MUMPS

Завязывай со спидами.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

взяли бы нормальную, полноценную внешнюю СУБД (не SQL, разумеется, а получше) – и всё это было бы легко осуществимо.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.