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

Потому что тогда MS SQL выглядел бы ещё более жалко.


Неверно, так как MS SQL имеет уровень изоляции транзакций Snapshot, чего нет у db2. При большем количестве читателей и писателей это очень актуально
4 мар 15, 22:27    [17344312]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54751

Любитель MSSQL
MS SQL имеет уровень изоляции транзакций Snapsho

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

Posted via ActualForum NNTP Server 1.5

4 мар 15, 22:38    [17344334]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
pkarklin
Member

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

автор
В Профитмеде около 400 одновременных пользователей, примерно 2 млн транзакций в сутки,


Одновременно подключенных или одновременно что-то делающих? Ибо "примерно 2 млн транзакций в сутки" это чуть больше 20 транзакций в секунду.

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


Как же здОрово, когда не надо ничего пристраивать, а взять редакцию экспресс, положить файлы (Excel, Word и т.п.) в FILESTREAM и FTS поверх всего этого.

автор
Какой, нахрен, кэш результатов запросов???, "внутренняя фрагментация" - вообще непонятно о чем.


Я, право, тоже не совсем точно понял, о чем идет речь, поэтому пока не буду комментировать.
4 мар 15, 22:40    [17344341]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Dimitry Sibiryakov
То есть, вместо того, чтобы просто записать новую версию записи на одну страницу данных,
как это делает Firebird, MS SQL запишет новую версию в лог, потом её же в отдельную
структуру данных и, наконец, запишет старую версию в tempdb. Три операции записи вместо
одной. Прэлееестно...


При этом физическая из них только одна - последовательная запись в лог.
4 мар 15, 22:41    [17344345]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Dimitry Sibiryakov
Ага, так вот почему у него лог так пухнет: он пишет только в него, а в саму базу данные
никогда не попадают.


Отчего же?! Попадают, но совершенно ассинхронно с "основным процессом".
4 мар 15, 22:45    [17344355]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
S.G.
У нас на предприятии...


Сделать правильный выбор - всегда трудная задача. Выбирал систему, на мой взгляд, не специалист.
4 мар 15, 22:51    [17344364]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30232
pkarklin
Одновременно подключенных или одновременно что-то делающих?

одновременно что-то делающих.

pkarklin
Ибо "примерно 2 млн транзакций в сутки" это чуть больше 20 транзакций в секунду.

было бы весьма опрометчиво оценивать взаимосвязь кол-ва транзакций в сутки и кол-ва активных пользователей.
2млн транзакций в сутки я привел как оценочный параметр нагрузки, и тут, согласен, у других СУБД могут быть совершенно другие критерии. Как и у других систем на ФБ - есть 3.6млн транзакций в сутки на 200 пользователей, и наоборот.

2млн транзакций в сутки на 400 пользователей и 10 рабочих часов означает 55 транзакций в секунду, или 0.14 транзакций в секунду на 1 пользователя. То есть, 1 транзакция от пользователя каждые 10 секунд, что выглядит вполне нормально. Даже 1 транзакция в 20 секунд, непрерывно, круглые сутки, тоже дает определенное представление о нагрузке системы.
Тут надо учитывать, что 1 транзакция на 1 запрос в InterBase и Firebird - это совсем крайний случай. А транзакции определенного уровня изолированности вообще могут быть активными хоть месяц, не оказывая влияния на производительность.

pkarklin
При этом физическая из них только одна - последовательная запись в лог.

кажется, где-то тут этот вопрос уже разбирали. Допустим, существует запись в БД. Потом ее изменили. Т.е. старая запись в БД, новая - в логе. В разных местах. Делаем коммит. Запись из лога попадает в БД? А если до сих пор существует транзакция snapshot, которой надо видеть старый вариант записи?
Дисковая структура IB и FB оптимизирована под хранение версий, под множество длительных конкурентных snapshot, и т.д. Более того, у InterBase с версии 2007 есть журнал, только все это никак не влияет на вопрос, поднятый "Любитель MSSQL".
Если хотите, его придумки это почти то же самое, если я сейчас начну фантазировать на тему "почему MS SQL так неоптимально хранит данные и обрабатывает транзакции".
4 мар 15, 23:01    [17344386]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
pkarklin
Попадают, но совершенно ассинхронно с "основным процессом".

почему-то под "асинхронно" зачастую понимают "когда-нибудь потом, когда оно никому не мешает". А теперь запускаем oltp-тест и видим, как чекпойнты начинают очень быстро накладываться на запись в лог и тормозить циферки tpmC, пусть даже лог с базой на разных шпинделях. Понятно, что торможение не двухкратное, но "совершенно асинхронно" это скорее про 50 ленивых операторов с перекурами, а не про большую нагрузку. Где я ошибаюсь?
4 мар 15, 23:07    [17344400]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Dimitry Sibiryakov
Начните, например, с доказательства того, что у SSD при записи seek time отличен от нуля.


Тем не менее, у озвученного здесь Профитмед не SSD. Файл один. В него происходит и запись, и чтение. И нет возможности развести эти потоки.

По большому счету с последовательной записью успешно справлются и массивы обычных дисков. Поэтому для СУБД, имеющих отдельный Write-ahead log, размещение его на SSD массиве слишком затратно. А вот расположить файл данных на SSD массиве (высокая скорость чтения), а файл лога на SAS массиве (достаточная скорость записи) - профит.

Я не буду вдаваться в возможности СУБД иметь бд, состояющую из большого кол-ва файлов данных, ибо это за рамками размера бд в Профитмед.
4 мар 15, 23:09    [17344402]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54751

pkarklin
Попадают, но совершенно ассинхронно с "основным процессом".

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

Posted via ActualForum NNTP Server 1.5

4 мар 15, 23:10    [17344405]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Вася Уткин
Guest
kdv
кажется, где-то тут этот вопрос уже разбирали. Допустим, существует запись в БД. Потом ее изменили. Т.е. старая запись в БД, новая - в логе. В разных местах. Делаем коммит. Запись из лога попадает в БД? А если до сих пор существует транзакция snapshot, которой надо видеть старый вариант записи?

у MS SQL все версии в памяти, а те что не влезли - всё в tempBD.
Уж и тут по моему миллион раз перетиралось :)

Осталось только сравнить Firebird с Oracle и Deadlock-и с Update Conflict-ами, ну и про двух-версионность оракла :)
4 мар 15, 23:13    [17344410]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
pkarklin
Member

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

автор
Допустим, существует запись в БД. Потом ее изменили. Т.е. старая запись в БД, новая - в логе. В разных местах. Делаем коммит. Запись из лога попадает в БД? А если до сих пор существует транзакция snapshot, которой надо видеть старый вариант записи?


Ну, уж, если, хотим конкурировать с "кем-то", то "как оно работает" у конкурента, всё-таки следовало бы знать. Будет ли достаточно ссылки на документацию MS SQL или надо здесь расжевать?
4 мар 15, 23:15    [17344413]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Dimitry Sibiryakov
pkarklin
Попадают, но совершенно ассинхронно с "основным процессом".

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


Дима, меня всегда поражала Ваша способность делать совершенно противоположные выводы при прочих равных исходных данных. MS SQL Server не "расскидывает данные из лога". Процесс сброса "грязных" страниц данных на диск - это совершенно отдельный ассинхронный процесс, никак не связанный с остальными.

Надеюсь, Вас не удивит, что на Вашем компьютере более чем одна программа использует ресурсы жесткого диска?
4 мар 15, 23:20    [17344425]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Вася Уткин
Guest
dimitr
pkarklin
Попадают, но совершенно ассинхронно с "основным процессом".

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

OLTP генерит мало данных за день, ну гигабайт 50, и СУБД может хоть весь день не скидывать данные в БД, все в лог, а актуальные измененные строки в ОЗУ (64 - 128 ГБ), ночью скинет. Коммит или чекпоинт не ждут пока данные упадут в БД, достаточно в журнал плюс в ОЗУ.
4 мар 15, 23:23    [17344430]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
S.G.
Member

Откуда: cartoon network
Сообщений: 30611
pkarklin
S.G.
У нас на предприятии...

Сделать правильный выбор - всегда трудная задача.
Это да.
pkarklin
Выбирал систему, на мой взгляд, не специалист.
Да, выбрал директор, слушая.. так сказать, любителя mssql, который расписал ему, как здорово иметь возможность откатывать далеко назад транзакции... чего не понадобилось делать ни разу.


Любитель MSSQL
Это мое субъективное мнение и мой личный домысел
Очень трудно оценить "на пальцах" как влияет та или иная характеристика на скорось или на надежность конечной системы. Поэтому люди делают тесты, и говорят "вот на таком железе при таких запросах, мы получили то-то и то-то". И все.
А позиция "это круто/а это не годится", для сравнения любой пары из первой пятерки СУБД - несколько неправильна. Поскольку для каждого сервера есть немало примеров высоконагруженых систем.
4 мар 15, 23:30    [17344444]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
hvlad
Member

Откуда:
Сообщений: 11551
Вася Уткин
OLTP генерит мало данных за день, ну гигабайт 50, и СУБД может хоть весь день не скидывать данные в БД, все в лог
А читать их она потом тоже будет из лога ? Или кеш резиновый ?
4 мар 15, 23:30    [17344445]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
hvlad
Member

Откуда:
Сообщений: 11551
pkarklin
Процесс сброса "грязных" страниц данных на диск - это совершенно отдельный ассинхронный процесс, никак не связанный с остальными.
Не бывает "совершенно отдельных процессов, никак не связанных с остальными" - всё связано, даже если вам об этом не сказали.
4 мар 15, 23:32    [17344450]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54751

pkarklin
MS SQL Server не "расскидывает данные из лога". Процесс сброса "грязных"
страниц данных на диск - это совершенно отдельный ассинхронный процесс, никак не связанный
с остальными.

И тут-то сразу вспоминается старая байка, которую рассказывал
Любитель MSSQL
будет как сумасшедший раскладывать по полочкам данные и версии,
которые находятся в разных местах диска

Posted via ActualForum NNTP Server 1.5

4 мар 15, 23:34    [17344456]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
dimitr
почему-то под "асинхронно" зачастую понимают "когда-нибудь потом, когда оно никому не мешает".


Не совсем так. Интервал чекпоинтов не завязан на "когда оно никому не мешает" и может быть настроен.

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


Я правильно понимаю, что конфигурация Вашей дисковой системы не справляется с нагрузкой?

dimitr
Понятно, что торможение не двухкратное, но "совершенно асинхронно" это скорее про 50 ленивых операторов с перекурами, а не про большую нагрузку. Где я ошибаюсь?


Наверное, в том, что Вы не привели какие-либо количественные характеристики "большой нагрузки"?
4 мар 15, 23:34    [17344458]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
hvlad
Не бывает "совершенно отдельных процессов, никак не связанных с остальными" - всё связано, даже если вам об этом не сказали.

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

У Вас, полагаю, есть данные влияния процесса Lazy Writer на все остальные?
4 мар 15, 23:40    [17344474]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Dimitry Sibiryakov
И тут-то сразу вспоминается старая байка


Было бы здОрово, если бы вместо баек, приводились бы выкладки.
4 мар 15, 23:42    [17344478]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Вася Уткин
Guest
hvlad
Вася Уткин
OLTP генерит мало данных за день, ну гигабайт 50, и СУБД может хоть весь день не скидывать данные в БД, все в лог
А читать их она потом тоже будет из лога ? Или кеш резиновый ?

Ответ на свой вопрос вы вырезали из цитаты, прям супер-полемический прием, детский сад
автор
OLTP генерит мало данных за день, ну гигабайт 50, и СУБД может хоть весь день не скидывать данные в БД, все в лог, а актуальные измененные строки в ОЗУ (64 - 128 ГБ), ночью скинет.

В течении дня не спеша скинет в БД сколько сможет, никак не влияя на производительность системы в целом, а ночью всё что осталось докинет.
4 мар 15, 23:43    [17344483]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54751

Вася Уткин
а ночью всё что осталось докинет.

А до ночи эти данные будут пребывать в мировом эфире или тесниться в том гигабайте ОЗУ,
которым Экспресс жёстко ограничен?

Posted via ActualForum NNTP Server 1.5

4 мар 15, 23:49    [17344497]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
Вася Уткин
Guest
Dimitry Sibiryakov
Вася Уткин
а ночью всё что осталось докинет.

А до ночи эти данные будут пребывать в мировом эфире или тесниться в том гигабайте ОЗУ,
которым Экспресс жёстко ограничен?

Причем здесь экспресс, экспресс вообще в продуктиве не используется - особенно где OLTP генерят 50 ГБ данных за день
4 мар 15, 23:52    [17344505]     Ответить | Цитировать Сообщить модератору
 Re: Firebird, PostgreSQL, MsSql, Oracle  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30232
pkarklin
Файл один. В него происходит и запись, и чтение. И нет возможности развести эти потоки.

гм, в каком смысле? Невозможно из разных потоков-процессов писать в один random-access файл? Это как это?
Или вы про лог MS SQL?

pkarklin
иметь бд, состояющую из большого кол-ва файлов данных, ибо это за рамками размера бд в Профитмед.

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

Тем не менее, в любой СУБД есть пересекающиеся дисковые (и не-дисковые) ресурсы. Без этого, увы, никак, что в ФБ, что в MS SQL. Однако, отличие этих "пересекающихся ресурсов" не позволяет сделать вывод, что ФБ не способен обслуживать более 50 пользователей, с чего тут и началась дискуссия.
4 мар 15, 23:59    [17344523]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7 8 9 10 .. 14   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить