Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 11 12 13 14 15 [16] 17 18 19 20 .. 54   вперед  Ctrl
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
Dimitry Sibiryakov
Member

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

Гость333
Продолжайте вашу мысль, очень интересно.

Да нет, это Вы развивайте свою: "страница DCM не пишутся на диск, а пишутся только в
журнал, который находится на диске". Возьмём тривиальный insert into t values (1). Он
изменяет (в простейшем случае) одну страницу данных. Без DCM на диск записалась бы одна
страница данных. С DCM пишется та же страница данных + страница DCM. Тут точно нет
удвоения ввода/вывода?..

Posted via ActualForum NNTP Server 1.5

14 окт 13, 14:12    [14966968]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
Гость333
Alexander Ryndin
пропущено...
Разве это повзоляет сжать существующую таблицу в 7-10 раз?

Ок, Clustered columnstore index, coming soon (появится в MSSQL 2014) :^)
эм. Какая разница? Он все равно не сжимает существующую таблицу. Разве не так?
14 окт 13, 14:27    [14967092]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
Гость333
Member

Откуда:
Сообщений: 3683
Dimitry Sibiryakov
Да нет, это Вы развивайте свою: "страница DCM не пишутся на диск, а пишутся только в
журнал, который находится на диске".

Страницы DCM никогда не пишутся в журнал транзакций.

Расшифрую свою мысль: "При коммите страницы данных, также как и страницы DCM, не пишутся на диск. Пишутся только записи в журнал транзакций."
Записи в журнале транзакций — это не страницы данных и не страницы DCM. Это отдельные сущности. Именно эти сущности пишутся на диск при коммите.

Запись страниц данных и страниц DCM на диск — асинхронна. Срабатывает, например, раз в минуту при чекпойнте. При этом все страницы, изменённые в RAM ("грязные" страницы), записываются на диск. Все грязные страницы, участвовавшие за эту минуту во всех коннектах и транзакциях.

Dimitry Sibiryakov
Возьмём тривиальный insert into t values (1). Он
изменяет (в простейшем случае) одну страницу данных. Без DCM на диск записалась бы одна
страница данных. С DCM пишется та же страница данных + страница DCM. Тут точно нет
удвоения ввода/вывода?..

Если за минуту сервер совершил одну эту операцию, то удвоение будет. Я это уже признал, уточнив, что это вырожденный случай.
14 окт 13, 14:33    [14967146]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
hvlad
Member

Откуда:
Сообщений: 11577
softwarer
В принципе, если браться решать именно такую задачу, не думая о прочем.. я, наверное, двигался бы в сторону версионности метаинформации. То есть alter table modify хранит колонки в виде двунаправленного списка версий. При хранении и передаче поле сопровождается маркером поля/версии, соответственно, в подходящем месте данные кастятся к актуальной версии / выкидывается исключение при невозможности конвертации.
Это на 80% описание механизма работы IB\FB :)
14 окт 13, 14:37    [14967184]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
softwarer
В принципе, если браться решать именно такую задачу, не думая о прочем.. я, наверное, двигался бы в сторону версионности метаинформации. То есть alter table modify хранит колонки в виде двунаправленного списка версий. При хранении и передаче поле сопровождается маркером поля/версии, соответственно, в подходящем месте данные кастятся к актуальной версии / выкидывается исключение при невозможности конвертации.


У SQL Serverа как раз нет версионности метаинформации:

SQL Server does not keep multiple versions of system metadata. Data definition language (DDL) statements on tables and other database objects (indexes, views, data types, stored procedures, and common language runtime functions) change metadata.
14 окт 13, 14:41    [14967215]     Ответить | Цитировать Сообщить модератору
 Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
pkarklin
Member

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

автор
Разве это позволяет сжать существующую таблицу в 7-10 раз


Если речь о сжатии, то:

SQL Server supports both row and page compression for both tables and indexes. Data compression can be configured for the following database objects:

  • A whole table that is stored as a heap.
  • A whole table that is stored as a clustered index.
  • A whole nonclustered index.
  • A whole indexed view.


    For partitioned tables and indexes, the compression option can be configured for each partition, and the various partitions of an object do not have to have the same compression setting.

    Оно?
  • 14 окт 13, 14:44    [14967236]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    pkarklin
    Member

    Откуда: Москва (Муром)
    Сообщений: 74930
    Alexander Ryndin
    Гость333
    пропущено...

    CREATE CLUSTERED INDEX I_ORDERS ON ORDERS(ORDER_DATE) WITH(DROP_EXISTING=ON, ONLINE=ON) ON My_Partition_Scheme(ORDER_DATE)
    
    Принято. Слегка негранулированный подход (все делает одним махом и не позволяет сделать шаг влево, шаг вправо), но задачу, на первый взгяд, решает.


    А какой подход был бы необходим?
    14 окт 13, 14:48    [14967267]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    Гость333
    Member

    Откуда:
    Сообщений: 3683
    Alexander Ryndin
    Гость333
    пропущено...

    Ок, Clustered columnstore index, coming soon (появится в MSSQL 2014) :^)
    эм. Какая разница? Он все равно не сжимает существующую таблицу. Разве не так?

    Вот здесь http://blog.dbandbi.com/sql-server-2014-columnstore-index/ автор создал на таблице clustered columnstore index и сжал таблицу с 409 Мб до 74 Мб — компрессия 18%. Весьма близко к искомым 7-10 раз. У меня MSSQL 2014 нет, проверить не могу. (И ставить пре-релиз 2014 совсем не хочу — т.к. потом возможны проблемы с установкой релизной версии ).
    14 окт 13, 14:52    [14967307]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    Dimitry Sibiryakov
    Member

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

    Гость333
    Запись страниц данных и страниц DCM на диск — асинхронна. Срабатывает,
    например, раз в минуту при чекпойнте. При этом все страницы, изменённые в RAM ("грязные"
    страницы), записываются на диск. Все грязные страницы, участвовавшие за эту минуту во всех
    коннектах и транзакциях.

    И вот тут возможны два сценария: страница DCM пишется после всех остальных грязных страниц
    или перед ними. При приходе "времени Пи" между этими событиями получаем два возможных
    результата: в следующий диф.бэкап некоторые изменённые страницы не попадут или в него
    попадут неизменённые страницы. Какой сценарий реализован в MS SQL?

    Posted via ActualForum NNTP Server 1.5

    14 окт 13, 14:52    [14967311]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    Dimitry Sibiryakov
    Member

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

    Гость333
    (И ставить пре-релиз 2014 совсем не хочу — т.к. потом возможны проблемы с
    установкой релизной версии ).

    И это ещё один повод не выбирать MS SQL.

    Posted via ActualForum NNTP Server 1.5

    14 окт 13, 14:54    [14967332]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    Гость333
    Member

    Откуда:
    Сообщений: 3683
    pkarklin
    row and page compression
    Оно?

    Не оно. При колоночном сжатии создаётся словарь данных для столбца целиком. При страничном сжатии — только для текущей страницы. Сжатие строк — игрок из ещё более низкой лиги.
    14 окт 13, 15:02    [14967424]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    Alexander Ryndin
    Member

    Откуда:
    Сообщений: 4919
    Блог
    Гость333
    Alexander Ryndin
    пропущено...
    эм. Какая разница? Он все равно не сжимает существующую таблицу. Разве не так?

    Вот здесь http://blog.dbandbi.com/sql-server-2014-columnstore-index/ автор создал на таблице clustered columnstore index и сжал таблицу с 409 Мб до 74 Мб — компрессия 18%. Весьма близко к искомым 7-10 раз. У меня MSSQL 2014 нет, проверить не могу. (И ставить пре-релиз 2014 совсем не хочу — т.к. потом возможны проблемы с установкой релизной версии ).
    Угу. вот только:
    http://blog.dbandbi.com/sql-server-2014-columnstore-index/
    A table with a clustered columnstore index cannot have any type of nonclustered index and a table with a clustered columnstore index cannot have unique constraints, primary key constraints, or foreign key constraints.
    14 окт 13, 15:05    [14967452]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    Alexander Ryndin
    Member

    Откуда:
    Сообщений: 4919
    Блог
    pkarklin
    Alexander Ryndin,

    SQL Server supports both row and page compression for both tables and indexes. Data compression can be configured for the following database objects:

    Оно?
    Не оно. Такое сжатие обычно дает двукратную экономию. Больше очень редко.
    14 окт 13, 15:07    [14967473]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    Гость333
    Member

    Откуда:
    Сообщений: 3683
    Dimitry Sibiryakov
    И вот тут возможны два сценария: страница DCM пишется после всех остальных грязных страниц
    или перед ними. При приходе "времени Пи" между этими событиями получаем два возможных
    результата: в следующий диф.бэкап некоторые изменённые страницы не попадут или в него
    попадут неизменённые страницы. Какой сценарий реализован в MS SQL?

    Вы согласны, что удвоение записи из-за DCM — это вырожденный случай?
    Дальше, неясно, что вы вкладываете в понятие "время Пи".
    Предположу, что в MSSQL реализован второй сценарий. При восстановлении из бэкапа изменения будут накачены с использованием журнала транзакций. В дифф.бэкапе обязательно есть кусок журнала транзакций, с помощью которого можно привести БД в консистентное состояние.
    14 окт 13, 15:15    [14967545]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    Гость333
    Member

    Откуда:
    Сообщений: 3683
    Alexander Ryndin
    Угу. вот только:
    http://blog.dbandbi.com/sql-server-2014-columnstore-index/
    A table with a clustered columnstore index cannot have any type of nonclustered index and a table with a clustered columnstore index cannot have unique constraints, primary key constraints, or foreign key constraints.

    Вот видите, какой простор для допиливания в каком-нибудь MSSQL 2016 :)
    14 окт 13, 15:17    [14967561]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    Dimitry Sibiryakov
    Member

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

    Гость333
    неясно, что вы вкладываете в понятие "время Пи".

    Момент, в который какой-то кретин нажал кнопку "Reset".

    Posted via ActualForum NNTP Server 1.5

    14 окт 13, 15:29    [14967647]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    Гость333
    Member

    Откуда:
    Сообщений: 3683
    В MSSQL можно выполнять DDL в транзакции. Это круто.
    Оракл не может этим похвастать.

    В MSSQL можно невозбранно пользоваться временными таблицами в распределённых транзакциях.
    В Оракле, согласно документации, этого делать нельзя. В реальности — пользуйся, не будет выдано никакой ошибки, но! В случае роллбэка такой транзакции возможны ошибки вплоть до краха базы данных. Оракловая техподдержка при этом умывает руки и тычет в доку. В общем, задокументировали баг и сказали, что это фича. А это уже какой-то отстой.
    14 окт 13, 15:50    [14967800]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    Alexander Ryndin
    Member

    Откуда:
    Сообщений: 4919
    Блог
    pkarklin
    Alexander Ryndin,

    автор
    Разве это позволяет сжать существующую таблицу в 7-10 раз


    Если речь о сжатии, то:

    SQL Server supports both row and page compression for both tables and indexes. Data compression can be configured for the following database objects
    Такое сжатие обычно дает двукратную экономию. Больше очень редко.
    14 окт 13, 15:50    [14967805]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    Yo.!
    Guest
    Dimitry Sibiryakov
    И вот тут возможны два сценария: страница DCM пишется после всех остальных грязных страниц
    или перед ними. При приходе "времени Пи" между этими событиями получаем два возможных
    результата: в следующий диф.бэкап некоторые изменённые страницы не попадут или в него
    попадут неизменённые страницы. Какой сценарий реализован в MS SQL?

    кончай уже клоунаду, есть же лит-ра для новичков. серверу с транзакшен логом (любому) по барабану запишется ли блок из кеша в датафайл или нет. если какой-то лапоть нажал ресет до того как блок был записан в датафайл, процесс рекавери из лога транзакции реконструирует этот блок. бэкап возьмет блок из кеша, а не файловой системы.
    14 окт 13, 15:54    [14967832]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    Dimitry Sibiryakov
    Member

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

    Yo.!
    процесс рекавери из лога транзакции реконструирует этот блок. бэкап возьмет
    блок из кеша, а не файловой системы.

    Угу, остаётся сущая мелочь: прежде чем с базой можно будет работать, надо подождать
    окончания "процесса рекавери" и молиться, что он не упадёт. (Привет, Сбербанк!)

    Posted via ActualForum NNTP Server 1.5

    14 окт 13, 16:11    [14967965]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    Yo.!
    Guest
    Dimitry Sibiryakov
    Угу, остаётся сущая мелочь: прежде чем с базой можно будет работать, надо подождать
    окончания "процесса рекавери" и молиться, что он не упадёт. (Привет, Сбербанк!)

    на то оно и энтерпрайз, вашему ФБ без лога и молитвы в той ситуации бы не помогли. у дб2 была похожая ситуация, тогда немецкий банк (данцига?) неделю ловил баги на рекавери процессе.
    14 окт 13, 16:41    [14968251]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    Dimitry Sibiryakov
    Member

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

    Yo.!
    вашему ФБ без лога и молитвы в той ситуации бы не помогли

    Ему молитвы и не нужны: рекавери процесс у ФБ не включает в себя накат длинного лога.

    Posted via ActualForum NNTP Server 1.5

    14 окт 13, 16:44    [14968278]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    Yo.!
    Guest
    Dimitry Sibiryakov
    Ему молитвы и не нужны: рекавери процесс у ФБ не включает в себя накат длинного лога.

    об том и речь, если бы на месте оракла был ущербный ФБ шансов восстановить данные не было бы никаких. все, что мог бы предложить ФБ - последний бэкап.
    14 окт 13, 17:30    [14968636]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    iv_an_ru
    Member

    Откуда: Новосибирск
    Сообщений: 20368
    softwarer
    iv_an_ru
    Это-то как раз не проблема --- автокаст к типу, который должен быть по метаданным, и всё.
    ... В принципе, если браться решать именно такую задачу, не думая о прочем.. я, наверное, двигался бы в сторону версионности метаинформации. То есть alter table modify хранит колонки в виде двунаправленного списка версий. При хранении и передаче поле сопровождается маркером поля/версии, соответственно, в подходящем месте данные кастятся к актуальной версии / выкидывается исключение при невозможности конвертации.
    Ну да. Версионность. В случае Виртуозы каждая версия структуры каждого индекса получает уникальный номер. Для каждой страницы каждого индекса этот номер хранится в начале страницы. Ну и всё, даже никаких списков версий не надо. А если ещё учесть, что версии индексов должны поддерживаться в любом случае, так как есть куча методов репликации, и никто не обещает синхронного изменения схемы на всех "причастных" серверах, то фича получается "бесплатной", очень мало лишнего кода.
    14 окт 13, 17:45    [14968735]     Ответить | Цитировать Сообщить модератору
     Re: Зачем выбирать другие СУБД, если существует MS SQLServer?  [new]
    Dimitry Sibiryakov
    Member

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

    Yo.!
    если бы на месте оракла был ущербный ФБ шансов восстановить данные не было бы
    никаких

    А что, простите, там надо было восстанавливать? Данные были целы, только их накат занял
    слишком много времени. "Ущербный ФБ" был бы готов к работе за пару секунд и самой проблемы
    не могло возникнуть в принципе.

    Posted via ActualForum NNTP Server 1.5

    14 окт 13, 17:49    [14968763]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 .. 11 12 13 14 15 [16] 17 18 19 20 .. 54   вперед  Ctrl
    Все форумы / Сравнение СУБД Ответить