Текущее время: Чт, мар 28 2024, 17:15

Часовой пояс: UTC + 3 часа


Правила форума


- Не материться в явном виде (за нарушение выносится первое предупреждение, оно же и последнее, далее - бан)
- Не разжигать рознь на национальной, религиозной, половой и расовой почве (следует немедленный годичный бан)
- Троллинг, кащенизм, холивары, упячка ведут к вечному упокоению в бане
- Пользование подфорумом "Частные объявления" - см. п. 6.2 Правил форума
- Пользование подфорумами "Встречи" и "Поздравления" - см. п. 6.3 Правил форума
- Все прочее - см. раздел 6.1 Правил форума



Начать новую тему Ответить на тему  [ Сообщений: 161 ]  На страницу Пред.  1, 2, 3, 4, 5 ... 11  След.
Автор Сообщение
 Заголовок сообщения: Re: Ora vs HANA
СообщениеДобавлено: Вт, окт 06 2015, 17:51 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Пн, мар 28 2005, 15:38
Сообщения: 1246
Цитата:
Почитайте комментарии Хассо Платнера.


Спасибо.
Узнаю сап. В мануалах - инфы нет. Зато есть в камментах на форуме и блогах.
Вот кстати еще один вопрос волнует: как происходит у всех этих ин-мемори обработок процесс восстановления после сбоя? Про тот же оракл все очень хорошо документировано (все эти незакоммиченные транзакции и redo-логи и т.д., описанием что происходит при подъеме по шагам), а вот у HANA это как-то описано?

_________________
Там, где я рос, единственным развлечением было запоминать число «π».(С) Н. Стивенсон


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ora vs HANA
СообщениеДобавлено: Сб, окт 17 2015, 13:27 
Младший специалист
Младший специалист

Зарегистрирован:
Сб, окт 17 2015, 13:11
Сообщения: 59
Точно так же и происходит.
Есть REDO-log, есть UNDO.
Интересная реализованная фича - shadow paging, позволяющая восстанавливаться значительно быстрее, за счет того, что модифицированные страницы при записи на диск не заменяют имеющиеся, а кладутся рядом. В случае креша при сэйвпоинте, из файлов возьмутся те, что не были модифицированы, и прогонится redo+undo логи.
Да, и про сортировку, так и есть. Словарь хранится в сортированном виде, при изменении-добавлении данных они кладутся в дельту, несортированно, при дельта мердже происходит модификация словаря, если надо (пере)сжатие. Поэтому по агрегациям HANA решает.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ora vs HANA
СообщениеДобавлено: Сб, окт 17 2015, 20:53 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Пн, мар 28 2005, 15:38
Сообщения: 1246
Цитата:
Точно так же и происходит.
Есть REDO-log, есть UNDO.


Воу-воу! как интересно. Значит так.. у нас в памяти по максимуму для одного узла. Т.е. 6Тб, как обещали. Юзеры активно чего-то там делают с базой: то запись изменят, то, не дай боженька - удалят. И так - каждый из много-много подключенных. Т.к. все в памяти, то до винта (и тех самых redo-log) еще многое не доехало (при том что коммит, официально, был-таки сказан!). И тут, значится, приходит мелкий пушной зверек в виде пропавшего электричества. И? И вот что в этом разе будет-то?

Цитата:
Да, и про сортировку, так и есть. Словарь хранится в сортированном виде, при изменении-добавлении данных они кладутся в дельту, несортированно, при дельта мердже происходит модификация словаря, если надо (пере)сжатие. Поэтому по агрегациям HANA решает.


Решает, говорите? По агрегациям? А вы когда-нибудь на большой таблице в хане пробовали гонять оконные функции? Если да - то как ощущения?

_________________
Там, где я рос, единственным развлечением было запоминать число «π».(С) Н. Стивенсон


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ora vs HANA
СообщениеДобавлено: Вс, окт 18 2015, 12:23 
Младший специалист
Младший специалист

Зарегистрирован:
Сб, окт 17 2015, 13:11
Сообщения: 59
Кодер написал(а):
Т.к. все в памяти, то до винта (и тех самых redo-log) еще многое не доехало (при том что коммит, официально, был-таки сказан!)


Ну, коллега, у Вас что-то неверные какие-то знания о Хане. Хана - нормальная реляционная СУБД, которая гарантирует соответствие ACID принципам, соответственно после коммита запись в редо об успешной транзакции будет выполнена. После рестарта, транзакция, согласно редо логу будет проведена заново.

Кодер написал(а):
Решает, говорите? По агрегациям? А вы когда-нибудь на большой таблице в хане пробовали гонять оконные функции? Если да - то как ощущения?

Нет, не пробовал, и было бы интересно почитать, желательно с результатами. В идеальном случае, конечно бы, перформанс трейс выложить, но я об этом и не загадываю.
Чудес не бывает, и если другие бд упираются в бОльшее количество операций с памтью и кэшами процессоров просто за счет того, что они чаще должны в память заглядывать, то Хана будет быстрее просто в силу того, что таких операций, опять-таки в силу архитектуры у нее будет меньше. Если же число процессорных операций на Хане будет больше, то общее время выполнения будет медленнее, всего делов.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ora vs HANA
СообщениеДобавлено: Вс, окт 18 2015, 15:51 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Пн, мар 28 2005, 15:38
Сообщения: 1246
Цитата:
Ну, коллега, у Вас что-то неверные какие-то знания о Хане. Хана - нормальная реляционная СУБД, которая гарантирует соответствие ACID принципам, соответственно после коммита запись в редо об успешной транзакции будет выполнена. После рестарта, транзакция, согласно редо логу будет проведена заново.


То, какого типа СУБД (реляционная или нет), несколько не связано с тем, как реализована конкретная СУБД, не правда ли?
Целенаправленно поискал мануал по backup&recovery. На бумаге - ок. Но детали не прояснены (частота savepoint и как это стыкуется с декларируемой in-memory обработкой)

_________________
Там, где я рос, единственным развлечением было запоминать число «π».(С) Н. Стивенсон


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ora vs HANA
СообщениеДобавлено: Вс, окт 18 2015, 17:06 
Младший специалист
Младший специалист

Зарегистрирован:
Сб, окт 17 2015, 13:11
Сообщения: 59
Кодер написал(а):
То, какого типа СУБД (реляционная или нет), несколько не связано с тем, как реализована конкретная СУБД, не правда ли?

Позвольте не согласиться. Если СУБД хочет называться реляционной, она должна соответствовать принципам построения реляционных бд, прежде всего ACID. А уж как она их реализует, это конечно ее, СУБД, личное дело. Соответственно, если RAM волатильная, то хочешь не хочешь, а вынужден сохранять записи о транзакциях на неволатильном хранилище.
Кодер написал(а):
Целенаправленно поискал мануал по backup&recovery. На бумаге - ок. Но детали не прояснены (частота savepoint и как это стыкуется с декларируемой in-memory обработкой)

Когда транзакция стартует(для примера, пусть это будет некий INSERT в column-store таблицу), Хана сохраняет данные этого инсерта в области Delta, и сохраняет запись о произошедей транзакции в redo-лог, после этого управление транзакции возвращается. После того, как транзакция запускает комманду COMMIT, запись об этом также пишется в redo-лог, Хана дожидается подтверждения от диска, что запись на диск произошла, и только после этого управление из COMMIT'a возвращается. Таким образом, если сразу после этого происходит падение, то путем прохождения по Redo логу, эта транзакция повторяется.
Сэйвпоинт же, операция асинхронная и никак с конкретной транзакцией не связанная. Когда данные INSERT'a помещаются в дельту, страница памяти помечается, как грязная. Отдельный диспетчер проходит по списку грязных страниц и их сохраняет. По дефолту, это происходит раз в 5 минут. В случае, если транзакция что-то там заинсёртила, но не спешит коммититься, грязная страница с данными все равно будет сброшена на диск, но при этом записи о коммите в redo-логе не будет, и если произойдет падение, то произойдет откат неподтвержденных данных.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ora vs HANA
СообщениеДобавлено: Вс, окт 18 2015, 17:46 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Пн, мар 28 2005, 15:38
Сообщения: 1246
Цитата:
Когда транзакция стартует...

Подскажите, пожалуйста, где это в документации описано?
Цитата:
Хана сохраняет данные этого инсерта в области Delta, и сохраняет запись о произошедей транзакции в redo-лог, после этого управление транзакции возвращается. После того, как транзакция запускает комманду COMMIT, запись об этом также пишется в redo-лог, Хана дожидается подтверждения от диска, что запись на диск произошла, и только после этого управление из COMMIT'a возвращается.

Описание, за исключением некоторых деталей, как мне кажется, аналогично механизму оракла. Отсюда вопрос: т.е. при этих действиях, ин-мемори обработка никакого выигрыша не дает? И при массовых операциях вставки, все будет так же медленно и печально как и др. традиционной субд. Пока не будет совершен коммит(и сделана запись на диск), никаких бонусов от использования принципа "все-в-памяти", как бы и нет?

_________________
Там, где я рос, единственным развлечением было запоминать число «π».(С) Н. Стивенсон


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ora vs HANA
СообщениеДобавлено: Вс, окт 18 2015, 20:21 
Младший специалист
Младший специалист

Зарегистрирован:
Сб, окт 17 2015, 13:11
Сообщения: 59
Кодер написал(а):
Подскажите, пожалуйста, где это в документации описано?

Не совсем оф.документация, но, например, здесь
Кодер написал(а):
т.е. при этих действиях, ин-мемори обработка никакого выигрыша не дает?

Скажите, какая по Вашему, должна быть обработка при простом инсерте?

Если же мы говорим о вставке в большую таблицу, на которую навешаны unique constraints и/или различные индексы, то при прочих равных HANA будет быстрее (т.к. проверка на уникальность проверяется по словарю, который практически всегда меньше таблицы, кроме того, Хане не надо строить индексы, т.е. перебалансировать деревья, изменять списки и т.п.), хотя, скорее всего, у Оракла есть оптимизации, типа перестроения индекса в фоне, асинхронно и т.п.
Кодер написал(а):
Пока не будет совершен коммит(и сделана запись на диск), никаких бонусов от использования принципа "все-в-памяти", как бы и нет?

Здесь можно разделить ответ на 2 момента:
1. Дословно - предположение неверно, т.к. и пока не совершен коммит, и после совершения коммита, данные остаются в памяти, т.е. бонусы от использования принципа "все-в-памяти", несомненно, есть.
2. Если Вы планируете в одной транзакции и добавлять данные, и тут же, без коммита, совершать над ними (подчеркиваю, над этими, только что добавленными и незакоммиченными) какие-либо действия, может, стоит задуматься о прорехах в архитектуре? Пока мне сложно предположить, зачем такое может быть нужно.
И в целом, все-таки самая обычная реляционная база данных предполагает превалирование операций чтения (селектов), иначе зачем нам данные, которые никто не потрбеляет. Если же по бизнес-архитектуре предполагается ежесекундно, в течение месяца, только добавлять данные, а раз в месяц по ним, например, строить какую-либо аналитику, то тут вопрос, а вообще нужна ли в таком случае реляционная бд?


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ora vs HANA
СообщениеДобавлено: Вс, окт 18 2015, 21:58 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Пн, мар 28 2005, 15:38
Сообщения: 1246
Цитата:
Не совсем оф.документация, но, например, здесь

Спасибо. Почитаю

Цитата:
Скажите, какая по Вашему, должна быть обработка при простом инсерте?

Эм? кажется вы не понимаете мою мысль. О том как работает оракл при простом инсерте - я представление имею. Мои вопросы же касаются того, где преимущество ханы перед орой (см. название темы). По описанному - пока не вижу.

Цитата:
т.к. проверка на уникальность проверяется по словарю, который практически всегда меньше таблицы

а вот сейчас очень интересно было. Меньше в каком смысле? вот у вас поле - первичный ключ. BigInt в Hana. С Unique constraint. и что? их количество будет меньше? Нет.

Цитата:
Дословно - предположение неверно, т.к. и пока не совершен коммит, и после совершения коммита, данные остаются в памяти, т.е. бонусы от использования принципа "все-в-памяти", несомненно, есть.

данные остаются в памяти, но др. транзакциям(предположим Read Commited уровень изоляции данных) он станет доступен только после того, как коммит дольется до диска (не после того, как был сказан коммит, а именно после того как редо-лог этот факт записал, не так ли?)
Цитата:
Если Вы планируете в одной транзакции и добавлять данные, и тут же, без коммита, совершать над ними (подчеркиваю, над этими, только что добавленными и незакоммиченными) какие-либо действия, может, стоит задуматься о прорехах в архитектуре? Пока мне сложно предположить, зачем такое может быть нужно.

Пожалуйста, не приписывайте свои мысли мне. Хану позиционируют как скоростную БД с данными в памяти. Многие заказчики ожидают минимальное время между коммитом и возможностью получить закомиченные данные в др. транзакции БД (самое простое - в отчете) - ведь они же в памяти!

_________________
Там, где я рос, единственным развлечением было запоминать число «π».(С) Н. Стивенсон


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ora vs HANA
СообщениеДобавлено: Пн, окт 19 2015, 04:48 
Специалист
Специалист

Зарегистрирован:
Чт, мар 25 2010, 09:02
Сообщения: 207
Мне, кстати, тоже было интересно как хана гарантирует консистентность, нам тоже самое сказали, что коммит проходит только тогда кога данные запишутся на диск в каком-то виде, поэтому, я так понимаю, хана не дает какого-либо существенного выйгрыша при операциях изменения данных. Особо просто этот факт не афишируется.


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Ora vs HANA
СообщениеДобавлено: Пн, окт 19 2015, 11:15 
Младший специалист
Младший специалист

Зарегистрирован:
Сб, окт 17 2015, 13:11
Сообщения: 59
Кодер написал(а):
Эм? кажется вы не понимаете мою мысль. О том как работает оракл при простом инсерте - я представление имею. Мои вопросы же касаются того, где преимущество ханы перед орой (см. название темы).

Перечитал название темы. Не смог интерпретировать "Ora vs. HANA" как "Преимущество Ханы перед Ораклом". Название темы как бы подразумевает сравнение, а не доказательство преимуществ, нет?
Кодер написал(а):
Меньше в каком смысле? вот у вас поле - первичный ключ. BigInt в Hana. С Unique constraint. и что? их количество будет меньше? Нет.

Это зависит от поля. Если это поле числовое, например, номер документа или что-то подобное, то будет меньше. Если что-то совсем случайно-уникальное типа GUID/HASH - нет. Поэтому я и написал "Практически во всех случаях".
Кодер написал(а):
данные остаются в памяти, но др. транзакциям(предположим Read Commited уровень изоляции данных) он станет доступен только после того, как коммит дольется до диска (не после того, как был сказан коммит, а именно после того как редо-лог этот факт записал, не так ли?)

Еще раз перечитайте мое сообщение выше. Когда приложение вызывает команду COMMIT, то возврат из этой команды произойдет тогда, когда информация о коммите, не обновленные данные, а, грубо говоря некий признак-флаг (очень маленький по размеру), что коммит прошел, сохранится в лог-сегменте.
Кодер написал(а):
Пожалуйста, не приписывайте свои мысли мне. Хану позиционируют как скоростную БД с данными в памяти. Многие заказчики ожидают минимальное время между коммитом и возможностью получить закомиченные данные в др. транзакции БД (самое простое - в отчете) - ведь они же в памяти!

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

И в целом, коллеги, мы же технические специалисты, инженеры. Соответственно, подходить к любым заявлениям-утверждениям (даже моим =) ) необходимо критически. Не надо принимать все за чистую монету. Есть Хана под рукой - взяли, прогнали серию тестов, получили результат, интерпретировали. Если же и Оракл есть под руокй, то еще лучше, прогнали всё то же на том же объеме данных, интерпретировали, сравнили. Всё.
К тому же, в любых перфоманс тестах имеет смысл избегать широких экстраполяций. Получили преимущество Ханы в сложном селекте - не стоит экстраполировать до фразы "Хана быстрее всех селекты исполняет". Точно также и с Ораклом. Любое инженерное решение, а уж тем более такое сложное как современная РСУБД, это система компромиссов. Выигрываем в чем-то одном (сжатие, скорость исполнения сложных выборок), проигрываем в другом (затраты на организацию сжатия и поколоночное хранение) и т.п. Серебряной пули, увы, не существует.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ora vs HANA
СообщениеДобавлено: Пн, окт 19 2015, 11:55 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Пн, мар 28 2005, 15:38
Сообщения: 1246
Цитата:
Название темы как бы подразумевает сравнение, а не доказательство преимуществ, нет?

Ок.
Цитата:
Если что-то совсем случайно-уникальное типа GUID/HASH - нет. Поэтому я и написал "Практически во всех случаях".

Я указал вполне конкретный тип из HANA - BigInt. насколько я знаю, пережиматься такой столбец не будет совсем.

Цитата:
Когда приложение вызывает команду COMMIT, то возврат из этой команды произойдет тогда, когда информация о коммите, не обновленные данные, а, грубо говоря некий признак-флаг (очень маленький по размеру), что коммит прошел, сохранится в лог-сегменте.

Если это просто флаг, то выключение рубильника сохранит в редо-лог только флаг, а не данные. Инфа о данных будет потеряна, не правда ли? Из чего тогда будет происходить восстановление?

_________________
Там, где я рос, единственным развлечением было запоминать число «π».(С) Н. Стивенсон


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ora vs HANA
СообщениеДобавлено: Пн, окт 19 2015, 14:28 
Младший специалист
Младший специалист

Зарегистрирован:
Сб, окт 17 2015, 13:11
Сообщения: 59
Цитата:
насколько я знаю, пережиматься такой столбец не будет совсем.

У Вас неверные сведения. За пруфом отсылаю к таблице CS_COLUMNS_ , где SQL_TYPE_ID = 4
Например у меня на тестовой таблице, коэффициент сжатия 43,05

Цитата:
Если это просто флаг, то выключение рубильника сохранит в редо-лог только флаг, а не данные. Инфа о данных будет потеряна, не правда ли?

Неправда. Перечитайте сообщение от Вс, окт 18 2015, 18:06


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ora vs HANA
СообщениеДобавлено: Пн, окт 19 2015, 15:48 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Пн, мар 28 2005, 15:38
Сообщения: 1246
Цитата:
У Вас неверные сведения. За пруфом отсылаю к таблице CS_COLUMNS_ , где SQL_TYPE_ID = 4
Например у меня на тестовой таблице, коэффициент сжатия 43,05

1) под рукой ханы кончились
2) на основе предыдущих опытов, когда хана была под рукой, к сожалению, я с коллегами убедился, что при уникальных значениях в столбце типа BigInt - сжатия этого столбца практически нет.
Цитата:
Неправда. Перечитайте сообщение от Вс, окт 18 2015, 18:06

перечитал. цитирую вас:
Цитата:
сохраняет запись о произошедей транзакции в redo-лог, после этого управление транзакции возвращается. После того, как транзакция запускает комманду COMMIT, запись об этом также пишется в redo-лог, Хана дожидается подтверждения от диска, что запись на диск произошла, и только после этого управление из COMMIT'a возвращается.

Т.е. до винта таки должно долиться все, не только флаг. Что несколько противоречит вашим же словам
Цитата:
Когда приложение вызывает команду COMMIT, то возврат из этой команды произойдет тогда, когда информация о коммите, не обновленные данные, а, грубо говоря некий признак-флаг (очень маленький по размеру), что коммит прошел, сохранится в лог-сегменте.

Так в какой из ваших цитат описана реальная логика работы?

_________________
Там, где я рос, единственным развлечением было запоминать число «π».(С) Н. Стивенсон


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ora vs HANA
СообщениеДобавлено: Вт, окт 20 2015, 10:51 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, сен 16 2004, 17:10
Сообщения: 2229
Откуда: Moscow, кажется...
Пол: Мужской
Вот смотрю я сейчас на всю эту вакханалию, другого слова не подберу, и пытаюсь понять вообще необходимость HANA. И никак это мне не просматривается.
Вот некоторые простые мысли.
1. У нас как была, так и остается трехзвенка. Т.е. есть сервер приложений, в памяти которого болтается все, что требуется для работоспособности, скажем так, ERP
По мере необходимости кэшированные данные вытесняются новыми, прочитанными с диска. Подтвержденными данные становятся после того, как они (данные) легли на постоянное хранилище. Не в память.
Т.е. для работы с HANA вместо Ora (да или чего угодно остального не in-memory) мы все равно оставляем этот же самый механизм.
Ну, до тех пор, пока SAP не перепишет ВСЮ логику обработки на HANA
Т.е. ждем, когда сервера приложений станут нам не нужны. Правильно? А пока нам для HANA надо иметь памяти на аппликухе несколько больше, чем до того. И как бы не соотносительно с памятью для Appliance HANA. В противном случае будет непрерывный своп объектов на сервере приложений, что ну никак не ускоряет работу.

2. Кстати: у тех, кто ставит HANA, какая скорость сетки от аппликухи до HANA? Если не 10g, то...

3. А если на сервере приложений зафигачить столько же памяти, сколько надо для HANA? Оно не будет работать in-memory? Ась? Не забываем, что вся логика пока еще на стороне сервера приложений, не на стороне HANA

4. Скорость каравана определяется скоростью самого медленного верблюда. Это я по поводу коммита данных. Коммит считается завершенным, когда все измененные данные легли на хранилище. Отсюда вывод - база данных in-memory хороша на чтение. Хороша на совместное использование малоизменяемых данных. Для получения приемлемых скоростей на запись - надо ставить под журналы SSD. И чем больше возможные объемы записи, тем больше надо SSD. В идеале, конечно, всю базу надо класть на SSD. Но это уже не совсем гуманно с точки зрения цены.

5. Вытекает из четвертого пункта :)
Разницу в быстродействии между системами на HANA, Oracle in-memory, просто Oracle и пр. можно будет увидеть в случае оптимизации операций в памяти для конкретного приложения, например ERP или BW (причем это должна быть разная оптимизация, т.е. прощай универсальная база данных, или же в её цену войдут затраты на оптимизацию over дофига ненужных в конкретном месте продуктов). В случае отсутствия оптимизаций быстродействие будет отличаться весьма мало.

6. Кто-нибудь хочет посчитать размеры и цену HANA Appliance для базы ну, скажем в 100 Tb в размерности Oracle?

7. А что там у нас с теми, кто живет не на Intel x86 архитектуре?

Ну это так, навскидку ;) Не касаясь отсутствия внятной документации. Даже вендоры не сильно понимают что они поставляют в качестве HANA Appliance. Вопросы отказоустойчивости висят в воздухе. Вопросы установки песочниц (ну, это побочная проблема, но весьма важная) тоже висят...

Всё это мое IMHO, но пока я не вижу никаких плюсов от HANA. И в ближайшей перспективе - тоже.

_________________
Я бы хотел поглядеть на эффективную армию, состоящую из эффективных менеджеров.
BRGDS,
Aleks Изображение


Принять этот ответ
Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 161 ]  На страницу Пред.  1, 2, 3, 4, 5 ... 11  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB