ReSQL.ru
     
powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Firebird, PostgreSQL, MsSql, Oracle
25 сообщений из 343, страница 4 из 14
  4  все
Firebird, PostgreSQL, MsSql, Oracle
    #38895206
Фотография Любитель MSSQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Любитель MSSQL
Участник
Dimitry Sibiryakovirbis_alпочему-то в таблице про db2 незаслуженно забыли.
Потому что тогда MS SQL выглядел бы ещё более жалко.


Неверно, так как MS SQL имеет уровень изоляции транзакций Snapshot, чего нет у db2. При большем количестве читателей и писателей это очень актуально
...
Рейтинг: 0 / 0
04.03.2015, 22:27
| Ответить | Цитировать | Написать  
Firebird, PostgreSQL, MsSql, Oracle
    #38895213
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Любитель MSSQLMS SQL имеет уровень изоляции транзакций Snapsho
Ну наконец-то MS SQL достиг уровня изоляции, с которого Interbase начинал 30 лет назад.
Поздравляю.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
04.03.2015, 22:38
| Ответить | Цитировать | Написать  
Firebird, PostgreSQL, MsSql, Oracle
    #38895217
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
kdv,

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

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

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

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

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

Я, право, тоже не совсем точно понял, о чем идет речь, поэтому пока не буду комментировать.
...
Рейтинг: 0 / 0
04.03.2015, 22:40
| Ответить | Цитировать | Написать  
Firebird, PostgreSQL, MsSql, Oracle
    #38895219
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
Dimitry SibiryakovТо есть, вместо того, чтобы просто записать новую версию записи на одну страницу данных,
как это делает Firebird, MS SQL запишет новую версию в лог, потом её же в отдельную
структуру данных и, наконец, запишет старую версию в tempdb. Три операции записи вместо
одной. Прэлееестно...


При этом физическая из них только одна - последовательная запись в лог.
...
Рейтинг: 0 / 0
04.03.2015, 22:41
| Ответить | Цитировать | Написать  
Firebird, PostgreSQL, MsSql, Oracle
    #38895222
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
Dimitry SibiryakovАга, так вот почему у него лог так пухнет: он пишет только в него, а в саму базу данные
никогда не попадают.


Отчего же?! Попадают, но совершенно ассинхронно с "основным процессом".
...
Рейтинг: 0 / 0
04.03.2015, 22:45
| Ответить | Цитировать | Написать  
Firebird, PostgreSQL, MsSql, Oracle
    #38895228
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
S.G.У нас на предприятии...

Сделать правильный выбор - всегда трудная задача. Выбирал систему, на мой взгляд, не специалист.
...
Рейтинг: 0 / 0
04.03.2015, 22:51
| Ответить | Цитировать | Написать  
Firebird, PostgreSQL, MsSql, Oracle
    #38895236
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
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 так неоптимально хранит данные и обрабатывает транзакции".
...
Рейтинг: 0 / 0
04.03.2015, 23:01
| Ответить | Цитировать | Написать  
Firebird, PostgreSQL, MsSql, Oracle
    #38895240
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
pkarklinПопадают, но совершенно ассинхронно с "основным процессом".
почему-то под "асинхронно" зачастую понимают "когда-нибудь потом, когда оно никому не мешает". А теперь запускаем oltp-тест и видим, как чекпойнты начинают очень быстро накладываться на запись в лог и тормозить циферки tpmC, пусть даже лог с базой на разных шпинделях. Понятно, что торможение не двухкратное, но "совершенно асинхронно" это скорее про 50 ленивых операторов с перекурами, а не про большую нагрузку. Где я ошибаюсь?
...
Рейтинг: 0 / 0
04.03.2015, 23:07
| Ответить | Цитировать | Написать  
Firebird, PostgreSQL, MsSql, Oracle
    #38895241
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
Dimitry SibiryakovНачните, например, с доказательства того, что у SSD при записи seek time отличен от нуля.


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

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

Я не буду вдаваться в возможности СУБД иметь бд, состояющую из большого кол-ва файлов данных, ибо это за рамками размера бд в Профитмед.
...
Рейтинг: 0 / 0
04.03.2015, 23:09
| Ответить | Цитировать | Написать  
Firebird, PostgreSQL, MsSql, Oracle
    #38895242
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
pkarklinПопадают, но совершенно ассинхронно с "основным процессом".
То есть MS SQL не способен работать под постоянной нагрузкой, ему нужны окна простоя чтобы
раскидать данные из лога в БД.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
04.03.2015, 23:10
| Ответить | Цитировать | Написать  
Firebird, PostgreSQL, MsSql, Oracle
    #38895245
Вася Уткин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вася Уткин
Гость
kdvкажется, где-то тут этот вопрос уже разбирали. Допустим, существует запись в БД. Потом ее изменили. Т.е. старая запись в БД, новая - в логе. В разных местах. Делаем коммит. Запись из лога попадает в БД? А если до сих пор существует транзакция snapshot, которой надо видеть старый вариант записи?
у MS SQL все версии в памяти, а те что не влезли - всё в tempBD.
Уж и тут по моему миллион раз перетиралось :)

Осталось только сравнить Firebird с Oracle и Deadlock-и с Update Conflict-ами, ну и про двух-версионность оракла :)
...
Рейтинг: 0 / 0
04.03.2015, 23:13
| Ответить | Цитировать | Написать  
Firebird, PostgreSQL, MsSql, Oracle
    #38895247
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
kdv,

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

Ну, уж, если, хотим конкурировать с "кем-то", то "как оно работает" у конкурента, всё-таки следовало бы знать. Будет ли достаточно ссылки на документацию MS SQL или надо здесь расжевать?
...
Рейтинг: 0 / 0
04.03.2015, 23:15
| Ответить | Цитировать | Написать  
Firebird, PostgreSQL, MsSql, Oracle
    #38895251
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
Dimitry SibiryakovpkarklinПопадают, но совершенно ассинхронно с "основным процессом".
То есть MS SQL не способен работать под постоянной нагрузкой, ему нужны окна простоя чтобы
раскидать данные из лога в БД.


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

Надеюсь, Вас не удивит, что на Вашем компьютере более чем одна программа использует ресурсы жесткого диска?
...
Рейтинг: 0 / 0
04.03.2015, 23:20
| Ответить | Цитировать | Написать  
Firebird, PostgreSQL, MsSql, Oracle
    #38895254
Вася Уткин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вася Уткин
Гость
dimitrpkarklinПопадают, но совершенно ассинхронно с "основным процессом".
почему-то под "асинхронно" зачастую понимают "когда-нибудь потом, когда оно никому не мешает". А теперь запускаем oltp-тест и видим, как чекпойнты начинают очень быстро накладываться на запись в лог и тормозить циферки tpmC , пусть даже лог с базой на разных шпинделях.
OLTP генерит мало данных за день, ну гигабайт 50, и СУБД может хоть весь день не скидывать данные в БД, все в лог, а актуальные измененные строки в ОЗУ (64 - 128 ГБ), ночью скинет. Коммит или чекпоинт не ждут пока данные упадут в БД, достаточно в журнал плюс в ОЗУ.
...
Рейтинг: 0 / 0
04.03.2015, 23:23
| Ответить | Цитировать | Написать  
Firebird, PostgreSQL, MsSql, Oracle
    #38895259
Фотография S.G.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
S.G.
Участник
pkarklinS.G.У нас на предприятии...
Сделать правильный выбор - всегда трудная задача. Это да.
pkarklinВыбирал систему, на мой взгляд, не специалист.Да, выбрал директор, слушая.. так сказать, любителя mssql, который расписал ему, как здорово иметь возможность откатывать далеко назад транзакции... чего не понадобилось делать ни разу.


Любитель MSSQL Это мое субъективное мнение и мой личный домысел Очень трудно оценить "на пальцах" как влияет та или иная характеристика на скорось или на надежность конечной системы. Поэтому люди делают тесты, и говорят "вот на таком железе при таких запросах, мы получили то-то и то-то". И все.
А позиция "это круто/а это не годится", для сравнения любой пары из первой пятерки СУБД - несколько неправильна. Поскольку для каждого сервера есть немало примеров высоконагруженых систем.
...
Рейтинг: 0 / 0
04.03.2015, 23:30
| Ответить | Цитировать | Написать  
Firebird, PostgreSQL, MsSql, Oracle
    #38895260
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Вася УткинOLTP генерит мало данных за день, ну гигабайт 50, и СУБД может хоть весь день не скидывать данные в БД, все в логА читать их она потом тоже будет из лога ? Или кеш резиновый ?
...
Рейтинг: 0 / 0
04.03.2015, 23:30
| Ответить | Цитировать | Написать  
Firebird, PostgreSQL, MsSql, Oracle
    #38895264
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
pkarklinПроцесс сброса "грязных" страниц данных на диск - это совершенно отдельный ассинхронный процесс, никак не связанный с остальными.Не бывает "совершенно отдельных процессов, никак не связанных с остальными" - всё связано, даже если вам об этом не сказали.
...
Рейтинг: 0 / 0
04.03.2015, 23:32
| Ответить | Цитировать | Написать  
Firebird, PostgreSQL, MsSql, Oracle
    #38895265
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
pkarklinMS SQL Server не "расскидывает данные из лога". Процесс сброса "грязных"
страниц данных на диск - это совершенно отдельный ассинхронный процесс, никак не связанный
с остальными.
И тут-то сразу вспоминается старая байка, которую рассказывал
Любитель MSSQLбудет как сумасшедший раскладывать по полочкам данные и версии,
которые находятся в разных местах диска
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
04.03.2015, 23:34
| Ответить | Цитировать | Написать  
Firebird, PostgreSQL, MsSql, Oracle
    #38895266
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
dimitrпочему-то под "асинхронно" зачастую понимают "когда-нибудь потом, когда оно никому не мешает".

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

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

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

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

Наверное, в том, что Вы не привели какие-либо количественные характеристики "большой нагрузки"?
...
Рейтинг: 0 / 0
04.03.2015, 23:34
| Ответить | Цитировать | Написать  
Firebird, PostgreSQL, MsSql, Oracle
    #38895270
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
hvladНе бывает "совершенно отдельных процессов, никак не связанных с остальными" - всё связано, даже если вам об этом не сказали.
Безусловно, но не так, как видится Диме:
Dimitry Sibiryakovему нужны окна простоя чтобы раскидать данные из лога в БД.
У Вас, полагаю, есть данные влияния процесса Lazy Writer на все остальные?
...
Рейтинг: 0 / 0
04.03.2015, 23:40
| Ответить | Цитировать | Написать  
Firebird, PostgreSQL, MsSql, Oracle
    #38895271
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
Dimitry SibiryakovИ тут-то сразу вспоминается старая байка

Было бы здОрово, если бы вместо баек, приводились бы выкладки.
...
Рейтинг: 0 / 0
04.03.2015, 23:42
| Ответить | Цитировать | Написать  
Firebird, PostgreSQL, MsSql, Oracle
    #38895272
Вася Уткин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вася Уткин
Гость
hvladВася УткинOLTP генерит мало данных за день, ну гигабайт 50, и СУБД может хоть весь день не скидывать данные в БД, все в логА читать их она потом тоже будет из лога ? Или кеш резиновый ?
Ответ на свой вопрос вы вырезали из цитаты, прям супер-полемический прием, детский сад
автор OLTP генерит мало данных за день, ну гигабайт 50 , и СУБД может хоть весь день не скидывать данные в БД, все в лог, а актуальные измененные строки в ОЗУ (64 - 128 ГБ), ночью скинет.
В течении дня не спеша скинет в БД сколько сможет, никак не влияя на производительность системы в целом, а ночью всё что осталось докинет.
...
Рейтинг: 0 / 0
04.03.2015, 23:43
| Ответить | Цитировать | Написать  
Firebird, PostgreSQL, MsSql, Oracle
    #38895275
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Вася Уткина ночью всё что осталось докинет.
А до ночи эти данные будут пребывать в мировом эфире или тесниться в том гигабайте ОЗУ,
которым Экспресс жёстко ограничен?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
04.03.2015, 23:49
| Ответить | Цитировать | Написать  
Firebird, PostgreSQL, MsSql, Oracle
    #38895276
Вася Уткин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вася Уткин
Гость
Dimitry SibiryakovВася Уткина ночью всё что осталось докинет.
А до ночи эти данные будут пребывать в мировом эфире или тесниться в том гигабайте ОЗУ,
которым Экспресс жёстко ограничен?

Причем здесь экспресс, экспресс вообще в продуктиве не используется - особенно где OLTP генерят 50 ГБ данных за день
...
Рейтинг: 0 / 0
04.03.2015, 23:52
| Ответить | Цитировать | Написать  
Firebird, PostgreSQL, MsSql, Oracle
    #38895279
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
pkarklinФайл один. В него происходит и запись, и чтение. И нет возможности развести эти потоки.
гм, в каком смысле? Невозможно из разных потоков-процессов писать в один random-access файл? Это как это?
Или вы про лог MS SQL?

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

Тем не менее, в любой СУБД есть пересекающиеся дисковые (и не-дисковые) ресурсы. Без этого, увы, никак, что в ФБ, что в MS SQL. Однако, отличие этих "пересекающихся ресурсов" не позволяет сделать вывод, что ФБ не способен обслуживать более 50 пользователей, с чего тут и началась дискуссия.
...
Рейтинг: 0 / 0
04.03.2015, 23:59
| Ответить | Цитировать | Написать  
25 сообщений из 343, страница 4 из 14
  4  все
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Firebird, PostgreSQL, MsSql, Oracle
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=35&msg=38895279&tid=1552266]:
 0ms
get settings:
 10ms
get forum list:
 14ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 145ms
get topic data:
 8ms
get forum data:
 2ms
get page messages:
 62ms
get tp. blocked users:
 1ms
others: 13ms
total:  263ms
созд. / загр.: 263ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]