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

Итак из известных фактов, сказанных официальными представителями iAnywhere:
1. Сервер останется таким же легким, однако обещают, что он сможет поддерживать и обрабатывать большие массивы данных (хотя для 9-ки уже давно на iAnywhere заявлено, что сотни гигов не проблемы, что подтверждается эксплуатацией). Соответствующе для этого обещают здорово поумнеть оптимизатор (куда уж умнее то), улучшить поддержку RAID.
2. Будут реализованы материализованные представления. Мат. представления - это представления, которые помимо запроса сразу хранят в БД предрасчитанные данные и имеют несколько способов их перерасчетов. Основным из удобств мат представлений является их скорость работы - для сложного аггрегированного запроса, захватывающего статические данные, гораздо выгоднее один раз рассчитать и сохранить результат и далее выборки проводить по этому результату. Сейчас мы это делаем ручками, создавая доп. таблички и триггера. Мат. представления это организовывают автоматически.
3. Будет поддержка HotFailOver из 3 машин, где третьий сервер является контроллером, все соединения через него идут к основному серверу, если он рушится, то они тут же перенаправляются на второй сервер, не понятно, если рушится второй сервер, будет ли третий так же держать горячую копию БД и станет ли он обслуживать клиентов. Так же не понятна лицензионная политика - придется ли покупать 3 лицензии на сервер или же это будет считаться одним сервером, как нужно рассматривать процессорную лицензию и т.д.
4. Будут существенно расширены визуальные утилиты, к примеру в редакторе кода появится intellisense, то есть выскакивающие автоподсказки в коде. Так же будет дальше продолжена работа по улучшению консультанта индексов.
5. Будет здорово расширен механизм MobiLink и сделаны специальные утилиты визуального управления репликациями.

Из известных слухов, так или иначе сказанных уважаемыми людьми и иногда намеками официальными представителей:
1. Будет реализован уровень изоляций Snapshot. В официальном заявлении об этом ничего сказано не было, однако многие их разработчики говорят об этом так уверено, как будто бы заявление было сделано. Лично я не представляю, как можно полноценно прикрутить этот уровень изоляций к серверу блокировочнику за пару лет, тот же MS потратил на это 5 лет и все равно сделал нашлепку. Единственная мысль - это скрестить snapshot с checkpoint log, который как известно хранит в конце БД оригинальные версии изменяемых страниц до того момента, как не будет подтверждена транзакция и проведена контрольная точка. Ну и надо думать, Snapshot нельзя назвать версионником, так как при этом уровне изоляции писатели не блокируют читателей, но замечательно блокируют других писателей. Фактически это срез оригинальной информации на момент ее чтения, тоже самое можно добиться, просто вынося информацию во времянки (что MSSQL 2005 можно сказать примерно и сделано). Такая реализация тормознутая и лично меня совершенно не устраивает. Вот если они смогут прикрутить к checkpoint log, тогда будет совершенно другое дело, так как оригинальные страницы в него пишутся по любому, так что в итоге даже при появлении snapshot скорость DML операторов осталась бы прежней.
2. Будет сделана поддержка триггеров "Instead of" (то есть "ВМЕСТО"). Такие триггера вызываются при DML операторах изменения данных и далее сервер ничего сам не меняет - это должен сделать вызванный триггер в своем коде. Очень удобно их вешать на сложные необновляемые представления, где в таком триггере можно самому описать, что делать, при изменении данных в представлении.
3. Jasper будет официально выпущен в конце 1 квартала 2006 года. Представители iAnywhere заявили это официально, но памятуя о 3-летней задержке MSSQL2005, я все таки это отношу к слухам.
4. Sybase упорно продолжает гнуть палку, что ASA это SMB&Mobile RDBMS. iAnywhere даже для 9-ки не забывает вставлять про "Enterprise calibre", судя по слухам 10-ку они будут официально называть Enterprise.

Пока все, будем писать сюда что нибудь новенькое, пока не увидим 10-ку.

sn1251По-моему во всех версионниках (Oracle/FB/Pg) писатели блокируют писателей. Или я не понял вашу трактовку. Извиняюсь за оффтоп.
Не правильно выразился. В версионниках отсутствует уровень serializable, который как известно может заблокировать писателей других строк. В итоге, если посчитать и записать на снапшоте к примеру остатки, то считать мы будет оригинальные версии, не видя, если кто то в этот момент изменяет значения в транзакциях и запишем в табличку неправильные цифры. При уровне сериализации этого никогда не случится (единственный уровень, который это гарантирует), однако начав считать остатки, мы скорей всего заблокируем других писателей - даже тех, кто не работает с диапазоном обрабатываемых нами записей.

