Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 .. 14   вперед  Ctrl
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
kdv,

Позволю себе начать с конца.
автор
Однако, отличие этих "пересекающихся ресурсов" не позволяет сделать вывод, что ФБ не способен обслуживать более 50 пользователей, с чего тут и началась дискуссия.

Я не делал таких выводов! "Слово это ругательное, и прошу его ко мне не применять!" ((с) х\ф Иван Васильевич меняет профессию)
автор
гм, в каком смысле? Невозможно из разных потоков-процессов писать в один random-access файл? Это как это?

Невозможно в FB читать из одного файла, а в другой писать. Это понятно, я надеюсь?
автор
запись в разные участки одного файла ничем не отличается от записи в разные участки разных файлов.

При этом чтение из разных участков одного файла это одно, а чтение из одного (многих) и последовательная запись "в конец" другого - это другое. Прошу прощения за тавтологию.
автор
Тем не менее, в любой СУБД есть пересекающиеся дисковые (и не-дисковые) ресурсы. Без этого, увы, никак, что в ФБ, что в MS SQL.

Бешено плюсую!
5 мар 15, 00:12    [17344554]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
hvlad
Member

Откуда:
Сообщений: 11551
Вася Уткин
Ответ на свой вопрос вы вырезали из цитаты, прям супер-полемический прием, детский сад
Я процитировал не больше и не меньше необходимого. Если вам это кажется детсадом, то это просто ваш уровень понимания собеседника.

Ну и подумайте над собственным уровнем аргументации:
Вася Уткин
СУБД может хоть весь день не скидывать данные в БД, все в лог
Вася Уткин
В течении дня не спеша скинет в БД сколько сможет
это ли не детсад ?

PS Мне гораздо больше кажется детсадом ваш серый ник... но не будем об этом.
5 мар 15, 00:12    [17344556]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
hvlad
PS Мне гораздо больше кажется детсадом ваш серый ник...


Yo.!, ты слышал?
5 мар 15, 00:17    [17344566]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
hvlad
Member

Откуда:
Сообщений: 11551
pkarklin
У Вас, полагаю, есть данные влияния процесса Lazy Writer на все остальные?
Из очевидного - пока данные пишутся на диск, страницы заблокированы от записи.
При плотном потоке изменений Lazy Writer не будет успевать сбросить все грязные страницы между чекпойнтами и\или предотвратить заполнение всего кеша грязными страницами.
На более низком уровне - контроллер диска обработает меньше запросов на чтение, при наличии потока запросов на запись.
И т.д. Я не удивлюсь, если там есть ещё связи, которые мне отсюда не видны.
5 мар 15, 00:21    [17344574]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Вася Уткин
Guest
hvlad
Вася Уткин
Ответ на свой вопрос вы вырезали из цитаты, прям супер-полемический прием, детский сад
Я процитировал не больше и не меньше необходимого. Если вам это кажется детсадом, то это просто ваш уровень понимания собеседника.

Ну и подумайте над собственным уровнем аргументации:
Вася Уткин
СУБД может хоть весь день не скидывать данные в БД, все в лог
Вася Уткин
В течении дня не спеша скинет в БД сколько сможет
это ли не детсад ?

PS Мне гораздо больше кажется детсадом ваш серый ник... но не будем об этом.

Мда, так задело сильно?
Между может и должен знаете разницу? Ясли

Автору надо добавить колонку - количество адекватных разработчиков СУБД, а то потом будете вот с такими общаться :)
5 мар 15, 00:27    [17344586]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
hvlad
При плотном потоке изменений Lazy Writer не будет успевать сбросить все грязные страницы между чекпойнтами и\или предотвратить заполнение всего кеша грязными страницами.
На более низком уровне - контроллер диска обработает меньше запросов на чтение, при наличии потока запросов на запись.
И т.д. Я не удивлюсь, если там есть ещё связи, которые мне отсюда не видны.


А можно это фантасмогорию представить в виде репро? Я готов в выходные потратить время на прогоне этого всего на Stage окружении.
5 мар 15, 00:32    [17344599]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30242
pkarklin
Я не делал таких выводов!

я все пытаюсь вернуть дискуссию к автору, ее развязавшему.
pkarklin
Невозможно в FB читать из одного файла, а в другой писать. Это понятно, я надеюсь?

в ФБ можно читать из одной части файла, и писать в другую. Кроме того, ФБ работает с временными файлами для разных целей, и т.д.
Ей-богу, я до сих пор не понимаю, при чем тут один файл. С тем же успехом можно сказать, что MS SQL не может работать с БД как с одним файлом, и считать это его недостатком. А?
pkarklin
При этом чтение из разных участков одного файла это одно, а чтение из одного (многих) и последовательная запись "в конец" другого - это другое.

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

если бы, как считает "любитель MSSQL", MS SQL занимался бы только "последовательным доступом к диску" 17342189... Но ведь это не так. А вместо этого берется архитектура MS SQL, натягивается на FB, который имеет другую архитектуру, и отсюда делается вывод, что ФБ плохой, потому что он ... не MS SQL?
5 мар 15, 01:15    [17344662]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Любитель MSSQL
Guest
У многих адептов IB/FB здесь есть не совсем верное понимание об архитектуре MS SQL:

1. Все изменения страниц происходят в ОЗУ. Если данной страницы в ОЗУ нет, ее подгружает сервер из файла данных.
2. Измененная страница не попадает сразу в файл данных, а хранится в ОЗУ и все новые запросы к ней обращаются именно к измененному состоянию страницы, которое хранится в ОЗУ
3. Все запросы читают данные из ОЗУ, если их там нет, то они подгружаются
4. Если "грязная" страница не сброшена на диск и опять подвергается изменению, она просто становится более "грязнее" (это к вопросу hvlad) и когда-нибудь она будет сброшена на диск в последнем состоянии.
5. Сброс на диск (он же чекпойнт) процедура вовсе некритически важная для целостности базы. Вся информация о странице есть в журнале транзакций.
6. Каждая страница в файле данных имеет номер транзакции после последнего сброса, и в случае сбоя, при восстановлении базы сервер сравнивает последний номер транзакции базы с последним номером данной страницы, и принимается решение о накате или откате.
7. То есть SQL Server проводит "красной нитью" концепцию "меньше работаем с файлами данных на запись", "все делаем в ОЗУ", "последовательно пишем в журнал".

Хотя я могу ошибаться, но многоуважаемый мною pkarklin меня думаю поправит.
5 мар 15, 01:24    [17344671]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
hvlad
Member

Откуда:
Сообщений: 11551
Вася Уткин,

Ещё раз убедился, что говорить тут не с кем и не о чем.
5 мар 15, 01:29    [17344679]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
hvlad
Member

Откуда:
Сообщений: 11551
pkarklin
А можно это фантасмогорию представить в виде репро?
Вы пытаетесь меня заставить что-то доказывать - я не вижу для себя смысла играть в ваши игры.
Всё, что я написал выше легко проверить самостоятельно, при наличии желания.
Если вы с этим не согласны - ваше право, я не имею ни малейшего желания тут кого-то в чём-то убеждать.
5 мар 15, 01:32    [17344682]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
hvlad
Member

Откуда:
Сообщений: 11551
Любитель MSSQL,

вы действительно думаете, что открыли для кого-то здесь что-то новое ?
Научитесь сначала читать то, что вам пишут, потом будете откровениями сыпать :)
5 мар 15, 01:37    [17344686]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Любитель MSSQL
Guest
автор
Из очевидного - пока данные пишутся на диск, страницы заблокированы от записи.


Кто Вам сказал этот бред, процедура сброса на диск (в файл данных) и процедура их изменения в ОЗУ абсолютно независимы (для этого в нормальных СУБД и придумали журнал как отдельная структура). Допустим начался процесс чекпойнт, и пока он длится меняйте хоть 1000 раз страницу, когда дойдет до нее очередь, страница просто сбросится последнем состоянии. Но все 1000 изменений будут в журнале. И мы можем восстановится, в случае необходимости на 952 состояние. Вам нужно понять одно, что чейкпойнт нужен лишь для того, чтобы быстрее восстанавливаться. В теории можно все восстановить из лога, но это будет очень-очень долго. Поэтому и нужны промежуточные состояния страниц на диске, да и ОЗУ не безлимитная. Так понятнее?
5 мар 15, 01:39    [17344690]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Любитель MSSQL
Guest
hvlad
Вася Уткин,

Ещё раз убедился, что говорить тут не с кем и не о чем.


Я думаю, если в дискуссии узнаешь, что-то новое, это всегда полезно. Никто не говорит бросайте FB и переходите на MS. Просто идет обмен мнениями и домыслами о разном устройстве разных СУБД.
5 мар 15, 01:44    [17344696]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Любитель MSSQL
Guest
Dimitry Sibiryakov
Любитель MSSQL
MS SQL имеет уровень изоляции транзакций Snapsho

Ну наконец-то MS SQL достиг уровня изоляции, с которого Interbase начинал 30 лет назад.
Поздравляю.


Он достиг этого 10 лет назад.
5 мар 15, 01:48    [17344706]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Любитель MSSQL
Guest
автор
Какой, нахрен, кэш результатов запросов???, "внутренняя фрагментация" - вообще непонятно о чем.

Я, право, тоже не совсем точно понял, о чем идет речь, поэтому пока не буду комментировать.

Это выдержка из википедии в статье о Firebird:)

https://ru.wikipedia.org/wiki/Firebird

автор
Среди недостатков: отсутствие кэша результатов запросов, полнотекстовых индексов, значительное падение производительности при росте внутренней фрагментации базы. Но над этим неустанно работает сообщество.
5 мар 15, 01:53    [17344711]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
hvlad
Member

Откуда:
Сообщений: 11551
Любитель MSSQL
автор
Из очевидного - пока данные пишутся на диск, страницы заблокированы от записи.


Кто Вам сказал этот бред, процедура сброса на диск (в файл данных) и процедура их изменения в ОЗУ абсолютно независимы
Ещё раз - перестаньте считать себя умнее собеседника, и научитесь читать то, что он пишет, а не то, что вам показалось.
5 мар 15, 01:59    [17344718]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
hvlad
Member

Откуда:
Сообщений: 11551
Любитель MSSQL
Я думаю, если в дискуссии узнаешь, что-то новое, это всегда полезно.
Именно. Поэтому - см. выше
5 мар 15, 01:59    [17344719]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Любитель MSSQL
Guest
kdv
pkarklin
При этом физическая из них только одна - последовательная запись в лог.

кажется, где-то тут этот вопрос уже разбирали. Допустим, существует запись в БД. Потом ее изменили. Т.е. старая запись в БД, новая - в логе. В разных местах. Делаем коммит. Запись из лога попадает в БД? А если до сих пор существует транзакция snapshot, которой надо видеть старый вариант записи?
Дисковая структура IB и FB оптимизирована под хранение версий, под множество длительных конкурентных snapshot, и т.д. Более того, у InterBase с версии 2007 есть журнал, только все это никак не влияет на вопрос, поднятый "Любитель MSSQL".
Если хотите, его придумки это почти то же самое, если я сейчас начну фантазировать на тему "почему MS SQL так неоптимально хранит данные и обрабатывает транзакции".


Итак по порядку

Допустим, существует запись в БД (я так понял в файле данных, номер LSN=100 (последний сброс из ОЗУ))
Потом ее изменили (я так понял зафиксировали транзакцию) (подгрузили в ОЗУ, и там изменили LSN=200, но файл данных об этом "не знает", но на все обращения других транзакций дается ответ по состоянию номера LSN=200)
Т.е. старая запись в БД, новая - в логе (старая запись в файле данных, а новая в журнале)
Запись из лога попадает в БД? (Нет!! Когда-то потом попадет из ОЗУ)
А если до сих пор существует транзакция snapshot, которой надо видеть старый вариант записи? (она увидит из базы tempdb, где будет хранится старая версия)

Это не придумки, повторюсь. Если вам необходимо записать 1000 дисковых блоков "последовательно", то есть головка будет себе постепенно смещаться в соседние сектора. Или в случае FB, она будет елозить по всему диску 1000 раз туда-сюда... А если 100 000...? Цифру 50 пользователей я взял с потолка. Просто подумайте какая бешенная нагрузка на перемещение головки.

И SSD не спасает, так как он не выигрывает по записи у обычного SAS. Он его обгоняет на чтении.
И поэтому рекомендуется в системах MS SQL сделать массив SSD для данных, чтобы их было возможным быстро читать, и лог на массив SAS, чтобы быстро и надежно (!) писать, так как лог важнее данных
5 мар 15, 02:19    [17344750]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Любитель MSSQL
Guest
hvlad
Любитель MSSQL
Я думаю, если в дискуссии узнаешь, что-то новое, это всегда полезно.
Именно. Поэтому - см. выше


Прости, ради Бога, я не хотел Вас никак задеть. Я, наверное, действительно неправильно понял Ваш пост.
5 мар 15, 02:23    [17344754]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Зимаргл
Guest
Добавлю еще один аргумент со стороны.
Меня на форуме не было года 3. Вот сейчас смотрю и вижу - те же люди обсуждают те же вопросы, что и 3 года назад.

А по теме вот
-Fb имеет все ту же рабочую версию 2.5.х
-MS SQL уже поменял 2 поколения с новой функциональностью

Прогресс конечно вреден, но не развиваясь, все теряет свою ценность, особенно специалисты и технологии
5 мар 15, 02:30    [17344762]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Таблоид
Member

Откуда:
Сообщений: 9456
Блог
wiki
Среди недостатков: отсутствие кэша результатов запросов
Кеш результатов запросов - да, отсутствует, ибо нужен в oltp также, как неуловимый Джо. В вашей oltp-системе часто юзера отсылают в точности одни и те же запросы, с одними и теми же параметрами ?
А собственный страничный кеш данных - есть. И проверить его воздействие очень легко - достаточно поставить FileSystemCacheThreshold < DefaultDBCacheBuffers и тихо впасть в ступор вместе с ФБ :-)

wiki
Среди недостатков: отсутствие ... полнотекстовых индексов
Насколько помню, некий FTI-продукт ("Sphinx", вроде) можно было прикрутить еще к ФБ 2.0. Реально ли это сделать к нынешним версиям - не знаю. Судя по отсутствию стенаний в bid=2 и fb-devel на эту тему - либо не сильно нужно, либо у многих работают велосипеды соб. пр-ва.

wiki
Среди недостатков: ... значительное падение производительности при росте внутренней фрагментации базы
Что бы там ни понималось под "внутренней фрагментацией" (пустоты внутри страницы ?), это не соответствует действительности.
Падение есть, но!
1) небольшое, и далеко не сразу;
2) от "роботизированной" нагрузки, которую никогда не создадут обычные юзера.

В подтверждение своих слов приведу фрагмент заголовка нашего продакшена на сейчас:
Database header page information:
Flags 0
Checksum 12345
Generation 839376376
Page size 16384
ODS version 11.2
Oldest transaction 802318392
Oldest active 802318393
Oldest snapshot 802318393
Next transaction 802318398
. . .
Creation date Oct 2, 2012 21:45:05 -- <<<< это когда последний раз делался рестор базы :-)

Variable header data:
Sweep interval: 0
*END*

Сами понимаете, за 2.5 года какая там сейчас "нутряная фрагментация". Число юзеров - около 150 (раньше было около 200). За день оформляется примерно 1000-1200 док-тов (раньше было ~2000), очень много апдейтов и достаточно много удалений.
Жалоб на скорость, однако ж, нет примерно с того времени, когда был последний рестор :-)

Кроме того, для ФБ 2.5 & 3.0 есть тест, достаточно детально имитирующий бизнес-процессы одной торговой компании и допускающий замеры производительности на нагрузочных режимах от самого малого до супер-звериного. Для нагрузки в течение 180 минут от 100, 125, ..., 300 аттачей результаты (.ppt) можно глянуть тут: https://yadi.sk/d/u2Eb_Gzdf3b72
Причём, это результаты молотьбы в режиме без пауз - по сути, как если бы было получение в реальном времени команд от датчиков, а не от "пиплов с перекурами".
Если там будет что непонятно, спрашивайте. Если что-то подробно надо по тесту объяснить - пишите в личку: p519446 acii_char(64) яндекс.ру
5 мар 15, 03:04    [17344769]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
хыхыхы
Guest
Зимаргл
-Fb имеет все ту же рабочую версию 2.5.х
-MS SQL уже поменял 2 поколения с новой функциональностью

Прогресс конечно вреден, но не развиваясь, все теряет свою ценность, особенно специалисты и технологии


От html4 до html5 прошло более 10 лет. php4 вышел в 2000 году. Какая там у нас щас последняя версия php? 5.6? Технология в упадке, специалисты в опе.
5 мар 15, 07:27    [17344876]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 11092
Зимаргл,

ну так ты ресурсы сравни. В FB ядром занимаются всего 4 человека. А сколько в MS SQL?

Ну так к слову, изменения при переходе 2.5 -> 3.0 очень существенные. Столько изменений ещё никогда не делалось. Это приблизительно тоже самое как переход MS SQL 2000 -> MS SQL 2005. Им тоже 5 лет потребовалось, чтобы перелапатить архитектуру.
5 мар 15, 09:57    [17345218]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3787
Любитель MSSQL
У многих адептов IB/FB здесь есть не совсем верное понимание об архитектуре MS SQL:

1. Все изменения страниц происходят в ОЗУ. Если данной страницы в ОЗУ нет, ее подгружает сервер из файла данных.
2. Измененная страница не попадает сразу в файл данных, а хранится в ОЗУ и все новые запросы к ней обращаются именно к измененному состоянию страницы, которое хранится в ОЗУ
3. Все запросы читают данные из ОЗУ, если их там нет, то они подгружаются
4. Если "грязная" страница не сброшена на диск и опять подвергается изменению, она просто становится более "грязнее" (это к вопросу hvlad) и когда-нибудь она будет сброшена на диск в последнем состоянии.
5. Сброс на диск (он же чекпойнт) процедура вовсе некритически важная для целостности базы. Вся информация о странице есть в журнале транзакций.
6. Каждая страница в файле данных имеет номер транзакции после последнего сброса, и в случае сбоя, при восстановлении базы сервер сравнивает последний номер транзакции базы с последним номером данной страницы, и принимается решение о накате или откате.
7. То есть SQL Server проводит "красной нитью" концепцию "меньше работаем с файлами данных на запись", "все делаем в ОЗУ", "последовательно пишем в журнал".

Хотя я могу ошибаться, но многоуважаемый мною pkarklin меня думаю поправит.

чето я одного не понимаю?? Есть субд где это не так (мускл оставим). Асинхронный сброс на диск чекпоинтами - это стандарт давно же, не??
5 мар 15, 11:19    [17345618]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 11092
Ivan Durak,

нет такого стандарта. Есть стандарт на язык SQL, на то какими свойствами должны обладать транзакции и т.д. А вот на реализацию нет стандарта, даже если оно сделано так в большинстве других СУБД.
5 мар 15, 11:39    [17345747]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 .. 14   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить