The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск СУБД Firebird 3.0.3, opennews (??), 05-Фев-18, (0) [смотреть все] +1

Сообщения [Сортировка по времени | RSS]


25. "Выпуск СУБД Firebird 3.0.3"  +/
Сообщение от amonymous (?), 05-Фев-18, 13:09 
Ну то есть SQLite3 её может заменить только в путь.
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

29. "Выпуск СУБД Firebird 3.0.3"  +3 +/
Сообщение от iZEN (ok), 05-Фев-18, 13:47 
SQLite3 не поддерживает клиент-серверный режим по сети и блокирует файл от других процессов при записи в БД. То есть SQLite3 - это встраиваемая СУБД с монопольным доступом на запись. Firebird работает с несколькими транзакционными моделями, например, даже тогда, когда данные могут не блокироваться от модификации при доступе к базе из нескольких процессов.
Ответить | Правка | Наверх | Cообщить модератору

37. "Выпуск СУБД Firebird 3.0.3"  –3 +/
Сообщение от пох (?), 05-Фев-18, 15:32 
> SQLite3 не поддерживает клиент-серверный режим по сети и блокирует файл от других

то есть ненужного протокола (написанного специалистом по тазам банных - т.е. как правило либо плохого, либо с дырой вместо аутентификации, либо то и другое сразу, и все бережно завернуто в openssl)
> процессов при записи в БД. То есть SQLite3 - это встраиваемая

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

> СУБД с монопольным доступом на запись. Firebird работает с несколькими транзакционными
> моделями, например, даже тогда, когда данные могут не блокироваться от модификации
> при доступе к базе из нескольких процессов.

не могут. Это называется "транзакционная целостность".
Просто то, что в случае sqlite, решается банальным lockf, и ожиданием других процессов, в случае "больших" баз может решаться постановкой запросов в очередь единственного процесса (а чаще то и другое - пул процессов плюс взаимный локинг). Что совой об пень, что пнем о сову - пока данные не запишутся на диск, сообщить сказавшему 'commit' об успешном завершении (или дать ему по морде forced rollback'ом, если пока он копался, данные протухли) мы не можем.

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

А "транзакционные модели" вида immediate/exclusive/deferred есть, не поверишь, и у sqlite. row locks вот нету, не очень и нужны.

Ответить | Правка | Наверх | Cообщить модератору

53. "Выпуск СУБД Firebird 3.0.3"  +3 +/
Сообщение от Crazy Alex (ok), 05-Фев-18, 18:02 
Ты пошутить решил?

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

Ответить | Правка | Наверх | Cообщить модератору

55. "Выпуск СУБД Firebird 3.0.3"  –1 +/
Сообщение от пох (?), 05-Фев-18, 18:18 
> Как самый-самый минимум - "большие" сервера лочат таблицы, а не базу целиком. А обычно - даже не
> таблицы, а диапазоны

ты реально не отличаешь внутриsqlевые "локи" от логики физической записи на диск?

Ответить | Правка | Наверх | Cообщить модератору

70. "Выпуск СУБД Firebird 3.0.3"  +/
Сообщение от Crazy Alex (ok), 06-Фев-18, 01:05 
Ты ж не думаешь, что в больших БД действительно все транзакции последовательно идут и сразу на диск пишутся? А у sqlite - да, гранулярность - вся база.
Ответить | Правка | Наверх | Cообщить модератору

73. "Выпуск СУБД Firebird 3.0.3"  +1 +/
Сообщение от Аноним (-), 06-Фев-18, 03:41 
Физическая запись какого рода имеется ввиду? В редо-логи, ундо-логи или в сами таблицы?
Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

101. "Выпуск СУБД Firebird 3.0.3"  –1 +/
Сообщение от пох (?), 06-Фев-18, 12:20 
> Физическая запись какого рода имеется ввиду? В редо-логи, ундо-логи или в сами
> таблицы?

и в чем великая разница?

Ответить | Правка | Наверх | Cообщить модератору

121. "Выпуск СУБД Firebird 3.0.3"  +1 +/
Сообщение от _ (??), 06-Фев-18, 19:40 
Как бы это тебе сказать то ... в кровавом они как минимум на разных девайсах :-)
Причём сами таблы - всё ещё на блинах, а вот другие - на другом :)
Дальше объяснять?
Ответить | Правка | Наверх | Cообщить модератору

124. "Выпуск СУБД Firebird 3.0.3"  –1 +/
Сообщение от rpm (?), 07-Фев-18, 00:14 
>> Физическая запись какого рода имеется ввиду? В редо-логи, ундо-логи или в сами
>> таблицы?
> и в чем великая разница?

Как минимум в частоте записи. Сохранять данные после каждого комита дорого. Поэтому для устойчивости придумали редологи, что позволяет сами данные сохранять нечасто. А сами надо то в силу простоты имеют высокую производительность. И уж точно не является скрытой блокировкой, об утверждении которой и началось обсуждение, тк запись в редо независима и не требцет никаких блокировок.

Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

72. "Выпуск СУБД Firebird 3.0.3"  +1 +/
Сообщение от Аноним (-), 06-Фев-18, 03:39 
>не могут. Это называется "транзакционная целостность".
>Просто то, что в случае sqlite, решается банальным lockf, и ожиданием других процессов, в случае >"больших" баз может решаться постановкой запросов в очередь единственного процесса (а чаще то и >другое - пул процессов плюс взаимный локинг). Что совой об пень, что пнем о сову - пока данные не >запишутся на диск, сообщить сказавшему 'commit' об успешном завершении (или дать ему по морде forced rollback'ом, если пока он копался, данные протухли) мы не можем.
>у других есть еще всякие гранулярные локи, но выигрыш от них, как правило, преувеличен, по >сравнению со сложностью реализации.

Наглядный пример воинствующей некомпетенсности.

Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

80. "Выпуск СУБД Firebird 3.0.3"  –1 +/
Сообщение от anomymous (?), 06-Фев-18, 08:43 
Нахрена огнептаху клиент-сервер, если его большинство всё равно гоняет рядом с приложением?
Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

41. "Выпуск СУБД Firebird 3.0.3"  –1 +/
Сообщение от пох (?), 05-Фев-18, 15:39 
не, не может - "сертификация ФСТЭК" это вам не хухры-мухры.
Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

76. "Выпуск СУБД Firebird 3.0.3"  +/
Сообщение от Аноним (-), 06-Фев-18, 04:46 
Ай, ну объявится какой-нибудь местный Firebird Pro. Был бы спрос.
Ответить | Правка | Наверх | Cообщить модератору

81. "Выпуск СУБД Firebird 3.0.3"  +/
Сообщение от anomymous (?), 06-Фев-18, 08:45 
> не, не может - "сертификация ФСТЭК" это вам не хухры-мухры.

Если увидится спрос и выгода "сертификаторам" - сразу же сертифицируют.

Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

51. "Выпуск СУБД Firebird 3.0.3"  +/
Сообщение от Аноним (-), 05-Фев-18, 17:46 
> Ну то есть SQLite3 её может заменить только в путь.

Да не, слишком много в софте реализовать придётся ( т.е. дорого ) и в случае если перерастёт уровень 1 компа, то переписывание всего софта

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

59. "Выпуск СУБД Firebird 3.0.3"  –1 +/
Сообщение от пох (?), 05-Фев-18, 18:47 
> Да не, слишком много в софте реализовать придётся ( т.е. дорого ) и в случае если перерастёт
> уровень 1 компа, то переписывание всего софта

люди, "перерастающие уровень 1го компа" и НЕ переписывающие свой софт (часто заодно с полным переделыванием и структуры данных тоже) - вынуждены будут делать это ненамного позже, с характерным результатом в виде получения интенсивной любви от пользователей их продукта.

А если софт все равно переписывать - то в общем-то никто не мешает нарисовать правильный mid-layer, который и будет заниматься общением с базой. Как, в общем-то, в правильном софте и принято. А на то что субд заменит тебе нормальное проектирование софта для многоюзерской параллельной работы, надеются только кое-какеры и неудачники.

(были времена, когда это действительно было так, но, к сожалению, давным-давно прошли. А то б кругом был один oracle на мега-кластерах)

Ответить | Правка | Наверх | Cообщить модератору

71. "Выпуск СУБД Firebird 3.0.3"  +/
Сообщение от Crazy Alex (ok), 06-Фев-18, 01:14 
Есть дофига применений "между". Собственно, все базочки для мелких контор из этого "между". Где совершенно тупого выноса базы из embeddded в отдельный сервер (при условии рефелекторного примененения транзакций при написании софтины) достаточно, чтобы из однопользоватлеьской аппы сделать "многопользовательскую" - то есть нормально работающую на 3-5-10 человек, шуршащих без особой интенсивности. А больше - и не надо. С другой стороны, пока юзер один - можно не заморачиваться созданием и поддержкой отдельного сервера БД, который должен быть включён, доступен и не пинаем уборщицей.

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

Ответить | Правка | Наверх | Cообщить модератору

86. "Выпуск СУБД Firebird 3.0.3"  –1 +/
Сообщение от пох (?), 06-Фев-18, 09:01 
> Есть дофига применений "между".

сделанные я-у-мамы-программисом по рецептам, найденным на stackoverflow ("хотя бы из ответа, или из вопроса?")

> Собственно, все базочки для мелких контор из этого "между".

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

А дальше - кому как повезло. Но если было сделано на чем-то обычном, pg/mysql/да хрен с ним, ms, наконец - обычно наследники могут как-то это все поднять, без особых проблем. Иногда даже и улучшить что-то.
А ходить вокруг сдохшего overengineered монстра, выбросившего тебе ora-0006, можно вечность, без особых успехов. Или мучительно пытаться поапгрейдить уже толком неживую систему аж на one true interbase (c) borland на что-то, хотя бы не требующее библиотек и дистрибутива 2001го года выпуска.
(и главное, вроде ты все это и починил в конечном итоге, но осадочек-то остается)

> Где совершенно тупого выноса базы из embeddded в отдельный сервер (при условии рефелекторного
> примененения транзакций при написании софтины) достаточно, чтобы из однопользоватлеьской аппы
> сделать "многопользовательскую" - то есть нормально работающую на 3-5-10 человек, шуршащих без

ты не поверишь, мы трахались с такой "многопользовательской" аппой в далеком 95м году. Она даже и работала - пока их было 3-5-10 (без всякого отдельного сервера, попутно и ресурсы жрала не с одного сервера, а с многих клиентов разом, по тем временам гораздо более дешевое решение). А как стало 20 - наступили опаньки, и отдельный сервер ничему не помог. И пришлось все переделывать с нуля и нормально - потому что и сама база, спроектированная на трех юзеров и небольшой объем, оказалась нафиг неоптимальна для двадцати и совсем других масштабов.

Ответить | Правка | Наверх | Cообщить модератору

102. "Выпуск СУБД Firebird 3.0.3"  –1 +/
Сообщение от пох (?), 06-Фев-18, 12:31 
> А если о вебе говорить - так там вообще масштабирование в пределах
> трёх порядков решается костылями из кэшей. Бардак выходит, но более-менее живой

уныло глядя на висящие GET LOCK ... в processlist (как ты понимаешь, ни разу не sqlite, хотя вот этому уроду вполне бы хватило) - нихрена оно не решается :-(

> и приносящий деньги владельцу

и хде тут мой мильен? А, вот он...уп-с, нет, это счет от провайдера...

Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

82. "Выпуск СУБД Firebird 3.0.3"  +/
Сообщение от anomymous (?), 06-Фев-18, 08:47 
> Да не, слишком много в софте реализовать придётся ( т.е. дорого )
> и в случае если перерастёт уровень 1 компа, то переписывание всего
> софта

Если делать без абстракции - да. А если с абстракцией - то no problem, мимимальные правки в единичных неабстрагируемых запросах. Ну и в софте там "много" реализовывать нечего, тот же SQL.

Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

87. "Выпуск СУБД Firebird 3.0.3"  –1 +/
Сообщение от пох (?), 06-Фев-18, 09:06 
> Если делать без абстракции - да. А если с абстракцией - то

ты вот точно ради базы на одно лицо будешь пихать в код какие-то "абстракции" и универсальный бд-независимый midlayer?

> no problem, мимимальные правки в единичных неабстрагируемых запросах. Ну и в
> софте там "много" реализовывать нечего, тот же SQL.

пока не натыкаешься на несовместимость нестандартных типов, или на банальный 'autoincrement'.

Ответить | Правка | Наверх | Cообщить модератору

122. "Выпуск СУБД Firebird 3.0.3"  +/
Сообщение от _ (??), 06-Фев-18, 19:49 
>> Если делать без абстракции - да. А если с абстракцией - то
>ты вот точно ради базы на одно лицо будешь пихать в код какие-то "абстракции" и универсальный бд-независимый midlayer?

Я думаю он всего лишь об ORM. Я уж 100 лет не видел жабщика который сам SQL рисует. Есть же Hibernate! Причём оно умнее програмизда, ну и чего мучиЦЦо?! :-)

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру