LINUX.ORG.RU

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

 


0

2

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

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

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

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

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

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

Вывод

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

★★★★★

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

Какая-то бузина в огороде. «Вообще внутренняя БД» и как это конкретно реализовано в фаерфоксе, это немножко разные вещи.

Там ведь SQLite, имхо? Ну так если ты её рассматриваешь именно как БД, можешь подлезть к ней каким-нибудь DB Browser или вообще своё приложение написать. Другое дело, что Мозилла тебе не обещает, что оно гарантирует совместимость впоследствии.

Внутренняя БД не упрощает программирования

Не упрощает по сравнению с чем?

hobbit ★★★★★
()

процесс по удалению около 12~14 тысяч ссылок длился около двух часов

пользуйся на здоровье

$ find ${HOME}/.mozilla/firefox/ -type f -name places.sqlite -exec sqlite3 {} "delete from moz_places where url like('%windows.org.ru%');" \;

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

Есть некоторая разница между полным удалением кеша сайта и удалением выбранных в окне истории ссылок.

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

Можно было бы паралельно удалять URL и сидеть в браузере.
Возможно внешняя БД работала бы быстрее и имела развитый язык запросов, postgresql например вообще разрешает внутри себя делать скрипты.

На самом деле после поста О внешних и встраиваемых в приложение серверах баз данных (комментарий) думаю что может и не очень мног чего бы поменялось, но всё же то, что сейчас работа с историей по факту парализует браузер довольно не удобно.

torvn77 ★★★★★
() автор топика
Последнее исправление: torvn77 (всего исправлений: 1)
Ответ на: комментарий от chenbr0

Одна страница манги == одна ссылка, хоть при горизонтальном просмотре, хоть при вертикальном.

Да и ЛОР со своим ?cid= тоже генератор мусора.

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

Нужно мыслить глобальнее: долгое удаление ссылок по сравнению с 12 тысячами просмотренных страниц манги не такая уж и большая проблема.

chenbr0
()

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

Если вопрос к доступности … многие встройки имеют свой сервер (например гиперскуль), который позволяет использовать встройку как внешнюю бд, при этом само приложение может продолжать использовать базу локально.
И почти все встройки, таки или иначе, доступны через *dbc - т.е. ты можешь либо подергать файл как тебе надо в своей программе, или поискать уже умеющую это делать программу

rukez ★★★★
()

БД ни при чём, SQLite - хорошая пони. Скорее всего, кто-то сотворил херню - либо ты, либо разрабы лиса. Ставлю на второе, пожалуй.

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

Возможно внешняя БД работала бы быстрее и имела развитый язык запросов, postgresql например вообще разрешает внутри себя делать скрипты.

Так вы не о внешней, а о другой базе данных. Известно что sqlite3 - тормозное ублюдище, это не значит что другая встраиваемая БД вела себя также плохо.

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

Так вы не о внешней, а о другой базе данных. Известно что sqlite3 - тормозное ублюдище, это не значит что другая встраиваемая БД вела себя также плохо

Не знаю, что за «другая БД». С «PRAGMA synchronous = OFF» SQLite летает как ураган. И уж точно не медленнее мускуля/постгреса на простых операциях в аналогичных режимах.

С другой стороны, можно было бы вспомнить, что реляционные СУБД традиционно отличаются неспешностью работы — но эта неспешность часто проистекает из того, что эти СУБД используют неправильно, то есть, хранят не то, не так, и вообще не в той СУБД. Кто-то хранит текстовые блобы в РСУБД, кто-то сует финансовые транзакции в старую монгу.

Конкретно по фаерфоксу: у меня за несколько лет интенсивного серфа накопился places.sqlite весом в 80 мб, который спокойно умещается в оперативке, а потому большинство запросов к нему можно выполнить тупым сканом за долю секунды. Если брать многоверсионные СУБД, вроде MySQL, Firebird, PostgreSQL, то онные постоянно шатают БД при малейших изменениях новыми копиями, раздувая объем файла в 5-10-15-20 раз, и в таких раскладах моя же БД с посещениями стала бы порядка 1 Гб, что все-таки влезет в файловый кэш на моем компе, но не всегда. По этой причине MySQL, MS SQL, Oracle, и SAP HANA поддерживают сжатие данных — чтобы влезть в оперативу и бегать быстрее. Но в случае SQLite ты влезаешь в оперативу из коробки — разве это не замечательно?

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

Но по факту

занял всё свободное ОЗУ в 3.65 ГБ и е6щё примерно столько же в свопе

процесс по удалению около 12~14 тысяч ссылок длился около двух часов

И это при специально перезапущенном браузере, чтобы максимально освободить память.

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

Нужно мыслить глобальнее: долгое удаление ссылок по сравнению с 12 тысячами просмотренных страниц манги не такая уж и большая проблема.

А это не он, это его "питомцы". Четверых из них я уже сегодня прибил.

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

Но по факту

занял всё свободное ОЗУ в 3.65 ГБ и е6щё примерно столько же в свопе
процесс по удалению около 12~14 тысяч ссылок длился около двух часов

И это при специально перезапущенном браузере, чтобы максимально освободить память

Кто занял? Firefox или SQlite в нем? Кому, как не мне, хардкорщику с «You are about to close 6648 tabs. Are you sure you want to continue?», знать, что Firefox любит жрать память. Просто любит он это дело.

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

Значит, что-то делаешь не так. Подёргай настройки в about:config, наверняка там что-то есть относительно БД.

Ну или скриптом выше, как @resistance предлагает.

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

6648 tabs

Firefox любит жрать память

Вот ведь мерзкая лисица.

Nervous ★★★★★
()

разрабам налить с горы на проблемы пользователей https://github.com/bitcoin/bitcoin/issues/20647

вывод прост: хочешь чтобы было так как тебе нравится - редактор кода в руки и вперёд.

anonymous
()

Это Firefox говно просто, для SQLite такой объём не проблема.

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

Тормозит не sqlite3, а JS в этой самой форме.

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

Тогда я не понял, что за питомцы, и как ты их прибиваешь…

Тараканы. На ЛОР-е уже байка ходит, что они ко мне от Торина мигрировали (на самом деле они из вентиляции полезли, надо будет на недельке там хорошенько законопатить лишние щели).

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

По сравнению с чем тормозное, и где бенчмарки?

Бенчей не осталось, но там где лайт вывозил 500к/с записей, гипер у меня вывез под 5кк/с сразу из коробки, уперевшись, подозреваю в диск.
Это просто запись в одну таблицу с одним индексом строки с пятком ууидов, парой интов и парой коротких строк.
Быстрее гипера у меня получалось только прямком на диск сливать заранее собранный буфер из озу, но это такое одностороннее решение :-)

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

Бенчей не осталось, но там где лайт вывозил 500к/с записей, гипер у меня вывез под 5кк/с сразу из коробки

Во, оказывается, кто-то уже делал аналог SAP HANA, причем, примерно одновременно с SAP. Собственно, тригером этому стал рост объема оперативной памяти до объема данных. Естественно, никакая disk-first СУБД не сможет сравниться с этими показателями. Жаль, что это не опенсорс — я искал подобную СУБД.

гипер у меня вывез под 5кк/с сразу из коробки, уперевшись, подозреваю в диск

На видеокартах достигали чего-то порядка миллиарда. Да, там и вовсе не было речи про многоверсионность и персистентность, а объем данных упирался в объем VRAM, которая намного дороже обычной оперативы.

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

SAP HANA по таймеру делает снимок данных из памяти. Бизнес, внезапно, осознал, что Durability составляющая ACID стоит недопустимо много, и ее можно просто выкинуть из уравнения, компенсировав недостаток надежности дублированием серверов. К слову, разрабы Hyper лапши навешали про свою поддержку ACID, но так популярно делать, так что они тут не единственные.

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

Охренеть соседство – Петербург и Житомир.

Да вот я и удивился :) Ну и тараканы как зрители манги отдельно от хозяина квартиры — это тоже прекрасно.

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

но там где лайт вывозил 500к/с записей, гипер у меня вывез под 5кк/с

«Лайт» при этом БД в памяти делал или на диске?

P.S. Ты про этот Гипер, как я понял? А то есть и другие СУБД с похожим названием, не говоря уж, что оно довольно плохо гуглится.

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от Korchevatel

Охренеть соседство – Петербург и Житомир.

Вот такой глобальный у нас Петербург!

Ну или Житомир.

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

Ну и тараканы как зрители манги отдельно от хозяина квартиры — это тоже прекрасно.

Что-то сразу тот канадский мультик про голубого кота и трёх тараканов вспомнился. Где-то даже "пуп" на него видел, где тараканы хентай смотрели.

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

Ну и тараканы как зрители манги отдельно от хозяина квартиры — это тоже прекрасно

Скоро они его расчленят и выкинут в Фонтанку.

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

Это правда, при старте компа с hdd у меня фокс парализован минут на 5

Эм-м-м-м.... у меня профиль лисы лежит на харде. Да, бинарники на SSD, но меняет ли это что-то? Старт где-то за минуту:

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

byko3y ★★★★
()

искать нужные ссылке среди всех этих мусорных ссылок было не удобно

Пропусукая цветение сакуры
Мангу ищет отаку в исутории
Баке подобен

Создаешь папку autocomplete в закладках, лайкаешь в нее нужные страницы своего хентая, историю очищаешь как обычно /тред

anonymous
()

Кто-то только об этом узнает. Проблеме 9 лет https://bugzilla.mozilla.org/show_bug.cgi?id=734643

Для тех кто хочет попробовать «воспроизвести» у себя:

  1. открыть историю браузера, окно «библиотека»
  2. слева выбрать всю историю написано «журнал» над месяцами
  3. в поисковом запросе сверху написать «search»
  4. выделить все CTRL+A - правой кнопкой - удалить страницы DEL.
  5. ?????? CABOOOM!

p.s. делайте бекапы перед игрушкой, особенно весело когда удаляется страниц так 2+ тысячи.

bhfq ★★★★★
()
Последнее исправление: bhfq (всего исправлений: 1)

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

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

согласен полностью. в Netscape/Mozilla/Firefox исторически было ранее Berkley DB, даже не встроенная СУБД толком а просто «библиотека доступа к данным». в хромиуме накостылили ещё один свой велосипед.

это если не считать LocalStorage и SQLite.

SQLite кстати тоже с проблемами именно для этого применения. его используют в качестве бесплатной поддержки транзакций из-за атомарного изменения «БД в одном файле». примерно как в fossil где весь репозиторий проекта хранится в одной SQLite базе.

если честно, то лучше бы нормальную СУБД взяли.

не SQL, конечно. а какую-то иерархическую ключ-значение, например тот же MUMPS с многомерным OLAP встроенным «из коробки».

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

заодно, XHTML вполне себе можно преобразовывать в MUMPS-совые глобали. и обращаться к ним как к многомерному гипертексту, по индексам в разреженном массиве (который по сути хешмапа ключ-значение, ключи иерархические и приводятся к строкам, числа в каноническом представлении тоже приводятся к строкам).

есть ощущение, что на глобалях MUMPSа можно запилить потоковый XML парсер. то есть, не строить полный DOM и не хранить его в оперативной памяти. а строить инкрементально, как персистентный объект.

на тему ОО СУБД можно в духе Cache Object Script (проприетарного для Cache; ну или вполне себе открытого EsiObjects для GT.M/YottaDB) запилить ORM слой.

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

из рекламы EsiObjects годов примерно 1995..2001, туториала:

  • создаём персистентый объект уровня ООСУБД: в графическом CASE IDE наподобие смоллтокового браузера или как в Cache COS:

  • добавили новый класс. частично из IDE, частично из REPL.

  • добавили этому классу новое свойство

  • добавили этому классу новый метод

  • добавили другой новый класс

  • добавили старому классу новое отношение : задав прямые и обратные связи разными отношениями. задали отношениям кардинальность : 1:N, M:N, N:1, 1:1 просто через Drag’n’Drop между классами. при этом при формировании первого автоматически сформировалось обратное, поддерживается целостность связей.

** практически похоже на то, как внешние ключи в Access в Query-by-Example делаются.

далее через такой вот визуальный CASE редактор можно практически мышкой набросать предметную область. в туториале там пример про документооборот.

  • затем таким объектам добавили события.

получаем готовый сервер ООСУБД, набросанный мышкой.

это живая система вроде смоллтока: работают фишки вроде Refactoring Browser. например можно рефакторить в инварианты: перемещать метод/свойство между предками и потомками, переименовывать сигнатуру (+автоматически все применения), создавать пакеты и подсистемы, библиотеки классов (серверные уровня ООСУБД)

  • потом пишем клиента, «сервер приложений». лепим фабрику объектов и MVC.

в итоге прочитав этот туториал по EsiObjects: получаем готовый ОО компонент клиент/сервер/сервер приложений где сервер – работает на ОО СУБД на своём ОО языке типа COS, (ОО, высокоуровневый), который автомаГически транслируется в низкоуровневый (типа MUMPS где глобали и рутины. то есть, иерархические деревья/разреженные массивы/хэштаблицы ключ-значение, с иерархическими ключами. а рутины – хранимки процедурные, не ОО).

то есть, на MUMPS реализована модель данных ООСУБД (а также SQL) и трансляция ООСУБД высокоуровневого языка хранимых объектов типа COS в низкоуровневое типа MUMPS.

наподобие метаобъектного протокола с рефлексией.

там были доступны исходники примера, CASE под GTK, дамп базы под GT.M, парсер этого языка на ANTLR 2.7, транслятор с этого языка в M.

в этом EsiObjects. то есть, с практической зрения можно считать что EsiObjects реализует всё то же самое, что и Cache Object Script.

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