sn1251Вот вопрос поинтереснее - не планируют ли они прикрутить WatcomSQL и оптимизатор ASA к ядру хранения ASE? А то сил уже моих нет с этим потомком трилобитов сражаться... :-(
Гм, разработчикам ASE при анонсировании ASE 15 и заявлений об улучшении работы оптимизатора был задан следующий вопрос: "Использовали ли Вы наработки оптимизатора ASA в новой версии ASE ?". Разработчики гордо ответили "Нет, мы самостоятельно дорабатывали и улучшали оптимизатор", чем честно говоря меня малость удивили - глупо не воспользоваться уже протестированными наработками коллег дочерней фирмы холдинга Sybase, когда тот же IQ 12.6 содрал большинство удачных решений ASA 9.0.2. Вообще, с учетом того, что ASE 15 теперь не поддерживает репликацию с ASA через ее родной SQLRemote, складывается впечатление, что дороги ASA/IQ и ASE разошлись - ASE претендует на рынок SMB своим бесплатным Express, конкурируя с ASA и рынок больших хранилищ данных, конкурируя с IQ. ASA в свою очередь с выходом 10-ки явно стремиться официально называться Enterprise, IQ наконец таки проснулся от застоя в развитии и активно наращивает функционал в сторону более полной совместимости с ASA. То же самое наблюдается и у других систем Sybase - к примеру ReplicationServer явный конкурент MobiLink ASA. На лицо явная конкуренция, кстати по Gartner, iAnywhere подняло на фоне доходов всего Sybase свой доход вдвое и теперь является одним из основных подразделений, приносящих доход:
автор
Although Sybase is trying to remake itself, its IPG and the DBMS products provide about 73
percent and 40 percent of its license revenue, respectively. Sybase's total license revenue growth
of one-half of a percent for 2004 is an improvement over the double-digit decline in previous
years, but it remains less than the DBMS growth achieved by Sybase's competitors. However,
Sybase's profits have increased steadily. Its cash position exceeds one year's revenue. Its total
revenue has also displayed strong growth, as well as quarter-over-quarter growth in IPG during
the past few quarters. Finally, iAnywhere has experienced double-digit growth and is becoming
one of Sybase's major divisions. The company's current strategy appears to be working. Gartner
believes that Sybase has turned a corner financially. Now, the company must continue to fuel this
growth.

Гартнер рекомендуют далее вливать финансовые потоки в iAnywhere, что и происходит, с учетом постоянных денежных вливаний, покупок перспективных патентовых разработок (к примеру под AnswerAnywhere) и поглошения готовых фирм с собственными продуктами и рынками клиентов (к примеру Extended Systems).

Так что нежелание ASE-разработчиков сотрудничать с iAnywhere - еще под вопросом кто в этом виноват - гордость разработчиков настоящей родной СУБД Sybase или же пальцегнутие дочерней независимой конторы iAnywhere, получающей от головной конторы большие средства на развития (тот же кемпинг им только в Канаде построили) и имеющие вполне естественное желание утопить конкурентов - вспомнить хотя бы реакцию разработчиков и пользователей ASA на ASE на их родных форумах, а так же недавнее предложение Брека переименовать Sybase Central в ASA Central или SQL Central, чтобы людей "не смущала приставка Sybase", плохо ассоциирующаяся у них с Sybase ASE.

Насчет будующего Sybase сюда прилагаю исследования от Gartner, одной из самых уважаемых аналитических контор, к прогнозам и выводам которой прислушиваются крупнейшие поставщики ПО и мнение которой считается почти де факто.

VovakaПо последней информации выход официального релиза отложен на полгода, т.е. перенесен на 4-ый квртал.
Жаль :(
А где почитать эту интересную инфу ?

pavelvp ASCRUSНе правильно выразился. В версионниках отсутствует уровень serializable, который как известно может заблокировать писателей других строк. В каких версионниках отсутствует serializable?
В любом чистом версионнике - в Oracle к примеру ... или IB/FB.

pavelvp В итоге, если посчитать и записать на снапшоте к примеру остатки, то считать мы будет оригинальные версии, не видя, если кто то в этот момент изменяет значения в транзакциях и запишем в табличку неправильные цифры. При уровне сериализации этого никогда не случится (единственный уровень, который это гарантирует), однако начав считать остатки, мы скорей всего заблокируем других писателей - даже тех, кто не работает с диапазоном обрабатываемых нами записей. Можешь этот обзац пояснить? Ничего не понял из того, что ты сказал про snapshot и serializable.
Обьясняю - уровень изоляции "снимок данных" позволит нам повторно считать же данные без видимости их изменений другими транзакциями и появления фантомов (то есть новых записей, подходящих под наше условие выполнение запроса и добавленных в ходе выполнения нашего запроса другими транзакциями). Однако ... такой способ не гарантирует, что эти данные актуальны для реального состояния БД, то есть snapshot в отличие от serializable будет работать с версиями (клонами) записей и во время работы нам не гарантируется, что другие транзакции не изменили или добавили обрабатываемые нами данные. Если не понятен пример с остатками, то можно привести другой пример - попробуйте на версионниках организовать ссылочную целостность без FK, посредством триггеров, чтобы сессия к примеру не могла вставить запись, ссылающуюся на удаляемую в этот момент другую запись или изменяемо каскадно ключ PK изменил FK у добавляемых на текущий момент новых записей в других транзакциях. На любом блокировочнике это делается на раз, причем на том же MSSQL, более старых версиях это был единственный способ организации каскадных операций, на версионниках это просто невозможно без блокировки всей таблицы с целью борьбы с фантомами, где понятное дело монопольный доступ не самый эффективный способ работы множества конкурирующих транзакций.

То же самое касается расчета остатков, балансов и прочего - то есть информации, которая состоит из множества входящей информации и должна фиксироваться на некие моменты времени с гарантией того, что на момент фиксации, входящие данные не смогут измениться существующие (в версионниках здесь есть поддержка в виде SELECT ... FOR UPDATE) и главное -добавиться (а вот здесь для борьбы с фантомами в версионниках на ум приходит только блокировка таблицы).

Отсюда резюме - serializable хорош для расчетов, snapshot хорош для отчетов. Отсутствие snapshot можно пережить (особенно когда есть времянки), за отсутствие serializable можно дорого поплатиться целостностью данных и неправильными данными, полученных в ходе расчетов и вычислений над входящей информацией.

pavelvp
Спорить не о чем - Оракл не имеет настоящего, соответствующего стандарту уровня сериализации транзакций, это уже обсасывалось в Сравнении СУБД не один раз. Вся проблема в том, что Вы видимо не до конца просто понимаете что такое serializable. Ну и высказывание насчет того, что на этом уровне блокируются все данные тоже не правильно - в FAQ лежит моя статья об уровнях изоляции в ASA и архитектуре блокировок, накладываемых сервером в различных случаях. Там как раз и рассказывается, что при serializable в запросе будут блокированы ровно те данные, которые попали под условия запроса (repeatable) и специальными блокировками позиций заблокированы на вставку только те записи других транзакций, что подходят под условия запроса (anti phantom), что достигается за счет использования блокировок на индексах.

P.S. В Оракле насколько я понимаю SELECT FOR UPDATE позволяет заблокировать от изменений прочитанные записи, то есть фактически эмулирует REPEATABLE.

pavelvpНе хочется снова сваливаться в дискуссию "блокировочник vs. версионник", однако... такая стратегия позволяет избавится от неповторяемого чтения и фантомов, но не может обеспечить "честную" полноценную сериализацию. Т.к. на момент старта транзакции условия наложения блокировок неизвестны, а к тому времени, когда станут известны, данные уже могли быть изменены и зафиксированы конкурирующей транзакцией...
Данные не могут быть изменены и зафиксированы другой транзакцией по причине того, что если она пытается изменить уже залоченные данные, то остановится до снятия блокировок, если текущая транзакция дойдет до изменяемых данных другой транзакцией, то она остановится, пока изменения не будут подтверждены.

pavelvpТы заблуждаешься. Для реализации repeatable read версионнику не нужны никакие блокировки. Достаточно знать время старта транзакции - и мы можем реализовать сколь угодно высокий уровень изоляции. И никаких блокировок.
Конечно нужны. Интересно знать, как это версионник может обеспечить сериализуемость выполнения всех действий транзакции, если на самом деле он и работает то не с живыми данными, а снимком и в этот момент другие сессии спокойно могут настоящие данные изменять. Тут можно задать такой вопрос "А зачем это в Оракл ввели SELECT FOR UPDATE или почему на форумах IB в некоторых случаях рекомендуют делать холостой UPDATE ?". Мое IMHO - не все так легко и просто у версионников, как они расписывают. Своего геммора не меньше, а отсутствие сериализации, которая частенько обязательно требуется при таких критических операциях, как расчет остатков, закрытие расчетного периода или опердня - вообще очевидный минус. Плюс у блокировочников очевидный плюс - это скорость работы - не нужно писать версии. Сделать SNAPSHOT я могу и ручками через времянки и правильным проектированием БД, а вот отключить лишние тормоза на запись у версионников не удастся.

P.S. Ладно, действительно завязываем. Для меня SNAPSHOT <> SERIALIZABLE, тут друг другу чего то доказывать бестолку :)

iLLer
Не могу не вмешаться и не поправить pavelvp, а то читающий народ и впрямь
будет думать, что "блокировочник"<->"версионник" это тоже самое что
"оптимист"<->"пессимист". Не нужно путать эти вещи. Оптимистичный - это
значит что СУБД совершает действия с данными в предположении, что их не
придется откатывать. И я четко могу сказать, что в АСА используется
оптимистичный механизм транзакций, а он (АСА) является как раз
блокировочником. Именно поэтому принятие транзакций идет гораздо быстрее,
чем откат, и это особенно ярко было выражено в ранних версиях АСА.
Угу, именно механизм CHECKPOINT LOG как раз и позволяет ASA работать в оптимистическом режиме и во вторых легко организовывать свой кэш записи без обращения к функциям ОС.

Yo.!! ASCRUS
Угу, именно механизм CHECKPOINT LOG как раз и позволяет ASA работать в оптимистическом режиме и во вторых легко организовывать свой кэш записи без обращения к функциям ОС.

ASCRUS, ну это скорее не оптимистический, а по@уестический режим, в котором были бы реализованы все известные фантомы которые появляются выше read commited и отсутсвует консистентное чтение ... это что-то типа буферизации фокспро, полезность такого режима весьма сомнительна ;)

ЗЫ. а чего вы тут прячитесь, приходите в сравнение, мы там уже соскучились по таким темам :)
Checkpoint log создан для кэширования записи и ведения отката после краха сервера - вкупе с журналом операций очень неплохое решение, дающее ASA возможность неплохо разгоняться на операциях записи. Никто и не говорит, что эта штука даст возможность прочитать оригинальные версии записей (хотя они на самом деле и присутствуют в БД в виде страниц внутри checkpoint log, пока транзакция не будет подтверждена и не проведена операция CHECKPOINT). Ну а насчет борьбы с фантомами на SERIALIZABLE без блокирования всех таблиц запроса - я уже писал в FAQ статью по блокировкам ASA, как это сделано - достаточно грамотно спроектировать БД, иметь необходимые индексы на борту и другие сессии, которые не пытаются влезть в заявленный запросом охват записей, будут себе спокойно работать, добавлять, изменять и удалять записи.

P.S. Гы - и ничего мы тут не прячемся, идет обсуждение новой ASA, хочется понять, а сдался ли нам SNAPSHOT и что мы на этом выиграем или потеряем. Я к примеру и без SNAPSHOT-а прекрасно живу, ничуть не ущемляя функциональности, зато не жертвуя скоростью. И если в ASA сделают SNAPSHOT, который начнет тормозить операции записи, то он на фиг не сдался, я и так Оракла насмотрелся, как он тормозит, пытаясь из себя одновременно изображать OLTP и OLAP, что то такого счастья не хочется

Yo.!!Ну надо сказать, что для чего нужен snapshot с его консистентным и неблокирущим чтением ИМХО вы блестяще показали в соседнем топике ;)

/topic/109801&pg=5#977105

ЗЫ. а тема serializble ИМХО раздута только потому, что mssqlный read commited (не знаю как с этим у ASA) не может гарантировать консистентное чтение, поэтому многие вынуждены сидеть на serializible, а реальная сериализация по большому счету никому и не нужна.
Ну у MSSQL много чего как не у всех - эксалация блокировок, траблы с кластерным ключом, отсутствие явного оператора блокировки таблицы, нелогируемых времянок, пиханье всего, что можно в TempDB, невозможнось получить новое значение инкремента без вставки записи и т.д. и т.п. Тут мне кажется, MSSQL не самый удачный сервер в качестве сравнения блокировочников и версионников, сильно много прикручено сзади и наоборот. К примеру, зачем в MSSQL 2005 прикрутили .NET вместо того, чтобы нормально расширить TSQL или же зачем версии записей хранить в TempDB - для меня загадка природы, не удивлюсь, если эта загадка имеет индуское происхождение. В общем как всегда MS жжет