Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7 8 9 10 .. 15   вперед  Ctrl
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Yo.!
Guest
Alexander Ryndin
Это как так? Мой трехдневный отчет заблокирует ежедневное обновление агрегатов? А где же тогда магия?

показываю магию. внимательно следите за руками !
вводим понятие банковский день/закрытый период и не разрешаем в этот период вносить изменения. отчеты строим только по закрытому периоду. 30 лет так работали и дальше так работать будут, а то, что у конкурентов на версионниках давно все в реалтайме, ну так это детали.
8 май 15, 09:34    [17616369]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Guest
Alexander Ryndin
PgSQLAnonymous
пропущено...

It depends. Если полный пересчёт (либо блокировки "пересекаются"), то пересчёт заблокируется (а то Вы не знали ;) ).

Вообще, я уже говорил --- я за гибридный подход (т.е. возможность выбора в одной СУБД как полноценного версионного, так и блокировочного механизма).
Это как так? Мой трехдневный отчет заблокирует ежедневное обновление агрегатов? А где же тогда магия?

А вот так, магии-то не существует. ;)

Alexander Ryndin
Хорошо, что я решил задать вам этот вопрос, а не снес Oracle.

Да ладно, снесли бы уж, что Вы всё сидите с не-ACID СУБД ;) (и это в 2015-то году! )

Alexander Ryndin
А то мне показалось, что вы в прошлый раз сказали вот это:
PgSQLAnonymous
В случае блокировочника во всём отчёте будут выведены данные после изменения, т.е. фактически считается, что он был выполнен после модификации, а в версионнике --- до модификации.

Да, сказал. А в этом случае модификация реально будет выполнена только после отчёта, а не до. ;)
Грубо говоря, в блокировочнике последовательность транзакций совпадает с последовательностью COMMIT-ов.
8 май 15, 09:38    [17616385]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Guest
Yo.!
Alexander Ryndin
Это как так? Мой трехдневный отчет заблокирует ежедневное обновление агрегатов? А где же тогда магия?

показываю магию. внимательно следите за руками !
вводим понятие банковский день/закрытый период и не разрешаем в этот период вносить изменения. отчеты строим только по закрытому периоду. 30 лет так работали и дальше так работать будут, а то, что у конкурентов на версионниках давно все в реалтайме, ну так это детали.

Уж скорее в stale-тайме. ;) Впрочем, на практике это всё не так уж бросается в глаза.
8 май 15, 09:57    [17616467]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Ggg_old
Member

Откуда: Одесса
Сообщений: 1342
в споре про 3х дневный отчет не правы обе стороны, т.к. непротиворечивость данных такого мега-отчета должен обеспечиваться не механизмами изоляции транзакций, а логикой хранения данных в базе и учета изменения в них.
Изоляция и обеспечение непротеворечивости в течение непродолжтительного времени (например проведения платежа) или построение быстрого оперативного отчета (например выписка по счету за текущий день) можно и частично переложить на мехнизмы блокировок или версий.
Практика показала, что версионный механизм так или иначе реализуется в субд. т.к. наличие выбора режима работы - это лучше чем только один вариант.
Лично я всегда предпочитал блокировочники, но у версионников как показало время есть преимущество в части масштабируемости информационных систем, которые не параллелятся по типу shared nothing. Например все тяжелые учетные системы, банковские системы. Дисковые стойки масштабируются очень хорошо и линейно, знай добавляй дисков и будет расти iops-ы, версионники хрянт инфу о блокировка на диске, а значит гораздо меньше зависят в отличие от блокировочников, хранящих блокировки в RAM. Т.е. производительность версионников привязана к гораздо более легко масштабируемому ресурсу, чем производительность блокировочников.
8 май 15, 10:33    [17616693]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
DPH3
Member

Откуда:
Сообщений: 456
Yo.!

вводим понятие банковский день/закрытый период и не разрешаем в этот период вносить изменения. отчеты строим только по закрытому периоду. 30 лет так работали и дальше так работать будут, а то, что у конкурентов на версионниках давно все в реалтайме, ну так это детали.[/quot]

Э, а какая магия дает возможность версионнику в реальном времени считать все движение по счетам за прошедшие 30 лет при каждом запросе, без всяких закрытых периодов?
Банковский день/закрытый период вводились просто в те времена, когда нормальных materialized view и партиционирования еще не было. Да и память/ядра стоили дорого.
Так что все-таки лучше без передергиваний.
8 май 15, 10:34    [17616702]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
PgSQLAnonymous
Yo.!
пропущено...

показываю магию. внимательно следите за руками !
вводим понятие банковский день/закрытый период и не разрешаем в этот период вносить изменения. отчеты строим только по закрытому периоду. 30 лет так работали и дальше так работать будут, а то, что у конкурентов на версионниках давно все в реалтайме, ну так это детали.

Уж скорее в stale-тайме. ;) Впрочем, на практике это всё не так уж бросается в глаза.
Пользователь обычно хочет получить согласованный результат. Будь он на время Т или время Т+2.
1) в случае версионника пользователь получит ответ на время Т, писатели данных продолжат менять данные
2) в случае блокировочника пользователь получит ответ на время Т, но писатели данных будут заблокированы
3) в случае блокировочника+грязного чтения пользователь не получит согласованный результат ни на Т, ни на Т+2, писатели продолжат менять данные
Мне кажется, с точки зрения бизнес приемлемы 1) и 2). Иногда может быть приемлем 3), но это нужно всегда оговаривать.
8 май 15, 10:39    [17616741]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
irbis_al
Member

Откуда: Симферополь
Сообщений: 1798
Alexander Ryndin,

2) в случае блокировочника пользователь получит ответ на время Т, но писатели данных будут заблокированы

Мне кажется блокировать писателей явно "не комильфо"...
от этого зависит отклик базы данных на запись.(оперативные журналы то не резиновые)
И если в базу много пишут...и ровно также много делают аналитических отчётов...производительность по записи блокировочника может просесть по отношению к версионнику.(Ну тут уже выше говорилось,что версионник лучше масштабируется)
8 май 15, 10:50    [17616810]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
Ggg_old
в споре про 3х дневный отчет не правы обе стороны, т.к. непротиворечивость данных такого мега-отчета должен обеспечиваться не механизмами изоляции транзакций, а логикой хранения данных в базе и учета изменения в них.
3 дня было взято для того, чтобы подчеркнуть проблему. Та же самая проблема будет, если отчет выполняется 2 минуты. Это как раз из разряда оперативных отчетов, но эти отчеты также могут обращаться к нескольких таблицам, что может привести к рассинхрону. Городить "логику хранения данных в базе и учета изменения в них" ради этих отчетов в OLTP системе никто не будет.
Ggg_old
Лично я всегда предпочитал блокировочники, но у версионников как показало время есть преимущество в части масштабируемости информационных систем
Это да. Не понятно к чем только фразы про shared nothing. Shared nothing может быть применен как к блокировочникам, так и к версионникам.
Ggg_old
версионники хрянт инфу о блокировка на диске, а значит гораздо меньше зависят в отличие от блокировочников, хранящих блокировки в RAM. Т.е. производительность версионников привязана к гораздо более легко масштабируемому ресурсу, чем производительность блокировочников.
Простите, какой-то поток сознания про RAM и диски. Какие такие версионники хранят блокировки на диске? Про Oracle могу сказать, что информация о блокировках хранится в заголовке блока данных, который в свою очередь лежит в оперативке.
8 май 15, 10:51    [17616818]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
miwaonline
SergSuper
пропущено...
ерунда, максимум что не сойдется сумма активов и пассивов в каком-нибудь отчете

Я правильно понял, что несогласованный между собой (или противоречащий сам себе) отчет для вас - ерунда?
неправильно
ерунда в том что не получится что Петя должен Васе
8 май 15, 10:53    [17616833]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
DPH3
Member

Откуда:
Сообщений: 456
PgSQLAnonymous
Вот Вам такой пример: я запускаю 2 транзакции --- отчёт (и он выполняется 3 дня) и какую-то модификацию данных, которые он затрагивает (и она выполняется 1 секунду), и они пересекаются.


Хм, интересно, а почему на OLTP системе запускаются отчеты, которые работают 3 дня и что бы сделать с архитектором за такие фокусы :)

Вообще, по моему опыту (трехзвенок) у версионников есть несколько реальных проблем, с самой БД мало связанных:

1) 95% разработчиков систем вообще не знают о разнице между блокировочниками и версионниками и думают, что у Oracle уровень serializable работает так же, как и у DB2.
В результате у нескольких платежных систем (реально работающих на рынке) при массовых операциях с одним счетом могут пропадать деньги и нарушаться пользовательские лимиты по счетам.

2) Версионники провоцируют смешивать OLTP и OLAP в большей степени, нежели блокировочники. Как, например, в задаче выше - никто из обсуждавших даже не спросил, а какой физический смысл у отчета про "состояние базы когда-то 3 дня назад". А как только добавляется "отчет по состоянию на 09:00 в понедельник", то сразу разница между блокировочником и версионником вообще исчезает, да и вообще лучше взять Spark.

3) Версионники, почему-то, сложнее администрировать. По крайней мере, DBA для DB2 и MS SQL стоят дешевле, чем для Oracle/Postgre и часов на типовую задачу у них уходит меньше.
Не знаю, проблемы с архитектурой или чем-то еще )

Ну и для реальных задач выбор между блокировочником и версионником не так уж и важен. А вот как реализовано партиционирование, материализованные представление, инкрементальный бакап, log shipping и сколько это стоит - действительно важно.
8 май 15, 10:53    [17616834]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Guest
Ggg_old
в споре про 3х дневный отчет не правы обе стороны, т.к. непротиворечивость данных такого мега-отчета должен обеспечиваться не механизмами изоляции транзакций, а логикой хранения данных в базе и учета изменения в них.

Это потому что Вы так сказали? ;) А я вот считаю наоборот, и что?

Ggg_old
Изоляция и обеспечение непротеворечивости в течение непродолжтительного времени (например проведения платежа) или построение быстрого оперативного отчета (например выписка по счету за текущий день) можно и частично переложить на мехнизмы блокировок или версий.

Опять-таки, не согласен. Я считаю, что эта задача (обеспечение непротиворечивости при конкурентном доступе) должна решаться именно СУБД.

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

Согласен.

Ggg_old
Лично я всегда предпочитал блокировочники, но у версионников как показало время есть преимущество в части масштабируемости информационных систем, которые не параллелятся по типу shared nothing. Например все тяжелые учетные системы, банковские системы. Дисковые стойки масштабируются очень хорошо и линейно, знай добавляй дисков и будет расти iops-ы, версионники хрянт инфу о блокировка на диске, а значит гораздо меньше зависят в отличие от блокировочников, хранящих блокировки в RAM. Т.е. производительность версионников привязана к гораздо более легко масштабируемому ресурсу, чем производительность блокировочников.

Вообще-то кеширование в основном скрывает эти различия, и как блокировки (которые тоже могут храниться на диске), так и версии (которые тоже можно хранить в RAM) обычно находятся именно в RAM. И, кстати, знай добавляй RAM и "будет расти iops-ы". ;)
8 май 15, 11:01    [17616883]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
DPH3
PgSQLAnonymous
Вот Вам такой пример: я запускаю 2 транзакции --- отчёт (и он выполняется 3 дня) и какую-то модификацию данных, которые он затрагивает (и она выполняется 1 секунду), и они пересекаются.


Хм, интересно, а почему на OLTP системе запускаются отчеты, которые работают 3 дня и что бы сделать с архитектором за такие фокусы :)

а какой физический смысл у отчета про "состояние базы когда-то 3 дня назад".
Еще раз повторюсь. 3 дня это для примера, чтобы усугубить. Абсолютно та же проблема будет и на запросе, который работает 1 день, 1 час и 1 минуту. Просто возникать она будет реже/чаще, а для пользователь будет создавать большие/меньшие проблемы.

Естественно аналитическую систему с отчетами, работающими часами нужно отделять. В версионнике смешение двух нагрузок также ничего хорошего не приносит. Например, у Oracle бывает ошибка ORA-01555 snapshot too old, говорящая о том, что нужная нам версия данных уже выброшена.
8 май 15, 11:03    [17616896]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Guest
Alexander Ryndin
PgSQLAnonymous
пропущено...

Уж скорее в stale-тайме. ;) Впрочем, на практике это всё не так уж бросается в глаза.
Пользователь обычно хочет получить согласованный результат. Будь он на время Т или время Т+2.
1) в случае версионника пользователь получит ответ на время Т, писатели данных продолжат менять данные
2) в случае блокировочника пользователь получит ответ на время Т, но писатели данных будут заблокированы
3) в случае блокировочника+грязного чтения пользователь не получит согласованный результат ни на Т, ни на Т+2, писатели продолжат менять данные
Мне кажется, с точки зрения бизнес приемлемы 1) и 2). Иногда может быть приемлем 3), но это нужно всегда оговаривать.

Нет, в случае блокировочника пользователь получит ответ на время Т+2 (по состоянию на конец этой транзакции).
8 май 15, 11:05    [17616903]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67469
Блог
Alexander Ryndin
Например, у Oracle бывает ошибка ORA-01555 snapshot too old, говорящая о том, что нужная нам версия данных уже выброшена.

Слушайте, вот честно, когда Вы её в последний раз видели? Я, если не считать искусственно создаваемых примеров - на версии 8.1.7.4, лет двенадцать назад.
8 май 15, 11:05    [17616904]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Yo.!
Guest
Ggg_old
версионники хрянт инфу о блокировка на диске, а значит гораздо меньше зависят в отличие от блокировочников, хранящих блокировки в RAM. Т.е. производительность версионников привязана к гораздо более легко масштабируемому ресурсу, чем производительность блокировочников.

это не правда. ни postgres, ни mysql/innodb, ни mssql/snapshot не хранят локи в датафайлах. эта мудрая мысль заложена только только в оракл.
8 май 15, 11:06    [17616916]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
softwarer
Alexander Ryndin
Например, у Oracle бывает ошибка ORA-01555 snapshot too old, говорящая о том, что нужная нам версия данных уже выброшена.

Слушайте, вот честно, когда Вы её в последний раз видели? Я, если не считать искусственно создаваемых примеров - на версии 8.1.7.4, лет двенадцать назад.
Если честно, то полгода назад.
8 май 15, 11:09    [17616930]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
PgSQLAnonymous
Alexander Ryndin
пропущено...
Пользователь обычно хочет получить согласованный результат. Будь он на время Т или время Т+2.
1) в случае версионника пользователь получит ответ на время Т, писатели данных продолжат менять данные
2) в случае блокировочника пользователь получит ответ на время Т, но писатели данных будут заблокированы
3) в случае блокировочника+грязного чтения пользователь не получит согласованный результат ни на Т, ни на Т+2, писатели продолжат менять данные
Мне кажется, с точки зрения бизнес приемлемы 1) и 2). Иногда может быть приемлем 3), но это нужно всегда оговаривать.

Нет, в случае блокировочника пользователь получит ответ на время Т+2 (по состоянию на конец этой транзакции).
...и пусть весь мир подождет.
8 май 15, 11:10    [17616937]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
DPH3
3) Версионники, почему-то, сложнее администрировать. По крайней мере, DBA для DB2 и MS SQL стоят дешевле, чем для Oracle/Postgre и часов на типовую задачу у них уходит меньше.
Не знаю, проблемы с архитектурой или чем-то еще )
Это по причине того, что вы сравниваете среднюю температуру по больнице. В вашу статистику попадают как DBA, сопровождающие банковские системы, так и DBA с 1С на MSSQL.
Если вы начнете сравнивать яблоки с яблоками, то увидите, что классный MSSQL спец получает не меньше чем классный спец по Oracle. Просто крутых систем на MSSQL построено раз два и обчелся, а на Oracle куда не плюнь бизнес-критические системы. Ну те же банки возьмите - они в России сидят на Oracle в 90% случаев.
8 май 15, 11:16    [17616957]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Guest
DPH3
PgSQLAnonymous
Вот Вам такой пример: я запускаю 2 транзакции --- отчёт (и он выполняется 3 дня) и какую-то модификацию данных, которые он затрагивает (и она выполняется 1 секунду), и они пересекаются.


Хм, интересно, а почему на OLTP системе запускаются отчеты, которые работают 3 дня и что бы сделать с архитектором за такие фокусы :)

Это да. ;)

DPH3
1) 95% разработчиков систем вообще не знают о разнице между блокировочниками и версионниками и думают, что у Oracle уровень serializable работает так же, как и у DB2.
В результате у нескольких платежных систем (реально работающих на рынке) при массовых операциях с одним счетом могут пропадать деньги и нарушаться пользовательские лимиты по счетам.


Подпишусь. "Слушайте, слушайте, и не говорите, что не слышали!" ;)

DPH3
Ну и для реальных задач выбор между блокировочником и версионником не так уж и важен. А вот как реализовано партиционирование, материализованные представление, инкрементальный бакап, log shipping и сколько это стоит - действительно важно.

Вообще-то да, но с учётом того, что "настоящих" (с полноценным версионным SERIALIZABLE) версионников не так уж и много, выбор всё равно важен. ;)
8 май 15, 11:18    [17616966]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Dimitry Sibiryakov
Member

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

DPH3
часов на типовую задачу у них уходит меньше.

Пример "типовой операции" - В СТУДИЮ!!!

Posted via ActualForum NNTP Server 1.5

8 май 15, 11:18    [17616970]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Guest
Yo.!
Ggg_old
версионники хрянт инфу о блокировка на диске, а значит гораздо меньше зависят в отличие от блокировочников, хранящих блокировки в RAM. Т.е. производительность версионников привязана к гораздо более легко масштабируемому ресурсу, чем производительность блокировочников.

это не правда. ни postgres, ни mysql/innodb, ни mssql/snapshot не хранят локи в датафайлах. эта мудрая мысль заложена только только в оракл.

Да ладно ;)

In PostgreSQL, tuple level locks are not held in RAM for any length of time; lock information is written to the tuples involved in the transactions.
Но это про predicate locks, которые ничего не блокируют, если честно. ;)
А кроме того, чем плоха эта мысль? Потенциально-то это способствует масштабируемости.
8 май 15, 11:27    [17617020]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Guest
Alexander Ryndin
PgSQLAnonymous
пропущено...

Нет, в случае блокировочника пользователь получит ответ на время Т+2 (по состоянию на конец этой транзакции).
...и пусть весь мир подождет.

В худшем случае --- да. ;)

А если вот в версионнике 100500 транзакций пересекаются и конкурируют за один и тот же ресурс, то "пусть весь мир отойдёт". ;) Уже наступил вечер, а транзакции всё откатывались.
8 май 15, 11:32    [17617067]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
irbis_al
Member

Откуда: Симферополь
Сообщений: 1798
1) 95% разработчиков систем вообще не знают о разнице между блокировочниками и версионниками и думают, что у Oracle уровень serializable работает так же, как и у DB2.
В результате у нескольких платежных систем (реально работающих на рынке) при массовых операциях с одним счетом могут пропадать деньги и нарушаться пользовательские лимиты по счетам.


А пропадают деньги у кого у оракла или дб2?...
Судя по всему у оракла...
Ну в принципе,если разработчики не занют разницы..это в принципе их косяк...
Ведь версионник может эмулировать блокировочник.

set transaction exclusive mode
или
select for update...
И тогда нужный набор будет ждать.
(Хотя для отчётов...значение иметь не будет всё равно...так же будут формироваться)
8 май 15, 11:36    [17617092]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
Yo.!
Alexander Ryndin
Это как так? Мой трехдневный отчет заблокирует ежедневное обновление агрегатов? А где же тогда магия?

вводим понятие банковский день/закрытый период и не разрешаем в этот период вносить изменения. отчеты строим только по закрытому периоду.


Тока если блокировочник вдруг не эскалирует блокировку (а для 3-дневного отчета у него будут все причины это сделать). Тогда никакой закрытый период не поможет. Только если все в отдельные таблицы (считай базу) не переносить.
8 май 15, 11:47    [17617155]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1090
DPH3
Хм, интересно, а почему на OLTP системе запускаются отчеты, которые работают 3 дня и что бы сделать с архитектором за такие фокусы :)


Это вы объясните людям, которые хотят на одной форме рядом с количеством для ввода видеть количество реализации за период. Вы конечно можете им пораcсказывать про OLTP и OLAP, про неправильную архитектуру их бизнеса. Но я надеюсь вы сами понимаете, куда вас пошлет заказчик.

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